TCP三次握手两种角度解释

第一种：从三次握手可以建立连接的层面上解释

这里先给出结论：

为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤
如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认
先修知识

为什么 TCP 需要握手这个操作
在解答为什么 TCP 需要三次握手， 而不是两次之前， 首先需要回答的问题是:

为什么需要握手这个操作， 能不能不握手？
如果读者对比一下 UDP 的通信流程和 TCP 的通信流程， 可以发现， 在 UDP 协议中， 是没有握手这个操作的。

这里就引出了 TCP 与 UDP 的一个基本区别， TCP 是可靠通信协议， 而 UDP 是不可靠通信协议。

TCP 的可靠性含义： 接收方收到的数据是完整， 有序， 无差错的。
UDP 不可靠性含义： 接收方接收到的数据可能存在部分丢失， 顺序也不一定能保证。
UDP 和 TCP 协议都是基于同样的互联网基础设施， 且都基于 IP 协议实现， 互联网基础设施中对于数据包的发送过程是会发生丢包现象的， 为什么 TCP 就可以实现可靠传输， 而 UDP 不行？

TCP 协议为了实现可靠传输， 通信双方需要判断自己已经发送的数据包是否都被接收方收到， 如果没收到， 就需要重发。 为了实现这个需求， 很自然地就会引出序号（sequence number） 和 确认号（acknowledgement number） 的使用。

发送方在发送数据包（假设大小为 10 byte）时， 同时送上一个序号( 假设为 500)，那么接收方收到这个数据包以后， 就可以回复一个确认号（510 = 500 + 10） 告诉发送方 “我已经收到了你的数据包， 你可以发送下一个数据包， 序号从 510 开始” 。

这样发送方就可以知道哪些数据被接收到，哪些数据没被接收到， 需要重发。

为什么需要三次握手，而非两次
正如上文所描述的，为了实现可靠传输，发送方和接收方始终需要同步( SYNchronize )序号。 需要注意的是， 序号并不是从 0 开始的， 而是由发送方随机选择的初始序列号 ( Initial Sequence Number, ISN )开始 。 由于 TCP 是一个双向通信协议， 通信双方都有能力发送信息， 并接收响应。 因此， 通信双方都需要随机产生一个初始的序列号， 并且把这个起始值告诉对方。

 

第二种：从两次握手可以建立连接层面上解释

TCP的连接因为是全双工的，也就是Client和Server两端，发送消息两个方向的连接都要建立成功。如果要保证双向连接都成功的话，三次通信是最少的次数了。大于三次的话，后面的次数通信就没有必要了，是在浪费资源。

二次的话，会怎么样，可不可以呢？答案是不可以，我们来看下，下面的场景。
在谈论这个之前，我们先要知道TCP是基于IP协议的，而IP协议是有路由的，IP协议不能够保证先发送的数据先到达，这当中依赖于IP协议底层的网络质量，以及Client与Server之间的路由跳数。
Client在发送完Syn消息1，这里称作Syn1之后，假设因为网络原因，Syn1并没有到达Server端，这个时候Client端已经超时，Client之后重新发起SYN消息，这里称作Syn2。结果由于网络原因Syn2先到答Server，Server于是与Client基于Syn2建立了连接，结果没过多久Syn1又到达了Server,Server于是关掉了Syn2建立的那条连接，又重新建立了一条连接。对于Client来说新建立的这条连接是早就过时的，所以Client不会在这条连接上发送任何数据，这就导致了Server端长时间收不到数据，Client新的连接被断掉了。

三次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

三次握手的状态转换？
TCP的状态变化图如下所示，Client和Server的初始状态都是CLOSED状态，其中：
Client:
CLOSED-----发送Syn 消息--->SYN_SENT-----收到Server端发回的SYN+ACK--->ESTABLISHED---发送和接收数据-->......
Server:
CLOSED----收到Client端发送过来的SYN消息-->SYN_RCVD-----发送SYN+ACK消息--->SYN_RCVD----收到Client发回来的ACK消息--->ESTABLISHED-----发送和接收数据-->......

其中TCP的三次握手与Scoket的函数对应关系如下所示：

备注：connect时，触发了连接请求，向服务器发送了SYN J包，这时connect进入阻塞状态；服务器监听到连接请求，即收到SYN J包，调用accept函数接收请求向客户端发送SYN K ，ACK J+1，这时accept进入阻塞状态；客户端收到服务器的SYN K ，ACK J+1之后，这时connect返回，并对SYN K进行确认；服务器收到ACK K+1时，accept返回，至此三次握手完毕，连接建立