《TCP链接的关闭及状态转换》

tcp链接的关闭方式

一、tcp的链接
TCP连接建立与关闭过程中的状态。TCP连接过程是状态的转换，促使状态发生转换的因素包括用户调用、特定数据包以及超时等，具体状态如下所示：
1、CLOSED：初始状态，表示没有任何连接。
2、LISTEN：Server端的某个Socket正在监听来自远方的TCP端口的连接请求。
3、SYN_SENT：发送连接请求后等待确认信息。当客户端Socket进行Connect连接时，会首先发送SYN包，随即进入SYN_SENT状态，然后等待Server端发送三次握手中的第2个包。
4、SYN_RECEIVED：收到一个连接请求后回送确认信息和对等的连接请求，然后等待确认信息。通常是建立TCP连接的三次握手过程中的一个中间状态，表示Server端的Socket接收到来自Client的SYN包，并作出回应。
5、ESTABLISHED：表示连接已经建立，可以进行数据传输。


二、tcp的断开
1、FIN_WAIT_1：主动关闭连接的一方等待对方返回ACK包。若Socket在ESTABLISHED状态下主动关闭连接并向对方发送FIN包（表示己方不再有数据需要发送），则进入FIN_WAIT_1状态，等待对方返回ACK包，此后还能读取数据，但不能发送数据。在正常情况下，无论对方处于何种状态，都应该马上返回ACK包，所以FIN_WAIT_1状态一般很难见到。


2、FIN_WAIT_2：主动关闭连接的一方收到对方返回的ACK包后，等待对方发送FIN包。处于FIN_WAIT_1状态下的Socket收到了对方返回的ACK包后，便进入FIN_WAIT_2状态。由于FIN_WAIT_2状态下的Socket需要等待对方发送的FIN包，所有常常可以看到。若在FIN_WAIT_1状态下收到对方发送的同时带有FIN和ACK的包时，则直接进入TIME_WAIT状态，无须经过FIN_WAIT_2状态。


3、TIME_WAIT：主动关闭连接的一方收到对方发送的FIN包后返回ACK包（表示对方也不再有数据需要发送，此后不能再读取或发送数据），然后等待足够长的时间（2MSL）以确保对方接收到ACK包（考虑到丢失ACK包的可能和迷路重复数据包的影响），最后回到CLOSED状态，释放网络资源。


4、CLOSE_WAIT：表示被动关闭连接的一方在等待关闭连接。当收到对方发送的FIN包后（表示对方不再有数据需要发送），相应的返回ACK包，然后进入CLOSE_WAIT状态。在该状态下，若己方还有数据未发送，则可以继续向对方进行发送，但不能再读取数据，直到数据发送完毕。


5、LAST_ACK：被动关闭连接的一方在CLOSE_WAIT状态下完成数据的发送后便可向对方发送FIN包（表示己方不再有数据需要发送），然后等待对方返回ACK包。收到ACK包后便回到CLOSED状态，释放网络资源。


6、CLOSING：比较罕见的例外状态。正常情况下，发送FIN包后应该先收到（或同时收到）对方的ACK包，再收到对方的FIN包，而CLOSING状态表示发送FIN包后并没有收到对方的ACK包，却已收到了对方的FIN包。有两种情况可能导致这种状态：其一，如果双方几乎在同时关闭连接，那么就可能出现双方同时发送FIN包的情况；其二，如果ACK包丢失而对方的FIN包很快发出，也会出现FIN先于ACK到达。


三、tcp链接的关闭方式
可以想象成两条链接
建立TCP连接需要三次握手，而关闭连接则需要四次握手，并且分为主动关闭和被动关闭。这是由于TCP连接是全双工的，我关了你的连接，并不等于你关了我的连接，因此双方都必须单独进行关闭。当一方完成它的数据发送任务后可以发送FIN包来终止这个方向的连接，表明自己不再有数据需要发送；收到FIN包的那一方虽然不能再读取数据，但仍能发送数据


