TCP连接建立的三次握手过程介绍及使用原因分析

大致流程（三个步骤）

第一步： 客户端的TCP向服务器端的TCP发送一个连接请求报文段，其中同步位SYN置为1，客户端会随机选择一个起始序号，图中的起始序号为n
PS：当SYN=1，ACK=0即ACK不作处理时，表明这是一个连接请求报文，连接请求报文不携带数据，但要消耗一个序号

第二步： 服务器端的TCP收到连接请求报文段（根据SYN和ACK置位情况判断）后，如果同意建立连接，就向客户端发回确认，并为该TCP连接分配TCP缓存和变量。在确认报文段中，同步位SYN和确认位ACK都置为1，表明该报文是确认报文，同时确认号字段根据请求报文的序号确定（如上一步序号是n，那对应的确认号字段的值为n+1），并且服务器端也随机产生起始序号seq（如图中seq为k）
PS：确认报文不携带数据，但要消耗一个序号

第三步： 客户端收到确认报文后，向服务器端给出确认，并且开始为该连接分配缓存和变量。该报文段的确认位ACK置为1，序号字段seq=n+1（因为上一个是n），确认号字段ack=k+1（因为服务器端发来的序号为k）
PS：该报文段可以携带数据

Question：为什么不采用“两次握手”建立连接？
因为“两次握手”可能会导致连接发生死锁。
例如，计算机A和B进行通信，A向B发送一个连接请求报文，B收到后发送一个确认报文。按照“两次握手”的规则，B端已经认为连接已经建立，可以开始发送数据报文。但如果该确认报文在传输过程中丢失了，A将不知道B是否准备好，也不知道B发送数据使用的起始序列号，甚至认为自己的请求报文在传输中丢失了。这样一来，A认为连接未建立好，将忽略B发来的任何数据报文，只等待连接确认报文。而B在报文超时后，重复发送同样的数据报文，等待A对数据报文的确认。