之前自己学习的网络都是浅尝辄止,最近被人反复问起 TCP 相关的挥手问题的相关问题,有必要整理下自身所学,以提供自己和别人查阅。


下图是 TCP 挥手的一个完整流程,这里引用了 tcpipguide 的流程图,更加直观的了解下挥手过程。




首先不要被这里的图给迷惑了,因为连接的主动断开是可以发生在客户端,也同样可以发生在服务端。


FIN_WAIT1

由图可知,当一方接受到来自应用断开连接的信号时候,就发送 FIN 数据报来进行主动断开,并且该连接进入 FIN_WAIT1 状态,连接处于半段开状态(可以接受、应答数据,当不能发送数据),并将连接的控制权托管给 Kernel,程序就不再进行处理。一般情况下,连接处理 FIN_WAIT1 的状态只是持续很短的一段时间。


我这里通过对数据包的拦截(不对 FIN 请求进行应答)来实现 FIN_WAIT1 状态,下图是主动断开一遍的 FIN 数据发送抓包记录。




在 18:12.43 的时间点,这台机器主动断开连接,并发送 FIN 请求,并且达到 RTO 后未收到响应后,一共重试了9次,每次重试时间是上一次的2倍,这条连接额外占用了 54 秒的时间。如果在服务中,这类连接数据一多就会消耗大量的服务器资源,我这里简单的提供 2 个参数来处理这个问题。


tcp_orphan_retries :Integer,这里系统参数默认为 9(文档里面默认值为7,和系统配置有关),就是近端丢弃 TCP 连接的时候,重试次数,在我的系统中。在刚刚那种情况,如果将该参数调整为 3 次,这类连接在系统中存活的时间就会大大减少,从而缓解这个问题。如果你的系统负载很大,有发现是因为 FIN_WAIT1 引起的,也可以适当的调整这个参数。


tcp_max_orphans:Integer,默认值 8096。系统所能处理不属于任何进程的 TCP sockets 最大数量。当超过这个值所有不属于任何进程的 TCP 连接(孤儿连接)都会被重置。这个参数仅仅是为了防御简单的 Dos ,不能依赖这个参数。


FIN_WAIT2

当主动断开一端的 FIN 请求发送出去后,并且成功够接受到相应的 ACK 请求后,就进入了 FIN_WAIT2 状态。其实 FIN_WAIT1 和 FIN_WAIT2 状态都是在等待对方的 FIN 数据报。当 TCP 一直保持这个状态的时候,对方就有可能永远都不断开连接,导致该连接一直保持着。


tcp_fin_timeout :Integer,默认 60,单位秒,不属于任何应用的孤儿连接保持 FIN_WAIT2 状态的最长时间,一当超过这个时间,就会被本地直接关闭,不会进入 TIME_WAIT 状态。 

但是总体上来将处于 FIN_WAIT2 状态的 TCP 连接,威胁要比 FIN_WAIT1 的小,占用的资源也很小,通常不会有什么问题。


TIME_WAIT

当前面的步骤都顺利完成了,并且接受到了 被动关闭端 发送过来的 FIN 数据报后,系统做出 ACK 应答后,该连接就进入了尾声,也就是 TIME_WAIT 状态。内核会设定一个时间长度为 2MSL 的定时器,当定时器在到时间点后,内核就会将该连接关闭。反之,当连接尚未关闭的时候,又收到了对方发送过来的 FIN 请求(可能是我们发送出去的请求对方并未收到),或者收到 ICMP 请求(比如 ACK 数据报,在网络传输中出现了错误),该连接就会重新发送 ACK 请求,并重置定时器。


为什么要设置时间为 2MSL?

MSL 是Maximum Segment Lifetime,译为“报文最大生存时间”,任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。


等待 2MSL 时间主要目的是怕最后一个 ACK 对方没收到,那么对方在超时后将重发第三次握手的 FIN ,主动关闭端接到重发的 FIN 包后,系统收到该分组后,可以再发一个 ACK 应答包。还有就是等来该连接在网络上的所有报文都传输完毕,所以处于 TIME_WAIT 状态时候,两端的端口都是不可用的,迟到的报文都会被废弃。


如果我们设置的时间少于 2MSL ,旧的连接刚刚关闭,这个时候有同样五元组的新连接进来了,而之前的连接还有残留报文在网络上,就会干扰新的连接的使用。


反之,如果连接处于 TIME_WAIT 过长,造成新 socket 无法复用这个端口,即使这个连接完全废弃(通常来说一个端口释放后会等待两分钟之后才能再被使用)。就像拉完屎还占着茅坑,可以尝试使用下SO_REUSEADDR(socket 参数),比如在服务停止后立即重启,这个时候可能会遇到原先的连接还处于 TIME_WAIT 状态,导致无法绑定原先的端口,就可以使用 SO_REUSEADDR。


tcp_timestamps: Boolean,默认1,表示tcp通讯的时候是否是否使用时间戳。如下图,在 TCP 头部信息的扩展头部字段中就附带了时间戳,数据长度为两个4字节。TSval是该数据报发送出来的时间,TSecr是回显时间戳(即该ack对应的data或者该data对应的上次 ack 中的 TSval 值)




