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

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

阶段1、深入多线程

阶段2、深入多线程设计模式

阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

码哥源码部分

码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】

码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】

码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】

​​​​​​码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】

码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作？】

码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了！】

码哥讲源码【谁再说Spring不支持多线程事务，你给我抽他！】

终结B站没人能讲清楚红黑树的历史，不服等你来踢馆！

打脸系列【020-3小时讲解MESI协议和volatile之间的关系，那些将x86下的验证结果当作最终结果的水货们请闭嘴】

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

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

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

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

# 万能公式

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

发送的 TCP 报文：

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

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

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

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

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

# 三次握手阶段的变化

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

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

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

服务端收到客户端的 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 字节的数据，流程图下：

客户端发送 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。如下图：

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

# 四次挥手阶段的变化

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

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

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

• 序列号设置为 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。

# 实际抓包图

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

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

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

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

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