图解计算机网络
首页 死磕 Java 优质系列 Java 技术总览 Java 面试宝典 关于我

TCP 序列号和确认号是如何变化的？

转
 2023-03-01  阅读(2)
©版权
原文作者：小林 Coding 原文地址：https://xiaolincoding.com/

在网站(opens new window)上回答了很多人的问题，我发现很多人对 TCP 序列号和确认号的变化都是懵懵懂懂的，只知道三次握手和四次挥手过程中，ACK 报文中确认号要 +1，然后数据传输中 TCP 序列号和确认号的变化就不知道了。

也有很多同学跟我反馈，希望我写一篇关于 TCP 序列号和确认号变化过程的文章。大家别小看这个基础知识点，其实很多人都不知道的。

所以，这次就跟大家聊聊以下过程中，TCP 序列号和确认号是如何变化的？

  • 三次握手中 TCP 序列号和确认号的变化
  • 数据传输中 TCP 序列号和确认号的变化
  • 四次挥手中 TCP 序列号和确认号的变化

# 万能公式

我根据经验总结了一条万能公式。

发送的 TCP 报文：

  • 公式一：序列号 = 上一次发送的序列号 + len（数据长度）。特殊情况，如果上一次发送的报文是 SYN 报文或者 FIN 报文，则改为 上一次发送的序列号 + 1。
  • 公式二：确认号 = 上一次收到的报文中的序列号 + len（数据长度）。特殊情况，如果收到的是 SYN 报文或者 FIN 报文，则改为上一次收到的报文中的序列号 + 1。

可能有点抽象，接下来举一些实际的场景，加深对这个万能公式的理解。

先给大家看看 TCP 序列号和确认号在 TCP 头部的哪个位置。可以看到，这两个字段都是 32 位。

202303012307571721.png

这里重点关注这三个字段的作用：

  • 序列号 ：在建立连接时由内核生成的随机数作为其初始值，通过 SYN 报文传给接收端主机，每发送一次数据，就「累加」一次该「数据字节数」的大小。 用来解决网络包乱序问题。
  • 确认号 ：指下一次「期望」收到的数据的序列号，发送端收到接收方发来的 ACK 确认报文以后，就可以认为在这个序号以前的数据都已经被正常接收。 用来解决丢包的问题。
  • **控制位：**用来标识 TCP 报文是什么类型的报文，比如是 SYN 报文、数据报文、ACK 报文，FIN 报文等。

# 三次握手阶段的变化

先来说说三次握手中 TCP 序列号和确认号的变化。

假设客户端的初始化序列号为 client_isn，服务端的初始化序列号为 server_isn，TCP 三次握手的流程如下：

202303012307582202.png

在这里我们重点关注，下面这两个过程。

服务端收到客户端的 SYN 报文后，会将 SYN-ACK 报文（第二次握手报文）中序列号和确认号分别设置为：

  • 序列号设置为服务端随机初始化的序列号 server_isn。
  • 确认号设置为 client_isn + 1，服务端上一次收到的报文是客户端发来的 SYN 报文，该报文的 seq = client_isn，那么根据公式 2（确认号 = 上一次收到的报文中的序列号 + len。特殊情况，如果收到的是 SYN 报文或者 FIN 报文，则改为 + 1），可以得出当前确认号 = client_isn + 1。

客户端收到服务端的 SYN-ACK 报文后，会将 ACK 报文（第三次握手报文）中序列号和确认号分别设置为：

  • 序列号设置为 client_isn + 1。客户端上一次发送报文是 SYN 报文，SYN 的序列号为 client_isn，根据公式 1（序列号 = 上一次发送的序列号 + len。特殊情况，如果上一次发送的报文是 SYN 报文或者 FIN 报文，则改为 + 1），所以当前的序列号为 client_isn + 1。
  • 确认号设置为 server_isn + 1，客户端上一次收到的报文是服务端发来的 SYN-ACK 报文，该报文的 seq = server_isn，那么根据公式 2（确认号 = 收到的报文中的序列号 + len。特殊情况，如果收到的是 SYN 报文或者 FIN 报文，则改为 + 1），可以得出当前确认号 = server_isn + 1。

为什么第二次和第三次握手报文中的确认号是将对方的序列号 + 1 后作为确认号呢？

