TCP的三次握手和四次挥手以及为什么

首先我们先了解一下TCP报文段的首部格式

TCP报文段首部格式

其中有几个重要的标志：

ACK：只有当 ACK 1 时确认号字段才有效。当 ACK 0 时，确认号无效。

SYN：同步 SYN = 1 表示这是一个连接请求或连接接受报文。

FIN：用来释放一个连接。FIN 1 表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。

ack：占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。

seq：占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节的序号。

三次握手

第一次握手：客户端A向服务器B发送一个TCP报文段，包括同步信号SYN=1，seq=x，seq=x表明传送的第一个数据字节的序号是x

第二次握手：服务器B收到客户端A的TCP报文以后，若是同意建立连接，则向客户端A发回复一个TCP报文段，包括SYN=1，ACK=1，seq=y，ack=x+1

第三次握手：客户端A收到服务器发出的确认报文以后，向服务器B发送一个确认报文，包括ACK=1，seq=x+1，ack=y+1,并向上层应用进程通知连接已经建立。服务器B收到客户端A的确认报文以后，也会通知上层的应用进程，连接已建立，此时双方就可以发送数据。

为什么要三次握手

若采用两次握手

假设客户端A在第一次发送链接请求时，第一次握发送的报文出现了网络延时，客户端误以为连接失败，然后重新发起连接，连接成功。数据发送完毕以后，并断开了连接。假设在此时，第一次发送的报文成功到达了服务器B，服务器以为客户端A重新发起来了连接，于是给客户端A恢复了一个确认消息。服务器默认就建立好了连接。但是客户端A并没有发起连接，就不会对服务器B发送的消息进行处理，经过一定的事件后，服务器B以为客户机A没有收到消息，然后就会进行重传，这样不仅浪费了服务器的资源，还有可能造成死锁

若采用四次握手

在第三次握手后，服务器又向客户机A发送了一个确认报文，但是在第三次握手的时候，双方已经通知上层应用进程，连接已经建立，所以，第四次握手会造成资源的浪费

四次挥手

第一次挥手：客户端A向服务B发送一个释放连接的报文段，包括FIN=1，seq=u,告诉服务器我要释放链接了

第二次挥手：服务器B收到客户端A的释放连接的请求，就会给客户端A回复一个确认释放的报文段，包括ACK=1，FIN=1，seq=w,ack=u+1,客户端收到该确认报文段，就释放了客户端A到服务器B方向的连接，但是若服务器B要给客户端A发送数据，客户端A仍旧要接收数据

第三次挥手：若服务端B没有数据再发给客户端A，同样会发一个释放连接的请求给客户端A

第四次挥手：客户端A收到服务器B的释放链接请求以后，就会发送一个确认报文段个服务器B，服务器B收到以后，服务器B到客户端A的方向的连接就释放了，在经过2MSL的时间，整个TCP连接就释放了

为什么要四次挥手

因为tcp通信的通道是一个全双工通信信道，即A可以给B发，B也可以给A发，所以需要四次挥手来确认双方通信都已经关闭

四次挥手为什么要等待2MSL

为了确保客户端A发送的最后一个报文段能够到达服务器B

防止已失效的连接请求的报文段又出现在下次连接中。A在发送最后一个ACK报文段以后，再经过2MSL,就可以使本链接持续时间内所产生的所有报文段都从网络上消失。这样下一个连接中就不会出现旧的连接请求报文段。