【计算机网络】TCP三次握手四次挥手（超级详细）

ゝ一纸荒年。 2024-04-22 22:22 67阅读 0赞

## ![17d94e1d1ee74e6a8d951c2209153c18.gif][] ##

> **文章目录**
> 
> 引入
> 
> 一、三次握手和四次挥手的简单介绍
> 
> 二、三个标记位
> 
> 三、三次握手和四次挥手的过程详解
> 
> 3、1 三次握手
> 
> 3、1、1 三次握手后连接就一定建立成功了吗 
> 
> 3、1、2 握手时产生的状态是什么意思
> 
> 3、2 为什么是三次握手
> 
> 3、2、1 一次握手不行吗
> 
> 3、2、2 两次握手为什么不行
> 
> 3、2、3 四次握手也不行
> 
> 3、3 四次挥手
> 
> 3、3、1 TIME\_WAIT状态和CLOSE\_WAIT状态
> 
> 3、3、2 为什么要存在 TIME\_WAIT 状态
> 
> 3、3、3 什么情况下会有大量的CLOSE\_WAIT状态
> 
> 3、3、4 为什么有时候连接时端口号被占用
> 
> 3、3、5 为什么等待时间是2MSL
> 
> 3、3、6 setsockopt 函数
> 
> --------------------
> 
> **?♂️ 作者：@Ggggggtm ?♂️**
> 
> **? 专栏：计算机网络 ?**
> 
> **? 标题：三次握手四次挥手?**
> 
>  **❣️ 寄语：与其忙着诉苦，不如低头赶路，奋路前行，终将遇到一番好风景 ❣️**

## 引入 ##

> **TCP的三次握手和四次挥手是面试被高频问到的一个知识点**。其中有较多的细节问题，本篇文章全部会详细讲解！

## 一、三次握手和四次挥手的简单介绍 ##

> TCP使用**三次握手和四次挥手来建立和终止连接**。为什么建立和终止连接还需要这么麻烦呢？TCP设置三次握手和四次挥手是为了**确保可靠的连接建立和终止**，在网**络通信中保护数据的完整性和可靠性。**后文会有更加详细的解释。

## 二、三个标记位 ##

> 在学习TCP的三次握手和四次挥手之前，我们先来了解一下三个标记位。
> 
> 1.  **SYN（Synchronize）：用于建立连接的初始握手**。发送方发送一个SYN报文段给接收方，**请求建立连接**。
> 2.  **ACK（Acknowledgement）**：**用于确认数据的传输**。当成功接收到数据后，**接收方发送一个带有ACK标记的报文段回复发送方，确认已经收到了数据**。
> 3.  **FIN（Finish）**：**用于关闭连接**。当发送方发送完所有数据后，会发送一个带有**FIN标记的报文段，请求关闭连接**。接收方在收到FIN报文段后，发送一个带有ACK标记的报文段进行确认，并使用一个定时器在一段时间后关闭连接。
> 
> 这三个表记为会在TCP的三次握手和四次挥手频繁被用到，我们这里先了解一下其概念和用户，后续会结合实际的三次握手和四次挥手进行再次补充讲解。

## 三、三次握手和四次挥手的过程详解 ##

### 3、1 三次握手 ###

> 我们在编写网络代码时，所用到的 connect 函数，就是在建立连接。而这个连接是怎么被建立起来的呢？具体可看下图：
> 
> ![f4d1118af72641d1894c3ab0ae90598f.png][]
> 
> 我们对上图再次进行解释：
> 
> 1.  第一次握手，是**客户端向服务器发送了一个SYN请求**，**也就是客户端在向服务器请求连接**。此时**客户端处于SYN\_SENT状态**。
> 2.  第二次握手，是**服务器向客户端发送了一个ACK+SYN的回应**，**表明服务器收到了客户端的请求，并且同意了客户端的请求建立连接**。此时**服务器处于SYN\_RCVD状态**。
> 3.  第三次握手，也是最后一次握手，是**客户端回应服务器一个ACK报文**。**表明客户端收到服务器的同意建立连接，并告诉服务器我收到了你的确认**。同时也会根据**此时客户端处于ESTABLISHED状态**。
> 
> 到此，三次握手的过程就算结束了。最后，当服务器收到客户端的 ACK 报文之后，也处于 ESTABLISHED 状态。此时，连接就已经建立成功了。
> 
> 但是**你怎么确定客户端和服务端接收到的ACK和SYN报文就是一一对应的呢**？不要忘记了还有序号和确认序号！具体如下图：
> 
> ![4c7775c3a8da48a7ac731905f9440785.png][]

