TCP为什么是三次握手不是两次

昨天回家，女盆友突然问了这么个问题——

“TCP为什么是三次握手而不是两次？”

我的表情是这样的。。。

于是赶紧研究了一波。。。。。。

经历一番折腾之后，终于参悟了其中秘密。

结论

先亮出大宝剑吧：

1. 为了防止已失效的连接请求发送到服务端，浪费资源。
2. 为了同步序列号，实现可靠传输。如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认。
3. 假定通过超时重传策略实现两次握手后双方都确认起时序列号，那么握手时间将增加，连接建立时间将变长。

cang老师大讲堂要开始啦，各位宝宝们赶快坐好。

课前准备

TCP 通信流程

上图中的每一个箭头都代表着一次 TCP数据包的发送

• 需要注意的是， 上图中出现的 ACK = x +1 的写法很容易让人误以为数据包中的 ACK 域的数据值被填成了 x+1 。 ACK = x+1 的实际含义是：
  • TCP 包的 ACK 标志位（1 bit） 被置成了 1
  • TCP 包的确认号（acknowledgement number, 表示希望收到的下一个包序号 ） 的值为 x+1，服务端希望接收到的下一个包序号为x +1
• 类似的， TCP 数据包中的 SYN 标志位， 也容易与序号（sequence number） 混淆，SYN seq = x表示SYN标志位置1，包序号为x。

TCP 三次握手，实际上就是通信双方互相确认初始序列号的过程。 TCP 协议为了实现可靠传输， 通信双方需要判断自己已经发送的数据包是否都被接收方收到， 如果没收到， 就需要重发。 为了实现这个需求， 很自然地就会引出序号（sequence number） 和 确认号（acknowledgement number） 的使用。
三次握手，恰好可以实现可靠传输，又能保证传输效率。

• 两次握手，无法实现可靠传输（或者说无法在保证效率的情况下实现可靠传输，后面会讲到快速重传问题）
• 四次握手，能三次实现的为什么要四次，脑子又没坑。。。

为什么不用两次握手？

原因一、不可靠

假定为两次握手
则交互如下：

TCP传输是可靠的，但没有第三次握手，Client不知道Server的初始序列号为6000，Client在接收到任何一个数据包后，都不知道是否应该上报——因为不知道到底的包是否为对方发送的第一个包。

能不能用两次握手让通信双方互相知道初始序列号呢，答案是可以：

假定Client在发出SYN请求之后，一定时间T1内未收到Server的SYN + ACK，则表示请求丢失或回复丢失，将超时重传；

• Client在收到SYN + ACK后，表示它知道Server已经收到SYN请求，且已得知序列号，连接基本建立完成。
• Server在收到SYN + ACK，并且回复后，在T2时间内，未收到同一个SYN请求，表示连接建立完成（当然也有可能是Client断网了，但这种情况在三次握手的情况下也会出现）。
  假定TCP使用两次握手的机制，让Server和Client互相知道初始序号，那么将增加连接建立的时间。

原因二、失效的连接请求占用资源问题

两次握手带来的另一个问题是失效连接会占用资源。

假定Client向Server发送了一个请求，但是该请求因为网络原因，在网路中逗留了一会儿，未及时送达。此时Client将再次向Server发送请求，Server接收到请求，发送确认包，完成连接并开始进行数据传输。数据传输完成后，断开连接。

但是断开连接后，Client的第一个请求兜兜转转，终于又找到server，此时Server将发送确认包，连接建立完成，但是Client已经完成了数据业务，并不会做任何事情，而Server还在等待进一步的数据交互——Server端的资源被白白浪费了。

但三次握手时，上述情况将不会发生，因为Client在第二次收到确认包时，不会做任何响应，连接将不会建立，某种程度上减少了资源的消耗。

reference

参考链接：
https://blog.csdn.net/lengxiao1993/article/details/82771768