【谈谈TCP中timewait状态】

参考资料：

1. https://xiaolincoding.com/network/3_tcp/time_wait_recv_syn.html#%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90
2. https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux
   
   
   
   

三次握手四次握手流程图

1. timewait状态会做什么？

1. 等待2个MSL时间后释放连接
2. 如果等待期间收到对方的数据包，则重置定时器继续等待
3. 不允许在同样的四元组上建立tcp连接
   
   

2. timewait状态为什么要这样做？

1. 对端在发出FIN包进入LAST_ACK状态后，需要得到ack才能真正地释放连接。也就是说，对端的连接释放依赖本端的ACK。
2. 假设本端在timewait状态不等待直接释放连接。若回复的ACK丢包了，即使对端的FIN包未能得到ACK触发超时重传，最终也还是无法得到ACK，导致无法释放连接。
3. 按照定义，MSL是数据在网络中存活的最大时间。
4. 2个MSL能保证：a) 不会遗漏对端可能的重传FIN包；b) 旧连接中的飞行中的消息会超过生命周期消失，不会被后续新连接收到
   
   

3. 什么情况下会出现大量timewait连接？

1. 核心：timewait状态只会出现在主动发起关闭方。
2. 程序产生了大量的短连接
3. 程序异常地关闭了连接
   
   

4. 大量timewait连接会导致什么问题？

1. 假设对端的ip和端口不变，本端ip不变。本端多次主动关闭连接，也就会有timewait连接，此时若想再在本端和对端之间建立连接，就需要更换本端的端口。如此下来，本地的端口很快被用完，最后无法发起连接。
2. timewait连接占用系统资源 ---- 其实timewait资源占用很小，可以忽略；
   
   

5. 怎么解决大量timewait连接？

1. 检查代码是否写得有问题，是否异常关闭了连接？
2. 考虑长连接复用
3. 修改内核参数使得timewait连接得以复用 ---- 不推荐
   
   

6. 怎么修改内核参数来复用timewait连接？

有两个内核参数可以修改，具体怎么修改本文不展开。

1. tcp_tw_reuse
2. tcp_tw_recycle ---- 高版本的linux中已经deprecated
3. 开启上述任一个，都需要开启tcp时间戳选项

注意到默认配置中都是关闭的，为什么默认关闭肯定是有它的原因的

7. 为什么我不推荐改内核参数？

1. tcp_tw_reuse：
   • 这个设置只在outboundConnection中生效。
   • outboundConnection是指，本方对于该四元组有一个timewait连接，本方可以在这个四元组上发起新的连接。
2. tcp_tw_recycle
   • 在outboundConnection和inboundConnection中都生效。
   • inboundConnection是指，本方对于该四元组有一个timewait连接，本方可以在该四元组上接收新的连接。
   • 致命问题：
     • 设置 tcp_tw_recycle和时间戳选项，就会开启一种叫 per-host 的 PAWS(protection against wrapped seq) 机制：即对「对端 IP 」做 PAWS 检查，而非对「IP + 端口」四元组做 PAWS 检查。
     • 如果客户端网络环境是用了 NAT 网关，那么同个NAT网关下的客户端，都会是相同的 IP 地址。在服务端看来，就好像只是在跟一个客户端打交道一样，无法区分出来。
     • 一个例子：当客户端 A 通过 NAT 网关和服务器建立 TCP 连接，然后服务器主动关闭并且快速回收 TIME-WAIT 状态的连接后，客户端 B 也通过 NAT 网关和服务器建立 TCP 连接，注意客户端 A 和 客户端 B 因为经过相同的 NAT 网关，所以是用相同的 IP 地址与服务端建立 TCP 连接，如果客户端 B 的 timestamp 比 客户端 A 的 timestamp 小，那么由于服务端的 per-host 的 PAWS 机制的作用，服务端就会丢弃客户端主机 B 发来的 SYN 包，客户端B无法跟服务器进行通信。注：tcp报文中的timestamp字段 是根据客户端各自的 CPU tick 得出的值。
3. 宏观上来说：
   • timewait状态只会阻拦同个四元组{sever_ip, sever_port, client_ip, client_port}，不同四元组是完全独立无影响的。即在服务器看来，不同ip的客户端的大量timewait连接彼此是完全不影响的。
   • timewait状态只会阻拦发起请求，但一般不会阻拦接收请求。再具体一点，客户端主动关闭连接导致大量timewait连接，后续无法访问服务端；服务端主动关闭连接导致大量timewait连接，客户端可能仍然能访问服务端。
     • 既然timewait状态一般不会阻拦接收请求，而tcp_tw_recycle还带来缺陷，为什么要改呢？
     • 虽然timewait状态会阻拦发起请求，但问题更多的是在，你开启大量的短连接把自己的端口都给用光了。即{peer_ip, peer_port, local_ip, local_port}中所有local_port都用光了，任何一个四元组都变为了timewait，那么为什么不使用长连接呢？
   • 出现大量timewait连接一般都是程序自身写得有问题，跟网络，内核参数没啥关系
     
     

8. 讲讲tcp_tw_reuse是如何实现timewait连接的outbound复用

1. 这里重点关注时间戳和PAWS特性
2. 如果左方在LAST_ACK状态下，未收到ACK(图片所示)：
   • 右方在timewait状态下发出SYN后，变为SYN-SENT状态。对于右方而言，发出的SYN是新连接的初始消息，在该SYN的时间戳之前的消息都无效，这意味着LAST_ACK状态的左方发来的FIN会因为timestamp过期而丢弃。
   • 左方收到SYN，会回复challenge ack，即上一条连接中的最后的ack序号，只是多带了fin字段
   • 右方发现第二次握手对应不上
     • 大概率序号对应不上，此时右方发送RST重置左方的连接，后续就可以发起SYN建立连接；
     • 如果序号对上了，但回复的报文没有SYN字段。按照我看到的源码(文件tcp_input.c，函数tcp_rcv_synsent_state_process)，右方会放弃。
3. 如果左方在LAST_ACK状态下收到了ACK，那么会释放连接，后续表现就是正常的三次握手。
   
   

9. 为什么服务端的timewait状态一般不会阻拦接收客户端的请求？

1. 注意到timewait状态只存在于发起关闭方。既然服务端在timewait状态，那么客户端只能是这两种状态，LAST_ACK状态或连接已回收。
2. 如果连接已回收(一般也是这个状态)，客户端能在同个四元组上发起syn请求。
3. 服务端中的同个四元组上的timewait连接收到SYN是能快速重建的
   • 收到合法的SYN ---- 立即重建
     

• 收到非法的SYN -> challenge ack -> RST，而后再发起SYN

补充：

• 客户端建立新连接发出的syn的时间戳，必定是会比旧连接中发出的任何数据包（比如重传的fin)要大的。
• 现在一般都会开启tcp的时间戳特性，也就有PAWS检查。服务端通过客户端的syn报文的时间戳执行检查，就能将之前的旧连接的数据包过滤去掉(因为它们的时间戳更早)。