#### 3、1、1 三次握手后连接就一定建立成功了吗 ####

> **三次握手后就一定能够把证建立连接成功吗**？答案是**不一定**。为什么呢？我们看到，第一次握手和第二次握手都有ACK回应。但是第三次握手并没有对应的回应。有没有如下一种可能：**前两次握手成功了，到第三次握手发出后，服务端并没有收到响应的报文，也就是丢包了！这时即使三次握手完成，连接也并没有建立成功！**
> 
>  **所谓连接建立成功，必须是服务端和客户端的状态都必须是ESTABLISHED状态。**

#### 3、1、2 握手时产生的状态是什么意思 ####

> 可能你在想：怎么理解这些状态呢？这些状态的意义是什么呢？结合进程的状态（就绪、阻塞、挂起等等），**状态就是说明你目前所处于什么阶段，干了什么东西，接下来需要怎么做**。我们再看握手时所产生的三个状态（SYN\_SENT和SYN\_RCVD和ESTABLISHED状态）所代表的含义。
> 
> 1.  **SYN\_SENT（同步已发送）状态：当客户端在建立TCP连接时发送一个SYN（同步）报文段后，进入SYN\_SENT状态**。在此状态下，客户端等待服务器回复确认报文段（ACK）以及确认序号（SYN+1）。这个状态表明客户端已发送了连接请求，但还未收到服务器的确认。
> 2.  **SYN\_RCVD（同步已接收）状态：服务器在接收到客户端发送的SYN报文段后，会发送回一个SYN+ACK（同步+确认）报文段作为响应，并进入SYN\_RCVD状态**。在此状态下，服务器等待客户端发送最后的确认（ACK）报文段，以完成连接的建立。这个状态表明服务器已经接收到了连接请求，但还未收到客户端的确认。
> 3.  **ESTABLISHED（已建立）状态：在TCP连接的成功建立后，双方进入ESTABLISHED状态**。在该状态下，双方可以互相发送数据。这个状态表示连接已经建立，并且双方都可以开始传输数据。
> 
>  **总结**：
> 
>  *  SYN\_SENT状态是客户端发送连接请求后的等待状态，表示已发送请求但还未收到服务器的确认。
>  *  SYN\_RCVD状态是服务器接收到客户端连接请求后的等待状态，表示已接收到请求但还未收到客户端的确认。
>  *  ESTABLISHED状态表示连接已经建立，双方可以进行数据传输。

### 3、2 为什么是三次握手 ###

#### 3、2、1 一次握手不行吗 ####

> 一次握手不行，因为在**建立连接时需要确认双方的发送和接收能力是否正常**。如果只进行一次握手，那么无法确认对方是否能够接收到自己的消息。
> 
> ps：这里额外说明一点。当我们使用telnet 127.0.0.1 连接自己的机器时，如果连接成功可正常通信，就可以说明大概率本地网络是没有问题的。

#### 3、2、2 两次握手为什么不行 ####

> **两次握手表明客户端可以正常的像服务器发送报文（因为此时已经有ACK响应报文）**。
> 
> ![b8e7a1c2c5184e98ac0aa38c77a2a065.png][]
> 
> **但是服务器并不知道自己所发送的报文是能被客户端正常接收到！！！因为服务器向客户端发送的报文并没有得到过客户端的ACK响应报文。**
> 
> **两次握手也无法确定客户端和服务器的初始序列号是否正确**。因为第二次握手并有其对应的确认序号。

