四次挥手详解

由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。

一、四次挥手各状态

FIN_WAIT_1

当主动关闭方在ESTABLISHED状态时发送一个FIN，用来关闭数据传送，此时即进入到FIN_WAIT_1状态。

CLOSE_WAIT

处于ESTABILSHED状态的服务器收到FIN包，将发回一个ACK，确认序号为收到的序号加1。
CLOSE_WAIT： 这种状态表示在等待关闭。当对方发送FIN报文给自己，系统会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。如果还有数据发送给对方则可以在数据发送结束后再发送FIN报文来结束连接，所以这个状态是被断开方再等待自己数据发送结束后断开连接

FIN_WAIT_2

处于FIN_WAIT_1状态时，当接收到对方回应的ACK报文后，则进入到FIN_WAIT_2状态

LAST_ACK

被动关闭一方在发送FIN报文后，最后等待对方的ACK报文期间处于LAST_ACK状态

TIME_WAIT

time_wait 是「主动关闭 TCP 连接」一方的状态，可能是==「客服端」的，也可能是「服务器端」==的；
当TCP的一端发起主动关闭（收到 FIN 请求），即第3次握 手完成后，发送了第四次握手的ACK包后（最后的 ACK 是由「主动关闭连接」的一端发出的），就进入了TIME_WAIT状态。

CLOSE

当被动方收到ACK报文后，也即可以进入到CLOSED可用状态了。

二、双方同时调用close()，FIN_WAIT_1状态后进入CLOSING状态

CLOSING状态

CLOSING： 当发送FIN报文后进入fin_wait_1状态，过后并没有收到对方的ACK报文，反而也收到了对方的FIN报文。就是双方几乎在同时close一个SOCKET，然后就出现了双方同时发送FIN报文的情况，表示双方都正在关闭SOCKET连接。
closing状态收到ack报文以后即直接进入time_wait状态

三、TIME_WAIT状态详解

(1) TIME_WAIT状态下的2MSL是什么

MSL （报文最大生存时间）

任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。（IP 报文）
RFC 793中规定MSL为2分钟，实际应用中常用的是30秒，1分钟和2分钟等。

为什么TIME__WAIT状态必须停留两倍MSL时间

等待2MSL时间主要目的是怕最后一个 ACK包对方没收到，那么对方在超时后将重发第三次握手的FIN包，主动关闭端接到重发的FIN包后，可以再发一个ACK应答包。

当连接处于2MSL等待阶段时，任何迟到的报文段都将被丢弃。

(2) TIME_WAIT存在的意义

可靠的实现 TCP 全双工连接的终止：
四次挥手关闭 TCP 连接过程中，最后的 ACK 是由「主动关闭连接」的一端发出的，如果这个 ACK 丢失，则，对方会重发 FIN 请求，因此，在「主动关闭连接」的一段，需要维护一个 time_wait 状态，处理对方重发的 FIN 请求；

假设发起主动关闭方发送的ACK （4次交互的最后一个包）在网络中丢失，那么由于TCP的重传机制，被动关闭方需要重发FIN（第三次挥手），在该FIN到达主动发起方之前，client必须维护这条连接的状态（尽管它已调用过close），具体而言，就是这条TCP连接对应的（源IP，源端口）资源不能被立即释放或重新分配。直到对端重发的FIN达到，client也重发ACK后，该TCP连接才能恢复初始的CLOSED状态。如果主动方不进入TIME_WAIT以维护其连接状态，则当被动方重发的FIN达到时，主动方的TCP传输层会以RST包响应对方，这会被对方认为有错误发生（而事实上，这是正常的关闭连接过程，并非异常）。

处理延迟到达的报文：
由于路由器可能抖动，TCP 报文会延迟到达，为了避免「延迟到达的 TCP 报文」被误认为是「新 TCP 连接」的数据，则，需要在允许新创建 TCP 连接之前，保持一个不可用的状态，等待所有延迟报文的消失，一般设置为 2 倍的 MSL（报文的最大生存时间），解决「延迟达到的 TCP 报文」问题。

TCP是流式的，所有包到达的顺序是不一致的，依靠序列号由TCP协议栈做顺序的拼接；假设如果一个新连接建立后旧连接的seq=1000包到达对端，可能会顶替掉新连接的seq=1000，造成错误

(3) 为什么会出现大量的TIME_WAIT状态

大量的短连接存在
TCP 四次挥手关闭连接机制中，为了保证 ACK 重发和丢弃延迟数据，设置 time_wait 为 2 倍的 MSL（报文最大存活时间）

(4) TIME_WAIT状态的影响

time_wait 状态下，TCP 连接占用的端口，无法被再次使用， 要等到2MSL时间结束，才可继续使用，而TCP 端口数量上限是 6.5w（65535，16 bit）
大量 time_wait 状态存在，会导致新建 TCP 连接会出错，address already in use : connect 异常

解决方法

• 服务器端允许 time_wait 状态的 socket 被重用

• 缩减 time_wait 时间，设置为 1 MSL（即，2 mins）

四、HTTP中一般服务端是请求断开方

在HTTP1.1协议中，有个 Connection 头，Connection有两个值，close和keep-alive，这个头就相当于客户端告诉服务端，服务端你执行完成请求之后，是关闭连接还是保持连接，保持连接就意味着在保持连接期间，只能由客户端主动断开连接。还有一个keep-alive的头，设置的值就代表了服务端保持连接保持多久。

HTTP默认的Connection值为close，那么就意味着关闭请求的一方几乎都会是由服务端这边发起的。那么这个服务端产生TIME_WAIT过多的情况就很正常了。

虽然HTTP默认Connection值为close，但是，现在的浏览器发送请求的时候一般都会设置Connection为keep-alive了。所以，也有人说，现在没有必要通过调整参数来使TIME_WAIT降低了。