TCP 序列号和确认号相关举例解释来啦

在《我要证明网》上，我发现很多人对 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࿰