>  两次握手就建立成功连接的话**，也存在很容易被恶意攻击的问题**。首先，因为有大量的client将来可能链接server，所以**server端一定会存在大量的连接**，OS要不要管理这些连接呢?答案是肯定要的。怎么进行管理呢？先描述，在组织！这也就意味着需要响应的数据结构，并对其进行维护。**维护是需要成本的（内存资源+CPU资源）**！！！
> 
> **所谓的连接：本质其实就是内核的一种数据结构类型，建立连接成功的时候，就是再内存中创建对应的连接对象！在对多个连接对象进行某种数据结构的组织**。
> 
> **SYN洪水**：那么现在有一个攻击者伪造多个源IP地址，并发送大量的SYN请求给目标服务器。只有两次握手，这就意味着只要发送SYN请求，服务器一旦回应就代表服务器段连接建立完成了。但攻击者（客户端）接收服务器发送ACK确认连接请求，也不继续后续的连接建立过程，就是把这段数据丢弃了。此时服务器存在大量连接，但攻击者（客户端）并没有受到任何影响。这样使得服务器的资源慢慢被消耗殆尽。由于服务器资源受限，其无法处理真正的合法连接请求，从而导致服务的拒绝其他请求。这样就对我们的服务器造成严重影响。

#### 3、2、3 四次握手也不行 ####

> 四次握手也不行，因为**多余的握手会导致过多的网络开销和资源消耗**。**三次握手就已经能够确认双方的发送和接收能力是正常的**。同时**四次握手与两次握手（偶数次握手）一样，会很容易受到SYN洪水攻击**。

### 3、3 四次挥手 ###

> TCP中的四次挥手是用来**关闭连接**的。我们平常所写的 close（sock），就是用来关闭连接的。注意：**关闭连接是两端的事情，并不是一端的事情**。四次挥手的过程如下：
> 
> ![e263bf9387d44261822847ff3eb8a9c3.png][]
> 
> 四次挥手的具体过程如下：
> 
> 1.  第一次挥手：客户端向服务器发送一个**FIN（结束）请求**，**表示客户端不再发送数据**。此时**客户端处于FIN\_WAIT\_1状态。**
> 2.  第二次挥手：**服务器收到请求后，回复客户端一个ACK响应确认**，但这个响应可能还携带有未传输完的数据。此时**服务器处于CLOSE\_WAIT状态**。注意，**在第三次挥手之前**，**数据还是可以从服务器传送到客户端的**。
> 3.  第三次挥手：**服务器完成数据传输后，向客户端发送一个FIN请求**，**表示服务器也没有数据要发送了**。此时**服务器状态变为LAST\_ACK状态**。
> 4.  第四次挥手：客户端收到服务器的请求后，回复服务器一个ACK响应确认。**此时客户端处于TIME\_WAIT状态，需要经过一段时间确保服务器收到自己的应答报文后，才会进入CLOSED状态**。
> 
> 到这里，四次挥手就已经结束了。最后，**服务器收到ACK报文后，就关闭连接，也处于CLOSED状态了**。

#### 3、3、1 TIME\_WAIT状态和CLOSE\_WAIT状态 ####

