TCP--三次握手四次挥手

假设现在有主机A运行的是TCP客户程序，主机B运行的是TCP服务器程序，最初两台机器都是关闭状态，现在主机A主动打开，而主机B被动打开，如图：

这里就不详细讲述其具体过程，只研究其为什么是三次握手；

假设是两次握手的话，那么当这两种情况出现时就会有问题：

1. 假设当A主机第一次发出的请求在网络当中被滞留，以至于触发了TCP中超时重传，这时候主机A会再次发送一个连接请求，这时候B主机收到第二个请求并回复确认，因为是两次握手，所以当B主机回复确认的时候就认为连接已经建立；但是在这之后，主机A的第一次请求到达了，那么主机B便又会回复一个确认，并且会再次创建一个新的连接，这样主机B就相当于维护了一个废的连接，白白浪费了资源

2. 假设主机A的请求报文正常到达，主机B收到并回复确认，此时主机B已经建立了连接，但是主机B的回复确认段在网络当中丢失了，这个时候主机A没收到确认，便会认为主机B没有收到，便会再次发送一条，主机B收到就又会建立一个连接，那么之前那个连接就白白浪费了资源

   采用三次连接的话，在这两种情况下，主机B都没有收到主机A的回复确认消息，也就知道主机A并没有准备建立连接

在TCP断开的时候是有四次挥手的：

这里要论述的就是为什么是四次挥手？

1. 当主机A想要释放连接时发送一个连接释放请求，此时主机A不在发送数据进入FIN-WAIT-1状态
2. 主机B收到主机的A的请求之后，先发送一个确认请求
3. 但此时主机B可能还有数据没有发完，所以此时的TCP进入FIN-WAIT-2阶段，当数据都发送完毕之后，主机B会再次发送一个连接释放请求，代表可以释放了
4. 主机A收到B的释放请求时，回复一个确认号，此时主机B收到主机A的确认报文段，便进入close状态，但是主机A进入TIME-WAIT状态；

这里再详细讲述一下最后为什么主机A要进入TIME-WAIT状态：

1. 为了保证最后主机A发出的确认报文段，主机B收到了，如果这个确认报文段丢失的话，那么主机B会超时重传一次释放请求报文段，然后再次回复，否则的话，可能会导致主机B不能正常进入到CLOSE状态；
2. 是为了防止上面所讲述的请求连接时，假设的第一种情况，这个时候“已经失效的请求报文段到了“，这样会让B以为是要创建一个新的连接；
   其等待时间是2倍的MSL（Maximum Segment Lifetime），MSL叫做最长报文段寿命，这样的话，就可以保证本连接持续的时间内产生的所有的报文段都从网络上消失了；