服务器的问题！为什么我的服务器一断开远程连接服务器上所运行的所有程序都结束了

一、限制断开会话存在时间

一般情况下，我们在维护远程服务器时，不可能长时间在线，但是系统默认的却是只要登录就不再断开。因此，我们可以修改这一默认设置，给他指定一个自动断开的时间即可。

在远程服务器上打开“运行”窗口，输入“tsccmsc”连接设置窗口。然后双击“连接”项右侧的“RDP-Tcp”，切换到“会话”标签，选中“替代用户设置”选项，再给“结束已断开的会话”设置一个合适的时间即可

二、增加连接数量

默认情况下允许远程终端连接的数量是2个用户，这也太少了一些，我们可以根据需要适当增加远程连接同时在线的用户。

打开“运行”窗口，输入“gpeditmsc”打开组策略编辑器窗口，依次选择“计算机配置”-“管理模板”-“Windows组件”-“终端服务”，再双击右侧的“限制连接数量”，将其TS允许的最大连接数设置大一些就可以了

这个问题以前遇到过!以上方法可行!

当然可以停止某个程序，不过你的PHP是由WEB服务器调用的，要停止WEB服务器才有效。

在WINDOWS系列服务器下，停止WEB服务器可以使用NET STOP命令，UNIX系统服务器可以调用APACHE的停止（HTTPD -K STOP），或者使用KILL进程。

补充：

你还是没有说服务器类型，我还是只有泛泛而谈了：上面说的用命令解释进行控制，这些命令是可以在PHP文件里面发出的，比如：

<php

system("apacgectl -k restart");

>

当然，最好的办法是编写无错的程序，或者设置较小的超时值，程序开头写下面语句:

set_time_limt(10);

通过session来判断。

session的结束方法主要有两种：

服务器自动清除没有活动的session，清除的时间限制就是通过setMaxInactiveInterval来设定的，一般tomcat的此默认时间值为20分钟；

调用session的invalidate方法，意思就是有意而为之。

第二点：必须纠正，关闭浏览器其实session并没有结束，他仅仅是失效了，因为再次打开浏览器又是新的session，这个旧session将再也不会被调用了，因此进入失效期，当时间达到setMaxInactiveInterval设定的时间值时被服务器结束。

主要特点：面向连接、面向字节流、全双工通信、通信可靠。

优缺点：

应用场景：要求通信数据可靠时，即 数据要准确无误地传递给对方。如：传输文件：HTTP、HTTPS、FTP等协议；传输邮件：POP、SMTP等协议

ps：首部的前 20 个字节固定，后面有 4n 字节根据需要增加。故 TCP首部最小长度 = 20字节（最大60个字节）。

TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。

重要字段：

客户端与服务器来回共发送三个TCP报文段来建立运输连接，三个TCP报文段分别为：

（1）客户端A向服务器B发送的TCP请求报段“SYN=1,seq=x”；

（2）服务器B向客户端A发送的TCP确认报文段“SYN=1,ACK=1,seq=y,ack=x+1”；

（3）客户端A向服务器B发送的TCP确认报文段“ACK=1,seq=x+1,ack=y+1”。

ps：在建立TCP连接之前，客户端和服务器都处于关闭状态（CLOSED）,直到客户端主动打开连接，服务器才被动打开连接（处于监听状态 = LISTEN）,等待客户端的请求。

TCP 协议是一个面向连接的、安全可靠的传输层协议，三次握手的机制是为了保证能建立一个安全可靠的连接。

通过上述三次握手， 双方确认自己与对方的发送与接收是正常的，就建立起一条TCP连接，即可传送应用层数据 。ps：因 TCP提供的是全双工通信，故通信双方的应用进程在任何时候都能发送数据；三次握手期间，任何1次未收到对面的回复，则都会重发。

为什么两次握手不行呢 ？

结论：防止服务器接收了 早已经失效的连接请求报文 ，服务器同意连接，从而一直等待客户端请求， 最终导致形成死锁、浪费资源 。

ps：SYN洪泛攻击：（具体见下文）

为什么不需要四次握手呢 ？

SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK确认序号标志消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。

如何来解决半连接攻击？

如何来解决全连接攻击？