> TIME\_WAIT状态和CLOSE\_WAIT状态是较为重要的两个状态，其中也是有一些细节需要我们去理解的。具体如下：
> 
> 1.  TIME\_WAIT 状态：
>     
>      *  发起方 (主动关闭连接的一方) 在发送最后一个 ACK 确认包之后，会进入 TIME\_WAIT 状态。
>      *  在 TIME\_WAIT 状态期间，该连接处于等待状态，以**确保网络中的任何未完成或延迟的分节都能到达目的地（确保对方（通常是服务器）已经成功收到并处理了FIN包。在这段时间内，该连接会进入TIME\_WAIT状态****）**。
>      *  **TIME\_WAIT 状态的持续时间通常为 2 倍的最大报文存活时间MSL**（Maximum Segment Lifetime，MSL）。
>      *  MSL 是指 IP 数据报在网络上的最长寿命，它是任何报文段被丢弃前在网络内的最长时间，超过这个时间报文将被丢弃。根据协议实现的不同，MSL 的时间长短也不同。
>      *  **进入 TIME\_WAIT 状态的作用是确保已经关闭的连接的所有分节都在网络中完全消失，以防止它们与新连接混淆**。
>      *  在TIME\_WAIT状态期间，这个**套接字不会被分配给其他连接使用**，但会占用一定的系统资源。
> 2.  CLOSE\_WAIT 状态：
>     
>      *  当对方 (被动关闭连接的一方) 收到关闭连接请求并发送了 ACK 确认包后，会进入 CLOSE\_WAIT 状态。
>      *  在 CLOSE\_WAIT 状态期间，**目标端继续等待应用程序关闭套接字**。
>      *  通常来说，如果被动端意识到应用程序没有正常关闭套接字，它可能会发送一条警告消息，以通知应用程序关闭套接字。
>      *  **如果被动关闭连接的一方（服务器）未能正确关闭套接字，CLOSE\_WAIT 状态可能会一直持续下去，导致资源泄漏**。

#### 3、3、2 为什么要存在 TIME\_WAIT 状态 ####

> TIME\_WAIT状态的存在是为了保证网络通信的可靠性和避免出现连接复用问题。以下是一些TIME\_WAIT状态的原因：
> 
> 1.  **可靠关闭连接：TIME\_WAIT状态是为了确保连接被完全关闭而引入的**。在TCP的四次握手过程中，最后一次挥手（发送FIN包）之后，需要等待一段时间，以确保对方已经收到并成功处理了FIN包。这样可以防止出现半开连接状态，从而避免数据传输混乱或错误。
> 2.  **避免连接复用问题：TIME\_WAIT状态同样可以防止因为旧的连接信息仍然存留在网络中而导致的连接复用问题**。假设一个新连接使用了与之前连接相同的源IP、源端口、目标IP和目标端口，如果该连接处于TIME\_WAIT状态，那么它能够阻止新连接接收到之前连接的延迟数据包，避免数据包错乱，确保连接的稳定性和可靠性。
> 3.  **处理网络拥塞：TIME\_WAIT状态还可以帮助处理网络拥塞**。当大量连接同时关闭时，TIME\_WAIT状态可以将关闭的连接延迟释放，避免短时间内有大量CLOSE\_WAIT连接并发导致系统资源过度消耗；同时，TIME\_WAIT状态也可以防止新连接的第一次握手和旧连接的最后一次握手同时发生，以免拥塞情况下造成更多的连接问题。
> 
> 尽管TIME\_WAIT状态会占用系统资源，**但它在保证连接可靠性、防止连接复用以及处理网络拥塞等方面起到了非常重要的作用**。

#### 3、3、3 什么情况下会有大量的CLOSE\_WAIT状态 ####

> 在CLOSE\_WAIT状态下，被动关闭连接的一方会一直等待对方读取数据或关闭连接。**如果长时间处于，可能会导致资源浪费和连接堆积**。因此，如果应用程序开发者没有正确处理接收到的数据或关闭连接，可能会导致CLOSE\_WAIT状态的积累。 **根本原因就是在于被动关闭方没有进行第三次挥手，也就是没有正确关闭自己的套接字（sockfd）**。
> 
> 举个例子：如果我们发现服务器具有大量的close\_wait状态的连接的时候。原因是服务器写的有bug，忘了关闭对应的连接sockfd。时间长了服务就可能崩溃了。

#### 3、3、4 为什么有时候连接时端口号被占用 ####

> 你可能也遇到过这种情况：**刚刚还能够正常连接呢，怎么现在突然说端口号被占用了呢**？原因就是**客户端在进行第四次挥手后，进入了TIME\_WAIT 状态，该状态是需要等上一段时间的。在等待的过程中，套接字不会被分配给其他连接使用**，**其该客户端的端口号依然是被处于使用的状态**。

