TCP三次握手_三次握手

首先:客户端和服务器端都处于关闭状态,客户端主动打开,服务器被动打开

(1)服务器创建tcb(传输控制块),等待接收客户端的请求,处于listen状态

(2)客户端也创建tcb(传输控制块)。想服务器发送请求报文段,这是首部的SYN设置为1,同时选择一个初序号x,seq=x,TCP规定SYN报文段(SYN=1)不能携带数据,但是需要消耗一个序号,同时TCP进入SYN_send状态

(3)客户端接收到了请求报文段的时候,发送确认报文,将ACK=1,SYN=1,确认序号ack=x+1(因为上一次消耗了一个序号,所以服务器希望客户端下次从x+1的序号开始发送数据),同时为自己设置一个序号(seq=1),发送后自己处于SYN_RECV状态,因为这个时候也不能携带数据,但是还是需要消耗一个序号

(4)客户端接收后,在继续向服务器发送一个确认报文,ACK=1,因为这个时候没有SYN,所以可以携带数据,也可以不携带数据,但是不携带数据的话也不会再向前两次消耗一个序号了。seq=x+1(因为上一次确认序号是x+1),ack=y+1(希望服务器下一次从y+1开始发送数据)这个结束后A进入ESTABLISHED(已建立连接状态)

(5)B接收到后也进入了已建立连接状态

 

为什么不是两次握手而是三次握手

“已失效的连接请求报文段”的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送ack包。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。

同时如果没有向上面的情况有先后达到,如果两个同时到达的话,可能会发生死锁的情况