织梦绑定网站出现错误网站开发脚本解析器
文章目录
- 原因 1
- 原因 2
- 遗留问题
- 问题 1
- 问题 2
- 为什么 TIME_WAIT 状态的持续时长是 2MSL？
主动关闭 TCP 连接的一方才有 TIME_WAIT 状态
需要 TIME_WAIT 状态，主要有两方面原因：
- 防止历史连接的报文(延迟的重传报文)被后面相同四元组的连接错误接收
- 保证「被动关闭连接」的一方，能收到对方的 ACK，也就是第四次挥手报文，正常关闭连接
原因 1
TIME_WAIT 状态持续时长 2MSL，这个时间足以让两个方向上的报文都被丢弃，使得原来连接的报文在网络中都自然消失，再出现的报文一定都是新建立的连接所产生的
原因 2
被动关闭连接的一方收到 RST 报文后，将其解释为一个错误(Connection reset by peer)，这对于一个可靠的协议来说不是一种优雅的终止方式
遗留问题
RFC 1122 4.2.3.1(P96) 规定，RTO_MAX 应该小于等于 2MSL
The recommended upper and lower bounds on the RTO are known to be inadequate on large internets. The lower bound SHOULD be measured in fractions of a second (to accommodate high speed LANs) and the upper bound should be 2*MSL, i.e., 240 seconds.
问题 1
Linux 实现中，RTO_MAX > 2MSL
/* Linux Kernel 6.14.7 tcp.h */
#define TCP_RTO_MAX ((unsigned)(120*HZ))
#define TCP_FIN_TIMEOUT TCP_TIMEWAIT_LEN/* BSD style FIN_WAIT2 deadlock breaker.* It used to be 3min, new value is 60sec,* to combine FIN-WAIT-2 timeout with* TIME-WAIT timer.*/
假设一种情况，TCP 第四次挥手报文一直丢失，那么就需要反复重传(受 tcp_orphan_retries 限制)第三次挥手报文，如果其中某一次的重传报文需要等待 120s 才被发送出去，但此时对方早已退出 TIME_WAIT 处于 CLOSED 状态，与原因 1 相违背
问题 2
如果 RTO_MAX 范围是 (MSL, 2MSL]，假设一种情况，TCP 第四次挥手报文一直丢失，那么就需要反复重传(受 tcp_orphan_retries 限制)第三次挥手报文，如果其中某一次的重传报文需要等待 RTO_MAX(1.01MSL) 才被发送出去，刚好此次重传报文在网络中经过 MSL 时间才到达对端，但此时对方早已退出 TIME_WAIT 处于 CLOSED 状态，与原因 1 相违背
希望有大佬看到后帮忙解答
希望有大佬看到后帮忙解答
希望有大佬看到后帮忙解答
为什么 TIME_WAIT 状态的持续时长是 2MSL？
为什么 TIME_WAIT 状态的持续时长是 2MSL？