TCP为什么三次握手四次挥手

╰半橙微兮° 2022-09-02 15:52 185阅读 0赞

## TCP为什么三次握手四次挥手。为什么不是四次握手或者五次挥手 ##

TCP 中的连接是什么，我们简单总结一下：用于保证可靠性和流控制机制的信息，包括 Socket、序列号以及窗口大小叫做连接。所以，建立 TCP 连接就是通信的双方需要对上述的三种信息达成共识，连接中的一对 Socket 是由互联网地址标志符和端口组成的，窗口大小主要用来做流控制，最后的序列号是用来追踪通信发起方发送的数据包序号，接收方可以通过序列号向发送方确认某个数据包的成功接收

## 1.为什么三次握手 ##

三次握手只是tcp中的约束，原因为了解决三个问题，初始化 Sockets、窗口大小、初始序列号并建立 TCP 连接。三次握手最终目的是保证发送方和接收方的请求都有来有回，即:也发送出去了，也接收到回复了。  
通过三次握手才能阻止重复历史连接的初始化；  
通过三次握手才能对通信双方的初始序列号进行初始化；  
讨论其他次数握手建立连接的可能性；  
这三个论点才是讨论为何需要三次握手的最主要原因，其他都是次要原因。

## 2.两次握手和四次握手行不行 ##

想象一下一种场景。因为tcp发包是不稳定的，会有网络的丢失，这就会使发送方进行重新发包。如果只是两次握手，那发送方在发送了第一次请求后因为网络原因未到达接收方，这时发送方会再次发送请求。如果接收方在建立了连接后，碰巧发送方第一次的发送请求有让接收方接收到了。那会不会产生同一个请求却建立了两个连接？那接收方只能在接受到请求方数据的时候必须选择接受或者拒绝连接请求。所以tcp需要三次握手建立连接并且引入RST确认消息。在接收方接受到消息后，返回给发送方SEQ+1,让发送方判断是否为历史消息。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Njc5NjIw_size_16_color_FFFFFF_t_70]

第一次：(A) –> \[SYN\] –> (B)  
A向B发起连接请求，以一个随机数初始化A的seq,这里假设为10000，此时ACK＝0  
第二次：(A) <– \[SYN/ACK\] <–(B)  
B收到A的连接请求后，也以一个随机数初始化B的seq，这里假设为20000，意思是：你的请求我已收到，我这方 的数据流就从这个数开始。B的ACK是A的seq加1，即10000＋1＝10001  
第三次：(A) –> \[ACK\] –> (B)  
A收到B的回复后，它的seq是它的上个请求的seq加1，即10000＋1＝10001，意思也是：你的回复我收到了，我这方的数据流就从这个数开始。A此时的ACK是B的seq加1，即20000+1=20001  
通过seq+1，也保证了双方序列号的问题，因为网络是不稳定的，可能第三个数据跑到了第二个前面，或者第三个数据发送了多次。这时接受放就可以根据回应的ack进行重复去重和重新排序，保证发包顺序。  
四次握手也是可以，只不过没必要，因为三次后双发就已经确定了连接和发包的顺序，就算再有网络不稳定，进行四次五次六次握手的结果和三次握手都是一样的。

## 3.为什么四次挥手 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Njc5NjIw_size_16_color_FFFFFF_t_70 1]

第一次：(A) –> \[FIN/ACK\] –> (B)  
客户端A没有要发送给服务端B的数据了，想要关闭链接，则发送一个FIN=1，ACK=1的包，告诉B可以关闭连接了，我没有什么数据要给你了。A会进入FIN\_WAIT\_1状态  
第二次：(A) <– \[ACK\] <– (B)  
然后B会发送ACK=1的包给A，告诉A我知道你没有什么想给我的了，但是我还有数据要给你，你先等下，我先不想FINISH呢。这时A会从FIN\_WAIT\_1变成FIN\_WAIT\_2状态。一直等待，如果这时候B跑路了，那A将永远停留在这个状态下。  
第三次：(A) <– \[FIN/ACK\] <– (B)  
等B把数据都发送给A之后，B会再次发送一个包，这次FIN=1，表示我这边也想关闭了，咱俩一起关把。在2和3之间，可能还会有很多B->A的传递，ack均为80001。  
第四次：(A) –> \[ACK\] –> (B)  
然后A回应一个ACK，表示我知道了，一起关吧。B收到这个ACK后，就会CLOSE。但是实际上A不会直接CLOSE，还会进入一个等待时间状态TIME\_WAIT，持续2倍的MSL（Maximum Segment Lifetime，报文段在网络上能存活的最大时间）。过了这个状态，才会CLOSE。  
第四次时，A客户端不能直接断开。原因在于如果A断开了访问，但是B之前丢失在路上包又到达A了，碰巧A已经删掉了这次连接，并且把这个端口赋给了新的应用。那这个请求是不是就到达了新的应用了而产生了错误？所以必须等到B的重复包一定死在了路上，A才能放心的断开连接。

## 4.三次挥手和五次挥手行不行 ##

三次挥手为何不靠谱，考虑一个场景。当第三次握手发生，也就是B发送给A，告诉A我也不玩了的时候。如果A收到了就断开，不回复B。如果B的请求包丢在了网络路上，但是B跑路了。A就会一直在这里等着，因为A没有收到B的断开请求。  
上段说过第四次时，A不能直接断开，原因也再次。如果第四次A给B发送的ack，B没有收到，这时A是不会断开的，需要等待一定时间，这个时间的长度是足够让B知道如果第四次挥手B没有收到，B会重新发送第三次挥手的信息到A的。所以五次挥手也只不过是浪费资源。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Njc5NjIw_size_16_color_FFFFFF_t_70]: /images/20220829/71cc7fc42760459cbfee22ed220432fa.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM1Njc5NjIw_size_16_color_FFFFFF_t_70 1]: /images/20220829/4f5d9c8cec1448b884824a32ab8bde9e.png