【TCP/IP】三次握手过程及原因

三次握手

三次握手 建立起 TCP连接 的 reliable，分配初始序列号和资源，在相互确认之后开始数据的传输。有 主动打开(一般是client) 和 被动打开(一般是server)。

TCP使用3次握手建立一条连接，该握手初始化了传输可靠性以及数据顺序性必要的信息，这些信息包括两个方向的初始序列号，确认号由初始序列号生成，使用3次握手是因为3次握手已经准备好了传输可靠性以及数据顺序性所必要的信息，该握手的第3次实际上并不是需要单独传输的，完全可以和数据一起传输。详细过程如下所示：

第一步，Client会进入SYN_SENT状态，并发送Syn 消息给Server端，SYN标志位在此场景下被设置为1，同时会带上Client这端分配好的Seq号，这个序列号是一个U32的整型数，该数值的分配是根据时间产生的一个随机值，通常情况下每间隔4ms会加1。除此之外还会带一个MSS，也就是最大报文段长度，表示Tcp传往另一端的最大数据块的长度。

第二步，Server端在收到，Syn消息之后，会进入SYN_RCVD状态，同时返回Ack消息给Client，用来通知Client，Server端已经收到SYN消息并通过了确认。这一步Server端包含两部分内容，一部分是回复Client的Syn消息，其中ACK=1，Seq号设置为Client的Syn消息的Seq数值+1；另一部分是主动发送Sever端的Syn消息给Client，Seq号码是Server端上面对应的序列号，当然Syn标志位也会设置成1，MSS表示的是Server这一端的最大数据块长度。

第三步，Client在收到第二步消息之后，首先会将Client端的状态从SYN_SENT变换成ESTABLISHED,此时Client发消息给Server端，这个方向的通道已经建立成功，Client可以发送消息给Server端了，Server端也可以成功收到这些消息。其次，Client端需要回复ACK消息给Server端，消息包含ACK状态被设置为1，Seq号码被设置成Server端的序列号+1。（备注：这一步往往会与Client主动发起的数据消息，合并到一起发送给Server端。）

第四步，Server端在收到这个Ack消息之后，会进入ESTABLISHED状态，到此时刻Server发向Client的通道连接建立成功，Server可以发送数据给Client，TCP的全双工连接建立完成。

换个易于理解的视角来看为什么要3次握手

客户端和服务端通信前要进行连接，“3次握手”的作用就是双方都能明确自己和对方的收、发能力是正常的。

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。 从客户端的视角来看，我接到了服务端发送过来的响应数据包，说明服务端接收到了我在第一次握手时发送的网络包，并且成功发送了响应数据包，这就说明，服务端的接收、发送能力正常。而另一方面，我收到了服务端的响应数据包，说明我第一次发送的网络包成功到达服务端，这样，我自己的发送和接收能力也是正常的。

第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力，服务端的发送、接收能力是正常的。 第一、二次握手后，服务端并不知道客户端的接收能力以及自己的发送能力是否正常。而在第三次握手时，服务端收到了客户端对第二次握手作的回应。从服务端的角度，我在第二次握手时的响应数据发送出去了，客户端接收到了。所以，我的发送能力是正常的。而客户端的接收能力也是正常的。

经历了上面的三次握手过程，客户端和服务端都确认了自己的接收、发送能力是正常的。之后就可以正常通信了。

每次都是接收到数据包的一方可以得到一些结论，发送的一方其实没有任何头绪。我虽然有发包的动作，但是我怎么知道我有没有发出去，而对方有没有接收到呢？

而从上面的过程可以看到，最少是需要三次握手过程的。两次达不到让双方都得出自己、对方的接收、发送能力都正常的结论。其实每次收到网络包的一方至少是可以得到：对方的发送、我方的接收是正常的。而每一步都是有关联的，下一次的“响应”是由于第一次的“请求”触发，因此每次握手其实是可以得到额外的结论的。比如第三次握手时，服务端收到数据包，表明看服务端只能得到客户端的发送能力、服务端的接收能力是正常的，但是结合第二次，说明服务端在第二次发送的响应包，客户端接收到了，并且作出了响应，从而得到额外的结论：客户端的接收、服务端的发送是正常的。

这里有个小细节，第三次握手是可以携带数据的，这是面试常问的点。

那么为什么要三次握手呢？两次不行吗？

• 为了防止服务器端开启一些无用的连接增加服务器开销

• 防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

由于网络传输是有延时的(要通过网络光纤和各种中间代理服务器)，在传输的过程中，比如客户端发起了 SYN=1 的第一次握手。

如果服务器端就直接创建了这个连接并返回包含 SYN、ACK 和 Seq 等内容的数据包给客户端，这个数据包因为网络传输的原因丢失了，丢失之后客户端就一直没有接收到服务器返回的数据包。

如果没有第三次握手告诉服务器端客户端收集到服务器端传输的数据的话，服务器端是不知道客户端有没有接收到服务器端返回的信息的。服务端就认为这个连接是可用的，端口就一直开着，等到客户端因超时重新发出请求时，服务器就会重新开启一个端口连接。

这样一来，就会有很多无效的连接端口白白地开着，导致资源的浪费。

这个过程可理解为：

还有一种情况是已经失效的客户端发出的请求信息，由于某种原因传输到了服务器端，服务器端以为是客户端发出的有效请求，接收后产生错误。
所以我们需要“第三次握手”来确认这个过程：

通过第三次握手的数据告诉服务端，客户端有没有收到服务器“第二次握手”时传过去的数据，以及这个连接的序号是不是有效的。若发送的这个数据是“收到且没有问题”的信息，接收后服务器就正常建立 TCP 连接，否则建立 TCP 连接失败，服务器关闭连接端口。由此减少服务器开销和接收到失效请求发生的错误。

参考