TCP协议的三次握手建立连接及四次握手断开连接

转自 教学网站—网络教学基地

1、TCP三次握手详细图解

TCP是因特网中的传输层协议，使用三次握手协议建立连接，下面是TCP建立连接的全过程。

TCP三次握手详细图解

 

　　上图画出了TCP建立连接的过程。假定主机A是TCP客户端，B是服务端。最初两端的TCP进程都处于CLOSED状态。图中在主机下面的是TCP进程所处的状态。A是主动打开连接，B是被动打开连接。

　　首先A向B发出连接请求报文段，这时首部中的同步位SYN=1，同时选择一个初始序号seq=x。TCP规定，SYN报文段不能携带数据，但要消耗掉一个序号。这时，A进入SYN-SENT状态。

　　B收到请求后，向A发送确认。在确认报文段中把SYN和ACK位都置为1，确认号是ack=x+1,同时也为自己选择一个初始序号seq=y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时B进入SYN-RCVD状态。

　　A收到B的确认后，还要向B给出确认。确认报文段的ACK置为1，确认号ack=y+1，而自己的序号seq=x+1。这时，TCP连接已经建立，A进入ESTABLISHED状态，当B收到A的确认后，也会进入ESTABLISHED状态。

　　以上给出的连接建立过程就是常说的TCP三次握手。

　　为什么A还要发送一次确认呢?这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。

　　所谓已失效的连接请求报文段是这样产生的。A发送连接请求，但因连接请求报文丢失而未收到确认，于是A重发一次连接请求，成功后建立了连接。数据传输完毕后就释放了连接。现在假定A发出的第一个请求报文段并未丢失，而是在某个网络节点长时间滞留了，以致延误到连接释放以后的某个时间才到达B。本来这是一个早已失效的报文段。但B收到此失效的连接请求报文段后，就误以为A又发了一次新的连接请求，于是向A发出确认报文段，同意建立连接。假如不采用三次握手，那么只要B发出确认，新的连接就建立了。

　　由于A并未发出建立连接的请求，因此不会理睬B的确认，也不会向B发送数据。但B却以为新的运输连接已经建立了，并一直等待A发来数据，因此白白浪费了许多资源。

采用TCP三次握手的方法可以防止上述现象发生。例如在刚才的情况下，由于A不会向B的确认发出确认，连接就不会建立。下面留个思考题给大家：如果在TCP第三次握手中的报文段丢失了会发生什么情况?

 

2、TCP断开连接过程：TCP四次挥手详解

上次我们讲了TCP三次握手建立连接的过程，今天我们结合双方状态的改变来讲讲TCP断开连接的过程：TCP四次挥手。

TCP四次挥手断开连接图解

　　数据传输结束后，通信的双方都可释放连接。现在A和B都处于ESTABLISHED状态。A的应用程序先向TCP发出连接释放报文段，主动关闭TCP连接。A把连接释放报文段的首部FIN置为1，序号seq=u，它等于前面已传送过的数据的最后一个字节的序号加1。这时A进入FIN-WAIT-1状态，等待B的确认。

　　B收到连接释放报文段后即发出确认，确认号是ack=u+1，而这个报文段自己的序号是v，等于B前面已传送过的数据的最后一个字节的序号加1。然后B就进入CLOSE-WAIT状态。TCP服务器进程这时通知高层应用进程，因为从A到B这个方向的连接释放了，这时的TCP连接处于半关闭状态，即A已经没有数据要发送了，但B若发送数据，A仍要接受。也就是说，从B到A这个方向的连接并未关闭。这个状态可以会持续一些时间。

　　A收到B的确认后，就进入FIN-WAIT-2状态，等待B发出的连接释放报文段。

　　若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使用FIN=1。现假定B的序号为w(在半关闭状态B可能又发送了一些数据)。B还必须重复上次已发送过的确认号ack=u+1。这是B就进入LAST-ACK状态，等待A的确认。

　　在A收到B的连接释放报文段后，必须对此发出确认。在确认报文段中把ACK置为1，确认号ack=w+1，而自己的序号是seq=u+1(前面的FIN报文消耗了1个序号)。然后进入TIME-WAIT状态。请注意，现在TCP连接还没释放掉。必须再经过2MSL后，A才进入到CLOSED状态。MSL叫最长报文段寿命，一般为2分钟。

当B收到A发出的确认，就进入CLOSED状态。由此可见B结束TCP连接的时间要比A早一些。等到2MSL结束后A也进入CLOSED状态，至此完成了TCP四次挥手断开连接全过程。