TIME_WAIT状态

前言请说说你对TCP连接中time_wait状态的理解解答：先上TCP的状态变迁图1. time_wait状态如何产生？ 由上面的变迁图，首先调用close()发起主动关闭的一方，在发送最后一个ACK之后会进入time_wait的状态，也就说该发送方会保持2MSL时间之后才会回到初始状态。MSL值得是数据包在网络中的最大生存时间。产生这种结果使得这个TCP连接在2MSL连接等待期间，定义这个连接的

建立一个TCP连接，一段时间后我们关闭这个连接，再基于相同插口建立一个新的TCP连接，这个新的连接称为前一个连接的化身。老的报文很有可能由于某些原因迟到了，那么新的TCP连接很有可能会将这个迟到的报文认为是新的连接的报文，而导致数据错乱。的时间为2min，在实际使用中一般是30s或者1min，在高并发的情况下毫无疑问，这将造成大量连接无法建立的问题，那么有什么方法可以处理这些问题那？或者负载均衡后，会发生严重的问题。后，主动关闭方收到包的时间戳比存储的时间戳小，则证明收到的包是一个旧的连接的包，直接丢弃。

1. time_wait状态如何产生？ 客户端和服务器都可以主动发起关闭连接，上图是客户端主动发起的TCP连接关闭。首先调用close()发起主动关闭的一方，在发送最后一个ACK之后会进入time_wait的状态，也就说该发送方会保持2MSL时间之后才会回到初始状态。在time_wait的状态下，定义这个连接的四元组（客户端IP地址和端口，服务端IP地址和端口号）不能被使用。 MSL：Maximum Segment Lifetime，也就是最大报文生存时间。 2. time_wait状态作用？..

TCP中time-wait这个状态的分析

正常情况下主动关闭连接的一端在连接正常终止后，会进入TIME_WAIT状态，存在这个状态有以下两个原因（参考《Unix网络编程》）：       1、保证TCP连接关闭的可靠性。如果最终发送的ACK丢失，被动关闭的一端会重传最终的FIN包，如果执行主动关闭的一端没有维护这个连接的状态信息，会发送RST包响应，导致连接不正常关闭。       2、允许老的重复分组在网络中消逝。假设在一个连接关闭

1.TCP状态 CLOSED：无连接是活动的或正在进行 LISTEN：服务器在等待进入呼叫 SYN_RECV：一个连接请求已经到达，等待确认 SYN_SENT：应用已经开始，打开一个连接 ESTABLISHED：正常数据传输状态 FIN_WAIT1：应用说它已经完成 FIN_WAIT2：另一边已同意释放 ITMED_WAIT：等待所有分组死掉 CLOSING：两边同时尝试关闭 TIME_WAIT：另一边已初始化一个释放 LAST_ACK：等待最后一个ACK信号，就关闭 2.发生的场景 在四次挥手的过

执行主动关闭的那端经历了这个状态，并停留MSL（最长分节生命期）的2倍，即2MSL。 TIME_WAIT存在的两个理由： 1 可靠的实现TCP全双工连接的终止 2 允许老的重复的分节在网络上的消逝 第一个：如果客户端不维持TIME_WAIT状态，那么将响应给服务端一个RST，该分节被服务器解释成一个错误。如果TCP打算执行所有必要的工作以彻底终止某个连接上两个方向的数据流，那么必须正确的处

转自: http://elf8848.iteye.com/blog/1739571 TIME_WAIT状态原理 ---------------------------- 通信双方建立TCP连接后，主动关闭连接的一方就会进入TIME_WAIT状态。 客户端主动关闭连接时，会发送最后一个ack后，然后会进入TIME_WAIT状态，再停留2个MSL时间(后有MSL的解释)，进入C

从Linux源码看TIME_WAIT状态的持续时间 前言 笔者一直以为在Linux下TIME_WAIT状态的Socket持续状态是60s左右。线上实际却存在TIME_WAIT超过100s的Socket。由于这牵涉到最近出现的一个复杂Bug的分析。所以，笔者就去Linux源码里面，一探究竟。 首先介绍下Linux环境 TIME_WAIT这个参数通常和五元组重用扯上关系。在这里，笔者先给出机器的内核参数设置，以免和其它问题相混淆。 cat /proc/sys/net/ipv4/tcp_tw_reus

要说明使用time_wait状态的原因就要假设没有time_wait状态会有什么影响由上图可以看到，被关闭端在收到最后的ACK包之前不会关闭连接，而是处于等待最后一个ACK包的状态。会在超时后重传FIN包，并且继续等待最后一个ACK包。如果没有time_wait状态，那重传的FIN包将永远不会被接收，也就没有最后的ACK包传回，那被关闭连接的一端将一直处于LAST_ACK状态。我们TCP是纯爱战士，不像UDP一样是给海王，所以得对另一端负责，要等待另一端重传的FIN包。

TIME_WAIT

在TCP断开的过程中会有四个状态变化过程,如下图所示: 常用的三个状态是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭。 TCP协议规定，对于已经建立的连接，网络双方要进行四次握手才能成功断开连接，如果缺少了其中某个步骤，将会使连接处于假死状态，连接本身占用的资源不会被释放。网络服务器程序要同时管理大量连接，所以很有必要保证

主动发起关闭连接的一方，才会有 TIME-WAIT 状态。 需要 TIME-WAIT 状态，主要是两个原因： 防止具有相同「四元组」的「旧」数据包被收到； 保证「被动关闭连接」的⼀方能被正确的关闭，即保证最后的 ACK 能让被动关闭方接收，从而帮助其正常关闭。 TCP 四元组可以唯⼀的确定⼀个连接，四元组包括如下： 源地址 源端⼝ ⽬的地址 ⽬的端⼝ 原因⼀：防止旧连接的数据包 假设 TIME-WAIT 没有等待时间或时间过短，被延迟的数据包抵达后会发⽣什么呢？ 如上图黄色

TCP/IP状态变迁图置顶： 可见，主动关闭的一方会进入TIME_WAIT状态。 该状态存在的缘由： 主动关闭的一方再最后回应了ACK报文之后，该ACK报文有丢失的可能，如果丢失，对端会重发FIN报文，因此目的之一是为ACK报文的丢失做应对措施。 主动关闭的一方再回应ACK报文之后，如果立刻关闭本连接，后续有可能新的连接复用该连接，这样就会有可能导致原连接的部分报文因为某些原因重新到来，导致与...

一、TCP连接断开的四次挥手： 　　由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。 　　其原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。 （1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送（报文段1）。 （2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段2）。和SYN一样，