共计 1651 个字符，预计需要花费 5 分钟才能阅读完成。
文章内容概览
TCP 的四次挥手
上一篇文章中分享了 TCP 的三次握手，本文是相同的过程，是对 TCP 连贯的开释
TCP 四次挥手过程
还是假如这里有一个发送方结算机和一个接管方计算机，纵向为时间轴。连贯失常的时候，单方是能够始终进行数据传输的。假如数据传输实现了，此时就会进行 TCP 连贯的开释。假如发送方被动的进行了连贯的开释
第一次挥手
发送方发送第一次挥手的报文，报文内容：
FIN=1：该标记示意须要开释连贯
seq=u：同步本人的序列号给接管方
此时发送方就进入了 连贯完结的第一个期待状态（FIN-WAIT-1）
第二次挥手
接管方在收到发送方的断开连接申请之后，它也会发送一个报文去确认，确认对方给我发送的序列号我曾经收到了，确认报文内容是：
ACK=1：示意这个报文曾经确认
seq=v：同步本身的序列号
ack=u+1：确认号是 u +1，示意接管方冀望接管到接发送方的序列号是 u + 1 的数据
发送方接管到确认报文之后，就进入了 连贯完结的第二个期待状态 （FIN-WAIT-2）。而接管方在发送了第一个确认报文之后就进入了 敞开期待状态（CLOSE-WAIT）
这个时候其实接管方还是能够进行数据的发送的，因为开释连贯的申请是发送方发动的，示意说发送方的数据发送实现了，然而接管方可能还没有发送实现
第三次挥手
接管方发送完第一个确认报文之后，又会发送一个新的报文，这个报文会携带 FIN= 1 的标记，示意它也能够进行连贯开释了，并且里边会携带一个 ack，示意反复的对发送方发送的序列号进行确认，该报文中的残缺内容：
FIN=1：该标记示意须要开释连贯，是一个开释连贯的申请
ACK=1：示意确认报文曾经收到
seq=w：给发送方同步本人的序列号
ack=u+1：确认号是 u +1，示意接管方冀望接管到接发送方的序列号是 u + 1 的数据
第四次挥手
发送方接管到接管方的确认报文之后，又会发送一个确认报文，确认接管方发送的报文我曾经收到了，此时能够开释掉连贯了
在接管方发送断开连接的申请到发送方的确认报文被接管方收到这之间，接管方处于 最初确认状态 （LAST-ACK）。是为了确认发送方曾经接管到了连贯开释的报文，此时发送方进入了 期待计时器状态 （TIME-WAIT）。发送方会在这个工夫期待状态中期待一段时间，确保这段时间没有呈现任何的问题，此时才进入 敞开状态（CLOSE）
以上便是四次挥手的过程
期待计时器
期待计时器，它会期待 2MSL（MSL（MAX Segment Lifetime）最长报文段寿命），通常 MSL 是设置成 2min 的
咱们晓得每一个 TCP 连贯都会占用一个端口，在一个连贯状态中，如果想启用另外一个网络过程去复用这个端口的话是不行的，因为这个端口曾经被占用了。在期待计时器这个状态中，连贯是不会开释的，也就是不会开释以后占用的端口。只有在期待计时器状态完结之后才会开释这个端口
其实平时如果在进行 TCP 编程的时候，会发现，如果你被动的开释了这个连贯，而后马上复用这个端口，其实是不行的。次要是因为被动开释的这一方进入了 期待计时器状态，在这个状态中，是不会开释占用的端口的，须要等计时器完结
为什么须要期待计时器？为什么是 2MSL？
只有发送方发送了第四次挥手的报文之后，就进入可期待状态，在进入期待的时候，最初一个报文是没有进行确认的 。这个期待计时器次要是为了 确保发送方的 ACK 能够达到接管方
2MSL 是报文能够在网络中存活的最长的工夫 ，如果在 2MSL 的工夫里，第四次挥手的报文没有被接管方接管到的话，接管方就会认为，我发送的第二次报文（也就是第三次挥手的报文）没有被发送方接管到，因而接管方会把第三次挥手的报文再发送一次，也就是反复一次第三次挥手。因而发送方会从新的结构一个报文，再次进行第四次挥手，这就是期待计时器的作用，它次要是为了 确保第四次挥手的报文能够正确的达到对方，如果没达到，接管方就会从新发送一次第三次挥手的报文
期待计时器其实还有一个作用就是：确保以后连贯的所有报文都曾经过期了（因为最初一个确认断开的报文都曾经过期了，其它的报文必定也曾经过期了）
