文章内容概览
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的时间里，第四次挥手的报文没有被接收方接收到的话，接收方就会认为，我发送的第二次报文（也就是第三次挥手的报文）没有被发送方接收到，因此接收方会把第三次挥手的报文再发送一次，也就是重复一次第三次挥手。因此发送方会重新的构造一个报文，再次进行第四次挥手，这就是等待计时器的作用，它主要是为了确保第四次挥手的报文可以正确的到达对方，如果没到达，接收方就会重新发送一次第三次挥手的报文
等待计时器其实还有一个作用就是：确保当前连接的所有报文都已经过期了（因为最后一个确认断开的报文都已经过期了，其它的报文肯定也已经过期了）
