一篇带你掌握TCP连接管理——三次握手

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

这里我们讨论TCP连接的建立：三次握手

首先看图解：

第一次握手：

• 客户端向服务器端发送请求，

     此时首部中的同步位SYN=1，（当SYN=1,表示这是一个请求报文段。对方若同意连接，则在响应的报文段中使用SYN=1和ACK=1）

     同时选择一个初始序号seq=x；（表示发送的序列，可以通过这个序号检测传输过程是否丢包）

第二次握手：

• 服务器收到请求包文段后，如果同意建立连接，则向客户端发送确认。

     上一步所示，如果同意首先要返回SYN=1和ACK=1

      然后返回确认号ack=x+1，（确认号，表示期望收到对方下一个报文段的第一个数据字节的序号）

      同时给自己选择一个初始序列号seq=y

第三次握手：

• 此时客户端已经知道可以向服务器发送数据，并且能够接收服务器端的数据，
• 但是服务器仅仅知道能够接收客户端发送的消息，自己发送的数据不知道客户端是否能接收到，因此还需要第三次握手
• 客户端收到服务器的确认后，还要向服务器给出确认

      此时已经知道能够连接，就不需要请求报文段SYN了

      此时返回确认报文段ACK=1，

      返回确认号，即ack=y+1，（希望服务器下一个发送报文段的第一个数据字节的序号）

      同时自己的序号seq=x+1

上面就是三次握手的三个部分。

---

三次握手的原因？为什么不是两次

三次握手可以防止已经失效的连接请求报文突然又传输到服务器导致的服务器资源浪费

tcp是全双工通信，两次握手只能确定单向数据链路是可以进行通信的，并不能保证反向的通信正常。

eg：

客户端先发送了一个SYN，但是由于网路阻塞，该SYN数据包在某个节点长期滞留。

然后客户端又重传SYN数据包并正确建立TCP连接，然后传输完数据包后关闭该连接。该连接释放后失效的SYN数据包才到达服务器端。

在二次握手的前提下，服务器会认为这是客户端发起的又一次请求，然后发送SYN，并且在服务器端创建socket套接字，一直等待客户端发送数据。
         由于客户端并没有发起新的请求，所以会丢弃服务器的SYN。此时服务器会一直等待客户端发送数据从而造成资源浪费

但是如果是三次握手，此时当客户端收到SYN后，并不会直接丢弃，而是再次向服务器发送RST报文，表示终止，服务器接收到消息之后就会把新创建的socket套接字释放，从而避免了资源浪费。

---

为什么不是四次？

本来握手和挥手一样都是需要确认两个方向都能联通的，本来模型应该是：

1. 客户端发送syn0给服务器
2. 服务器收到syn0，回复ack（syn0+1）
3. 服务器发送syn1
4. 客户端收到syn1，回复ack（syn1+1）

因为tcp是全双工的，上边的四步确定了数据在两个方向上都是可以正确到达的，但是2，3步没有上下的联系，可以将其合并，加快握手效率，所以就变成了三次握手。