1、TCP 三次握手/ 四次挥手详解1、建立连接协议（三次握手）（1）客户端发送一个带 SYN 标志的 TCP 报文到服务器。这是三次握手过程中的报文 1。（2） 服务器端回应客户端的，这是三次握手中的第 2 个报文，这个报文同时带 ACK 标志和 SYN 标志。因此它表示对刚才客户端 SYN 报文的回应；同时又标志 SYN 给客户端，询问客户端是否准备好进行数据通讯。（3） 客户必须再次回应服务段一个 ACK 报文，这是报文段 3。2、连接终止协议（四次挥手）由于 TCP 连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个 FIN 来终止这个方向的连
2、接。收到一个 FIN 只意味着这一方向上没有数据流动，一个 TCP 连接在收到一个 FIN 后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。（1） TCP 客户端发送一个 FIN，用来关闭客户到服务器的数据传送（报文段 4） 。（2） 服务器收到这个 FIN，它发回一个 ACK，确认序号为收到的序号加 1（报文段 5） 。和 SYN 一样，一个 FIN 将占用一个序号。（3） 服务器关闭客户端的连接，发送一个 FIN 给客户端（报文段 6） 。（4） 客户段发回 ACK 报文确认，并将确认序号设置为收到序号加 1（报文段 7） 。CLOSED: 这个没什么好说的了，表示
3、初始状态。LISTEN: 这个也是非常容易理解的一个状态，表示服务器端的某个 SOCKET 处于监听状态，可以接受连接了。SYN_RCVD: 这个状态表示接受到了 SYN 报文，在正常情况下，这个状态是服务器端的SOCKET 在建立 TCP 连接时的三次握手会话过程中的一个中间状态，很短暂，基本上用netstat 你是很难看到这种状态的，除非你特意写了一个客户端测试程序，故意将三次 TCP握手过程中最后一个 ACK 报文不予发送。因此这种状态时，当收到客户端的 ACK 报文后，它会进入到 ESTABLISHED 状态。SYN_SENT: 这个状态与 SYN_RCVD 遥想呼应，当客户端 SOC
4、KET 执行 CONNECT 连接时，它首先发送 SYN 报文，因此也随即它会进入到了 SYN_SENT 状态，并等待服务端的发送三次握手中的第 2 个报文。SYN_SENT 状态表示客户端已发送 SYN 报文。ESTABLISHED：这个容易理解了，表示连接已经建立了。FIN_WAIT_1: 这个状态要好好解释一下，其实 FIN_WAIT_1 和 FIN_WAIT_2 状态的真正含义都是表示等待对方的 FIN 报文。而这两种状态的区别是：FIN_WAIT_1 状态实际上是当 SOCKET 在 ESTABLISHED 状态时，它想主动关闭连接，向对方发送了 FIN 报文，此时该 SOCKET
5、即进入到 FIN_WAIT_1 状态。而当对方回应 ACK 报文后，则进入到FIN_WAIT_2 状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK 报文，所以 FIN_WAIT_1 状态一般是比较难见到的，而 FIN_WAIT_2 状态还有时常常可以用 netstat 看到。FIN_WAIT_2： 上面已经详细解释了这种状态，实际上 FIN_WAIT_2 状态下的 SOCKET，表示半连接，也即有一方要求 close 连接，但另外还告诉对方，我暂时还有点数据需要传送给你，稍后再关闭连接。TIME_WAIT: 表示收到了对方的 FIN 报文，并发送出了 ACK 报文，就等
6、2MSL 后即可回到 CLOSED 可用状态了。如果 FIN_WAIT_1 状态下，收到了对方同时带 FIN 标志和 ACK标志的报文时，可以直接进入到 TIME_WAIT 状态，而无须经过 FIN_WAIT_2 状态。CLOSING: 这种状态比较特殊，实际情况中应该是很少见，属于一种比较罕见的例外状态。正常情况下，当你发送 FIN 报文后，按理来说是应该先收到（或同时收到）对方的 ACK 报文，再收到对方的 FIN 报文。但是 CLOSING 状态表示你发送 FIN 报文后，并没有收到对方的 ACK 报文，反而却也收到了对方的 FIN 报文。什么情况下会出现此种情况呢？其实细想一下，也不难
7、得出结论：那就是如果双方几乎在同时 close 一个 SOCKET 的话，那么就出现了双方同时发送 FIN 报文的情况，也即会出现 CLOSING 状态，表示双方都正在关闭SOCKET 连接。CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。怎么理解呢？当对方 close 一个SOCKET 后发送 FIN 报文给自己，你系统毫无疑问地会回应一个 ACK 报文给对方，此时则进入到 CLOSE_WAIT 状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close 这个 SOCKET，发送 FIN 报文给对方，也即关闭连接。所以你在
8、CLOSE_WAIT 状态下，需要完成的事情是等待你去关闭连接。LAST_ACK: 这个状态还是比较容易好理解的，它是被动关闭一方在发送 FIN 报文后，最后等待对方的 ACK 报文。当收到 ACK 报文后，也即可以进入到 CLOSED 可用状态了。最后有 2 个问题的回答，我自己分析后的结论（不一定保证 100%正确）1、 为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？这是因为服务端的 LISTEN 状态下的 SOCKET 当收到 SYN 报文的建连请求后，它可以把ACK 和 SYN（ ACK 起应答作用，而 SYN 起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的 F
9、IN 报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭 SOCKET,也即你可能还需要发送一些数据给对方之后，再发送 FIN 报文给对方来表示你同意现在可以关闭连接了，所以它这里的 ACK 报文和 FIN 报文多数情况下都是分开发送的。2、 为什么 TIME_WAIT 状态还需要等 2MSL 后才能返回到 CLOSED 状态？这是因为：虽然双方都同意关闭连接了，而且握手的 4 个报文也都协调和发送完毕，按理可以直接回到 CLOSED 状态（就好比从 SYN_SEND 状态到 ESTABLISH 状态那样） ；但是因为我们必须要假想网
10、络是不可靠的，你无法保证你最后发送的 ACK 报文会一定被对方收到，因此对方处于 LAST_ACK 状态下的 SOCKET 可能会因为超时未收到 ACK 报文而重发 FIN报文，所以这个 TIME_WAIT 状态的作用就是用来重发可能丢失的 ACK 报文。TCP 链接中有一个 MSL 的概念，也就是最大生成时间，MSL 的值在一般的实现中取30s，有些实现采用 2 分钟，在 TCP 的状态机中的“被动关闭 ”:从 CLOSE_WAIT 到LAST_ACK 中有一个如下的规则：当 T C P 执行一个主动关闭，并发回最后一个 A CK,该连接必须在 TIME_WAIT 状态停留的时间为 2 倍的 MSL。这样可让 TCP 再次发送最后的ACK 以防这个 ACK 丢失（另一端超时并重发最后的 FIN)。 存在这个规则导致一个后果就是在这个 2MSL 的时间内，该地址上的链接（客户端地址、端口和服务器端的地址、端口）不能被使用。比如我们在建立一个链接后关闭链接然后迅速重启链接，那么就会出现端口不可用的情况。
