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，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 。