TCP 三次握手协议简介,为什么不是二次握手？

【摘要】本文记录一下 TCP 的三次握手协议，及为什么不是二次握手~

SYN（synchronous）是TCP/IP建立连接时使用的握手信号。在客户机和服务器之间建立正常的TCP网络连接时，客户机首先发出一个SYN消息，服务器使用SYN+ACK应答表示接收到了这个消息，最后客户机再以ACK消息响应。这样在客户机和服务器之间才能建立起可靠的TCP连接，数据才可以在客户机和服务器之间传递。

ACK (Acknowledgement）即是确认字符，在数据通信中，接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误。在TCP/IP协议中，如果接收方成功的接收到数据，那么会回复一个ACK数据。通常ACK信号有自己固定的格式,长度大小,由接收方回复给发送方。

TCP连接的第一个包，非常小的一种数据包。SYN 攻击包括大量此类的包，由于这些包看上去来自实际不存在的站点，因此无法有效进行处理。每个机器的欺骗包都要花几秒钟进行尝试方可放弃提供正常响应。

从图中，可以看出三次握手的基本步骤是：

第一次握手：客户端向服务器端发送连接请求包SYN（syn=j），等待服务器回应；

第二次握手：服务器端收到客户端连接请求包SYN（syn=j）后，将客户端的请求包SYN（syn=j）放入到自己的未连接队列，此时服务器需要发送两个包给客户端；

（1）向客户端发送确认自己收到其连接请求的确认包ACK（ack=j+1），向客户端表明已知道了其连接请求

（2）向客户端发送连接询问请求包SYN（syn=k），询问客户端是否已经准备好建立连接，进行数据通信；

即在第二次握手时服务器向客户端发送ACK（ack=j+1）和SYN（syn=k）包，此时服务器进入SYN_RECV状态。

第三次握手：客户端收到服务器的ACK（ack=j+1）和SYN（syn=k）包后，知道了服务器同意建立连接，此时需要发送连接已建立的消息给服务器；

向服务器发送连接建立的确认包ACK（ack=k+1），回应服务器的SYN（syn=k）告诉服务器，我们之间已经建立了连接，可以进行数据通信。

ACK（ack=k+1）包发送完毕，服务器收到后，此时服务器与客户端进入ESTABLISHED状态，开始进行数据传送。

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

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

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

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

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

我要打赏