TCP的三次握手 四次挥手

为什么是三次握手

确认通信能力

我们要明白，如果需要进行通信，首先需要保证的是双方都具有发信和收信能力。在不知双方能力状态下进行的通信都是无法保证可靠性和通信效率的。那么通信双方如何确认对方的通信能力呢？

1. A请求B进行连接。（B已确认B的收信能力和A的发信能力）
2. B返回ACK相应。（A已确认双方的收发能力）
3. A返回ACK并建立连接。（B确认双方收发能力） 上面可以看到，至少是进行三次握手，才能确认双方能力。

防止产生脏数据连接

网络通信情况复杂，不可能保证每一消息都能正常到达其目的地。在TCP连接中，TTL的网络报文的生存时间一般都会比TCP的连接超时时间要长。这样就有可能出现一个问题。A在发送第一次连接请求时，可能网络拥塞，导致数据包未短时间内到达。到达超时时间后，A又发送了一次连接请求，这次正常进行连接。连接结束断开后，A的第一次连接请求到达B，B返回ack。如果是两次握手，A通过当前的状态，直接拒绝B的请求，但B会单方面认为连接已经建立，实际上并不是...

第一次握手

• 首先会将TCP的header部分的控制位（上图的flags）中的SYN置为1。表示希望建立连接。
• 还有一个重要的数据，seq，即序号。这个东西是干嘛用的呢？这个涉及到TCP安全性和可靠性，与ack即确认号紧密相关。TCP在传输数据时，如果数据比较大，会进行拆分操作，将大数据拆成一个个小的数据包。序号就是在这个时候用的。我们必须要知道这个包的顺序是什么，才能把真正的数据在服务端还原。seq的顺序并不是从0或者1开始的，而是一个随机值。因为如果序号从1开始，那么整个通信的过程非常容易被预测。正因为是随机的，所以对方不知道你的seq，所以我们需要在开始收发数据之前，将seq先发送给对方。序号的初始值的传递就是通过SYN=1的操作传递的。

客户端此时处于同步状态，即可以建立连接。服务端处于监听状态。

第二次握手

• 标志位。因为已经收到了客户端的建立连接请求。所以必须要发送ack，以告知客户端自己已经收到消息。所以ACK的标志位要置为1，且SYN也是1，因为还未建立连接。
• seq。同第一次握手一样，也是一个随机值（TCP为全双工，所以双方都需要保留seq方便处理数据包）。
• ack。是对客户端发过来的序列号进行计算得到的。

服务端处于SYN接收状态。

第三次握手

• 标志位。此时只需要ACK=1。SYN已经不需要了，双方已经同步完seq等信息。
• seq。可以说是第二次握手收到的ack。
• ack。是对第二次握手收到的序列号进行计算得到的。用以告知已收到二次握手信息。

客户端处于连接建立状态，服务端收到信息之后也会进入连接建立状态，双方可以进行通信。

四次挥手

TCP连接在数据传输完成之后需要关闭，不然会一直占用系统资源。TCP的连接关闭需要四次通信才行，分手也是个麻烦事儿。

为什么四次才能断开连接呢？

分手这件事情，两边都说明白，分别断开即可。但是想要确认对方都要断开，那么一次两次是不够的。

.

四--能否只有两次握手？

答案肯定是不能。看下图

红线部分为一个迟到的连接请求，并且重传计时器结束了他还没有到达，于是发生重传（黑线）。

若只有两次握手，当迟到的到达后，接收方收到了，然后就按规矩建立连接，安排专人（资源）去等待发送方发送数据。但是发送方已经重传过了，他并不知道这个迟到的请求到达了（他也以为重传过了就不会再有重复请求到达），于是接收方就这样傻傻的等待。

 三次握手能防止已失效的连接请求报文段突然又传到TCP服务器，导致错误，浪费资源。

原文

https://blog.csdn.net/weixin_44865458/article/details/117234974?utm_medium=distribute.pc_relevant.none-task-blog-2~default~baidujs_baidulandingword~default-1-117234974-blog-121859889.pc_relevant_default&spm=1001.2101.3001.4242.2&utm_relevant_index=4