首页
学习
活动
专区
工具
TVP
发布
您找到你想要的搜索结果了吗?
是的
没有找到

详述 TCP 的 TIME_WAIT 状态要维持 2MSL 的原因

文章目录 前言 正文 前言 本文主要分析为什么 TIME_WAIT 状态的持续时间是 2MSL 而不是 1MSL,3MSL 或其它的时长,而不会详细描述为什么需要 TIME_WAIT 状态。...如果只考虑上述第一个目标,则 TIME_WAIT 状态需要持续的时间应该参考对端的 RTO(重传超时时间)以及 MSL(报文在网络中的最大生存时间)来计算而不是仅仅按 MSL 来计算,因为只要对端没有收到针对...不处理这些报文可能导致前后两个使用相同四元组的连接中的后一个连接出现异常(详见《UNIX网络编程》卷 1 的 2.7 节 第三版); 处于 TIME_WAIT 状态的一端在收到重传的 FIN 时会重新计时(rfc793以及 Linux...报文要从网络中消失最多还需要一个 MSL 时长,所以 A 还需要多等一个 MSL。...综上所述,TIME_WAIT 至少需要持续 2MSL 时长,这 2 个 MSL 中的第一个 MSL 是为了等自己发出去的最后一个 ACK 从网络中消失,而第二 MSL 是为了等在对端收到 ACK 之前的一刹那可能重传的

61010

为什么tcp的TIME_WAIT状态要维持2MSL

本文主要分析为什么TIME_WAIT状态的持续时间是2MSL而不是1MSL,3MSL或其它的时长,而不会详细描述为什么需要TIME_WAIT状态。...不处理这些报文可能导致前后两个使用相同四元组的连接中的后一个连接出现异常(详见UNIX网络编程卷1的2.7节 第三版); 处于TIME_WAIT状态的一端在收到重传的FIN时会重新计时(rfc793 以及 linux...所以晃眼一看,A只需要等待1个MSL就够了,但仔细想一下其实1个MSL是不行的,因为在B收到ACK前的一刹那,B可能因为没收到ACK而重传了一个FIN报文,这个FIN报文要从网络中消失最多还需要一个MSL...时长,所以A还需要多等一个MSL。...综上所述,TIME_WAIT至少需要持续2MSL时长,这2个MSL中的第一个MSL是为了等自己发出去的最后一个ACK从网络中消失,而第二MSL是为了等在对端收到ACK之前的一刹那可能重传的FIN报文从网络中消失

6.2K42

关闭连接后为什么客户端最后还要等待2MSL

MSL(Maximum Segment Lifetime)报文最大生存时间,2MSL即两倍的MSL,TCP允许不同的实现可以设置不同的MSL值。...因为这个ACK报文可能丢失,站在服务器的角度看来,我已经发送了FIN+ACK报文请求断开了,客户端还没有给我回应,应该是我发送的请求断开报文它没有收到,于是服务器又会重新发送一次,而客户端就能在这个2MSL...时间段内收到这个重传的报文,接着给出回应报文,并且会重启2MSL计时器。...客户端发送完最后一个确认报文后,在这个2MSL时间中,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。 ?

1.4K10

tcp_tw_reuse、tcp_tw_recycle注意事项

linux TIME_WAIT 相关参数: net.ipv4.tcp_tw_reuse = 0 表示开启重用。...net.ipv4.tcp_fin_timeout = 60 表示如果套接字由本端要求关闭,这个参数决定了它保持在FIN-WAIT-2状态的时间 注意: - 不像Windows 可以修改注册表修改2MSL...的值,linux 需要修改内核宏定义重新编译,tcp_fin_timeout 不是2MSL 而是Fin-WAIT-2状态超时时间. - tcp_tw_reuse 和 SO_REUSEADDR 是两个完全不同的东西...MSL 由来   发起连接关闭方回复最后一个fin 的ack,为避免对方ack 收不到、重发的或还在中间路由上的fin 把新连接给丢掉了,等个2MSLlinux 默认2min)。   ...2. reuse、recycle 通过timestamp的递增性来区分是否新连接,新连接的timestamp更大,那么保证小的timestamp的 fin 不会fin掉新连接,不用等2MSL

3.2K30

tcp_tw_reuse、tcp_tw_recycle 使用场景及注意事项

linux TIME_WAIT 相关参数: net.ipv4.tcp_tw_reuse = 0 表示开启重用。...的值,linux 是没有办法修改MSL的,tcp_fin_timeout 不是2MSL 而是Fin-WAIT-2状态. - tcp_tw_reuse 和SO_REUSEADDR 是两个完全不同的东西...服务器TIME_WAIT 高怎么办 不像客户端有端口限制,处理大量TIME_WAIT Linux已经优化很好了,每个处于TIME_WAIT 状态下连接内存消耗很少, 而且也能通过tcp_max_tw_buckets...MSL 由来   发起连接关闭方回复最后一个fin 的ack,为避免对方ack 收不到、重发的或还在中间路由上的fin 把新连接给干掉了,等个2MSL,4min。   ...细节之处还得好好阅读tcp 协议栈源码了 建议阅读以下参考: Coping with the TCP TIME-WAITstate on busy Linux servers tcp短连接TIME_WAIT

5.6K110

TIME_WAIT或者CLOSE_WAIT的原因以及如何解决

TCP的四次挥手图片MSL是Maximum Segment Lifetime英文的缩写,中文可以译为“报文最大生存时间”.2MSL在RFC 793协议中给出的建议是两分钟, 但是在Linux下一般时30...秒, 也就是说2MSL就是60秒.CLOSE_WAIT 产生的原因CLOSE_WAIT是被动关闭连接是形成的,根据TCP状态机,服务器端收到客户端发送的FIN,TCP协议栈会自动发送ACK,连接进入CLOSE_WAIT...TIME_WAIT 产生的原因TIME_WAIT的作用简单说timewait之所以等待2MSL的时长,是为了避免因为网络丢包或者网络延迟而造成的tcp传输不可靠,而这个TIME_WAIT状态则可以最大限度的提升网络传输的可靠性...或者将MSL值缩减, linuxMSL的值默认为60s,我们可以通过缩减MSL值来使得主动关闭连接一端由TIME_WAIT状态到关闭状态的时间减少。...查看默认的MSL值$ cat /proc/sys/net/ipv4/tcp_fin_timeout修改$echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout或者$ vim

6.1K50

为什么TCP 建连接要3次,断连接却要4次呢?

Linux下,默认重试次数为5次,重试的间隔时间从1s开始每次都翻售,5次的重试时间间隔为1s, 2s, 4s, 8s, 16s,总共31s,第5次发出后还要等32s都知道第5次也超时了,所以,总共需要...于是,Linux下给了一个叫tcp_syncookies的参数来应对这个事——当SYN队列满了后,TCP会通过源地址端口、目标地址端口和时间戳打造出一个特别的Sequence Number发回去(又叫cookie...因为,我们假设我们的TCP Segment在网络上的存活时间不会超过Maximum Segment Lifetime(缩写为MSL – Wikipedia语条),所以,只要MSL的值小于4.55小时,那么...关于 MSL 和 TIME_WAIT。通过上面的ISN的描述,相信你也知道MSL是怎么来的了。...我们注意到,在TCP的状态图中,从TIME_WAIT状态到CLOSED状态,有一个超时设置,这个超时设置是 2*MSL(RFC793定义了MSL为2分钟,Linux设置成了30s)为什么要这有TIME_WAIT

60630

被微信面麻了,问的太细节了。。。

上周有个读者在面试微信的时候,被问到既然打开 net.ipv4.tcp_tw_reuse 参数可以快速复用处于 TIME_WAIT 状态的 TCP 连接,那为什么 Linux 默认是关闭状态呢?...虽然 RFC 793 规定 MSL 为 2 分钟,但是在实际实现的时候会有所不同,比如 Linux 默认为 30 秒,那么 2MSL 就是 60 秒。...MSL 与 TTL 的区别:MSL 的单位是时间,而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间,以确保报文已被自然消亡。...TTL 的值一般是 64,LinuxMSL 设置为 30 秒,意味着 Linux 认为数据报文经过 64 个路由器的时间不会超过 30 秒,如果超过了,就认为报文已经消失在网络中了。...在 Linux 操作系统下,TIME_WAIT 状态的持续时间是 60 秒,这意味着这 60 秒内,客户端一直会占用着这个端口。

66820

TCP TIME_WAIT

下面是tcp状态图(来自下面的参考文章): tcp_flow.png 从图中可以看出,若服务器主动关闭连接,在四次挥手的最后一个ACK后连接端口会变为TIME_WAIT状态, 状态停留时长为两个MSL...MSL是一个TCP分段可以存在于互联网系统中的最大时长,RFC 793指出MSL为2分钟, 但在LINUX系统中一般为30s,通过下面这个命令可以确定一些LINUX系统上的MSL数值: sysctl net.ipv4...实现强加了更严格的限制, 在TIME_WAIT状态下,处于这个连接的本地端口默认情况下都不能再被使用,同时为了防止处于TIME_WAIT端口的主机出现故障,重启后马上建立新连接, RFC793有规定, TCP在重启动后的MSL...它的取值在Linux 4.10后的版本里做了些修改, 0表示关闭时间戳功能, 1 表示在收发包时不仅利用当前时间戳,还会利用每个连接生成的随机偏移量,2 表示只使用当前时间戳。...目前这个选项已经在Linux4.12以后的版本里被移除了。 参考文章: https://vincent.bernat.ch/en/blog/2014-tcp-time-wait-state-linux

2.1K00

为什么要Time_wait

这岂不是又浪费资源,又得不偿失影响下一次通信吗~~~~ 所以主动断开的最后一个ACK发送完后,不能直接断开连接,它必须确保对方收到最后一个ACK才能断开连接,所以ACK过去一个MSL,如果ACK快到丢包这消耗了一个...MSL,那么对端会重传FIN,这个FIN段又消耗了一个MSL,所以啊共2个MSL。...所以time_wait时间俩个MSL。...首先有个点是必须得知道的,tcp三次握手不止是为了建立连接,还要互相确认对方的当前的初始化序列号(这个序列号在Linux下是有哈希算法得来的),确保当前连接的安全性,如果不初始化,都是0开始的话,那么连接将不安全...其次还要互相决定下来MSL的大小。 所以如果2次握手。

23720
领券