TCP/IP三次握手详解——计算机网络

TCP的运输连接管理

TCP是面向连接的协议。运输连接是用来传送TCP报文的。

TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。

运输连接有三个阶段：连接建立、数据传送、连接释放

下图是这三个阶段的示意图：

连接的建立

TCP的连接采用客户服务器的方式。

主动发起连接建立的应用进程叫做客户（client）

被动等待连接建立的应用进程叫做服务器（server）

下面描述连接建立的过程：

假定主机A是客户端、主机B是服务端。

初始状态：A和B都是处于closed关闭状态。

操作：A主动打开连接，B被动打开连接

过程：

1. A的TCP客户进程首先创建传输控制模块TCB，然后向B发出连接请求报文。首部中同步位SYN=1，序列号seq=x.  TCP 规定，SYN报文段（SYN=1的报文段）不能够携带数据，但是要消耗一个序列号。发送完之后，A进入SYN-SENT状态。（同步已发送状态）。
2. B收到连接请求报文段后，如同意建立连接，就向A发送确认。确认字段中把 SYN 和 ACK 都置为1，确认号是ack=x+1，同时也为自己选择一个序列号：seq=y.  请注意，这个报文段也不能够携带数据，但是要消耗序列号。发送完之后，B进入SYN-RCVD状态（同步收到状态）。
3. A收到B的确认之后，还要向B给出确认。确认报文的ACK置为1，确认号ack=y+1，而自己的序号为seq=x+1。TCP标准规定，ACK报文可以携带数据，但是如果不携带数据则不消耗序号，在这种情况下，下一个数据报文的序号仍然是seq=x+1。发送完毕之后，TCP连接建立。A进入ESTABLISHED状态，B收到A的确认之后，也进入ESTABLISHED状态。

此时，三次握手完成。

问题：为什么A最后还要发送一次确认呢？

答案：这主要是为了防止已经失效的连接请求报文段突然又传送到B，因而产生错误。

所谓“已经失效的连接请求报文段”是这样产生的。

考虑一种正常情况，A发出连接请求，但因连接请求报文丢失而未收到确认。于是，A再重传一次连接请求，这次收到了确认，建立了连接。数据传输完毕之后，就释放了连接。

A总共发送了两次连接请求报文段，其中第一个丢失了，第二个到达了B. 此时没有已经失效的连接请求报文段。

现在考虑一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某些网络结点长时间滞留了，以致延误到连接释放之后的某个时间才到达B。本来这是一个已经失效的报文段。但B收到此失效的连接请求报文段之后，就误认为是A又发出一次连接请求。于是向A发出确认报文段，同意建立连接。假定不采用三次握手，那么只要B收到连接请求报文段，新的连接就建立了。

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

采用三次握手的办法可以防止以上现象的发生。例如在刚才情况下，A不会向B的确认发出确认，B由于收不到确认，就知道A并没有要求建立连接。