参考资料:
- https://xiaolincoding.com/network/3_tcp/time_wait_recv_syn.html#%E6%BA%90%E7%A0%81%E5%88%86%E6%9E%90
- https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux
三次握手四次握手流程图
1. timewait状态会做什么?
- 等待2个MSL时间后释放连接
- 如果等待期间收到对方的数据包,则重置定时器继续等待
- 不允许在同样的四元组上建立tcp连接
2. timewait状态为什么要这样做?
- 对端在发出FIN包进入LAST_ACK状态后,需要得到ack才能真正地释放连接。也就是说,对端的连接释放依赖本端的ACK。
- 假设本端在timewait状态不等待直接释放连接。若回复的ACK丢包了,即使对端的FIN包未能得到ACK触发超时重传,最终也还是无法得到ACK,导致无法释放连接。
- 按照定义,MSL是数据在网络中存活的最大时间。
- 2个MSL能保证:a) 不会遗漏对端可能的重传FIN包;b) 旧连接中的飞行中的消息会超过生命周期消失,不会被后续新连接收到
3. 什么情况下会出现大量timewait连接?
- 核心:timewait状态只会出现在主动发起关闭方。
- 程序产生了大量的短连接
- 程序异常地关闭了连接
4. 大量timewait连接会导致什么问题?
- 假设对端的ip和端口不变,本端ip不变。本端多次主动关闭连接,也就会有timewait连接,此时若想再在本端和对端之间建立连接,就需要更换本端的端口。如此下来,本地的端口很快被用完,最后无法发起连接。
- timewait连接占用系统资源 ---- 其实timewait资源占用很小,可以忽略;
5. 怎么解决大量timewait连接?
- 检查代码是否写得有问题,是否异常关闭了连接?
- 考虑长连接复用
- 修改内核参数使得timewait连接得以复用 ---- 不推荐
6. 怎么修改内核参数来复用timewait连接?
有两个内核参数可以修改,具体怎么修改本文不展开。
- tcp_tw_reuse
- tcp_tw_recycle ---- 高版本的linux中已经deprecated
- 开启上述任一个,都需要开启tcp时间戳选项
注意到默认配置中都是关闭的,为什么默认关闭肯定是有它的原因的
7. 为什么我不推荐改内核参数?
- tcp_tw_reuse:
- 这个设置只在outboundConnection中生效。
- outboundConnection是指,本方对于该四元组有一个timewait连接,本方可以在这个四元组上发起新的连接。
- 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 得出的值。
- 宏观上来说:
- 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复用
- 这里重点关注时间戳和PAWS特性
- 如果左方在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),右方会放弃。
- 如果左方在LAST_ACK状态下收到了ACK,那么会释放连接,后续表现就是正常的三次握手。
9. 为什么服务端的timewait状态一般不会阻拦接收客户端的请求?
- 注意到timewait状态只存在于发起关闭方。既然服务端在timewait状态,那么客户端只能是这两种状态,LAST_ACK状态或连接已回收。
- 如果连接已回收(一般也是这个状态),客户端能在同个四元组上发起syn请求。
- 服务端中的同个四元组上的timewait连接收到SYN是能快速重建的
- 收到合法的SYN ---- 立即重建
- 收到合法的SYN ---- 立即重建
- 收到非法的SYN -> challenge ack -> RST,而后再发起SYN
补充:
- 客户端建立新连接发出的syn的时间戳,必定是会比旧连接中发出的任何数据包(比如重传的fin)要大的。
- 现在一般都会开启tcp的时间戳特性,也就有PAWS检查。服务端通过客户端的syn报文的时间戳执行检查,就能将之前的旧连接的数据包过滤去掉(因为它们的时间戳更早)。