详解TCP链接的“三次握手”与“四次挥手”(下)
上文连接：html
4、TCP的四次挥手（Four-Way Wavehand）
0.前言
对于"三次握手"咱们耳熟能详，由于其相对的简单。可是，咱们却不常听见“四次挥手”，就算听过也未必能详细地说明白它的具体过程。下面就为你们详尽，直观，完整地介绍“四次挥手”的过程。服务器
1.“四次挥手”的详解
所谓的四次挥手即TCP链接的释放(解除)。链接的释放必须是一方主动释放，另外一方被动释放。如下为客户端主动发起释放链接的图解：网络
挥手以前主动释放链接的客户端结束ESTABLISHED阶段。随后开始“四次挥手”：tcp
（1）首先客户端想要释放链接，向服务器端发送一段TCP报文，其中：.net
标记位为FIN，表示“请求释放链接“；计算机网络
序号为Seq=U；3d
随后客户端进入FIN-WAIT-1阶段，即半关闭阶段。而且中止在客户端到服务器端方向上发送数据，可是客户端仍然能接收从服务器端传输过来的数据。htm
注意：这里不发送的是正常链接时传输的数据(非确认报文)，而不是一切数据，因此客户端仍然能发送ACK确认报文。blog
（2）服务器端接收到从客户端发出的TCP报文以后，确认了客户端想要释放链接，随后服务器端结束ESTABLISHED阶段，进入CLOSE-WAIT阶段（半关闭状态）并返回一段TCP报文，其中：
标记位为ACK，表示“接收到客户端发送的释放链接的请求”；
序号为Seq=V；
确认号为Ack=U+1，表示是在收到客户端报文的基础上，将其序号Seq值加1做为本段报文确认号Ack的值；
随后服务器端开始准备释放服务器端到客户端方向上的链接。
客户端收到从服务器端发出的TCP报文以后，确认了服务器收到了客户端发出的释放链接请求，随后客户端结束FIN-WAIT-1阶段，进入FIN-WAIT-2阶段
前"两次挥手"既让服务器端知道了客户端想要释放链接，也让客户端知道了服务器端了解了本身想要释放链接的请求。因而，能够确认关闭客户端到服务器端方向上的链接了
（3）服务器端自从发出ACK确认报文以后，通过CLOSED-WAIT阶段，作好了释放服务器端到客户端方向上的链接准备，再次向客户端发出一段TCP报文，其中：
标记位为FIN，ACK，表示“已经准备好释放链接了”。注意：这里的ACK并非确认收到服务器端报文的确认报文。
序号为Seq=W；
确认号为Ack=U+1；表示是在收到客户端报文的基础上，将其序号Seq值加1做为本段报文确认号Ack的值。
随后服务器端结束CLOSE-WAIT阶段，进入LAST-ACK阶段。而且中止在服务器端到客户端的方向上发送数据，可是服务器端仍然可以接收从客户端传输过来的数据。
（4）客户端收到从服务器端发出的TCP报文，确认了服务器端已作好释放链接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，并向服务器端发送一段报文，其中：
标记位为ACK，表示“接收到服务器准备好释放链接的信号”。
序号为Seq=U+1；表示是在收到了服务器端报文的基础上，将其确认号Ack值做为本段报文序号的值。
确认号为Ack=W+1；表示是在收到了服务器端报文的基础上，将其序号Seq值做为本段报文确认号的值。
随后客户端开始在TIME-WAIT阶段等待2MSL
为何要客户端要等待2MSL呢？见后文。
服务器端收到从客户端发出的TCP报文以后结束LAST-ACK阶段，进入CLOSED阶段。由此正式确认关闭服务器端到客户端方向上的链接。
客户端等待完2MSL以后，结束TIME-WAIT阶段，进入CLOSED阶段，由此完成“四次挥手”。
后“两次挥手”既让客户端知道了服务器端准备好释放链接了，也让服务器端知道了客户端了解了本身准备好释放链接了。因而，能够确认关闭服务器端到客户端方向上的链接了，由此完成“四次挥手”。
与“三次挥手”同样，在客户端与服务器端传输的TCP报文中，双方的确认号Ack和序号Seq的值，都是在彼此Ack和Seq值的基础上进行计算的，这样作保证了TCP报文传输的连贯性，一旦出现某一方发出的TCP报文丢失，便没法继续"挥手"，以此确保了"四次挥手"的顺利完成。
2.”四次挥手“的动态过程
3.“四次挥手”的通俗理解
举个栗子：把客户端比做男孩，服务器比做女孩。经过他们的分手来讲明“四次挥手”过程。
"第一次挥手"：日久见人心，男孩发现女孩变成了本身讨厌的样子，忍无可忍，因而决定分手，随即写了一封信告诉女孩。
“第二次挥手”：女孩收到信以后，知道了男孩要和本身分手，怒火中烧，心中暗骂：你算什么东西，当初你可不是这个样子的！因而立马给男孩写了一封回信：分手就分手，给我点时间，我要把你的东西整理好，所有还给你！
男孩收到女孩的第一封信以后，明白了女孩知道本身要和她分手。随后等待女孩把本身的东西收拾好。
“第三次挥手”：过了几天，女孩把男孩送的东西都整理好了，因而再次写信给男孩：你的东西我整理好了，快把它们拿走，今后你我恩断义绝！
“第四次挥手”：男孩收到女孩第二封信以后，知道了女孩收拾好东西了，能够正式分手了，因而再次写信告诉女孩：我知道了，这就去拿回来！
这里双方都有各自的坚持。
- 女孩自发出第二封信开始，限定一天内收不到男孩回信，就会再发一封信催促男孩来取东西！
- 男孩自发出第二封信开始，限定两天内没有再次收到女孩的信就认为，女孩收到了本身的第二封信；若两天内再次收到女孩的来信，就认为本身的第二封信女孩没收到，须要再写一封信，再等两天.....
假若双方信都能正常收到，最少只用四封信就能完全分手！这就是“四次挥手”。
4.为何“握手”是三次，“挥手”却要四次？
TCP创建链接时之因此只须要"三次握手"，是由于在第二次"握手"过程当中，服务器端发送给客户端的TCP报文是以SYN与ACK做为标志位的。SYN是请求链接标志，表示服务器端赞成创建链接；ACK是确认报文，表示告诉客户端，服务器端收到了它的请求报文。
即SYN创建链接报文与ACK确认接收报文是在同一次"握手"当中传输的，因此"三次握手"很少也很多，正好让双方明确彼此信息互通。
TCP释放链接时之因此须要“四次挥手”,是由于FIN释放链接报文与ACK确认接收报文是分别由第二次和第三次"挥手"传输的。为什么创建链接时一块儿传输，释放链接时却要分开传输？
- 创建链接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不须要任何准备，能够直接返回SYN和ACK报文，开始创建链接。
- 释放链接时，被动方服务器，忽然收到主动方客户端释放链接的请求时并不能当即释放链接，由于还有必要的数据须要处理，因此服务器先返回ACK确认收到报文，通过CLOSE-WAIT阶段准备好释放链接以后，才能返回FIN释放链接报文。
因此是“三次握手”，“四次挥手”。
5.为何客户端在TIME-WAIT阶段要等2MSL?
为的是确认服务器端是否收到客户端发出的ACK确认报文
当客户端发出最后的ACK确认报文时，并不能肯定服务器端可以收到该段报文。因此客户端在发送完ACK确认报文以后，会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程当中的最大生命周期。2MSL便是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。
服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；
- 若是客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端因为各类缘由没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文，计时器重置，从新开始2MSL的计时；
- 不然客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端能够进入CLOSED阶段，完成“四次挥手”。
因此，客户端要经历时长为2SML的TIME-WAIT阶段；这也是为何客户端比服务器端晚进入CLOSED阶段的缘由
6.抓包验证
图中显示的就是完整的TCP链接释放的”四次挥手”过程。在 80 -> 55389 中，假设80是本地(客户端)端口，55389是服务器端口。80端口与55389之间的四次来回就是"四次挥手"过程。
- ”第一次挥手”客户端发送的FIN请求释放链接报文以[FIN，ACK]做为标志位，其中报文序号Seq=2445；确认号Ack=558；
注意：这里与“第三次握手”的ACK并非表示确认的ACK报文。
”第二次挥手”服务器端返回的ACK确认报文以[ACK]做为标志位；其中报文序号Seq=558；确认号Ack=2246；
”第三次挥手”服务器端继续返回的FIN赞成释放链接报文以[FIN，ACK]做为标志位；其中报文序号Seq=558；确认号Ack=2246；
”第四次挥手”客户端发出的ACK确认接收报文以[ACK]做为标志位；其中报文序号Seq=2446；确认号Ack=559；
后一次“挥手”传输报文中的序号Seq值等于前一次"握手"传输报文中的确认号Ack值；
后一次“挥手”传输报文中的确认号Ack值等于前一次"握手"传输报文中的序号Seq值；
故这是连续的“四次挥手”过程，与前面的分析相符。
参考资料：