TCP timewait和closewait？2MSL?

time_wait与close_wait，time_wait状态持续多长时间？为什么会有time_wait状态？

time_wait另一边已经初始化一个释放，close_wait连接一端被动关闭；
首先调用close()发起主动关闭的一方，在发送最后一个ACK之后会进入time_wait的状态，也就说该发送方会保持2MSL时间之后才会回到初始状态。MSL指的是数据包在网络中的最大生存时间。产生这种结果使得这个TCP连接在2MSL连接等待期间，定义这个连接的四元组（客户端IP地址和端口，服务端IP地址和端口号）不能被使用。
为什么存在time_wait

TCP协议在关闭连接的四次握手过程中，最终的ACK是由主动关闭连接的一端（后面统称A端）发出的，如果这个ACK丢失，对方（后面统称B端）将重发出最终的FIN，因此A端必须维护状态信息（TIME_WAIT）允许它重发最终的ACK。如果A端不维持TIME_WAIT状态，而是处于CLOSED 状态，那么A端将响应RST分节，B端收到后将此分节解释成一个错误。因而，要实现TCP全双工连接的正常终止，必须处理终止过程中四个分节任何一个分节的丢失情况，主动关闭连接的A端必须维持TIME_WAIT状态。

为实现TCP全双工连接的可靠释放

由TCP状态变迁图可知，假设发起主动关闭的一方（client）最后发送的ACK在网络中丢失，由于TCP协议的重传机制，执行被动关闭的一方（server）将会重发其FIN，在该FIN到达client之前，client必须维护这条连接状态，也就说这条TCP连接所对应的资源（client方的local_ip,local_port）不能被立即释放或重新分配，直到另一方重发的FIN达到之后，client重发ACK后，经过2MSL时间周期没有再收到另一方的FIN之后，该TCP连接才能恢复初始的CLOSED状态。如果主动关闭一方不维护这样一个TIME_WAIT状态，那么当被动关闭一方重发的FIN到达时，主动关闭一方的TCP传输层会用RST包响应对方，这会被对方认为是有错误发生，然而这事实上只是正常的关闭连接过程，并非异常。

TCP segment 可能由于路由器异常而“迷途”，在迷途期间，TCP发送端可能因确认超时而重发这个segment，迷途的segment在路由器修复后也会被送到最终目的地，这个迟到的迷途segment到达时可能会引起问题。在关闭“前一个连接”之后，马上又重新建立起一个相同的IP和端口之间的“新连接”，“前一个连接”的迷途重复分组在“前一个连接”终止后到达，而被“新连接”收到了。为了避免这个情况，TCP协议不允许处于TIME_WAIT状态的连接启动一个新的可用连接，因为TIME_WAIT状态持续2MSL，就可以保证当成功建立一个新TCP连接的时候，来自旧连接重复分组已经在网络中消逝。

为使旧的数据包在网络因过期而消失

为说明这个问题，我们先假设TCP协议中不存在TIME_WAIT状态的限制，再假设当前有一条TCP连接：(local_ip, local_port, remote_ip,remote_port)，因某些原因，我们先关闭，接着很快以相同的四元组建立一条新连接。本文前面介绍过，TCP连接由四元组唯一标识，因此，在我们假设的情况中，TCP协议栈是无法区分前后两条TCP连接的不同的，在它看来，这根本就是同一条连接，中间先释放再建立的过程对其来说是“感知”不到的。这样就可能发生这样的情况：前一条TCP连接由local peer发送的数据到达remote peer后，会被该remot peer的TCP传输层当做当前TCP连接的正常数据接收并向上传递至应用层（而事实上，在我们假设的场景下，这些旧数据到达remote peer前，旧连接已断开且一条由相同四元组构成的新TCP连接已建立，因此，这些旧数据是不应该被向上传递至应用层的），从而引起数据错乱进而导致各种无法预知的诡异现象。作为一种可靠的传输协议，TCP必须在协议层面考虑并避免这种情况的发生，这正是TIME_WAIT状态存在的第2个原因。

