TCP的三次握手和四次挥手协议

TCP的三次握手协议以及过程

C---客户端

S---服务端

ACK=1,表示回复请求

第一次握手:客户端向服务端发送SYN(标志位确认身份)=1的请求，并且携带一个序号seq=X(随机序号)

第二次握手:服务端接受过后也会发送ACK=1(回复数据包)的回复且携带一个ACKnumber(Ack)=x+1的确认序号，同时还将发送SYN=1的请求，并且携带一个随机序号Seq=y。

第三次握手:客户端收到回复后也会向服务端发送ACK=1的回复请求，同时也会携带ACKnumbe()=y+1的确认序号和自身的序号Seq=x+1

建立三次握手后才会发送数据

三次握手简图解：

 

问题：为什么是三次握手而不能是两次握手？

因为需要考虑连接时丢包的问题，如果只握手2次，那么第二次握手时如果服务端发给客户端的确认报文段丢失，此时服务端已经准备好了收发数(可以理解服务端已经连接成功)据，而客户端一直没收到服务端的确认报文，所以客户端就不知道服务端是否已经准备好了(可以理解为客户端未连接成功)，这种情况下客户端不会给服务端发数据，也会忽略服务端发过来的数据。
如果是三次握手，即便发生丢包也不会有问题，比如如果第三次握手客户端发的确认ack报文丢失，服务端在一段时间内没有收到确认ack报文的话就会重新进行第二次握手，也就是服务端会重发SYN报文段，客户端收到重发的报文段后会再次给服务端发送确认ack报文。
 

通俗的说就是：你出去和朋友玩了，你妈妈把饭做好了，准备喊你回家吃饭，第一次握手:老妈喊你吃饭，等着你回应！ 第二次握手:你一听，这是我妈的声音，回应了一句：好！第三次握手：老妈听到了你的回应

四次挥手协议以及过程：

FIN:请求断开连接的标志位

第一次挥手：当客户A要断开TCP连接时，发送一个包，其中标志位FIN=1，ACK=1，发送序号Seq=x，确认序号Ack=y，下图中x=200，y=500。Client进入FIN_WAIT_1状态（已发送FIN，等待回复）
第二次挥手：客户B知道A要断开后，发送一个确认包，其中标志位ACK=1发送序号，Seq=y确认序号Acknumber=x+1=201，Server进入CLOSE_WAIT状态（被动关闭）。
第三次挥手：客户B也断开TCP连接，此时发送一个包，其中，标志位FIN=1，发送序号Seq=y+1=501，Server进入LAST_ACK状态（确认请求）。
第四次挥手：客户A收到B的断开请求后，Client进入TIME_WAIT状态，接着发送一个确认包，标志位ACK=1，发送序号Seq=x+1=201，确认序号Ack=y+2=502；Server进入CLOSED状态（关闭）。

 

四次挥手图解：

 

问题：为什么连接的时候是三次，而断开的时候是四次？

    因为只有在客户端和服务端都没有数据要发送的时候才能断开TCP。而客户端发出FIN报文时只能保证客户端没有数据发了，服务端还有没有数据发客户端是未知的。而服务端收到客户端的FIN报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了，但我服务端还有一些数据没发完，等这些数据发完了服务端才能给客户端发FIN报文(所以不能一次性将确认报文和FIN报文发给客户端，就是这里多出来了一次)。
 

三次握手和四次挥手的本质:

三次握手的本质是确认双方收发数据的能力

四次挥手的目的就是关闭连接