SYN 报文是特殊的 TCP 报文，用于建立连接时使用，虽然 SYN 报文不携带用户数据，但是 TCP 将 SYN 报文视为 1 字节的数据 ，当对方收到了 SYN 报文后，在回复 ACK 报文时，就需要将 ACK 报文中的确认号设置为 SYN 的序列号 + 1 ，这样做是有两个目的：

  • 告诉对方，我方已经收到 SYN 报文。
  • 告诉对方，我方下一次「期望」收到的报文的序列号为此确认号，比如客户端与服务端完成三次握手之后，服务端接下来期望收到的是序列号为 client_isn + 1 的 TCP 数据报文。

# 数据传输阶段的变化

完成了，三次握手后，客户端就可以发送第一个 ** **TCP 数据报文了，假设客户端即将要发送 10 字节的数据，流程图下：

202303012307594283.png

客户端发送 10 字节的数据，通常 TCP 数据报文的控制位是 [PSH, ACK]，此时该 TCP 数据报文的序列号和确认号分别设置为：

  • 序列号设置为 client_isn + 1。客户端上一次发送报文是 ACK 报文（第三次握手），该报文的 seq = client_isn + 1，由于是一个单纯的 ACK 报文，没有携带用户数据，所以 len = 0。根据公式 1（序列号 = 上一次发送的序列号 + len），可以得出当前的序列号为 client_isn + 1 + 0，即 client_isn + 1。
  • 确认号设置为 server_isn + 1。没错，还是和第三次握手的 ACK 报文的确认号一样，这是因为客户端三次握手之后，发送 TCP 数据报文 之前，如果没有收到服务端的 TCP 数据报文，确认号还是延用上一次的，其实根据公式 2 你也能得到这个结论。

可以看到， 客户端与服务端完成 TCP 三次握手后，发送的第一个 「TCP 数据报文的序列号和确认号」都是和「第三次握手的 ACK 报文中序列号和确认号」一样的 。

接着，当服务端收到客户端 10 字节的 TCP 数据报文后，就需要回复一个 ACK 报文，此时该报文的序列号和确认号分别设置为：

  • 序列号设置为 server_isn + 1。服务端上一次发送报文是 SYN-ACK 报文，序列号为 server_isn，根据公式 1（序列号 = 上一次发送的序列号 + len。特殊情况，如果上一次发送的报文是 SYN 报文或者 FIN 报文，则改为 + 1），所以当前的序列号为 server_isn + 1。
  • 确认号设置为 client_isn + 11 。服务端上一次收到的报文是客户端发来的 10 字节 TCP 数据报文，该报文的 seq = client_isn + 1，len = 10。根据公式 2（确认号 = 上一次收到的报文中的序列号 + len），也就是将「收到的 TCP 数据报文中的序列号 client_isn + 1，再加上 10（len = 10） 」的值作为了确认号，表示自己收到了该 10 字节的数据报文。

之前有读者问，如果客户端发送的第三次握手 ACK 报文丢失了，处于 SYN_RCVD 状态服务端收到了客户端第一个 TCP 数据报文会发生什么？

刚才前面我也说了，发送的第一个 「TCP 数据报文的序列号和确认号」都是和「第三次握手的 ACK 报文中序列号和确认号」一样的，并且该 TCP 数据报文也有将 ACK 标记位置为 1。如下图：

202303012308024704.png

所以，服务端收到这个数据报文，是可以正常完成连接的建立，然后就可以正常接收这个数据包了。

# 四次挥手阶段的变化

最后，我们来看看四次挥手阶段中，序列号和确认号的变化。

数据传输阶段结束后，客户端发起了 FIN 报文，请求服务端端开该 TCP 连接，此时就进入了 TCP 四次挥手阶段，如下图。

202303012308033465.png

客户端发送的第一次挥手的序列号和确认号分别设置为：

  • 序列号设置为 client_isn + 11。客户端上一次发送的报文是 [PSH, ACK] ，该报文的 seq = client_isn + 1, len = 10，根据公式 1（序列号 = 上一次发送的序列号 + len），可以得出当前的序列号为 client_isn + 11。
  • 确认号设置为 server_isn + 1。客户端上一次收到的报文是服务端发来的 ACK 报文，该报文的 seq = server_isn + 1，是单纯的 ACK 报文，不携带用户数据，所以 len 为 0。那么根据公式 2（确认号 = 上一次收到的序列号 + len），可以得出当前的确认号为 server_isn + 1 + 0 （len = 0），也就是 server_isn + 1。