如果time_wait维持的时间过长，主动关闭连接端迟迟无法关闭连接，占用程序资源。
如果服务器程序TCP连接一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。
time_wait状态如何避免

首先服务器可以设置SO_REUSEADDR套接字选项来通知内核，如果端口忙，但TCP连接位于TIME_WAIT状态时可以重用端口。在一个非常有用的场景就是，如果你的服务器程序停止后想立即重启，而新的套接字依旧希望使用同一端口，此时SO_REUSEADDR选项就可以避免TIME_WAIT状态。

Close_wait:

产生原因

在被动关闭连接情况下，在已经接收到FIN，但是还没有发送自己的FIN的时刻，连接处于CLOSE_WAIT状态。通常来讲，CLOSE_WAIT状态的持续时间应该很短，正如SYN_RCVD状态。但是在一些特殊情况下，就会出现连接长时间处于CLOSE_WAIT状态的情况。出现大量close_wait的现象，主要原因是某种情况下对方关闭了socket链接，但是我方忙与读或者写，没有关闭连接。代码需要判断socket，一旦读到0，断开连接，read返回负，检查一下errno，如果不是AGAIN，就断开连接。对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。

解决方法

要检测出对方已经关闭的socket，然后关闭它。

Time_wait为什么是2MSL的时间长度

TIME_WAIT的状态是为了等待连接上所有的分组的消失。单纯的想法，发送端只需要等待一个MSL就足够了。这是不够的，假设现在一个MSL的时候，接收端需要发送一个应答，这时候，我们也必须等待这个应答的消失，这个应答的消失也是需要一个MSL，所以我们需要等待2MSL。

TCP timewait和closewait？2MSL?相关推荐

TCP四次挥手 2MSL TIME_WAIT详解
TCP四次挥手 & 2MSL & TIME_WAIT详解 TCP四次挥手流程各状态解析 2MSL(2倍最大报文段生成时间) 2MSL (Maximum Segment Lifetim ...
tcp timewait closewait 过多情况
TIMEWAIT作用(为的是确认服务器端是否收到客户端发出的ACK确认报文) 为实现TCP全双工连接的可靠释放[最后一个ACK丢失了,被动关闭一方会重发它的FIN,主动关闭一方必须维持一个有效状态信息 ...
TCP知识点以及TimeWait和CloseWait原理图
TCP的三次握手两个教程(图片转载):https://zhuanlan.zhihu.com/p/53374516 https://blog.csdn.net/whuslei/article/deta ...
计算机网络知识点总结（ICMP、PING、OSPF、TIMEWAIT、CLOSEWAIT、HTTPS、HTTP2.0）
概述五层模型物理层数据链路层 CSMA/CD协议 PPP协议 MAC地址局域网交换机网络层(IP层) IP地址分类 IP地址与物理地址的区别 ARP协议(重点) ICMP协议(重点) Pi ...
Tcp TimeWait处理流程
1 谁先主动关闭tcp连接,谁将进入Time_wait状态. 2 Time_wait状态是在等最后的ack,如果没有最后的ack.本端不清楚连接状态,没有办法正常释放socket,比如没有等到ack, ...
tcp timewait过多
查看tcp状态统计命令:netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' what:主动close TCP(se ...
TCP TimeWait状态详解（比较全）
转载自:http://blog.chinaunix.net/uid-20384806-id-1954363.html TIME_WAIT状态 TCP要保证在所有可能的情况下使得所有的数据都能够正确被投 ...
Linux网络编程 | TCP状态转换【2MSL】
文章目录一.TCP状态转换 1.半关闭 2.2MSL 一.TCP状态转换 CLOSED:表示初始状态. LISTEN:表示服务器端的某个SOCKET处于监听状态,可连接. SYN_SENT:表示客户 ...
TIMEWAIT与CLOSEWAIT
[url]http://blog.csdn.net/kobejayandy/article/details/17655739[/url] TCP协议规定,对于已经建立的连接,网络双方要进行四次握手才能 ...

TCP timewait和closewait？2MSL?

TCP timewait和closewait？2MSL?相关推荐

最新文章

热门文章