请注意 ，现在 TCP 连接还没有释放掉。必须经过 时间等待计时器 设置的时间 2MSL（MSL：最长报文段寿命）后，客户端才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果服务器一收到 客户端的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，服务器结束 TCP 连接的时间要早于客户端。

TCP是全双工的连接，必须两端同时关闭连接，连接才算真正关闭。 简言之，客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器才会发送 FIN 连接释放报文，对方确认后就完全关闭了TCP连接。

举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。

ps：设想这样一个情景： 客户端已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。 显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用 TCP的保活计时器 。基本原理：

tcp11种状态及变迁其实基本包含在正常的三次握手和四次挥手中，除开CLOSING。

正常的三次握手包括4中状态变迁：

服务器打开监听(LISTEN)->客户端先发起SYN主动连接标识->服务器回复SYN及ACK确认->客户端再确认即三次握手TCP连接成功。这里边涉及四种状态及变迁：

正常的四次握手包含6种tcp状态变迁，如主动发起关闭方为客户端：

客户端发送FIN进入FIN_WAIT1 -> 服务器发送ACK确认并进入CLOSE_WAIT(被动关闭)状态->客户端收到ACK确认后进入FIN_WAIT2状态 -> 服务器再发送FIN进入LAST_ACK状态 -> 客户端收到服务器的FIN后发送ACK确认进入TIME_WAIT状态 -> 服务器收到ACK确认后进入CLOSED状态断开连接 -> 客户端在等待2MSL的时间如果期间没有收到服务器的相关包，则进入CLOSED状态断开连接。

CLOSING状态 ：连接断开期间，一般是客户端发送一个FIN，然后服务器回复一个ACK，然后服务器发送完数据后再回复一个FIN，当客户端和服务器同时接受到FIN时，客户端和服务器处于CLOSING状态，也就是此时双方都正在关闭同一个连接。

在进入CLOSING状态后，只要收到了对方对自己发送的FIN的ACK，收到FIN的ACK确认就进入TIME_WAIT状态，因此，如果RTT(Round Trip Time TCP包的往返延时)处在一个可接受的范围内，发出的FIN会很快被ACK从而进入到TIME_WAIT状态，CLOSING状态持续的时间就特别短，因此很难看到这种状态。

我们知道网络层，可以实现两个主机之间的通信。但是这并不具体，因为，真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机， 但是并没有交付给主机的具体应用进程 。而 端到端的通信才应该是应用进程之间的通信 。

应用场景 ：UDP协议比TCP协议的效率更高，TCP协议比UDP协议更加安全可靠。

下面主要对 数据传输出现错误/无应答/堵塞/超时/重复 等问题。

注意：TCP丢包：TCP是基于不可靠的网路实现可靠传输，肯定会存在丢包问题。如果在通信过程中，发现缺少数据或者丢包，那边么 最大的可能性是程序发送过程或者接受过程中出现问题。

总结：为了满足TCP协议不丢包，即保证可靠传输，规定如下：

注意：TCP丢包有三方面的原因，一是网络的传输质量不好，二是安全策略，三是服务器性能瓶颈

先理解2个基础概念：发送窗口、接收窗口

工作原理：

注意点：

关于滑动窗口的知识点：

滑动窗口中的数据类型：

ARQ解决的问题：出现差错时，让发送方重传差错数据：即 出错重传

类型：

流量控制和拥塞控制解决的问题：当接收方来不及接收收到的数据时，可通知发送方降低发送数据的效率：即 速度匹配

流量控制 ：

注意：

拥塞控制 ：

慢开始与拥塞避免 ：

快重传和快恢复 ：

补充：流量控制和拥塞控制的区别

什么情况造成TCP粘包和拆包？

解决TCP粘包和拆包的方法：

传输层无法保证数据的可靠传输 ，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。

最简单的方式是在应用层模仿传输层TCP的可靠性传输。 下面不考虑拥塞处理，可靠UDP的简单设计。

https://wwwjianshucom/p/65605622234b

http://wwwopen-opencom/lib/view/open1517213611158html

https://blogcsdnnet/dangzhangjing97/article/details/81008836

https://blogcsdnnet/qq_30108237/article/details/107057946

https://wwwjianshucom/p/6c73a4585eba