#### 3、3、5 为什么等待时间是2MSL ####

> 可能会有如下情况：**服务器可能没有收到最后一段ACK报文，也就是ACK报文丢包了**。此时就会触发超时重传。服务器会再次发送FIN报文。当客户端再次收到FIN报文，客户端就知道刚刚发送的ACK丢失，需要再次发送。
> 
> **如果在等待TIME\_WAIT期间，客户端并没有在收到任何报文，就一定表明回收成功了吗？也不一定**。网络的情况很复杂，也有可能网络阻塞等原因，即使服务器触发了超时重传，客户端也不一定能收到，只是概率比较小。等待TIME\_WAIT，只是减少出现错误的概率，并不能百分百保证。

#### 3、3、6 setsockopt 函数 ####

> **在有些情况下，服务器断开连接后是等不了的啊（不希望进行等待）**。例如，淘宝的双十一枪货，等待一分钟可是巨大的损失。这时我们可以用到setsockopt 函数。函数原型如下：
> 
>     int setsockopt(int sockfd, int level, int optname, const void *optval, socklen_t optlen);
> 
>  *  sockfd：套接字描述符，即要设置选项的套接字。
>  *  level：选项所属的协议层。常见的协议层包括SOL\_SOCKET（通用套接字选项）、IPPROTO\_TCP（TCP选项）、IPPROTO\_IP（IP选项）等。
>  *  optname：选项的名称或标识符，用来指定要设置的具体选项。例如，对于SOL\_SOCKET协议层，可以设置的选项包括SO\_REUSEADDR（地址重用）、SO\_RCVBUF（接收缓冲区大小）等。
>  *  optval：指向存放选项值的缓冲区的指针。
>  *  optlen：指定optval缓冲区大小的长度。
> 
> 下面是一些**常用的选项和对应的解释（了解）**：
> 
> 1.  SOL\_SOCEKT选项：
>     
>      *  SO\_REUSEADDR：允许重用本地地址和端口。
>      *  SO\_REUSEPORT：允许多个套接字绑定到同一个端口。
>      *  SO\_KEEPALIVE：启用对端的活动检测。
>      *  SO\_BROADCAST：允许发送广播消息。
>      *  SO\_RCVBUF和SO\_SNDBUF：设置接收和发送缓冲区大小。
> 2.  IPPROTO\_TCP选项：
>     
>      *  TCP\_NODELAY：禁止Nagle算法，允许小数据报立即发送。
>      *  TCP\_MAXSEG：设置TCP报文段的最大长度。
>      *  TCP\_KEEPIDLE、TCP\_KEEPINTVL和TCP\_KEEPCNT：用于启用和配置TCP的保活功能。
> 3.  IPPROTO\_IP选项：
>     
>      *  IP\_TOS：设置IP报文的服务类型。
>      *  IP\_MULTICAST\_TTL：设置组播数据包的TTL值。
> 
> 具体是我们在创建套接字时，就对其进行设置。具体代码如下：
> 
>     int listensock = socket(AF_INET, SOCK_STREAM, 0);
>     if (listensock < 0)
>     {
>         exit(1);
>     }
>     int opt = 1;
>     setsockopt(listensock, SOL_SOCKET, SO_REUSEADDR | SO_REUSEPORT, &opt, sizeof(opt));

[17d94e1d1ee74e6a8d951c2209153c18.gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/22/49d35503bb0b4d3ab1e5c753c63e7b6c.gif
[f4d1118af72641d1894c3ab0ae90598f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/22/3db46ce91e8146d0a27fdf69603c9555.png
[4c7775c3a8da48a7ac731905f9440785.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/22/5794620509174b4db4ef514598413bda.png
[b8e7a1c2c5184e98ac0aa38c77a2a065.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/22/e9b723350a614fe3aba0c43dc68a5333.png
[e263bf9387d44261822847ff3eb8a9c3.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/22/cb4cad5198e44c7c8028f9c445a2e65e.png