tcp_tw_reuse:Boolean,默认0,只在客户端有效,就是 TCP TIME_WAIT 链路复用。比如,当客户端不断向服务端建立连接获取数据,当每次都是客户端自己关闭连接,导致服务端进入 TIME_WAIT,之后客户端又要不断重连对方继续拉取数据,这个时候就可以复用 TIME_WAIT 的连接。当连接复用后势必会有旧连接残留在网络上的数据报,那么这些数据报要怎么处理,才能不影响新的连接的使用呢。可以使用上面的参数,时间戳来判断,建立建立后将缓存的时间戳更新到现在,当早于这个时间戳的数据报进来就表明是老连接的数据,内核会直接废弃掉。


tcp_tw_recycle:Boolean,默认0,启动后能够更快地回收 TIME_WAIT 套接字。不再是2MSL,而是几个 RTO 内进行回收。所以在网络上同样会残存旧连接的数据报,内核同样可以通过时间戳的方式来判断、丢弃过时数据报。


在早期的网络通信中,开启这个参数会导致一个问题。当多个客户端通过NAT方式联网同时与服务端通信,对于服务端只收到一个IP就好像是一台客户端进行与其进行通讯,但是客户端之间会有时间戳差异,就会导致服务端会将认为过期的数据报丢弃。导致只允许一个客户端与其进行通讯。现在的 NAT 服务器已经将协议升级成了NAPT,可以采用多端口与服务端通讯就可以避免这件事情。


CLOSE_WAIT

当被动关闭端,也就是图中的服务端,接受到了对方发送过来的 FIN 请求,并且对请求做出应答后,该连接就进入了 CLOSE_WAIT ,当连接处于这个状态的时候,该连接可能有数据需要发送,或者一些其他事情要做,当这类连接过多的时候,就会导致网络性能下降,耗尽连接数,无法建立新的连接。


比如连接一直没得到释放,相应的资源一直被占用,一但达到句柄数的上限( linux 可以通过 ulimit -a 查看 open files 数值,默认1024 )后,新的请求就无法继续处理,就会返回大量的 Too Many Open Files 错误。


常见错误原因

1.代码层面上未对连接进行关闭,比如关闭代码未写在 finally 块关闭,如果程序中发生异常就会跳过关闭代码,自然未发出指令关闭,连接一直由程序托管,内核也无权处理,自然不会发出 FIN 请求,导致连接一直在 CLOSE_WAIT 。


2.程序响应过慢,比如双方进行通讯,当客户端请求服务端迟迟得不到响应,就断开连接,重新发起请求,导致服务端一直忙于业务处理,没空去关闭连接。这种情况也会导致这个问题。


缓解方案

1.修改 /etc/security/limits.conf 配置文件中参数,提高句柄数上限 

2.修改 tcp 参数


参数名 默认值 优化值 说明

net.ipv4.tcp_keepalive_time 7200 1800 单位秒,默认为7200s,就是说一个异常的CLOSE_WAIT连接至少会维持2个小时

net.ipv4.tcp_keepalive_probes 9 3 在认定TCP连接失效之前,最多发送多少个keepalive探测消息。

tcp_keepalive_intvl 75 15 探测消息未获得响应时,重发该消息的间隔时间(秒)。

3.检查自己的代码,修改连接不规范的地方。


LAST_ACK

当被动关闭一段,发送出去了 FIN 数据报后,套接字就进入了 LAST_ACK 状态,并且等待对方进行发送 ACK 数据报。


1.收到了响应的ACK数据报后,连接进入CLOSED 状态,并释放相关资源 

2.如果超时未收到响应,就触发了TCP的重传机制。


到此整个挥手流程就结束了。

相关文档

https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt





补充

服务器保持了大量的close_wait状态

time_wait问题可以通过调整内核参数和适当的设置web服务器的keep-Alive值来解决。因为time_wait是自己可控的,要么就是对方连接的异常,要么就是自己没有快速的回收资源,总之不是由于自己程序错误引起的。但是close_wait就不一样了,从上图中我们可以看到服务器保持大量的close_wait只有一种情况,那就是对方发送一个FIN后,程序自己这边没有进一步发送ACK以确认。换句话说就是在对方关闭连接后,程序里没有检测到,或者程序里本身就已经忘了这个时候需要关闭连接,于是这个资源就一直被程序占用着。这个时候快速的解决方法是:

  • 关闭正在运行的程序,这个需要视业务情况而定

  • 尽快的修改程序里的bug,然后测试提交到线上服务器


rd写了爬虫运行在采集服务器A上,程序去B服务器上采集资源,但是A服务器很快就发现出现了大量的close_wait状态的连接。后来检查才发现这些处于close_wait状态的请求结果都是404,那就说明B服务器上没有要请求的资源。


服务器A是一台爬虫服务器,它使用简单的HttpClient去请求资源服务B获取文件资源,正常情况下,如果请求成功,那么在抓取完 资源后,服务器A会主动发出关闭连接的请求,这个时候就是主动关闭连接,服务器A的连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢?假设 请求的资源服务器B上并不存在,那么这个时候就会由服务器B发出关闭连接的请求,服务器A就是被动的关闭了连接,如果服务器A被动关闭连接之后程序员忘了 让HttpClient释放连接,那就会造成CLOSE_WAIT的状态了


可能的原因如下:

关闭socket不及时:例如I/O线程被意外阻塞,或者I/O线程执行的用户自定义Task比例过高,导致I/O操作处理不及时,链路不能被及时释放

CLOSE_WAIT问题排查

  1. 程序Bug,接收到FIN信号后没有及时关闭socket,这可能是netty的bug,也可能是业务层bug

  2. 关闭socket不及时:例如I/O线程被意外阻塞,或者I/O线程执行的用户自定义task比例过高,导致I/O操作处理不及时,链路不能被及时释放