linux网络编程实践：关闭链接存在的问题 TIME_WAIT的2MSL等待

Posted 2021-09-15 BBinChina

问题描述：

主动关闭socket的一方在time_wait需要等待2MSL（默认2分钟）

原因分析：

可以看到主动关闭的客户端在最后一个TIME_WAIT时，客户端跟服务端实际上已经做了关闭socket的动作（中断上层应用 对send 或recv时抛出 socket error）。

当服务端发送FIN时，表示已经进行close socket，并进入LAST_ACK状态，在这个状态下，服务端TCP会在2TTL（一去一回）时间内检测是否触发重传机制
客户端对FIN 进行ack，这个时候进入TIME_WAIT来处理 服务端可能触发的重传FIN（为什么说可能，是因为客户端有可能ack了，而服务端因为超时等原因进行了重发），为了陪玩，客户端牺牲了2MSL时间

服务端在LAST_ACK重传的次数超过 tcp_orphan_retries 内核参数设置的次数，就会放弃重传，然后进入close状态。

tcp_orphan_retries 内核参数的默认值是 0

总结下：
TIME_WAIT存在的意义主要有两点：

维护连接状态，使TCP连接能够可靠地关闭。如果连接主动关闭端发送的最后一条ACK丢失，连接被动关闭端会重传FIN报文。因此，主动关闭方必须维持连接状态，以支持收到重传的FIN后再次发送ACK。如果没有TIME_WAIT，并且最后一个ACK丢失，那么此时被动关闭端还会处于LAST_ACK一段时间，并等待重传；如果此时主动关闭方又立即创建新TCP连接且恰好使用了相同的四元组，连接会创建失败，会被对端重置。
等待网络中所有此连接老的重复的、走失的报文消亡，避免此类报文对新的相同四元组的TCP连接造成干扰，因为这些报文的序号可能恰好落在新连接的接收窗口内。

解决方案：

实际上，只有当新的TCP连接和老的TCP连接四元组完全一致，且老的迷走的报文序号落在新连接的接收窗口内时，才会造成干扰。为了使用TIME_WAIT状态的端口，现在大部分系统的实现都做了相关改进与扩展：

新连接SYN告知的初始序列号，要求一定要比TIME_WAIT状态老连接的序列号大，可以一定程度保证不会与老连接的报文序列号重叠。
开启TCP timestamps扩展选项后，新连接的时间戳要求一定要比TIME_WAIT状态老连接的时间戳大，可以保证老连接的报文不会影响新连接。
因此，在开启了TCP timestamps扩展选项的情况下（net.ipv4.tcp_timestamps = 1），可以放心的设置SO_REUSEADDR选项，支持程序快速重启。

注意不要与net.ipv4.tcp_tw_reuse系统参数混淆，该参数仅在客户端调用connect创建连接时才生效，可以使用TIME_WAIT状态超过1秒的端口（防止最后一个ACK丢失）；而SO_REUSEADDR是在bind端口时生效，一般用于服务端监听时，可以使用本地非LISTEN状态的端口（另一个端口也必须设置SO_REUSEADDR），不仅仅是TIME_WAIT状态端口。