服务端发送的第二次挥手的序列号和确认号分别设置为：

  • 序列号设置为 server_isn + 1。服务端上一次发送的报文是 ACK 报文，该报文的 seq = server_isn + 1，而该报文是单纯的 ACK 报文，不携带用户数据，所以 len 为 0，根据公式 1（序列号 = 上一次发送的序列号 + len），可以得出当前的序列号为 server_isn + 1 + 0 （len = 0），也就是 server_isn + 1。
  • 确认号设置为 client_isn + 12。服务端上一次收到的报文是客户端发来的 FIN 报文，该报文的 seq = client_isn + 11，根据公式 2（_确认号= 上一次_收到的序列号 + len，特殊情况，如果收到报文是 SYN 报文或者 FIN 报文，则改为 + 1），可以得出当前的确认号为 client_isn + 11 + 1，也就是 client_isn + 12。

服务端发送的第三次挥手的序列号和确认号还是和第二次挥手中的序列号和确认号一样。

  • 序列号设置为 server_isn + 1。
  • 确认号设置为 client_isn + 12。

客户端发送的四次挥手的序列号和确认号分别设置为：

  • 序列号设置为 client_isn + 12。客户端上一次发送的报文是 FIN 报文，该报文的 seq = client_isn + 11，根据公式 1（序列号 = 上一次发送的序列号 + len。特殊情况，如果收到报文是 SYN 报文或者 FIN 报文，则改为 + 1），可以得出当前的序列号为 client_isn + 11 + 1，也就是 client_isn + 12。
  • 确认号设置为 server_isn + 2。客户端上一次收到的报文是服务端发来的 FIN 报文，该报文的 seq = server_isn + 1，根据公式 2（_确认号 = 上一次_收到的序列号 + len，特殊情况，如果收到报文是 SYN 报文或者 FIN 报文，则改为 + 1），可以得出当前的确认号为 server_isn + 1 + 1，也就是 server_isn + 2。

# 实际抓包图

在这里贴一个，实际过程中的抓包图。

202303012308059886.png

套入我的万能公式， 发送的 TCP 报文：

  • 公式一：序列号 = 上一次发送的序列号 + len（数据长度）。特殊情况，如果上一次发送的报文是 SYN 报文或者 FIN 报文，则改为 上一次发送的序列号 + 1。
  • 公式二：确认号 = 上一次收到的报文中的序列号 + len（数据长度）。特殊情况，如果收到的是 SYN 报文或者 FIN 报文，则改为上一次收到的报文中的序列号 + 1。

懂了这套公式之后，相信你在看这类的抓包图中序列号和确认号的变化的时候，就不会没有逻辑了。

怎么样，学废了吗，溜啦溜啦！

Java 面试宝典是大明哥全力打造的 Java 精品面试题，它是一份靠谱、强大、详细、经典的 Java 后端面试宝典。它不仅仅只是一道道面试题，而是一套完整的 Java 知识体系，一套你 Java 知识点的扫盲贴。

它的内容包括：

  • 大厂真题：Java 面试宝典里面的题目都是最近几年的高频的大厂面试真题。
  • 原创内容：Java 面试宝典内容全部都是大明哥原创，内容全面且通俗易懂，回答部分可以直接作为面试回答内容。
  • 持续更新：一次购买，永久有效。大明哥会持续更新 3+ 年，累计更新 1000+，宝典会不断迭代更新，保证最新、最全面。
  • 覆盖全面：本宝典累计更新 1000+，从 Java 入门到 Java 架构的高频面试题，实现 360° 全覆盖。
  • 不止面试：内容包含面试题解析、内容详解、知识扩展，它不仅仅只是一份面试题，更是一套完整的 Java 知识体系。
  • 宝典详情：https://www.yuque.com/chenssy/sike-java/xvlo920axlp7sf4k
  • 宝典总览：https://www.yuque.com/chenssy/sike-java/yogsehzntzgp4ly1
  • 宝典进展：https://www.yuque.com/chenssy/sike-java/en9ned7loo47z5aw

目前 Java 面试宝典累计更新 400+ 道，总字数 42w+。大明哥还在持续更新中，下图是大明哥在 2024-12 月份的更新情况：

想了解详情的小伙伴，扫描下面二维码加大明哥微信【daming091】咨询

同时，大明哥也整理一套目前市面最常见的热点面试题。微信搜[大明哥聊 Java]或扫描下方二维码关注大明哥的原创公众号[大明哥聊 Java] ，回复【面试题】 即可免费领取。

阅读全文
文章标签： 计算机网络