1、Client向Server发送FIN包，表示Client主动关闭连接，然后进入FIN_WAIT_1状态，等待Server返回ACK包。此后Client不能再向Server发送数据，但能读取数据。


2、Server收到FIN包后向Client发送ACK包，然后进入CLOSE_WAIT状态，此后Server不能再读取数据，但可以继续向Client发送数据。Client收到Server返回的ACK包后进入FIN_WAIT_2状态，等待Server发送FIN包


3、Server完成数据的发送后，将FIN包发送给Client，然后进入LAST_ACK状态，等待Client返回ACK包，此后Server既不能读取数据，也不能发送数据。


4、Client收到FIN包后向Server发送ACK包，然后进入TIME_WAIT状态，接着等待足够长的时间（2MSL）以确保Server接收到ACK包，最后回到CLOSED状态，释放网络资源。Server收到Client返回的ACK包后便回到CLOSED状态，释放网络资源。


四、tcp关闭对server与client的影响

在详细了解TCP连接的状态和关闭方式后，我们会发现TIME_WAIT状态是一个坑爹的存在！主动关闭连接的一方在发送最后一个ACK包后，无论对方是否收到都会进入TIME_WAIT状态，等待2MSL的时间，然后才能释放网络资源。MSL就是Maximum Segment Lifetime（数据包的最大生命周期），是一个数据包能在互联网上生存的最长时间，若超过这个时间则该数据包将会消失在网络中。操作系统通常会将2MSL设为4分钟，最低不少于30秒，因而TIME_WAIT状态一般维持在30秒至4分钟。这个是TCP/IP协议必不可少的，是TCP/IP设计者设计的，也就是无法解决的

五、杂项

 建立链接请求:connect将完成三次握手，accept所监听的fd上，产生读事件，表示有新的链接请求；           
 关闭链接请求：close将完成四次挥手，如果有一方关闭sockfd，对方将感知到有读事件，如果read读取数据时，返回0，即读取到0个数据，表示有断开链接请求。(在操作系统中已经这么定义) 
 
 TIME_WAIT 是主动关闭 TCP 连接的那一方出现的状态，系统会在 TIME_WAIT 状态下等待 2MSL（maximum segment lifetime  ）后才能释放连接（端口）。通常约合 4 分钟以内。
 TIME_WAIT 状态等待 2MSL 的意义：确保连接可靠地关闭； 
 
 CLOSE_WAIT 是被动关闭 TCP 连接时产生的，如果收到另一端关闭连接的请求后，本地(Server端)不关闭相应套接字就会导致本地套接字进入这一状态。
 
 如果对方关闭了，没有收到关闭链接请求，就是下面的不正常情况)
 按TCP状态机，我方收到FIN，则由TCP实现发送ACK，因此进入CLOSE_WAIT状态。但如果我方不执行close()，就不能由CLOSE_WAIT迁移到LAST_ACK，则系统中会存在很多CLOSE_WAIT状态的连接。
 如果存在大量的 CLOSE_WAIT，则说明客户端并发量大，且服务器未能正常感知客户端的退出，也并未及时 close这些套接字。(如果不及时处理，将会出现没有可用的socket描述符的问题，原因是sockfd耗尽)。
 
 正常情况下:: 一方关闭sockfd，另外一方将会有读事件产生， 当recv数据时，如果返回值为0，表示对端已经关闭。此时我们应该调用close，将对应的sockfd也关闭掉。
 不正常情况下:: 一方关闭sockfd，另外一方并不知道，(比如在close时，自己断网了，对方就收不到发送的数据包)。此时，如果另外一方在对应的sockfd上写send或读recv数据。
 recv时，将会返回0，表示链接已经断开。
 send时， 将会产生错误，errno为ECONNRESET。
 
 TCP连接的回收：
