服务器tcp第三次发送信息,TCP三次握手原因

众所周知，TCP建立连接时，需通过三次确认。

第一次

第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号(Synchronize Sequence Numbers)。

第二次

第二次握手：服务器收到syn包，必须确认客户的SYN(ack=j+1)，同时自己也发送一个SYN包(syn=k)，即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次

第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED(TCP连接成功)状态，完成三次握手。

完成三次握手，客户端与服务器开始传送数据：

其实，第二次握手的时候，已经能确立起一个通道，进行数据传输，为什么还要第三次确认呢？

关于第三次握手：

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

所谓“已失效的连接请求报文段”是这样产生的。考虑一种可能情况，A发起连接请求，但是因为连接请求报文丢失而未收到确认。于是A再重新传一次请求。后来收到了确认，建立连接。数据传输完毕后，就释放了连接。A工发送了两个连接请求报文段，其中第一个丢失，第二个到达了B。没有“已失效的连接请求报文段”。

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

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

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