TCP的三次握手

TCP的运输连接管理

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

连接建立——三次握手

在TCP连接建立过程中要解决以下三个问题：

1. 要使每一方都能确知对方的存在
2. 要允许双方协商一些参数（如最大窗口值、是否使用窗口扩大选项…）
3. 能够对运输实体资源（如缓存大小、连接表中的项目等）进行分配

三次握手其实就是在建立一个TCP连接时，需要客户端和服务器共计发送三个报文段。

进行三次握手的目的就是：确认双方的发送与接受正常、指定各自的初始化序列号等为后面的可靠传输做准备。

具体过程：

最初两端TCP进程都处于关闭状态，开始时 B 的TCP服务器进程先创建传输控制块TCB，进入LISTEN状态；A 的TCP客户进程创建传输控制块TCB

• 第一次握手：客户端发送连接请求报文 将同步位 SYN = 1 和初始序列号 seq = x 发送给服务端，发送完之后客户端处于SYN_SEND 状态。

  TCP规定：SYN=1 的报文段不能携带数据，但要消耗掉一个序号。

• 第二次握手：服务端收到 SYN 请求报文之后，如果同意连接，则会以自己的同步序列号 SYN = 1 、初始序列号 seq = y 、确认 ACK = 1 和确认序列号（期望下次收到的数据包） ack = x+1 报文作为应答，服务器为SYN_RECEIVE 状态。

  （两次握手之后，站在客户端角度上思考：我发送和接收都ok，服务端的发送和接收也都ok，应该是可以传送数据了。但是站在服务端的角度思考：哎呀，我服务端接收ok，但是我不清楚我的发送ok不ok呀，而且我还不知道你接受能力如何呢？所以老哥，你需要给我三次握手来传个话告诉我一声。你要是不告诉我，万一我认为你跑了，然后我可能出于安全性的考虑继续给你发一次，看看你回不回我。）

• 第三次握手： 客户端接收到服务端的确认后，向服务端发送含有 确认ACK = 1 、确认序列号 ack = y + 1 以及序号 seq = x + 1 的确认报文段作为应答，客户端进入ESTABLISHED状态。

  （TCP标志规定，ACK报文段可以携带数据，但如果不携带数据下一个数据报文段的序号仍为 seq = x + 1 。）

为什么需要三次握手而不是两次？

弄清这个问题，需先弄明白三次握手的目的是什么，能不能只用两次握手来达到同样的目的。

• 第一次握手：客户端发送网络包，服务端收到了。 这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
• 第二次握手：服务端发包，客户端收到了。 这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
• 第三次握手：客户端发包，服务端收到了。 这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

因此，需要三次握手才能确认双方的接收与发送能力是否正常。

如果使用两次握手，可能会出现下面这种情况：

客户端发出连接请求，但因连接请求报文在某些网络结点长时间滞留了，客户端并不知情重新发送一个连接请求并收到确认，建立了连接，数据传输完毕后，就释放了连接。结果！！！在释放连接后，客户端第一次发送的那个请求报文又神奇般的到达了服务端。好吧，服务端误以为这是客户端又发出的一次新的连接请求，就同意建立新的连接了，此时客户端认为并没有发送连接请求啊，当然会忽略服务端发来的确认，也不会发送数据，而可怜的服务端以为新的运输连接建立了，一直等待客户端发送数据，就这样服务端的许多资源白白浪费了。