/proc/sys/net/ipv4/tcp_max_tw_buckets     对应net.ipv4.tcp_max_tw_buckets
   该参数设置系统的TIME_WAIT的数量，如果超过默认值则会被立即清除。
/proc/sys/net/ipv4/tcp_tw_reuse           对应net.ipv4.tcp_tw_reuse
   该参数设置TIME_WAIT重用，可以让处于TIME_WAIT的连接用于新的tcp连接
 这两天服务器网络不稳定，结果发现了一个现象：一个TCP连接的服务端（windows）早已停止，而客户端（linux）的连接状态却一直保持为ESTABLISHED，直到第二天中午连接才断开。在网上搜一下，才知道TCP的相关设置：
#cat /proc/sys/net/ipv4/tcp_keepalive_time
7200
#cat /proc/sys/net/ipv4/tcp_keepalive_intvl
75
#cat /proc/sys/net/ipv4/tcp_keepalive_probes
9
意思是如果某个TCP连接在idle 7200秒（2个小时）后,内核才发起probe.如果probe 9次(每次75秒)不成功,内核才彻底放弃,认为该连接已失效。
 

2*9=18小时，这就是为什么前一天下午网络出问题，到第二天中午那个连接才显示关掉。   

六、keepalive

TCP协议中有长连接和短连接之分。短连接在数据包发送完成后就会自己断开，长连接在发包完毕后，会在一定的时间内保持连接，即我们通常所说的Keepalive（存活定时器）功能。
默认的Keepalive超时需要7,200,000 milliseconds，即2小时，探测次数为5次。它的功效和用户自己实现的心跳机制是一样的。开启Keepalive功能需要消耗额外的宽带和流量，尽管这微不足道，但在按流量计费的环境下增加了费用，另一方面，Keepalive设置不合理时可能会因为短暂的网络波动而断开健康的TCP连接。

keepalive并不是TCP规范的一部分。在Host Requirements RFC罗列有不使用它的三个理由：（1）在短暂的故障期间，它们可能引起一个良好连接（good connection）被释放（dropped），（2）它们消费了不必要的宽带，（3）在以数据包计费的互联网上它们（额外）花费金钱。然而，在许多的实现中提供了存活定时器。
keepalive工作原理：
若在一个给定连接上，两小时之内无任何活动，服务器便向客户端发送一个探测段。（我们将在下面的例子中看到探测段的样子。）客户端主机必须是下列四种状态之一：
1)客户端主机依旧活跃（up）运行，并且从服务器可到达。从客户端TCP的正常响应，服务器知道对方仍然活跃。服务器的TCP为接下来的两小时复位存活定时器，如果在这两个小时到期之前，连接上发生应用程序的通信，则定时器重新为往下的两小时复位，并且接着交换数据。
2)客户端已经崩溃，或者已经关闭（down），或者正在重启过程中。在这两种情况下，它的TCP都不会响应。服务器没有收到对其发出探测的响应，并且在75秒之后超时。服务器将总共发送10个这样的探测，每个探测75秒。如果没有收到一个响应，它就认为客户端主机已经关闭并终止连接。
3)客户端曾经崩溃，但已经重启。这种情况下，服务器将会收到对其存活探测的响应，但该响应是一个复位，从而引起服务器对连接的终止。
4)客户端主机活跃运行，但从服务器不可到达。这与状态2类似，因为TCP无法区别它们两个。它所能表明的仅是未收到对其探测的回复

Linux内核包含对keepalive的支持。其中使用了三个参数：tcp_keepalive_time（开启keepalive的闲置时 长）tcp_keepalive_intvl（keepalive探测包的发送间隔）和tcp_keepalive_probes（如果对方不予应答，探测包的发送次数）；在liunx中，keepalive是一个开关选项，可以通过函数来使能。具体地说，可以使用以下代码：
setsockopt(rs, SOL_SOCKET, SO_KEEPALIVE, (void *)&keepAlive, sizeof(keepAlive));