TCP 连接中的三次握手与四次挥手

偏执的太偏执、 2022-10-20 01:17 213阅读 0赞

### TCP 连接中的三次握手与四次挥手 ###

*  三次握手
 *   *  请求携带参数
     *  三次握手
     *  抓包
 *  四次挥手
 *   *  请求携带参数
     *  四次挥手
     *  抓包
 *  问题
 *   *  1.说下 TCP 与 UDP 的区别
     *  2. 为什么需要四次挥手？
     *  3. 为什么需要有 TIME-WAIT 状态，而不直接 CLOSED
     *  4. 四次挥手中，为什么要第二次挥手与第三次挥手分开？合起来发不行吗？
     *  5. 四次挥手中，一定会有四个包吗？

# 三次握手 #

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

## 请求携带参数 ##

1.  **SYN：** 标志位，表示发起同步
2.  **seq：** 随机生成的序列号，用来进行同步确认校验，这里的值随手写的，用来表明意思
3.  **ACK：** 标志位，表示确认信息有效
4.  **ack：** 这个值为对端发送过来的 seq + 1，对端会根据发送来的 ack 值来校验请求是否正确
5.  **其他参数：** 请求中必然不可能只有这些参数，还包含比如滑动窗口大小，请求地址等信息

## 三次握手 ##

建立 TCP 连接时，需要客户端与服务端通过三个包以确认连接的建立。

**第一次握手：** 客户端请求建立连接  
**第二次握手：** 服务端针对客户端请求确认应答，并请求建立连接  
**第三次握手：** 客户端针对服务端请求确认应答

## 抓包 ##

首先抓到三次握手的包，然后我们再来看详细的信息，这里用的是 navicate 去连接数据库的抓包  
![在这里插入图片描述][20210716113623935.png]  
**第一次握手：**  
可以看到由 21 这台服务器，去向 23 服务器发起建立连接  
可以看到 SYN 标志位被置为了 1，并且注意 seq 值，为了后面做对比  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 1]

**第二次握手：**  
由 23 服务器去确认响应 21 服务器发来的连接请求，并且向 21 发起建立连接请求  
其中 SYN 标志位为 1，ACK 标志位为 1，ack 值为第一次握手的 seq + 1，seq 则是为了向建立 21 服务器发起建立连接所需的序列号  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 2]

**第三次握手：**  
21 服务器向 23 服务器发起第三次握手请求， ACK 标志位为 1，ack 值为第二次握手的 seq + 1  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 3]

# 四次挥手 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 4]

## 请求携带参数 ##

1.  **FIN：** 标志位，表示发起关闭
2.  **seq：** 随机生成的序列号，用来进行同步确认校验。关闭时，响应也是直接用 seq 来表示，而不是 ack
3.  **ACK：** 标志位，表示确认信息有效
4.  **ack：** 这个值为对端发送过来的 seq + 1，对端会根据发送来的 ack 值来校验请求是否正确
5.  **其他参数：** 请求中必然不可能只有这些参数，还包含比如滑动窗口大小，请求地址等信息

## 四次挥手 ##

**第一次挥手：** 客户端向服务端发起关闭请求

**第二次挥手：** 服务端对于客户端发来的请求进行响应

**第三次挥手：** 等待数据传输完成后，服务端向客户端发起关闭请求  
**服务端状态变化：CLOSE-WAIT 变为 CLOSE**

**第四次挥手：** 客户端对于服务端发来的请求进行响应  
**客户端状态变化：** **在等待一段时间后，TIME-WAIT 变为 CLOSED**。一般为 1-4 分钟，正式环境一般会调为更短

## 抓包 ##

![在这里插入图片描述][20210719102122506.png]

**第一次挥手：**  
首先 21 服务器向 23 服务器发起一个关闭请求的包，因此发送 FIN 标志位为 1 的包。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 5]

**第二次挥手与第三次挥手合并：**  
所以问题来了，四次挥手一定会有四次包吗？答案是否定的，因此第二次挥手和第三次挥手的目的就是保住中间数据的传输完成，因此假如中间就没传数据，就没必要分两个包了，此时会出现第二次挥手与第三次挥手的合并。  
**PS：我这里是简单的关闭数据库连接，所以出现了包合并。**

23 服务器向 21 服务器进行了应答同时发送了关闭连接请求，因此 FIN 标志位为 1，ack 等于第一次挥手的 seq + 1  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 6]

**第四次挥手：**  
21 服务器向 23 服务器发送应答包  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 7]

# 问题 #

## 1.说下 TCP 与 UDP 的区别 ##

答：  
UDP 是一种面向无连接的不可靠的协议，容易发生丢包。  
TCP 是一种面向连接的，可靠的网络协议。  
TCP 通过超时重传，应答确认的方式来保证传输的可靠，假如传输过程中出现包丢失或损坏的情况，TCP 就会进行包的重传。  
由于 TCP 在传输过程中不保证传输的顺序性，因此 TCP 在传输时会在包上打上序号，在传输时对包进行排序。  
并且由于服务器两端的性能的浮动性，因此 TCP 通过滑动窗口的方式动态调整每次传输的大小。  
UDP 比起 TCP 由于不需要保证可靠性，因此传输会更加高效，普遍运用于视频或者直播内容上。

## 2. 为什么需要四次挥手？ ##

答：因为 TCP 是全双工的，因此双方都需要向对方进行连接关闭确认，并且拿到响应。

## 3. 为什么需要有 TIME-WAIT 状态，而不直接 CLOSED ##

1.  **保证能够可靠的中止连接：** 因此第四次挥手的包是可能丢失的，假如丢失了就需要重发第四次挥手的包，因此不能 CLOSED
2.  **加保证迟来的 TCP 报文能够被丢弃：** 因为包在传输的过程中时间是不定的，因此需要这个时间让后面的包失效掉，否则，下个应用拿到这个包就不知道这个包是自己的还是上个应用的（依然不能完全避免）。

## 4. 四次挥手中，为什么要第二次挥手与第三次挥手分开？合起来发不行吗？ ##

答：  
第二次挥手和第三次挥手分开的本质目的是为了保证中间数据包传输完成，只有全部传输完成才会第三次挥手不再接收数据。  
事实上假如第二次挥手时候已经完全没有数据在传输了就会出现第二次挥手与第三次挥手的合并。

## 5. 四次挥手中，一定会有四个包吗？ ##

答：不一定，第二次挥手时候假如已经没有数据在传输就会出现第二次挥手与第三次挥手的合并。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70]: /images/20221004/6a90aedfb2194c0a9be89090d35d0b44.png
[20210716113623935.png]: /images/20221004/9f3901a40afd4efd8841c680829b8724.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 1]: /images/20221004/eeac7d7aed7640b5858877b0c0aab07f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 2]: /images/20221004/25afc752c94b45119a5db9f3671622e1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 3]: /images/20221004/1fc18995d1c34a668b7dcbf4933c015a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 4]: /images/20221004/3833c70101e9494397ff76e953632b78.png
[20210719102122506.png]: /images/20221004/6ce2897c952b48e6a0ecfa2f0a727997.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 5]: /images/20221004/9044c1c0d6de4bab9b24c298f827f2db.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 6]: /images/20221004/90db7870441c4e21b77b078293158fe4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM3MTQzNjcz_size_16_color_FFFFFF_t_70 7]: /images/20221004/159d60de82a94ab7b62388ea94960a56.png