TCP连接的三次握手过程，为什么不是两次或四次？

TCP的标记

标记	含义
URG	Urgent：紧急位， URG-1，表示紧急数据
ACK	Acknowledgement：确认位， ACK=1，确认号才生效
PSH	Push：推送位， PSH-1，尽快地把数据交付给应用层
RST	Reset：重置位， RST-1，重新建立连接
SYN	Synchronization：同步位， SYN=1表示连接请求报文
FIN	Finish：终止位， FIN=1表示释放连接

TCP连接中涉及到的标记有ACK、SYN、FIN

ACK是确认位，ack是确认号

三次握手的过程：

刚开始客户端和服务端都处于 CLOSED(关闭) 状态。本例中 客户端会（Client） 主动打开连接，服务端（Server） 被动打开连接。

一开始，服务端 的 TCP 服务器进程首先创建传输控制块TCB，准备接受客户端进程的连接请求。然后服务端进程就处于 LISTEN(监听) 状态，等待客户端的连接请求。如有，立即作出响应。

第一次握手：

• 客户端 的 TCP 客户端进程也是首先创建传输控制块 TCB。建立连接时发送SYN会选择一个初始序号（ISN），每个连接的ISN都是不同的。客服端发送一个数据包（SYN = 1，seq = x）到服务器，并进入同步已发送状态，等待服务端确认。

第二次握手：

• 服务器收到数据包之后，必须确认客户端的SYN（ACK = 1，ack = x + 1），同时自己也发送一个SYN包（SYN = 1，初始序号 seq = y），即SYN+ACK包， 此时服务器进入同步收到状态。

第三次握手：

• 客户端收到服务器的SYN＋ACK包。向服务器发送确认包（ACK=1，ack=y + 1)，自己的序号 seq = x + 1；发送完之后，客户端和服务器进入已建立连接状态，完成三次握手。

以上就是TCP三次握手的过程。

三次握手可以想象两个人在打电话；A：喂，能听到吗？，B：听得到，你能听到吗？A… B…

三次握手的作用：

• 可以确认双方的接受能力、发送能力是否正常。
• 指定自己的初始化序列号，为后面的可靠传送做准备。

思考为什么不是两次握手？

• 为了防止已经失效的连接请求报文段传送到接收方，引起错误。
  
  如果是用两次握手，考虑如下场景：

• 发送方先向接收方发送了一个报文，但是这个报文过了很久还没有到达接收方，发送方很久都没有收到确认消息，那么发送方会认为第一个发送报文超时，会发送第二次同样的报文

• 假设第二次发送建立起了连接；那么此时对于第一个超时请求的报文来说，它就是一个失效的请求报文，因为其功能已经被第二次发送的请求所完成

• 但如果后续这个失效的请求报文到达了接收方，并且接收方回应，此时又会建立一次连接

• 对于两次握手，只要服务器回应，就代表建立起连接，同样的请求，发送了两次，建立了两个连接

三次握手为何能解决

• 对于三次握手，服务器的确认会发送给发送方，发送方会再发送一个报文表示确认，代表第三次握手
• 考虑迟到失效的请求报文，接收方接收到之后会向发送方发送方确认，但是发送方已经进行了第三次握手，所以发送方会忽略掉第二次的确认消息
• 后面到达接收方的重复确认，发送方并没有进行第三次握手，这样就避免了两次握手会引发的错误。避免失效的请求到达对方而引发错误

为什么不是四次握手？

第三次握手时，客户端向服务端发送确认，如果这个确认包丢失或者滞留了会怎样？

在经过三次握手之后，已经可以确认发送方和接收方的接收能力、发送能力都正常，四次握手又会浪费资源。完全可靠的通信协议是不存在的，所以即便再增加握手次数也不能保证后面的通信完全可靠，所以是没有必要的。

四次握手就相当于：

A：”喂，你能听到我说话吗“

B：“我能听到，你听的到我吗”

A：“我听的到，你能听到我吗”

B：”不跟傻子说话“