在网站上回答了很多同学的问题,我发现很多人对 TCP 序列号和确认号的变化都是懵懵懂懂的,只知道三次握手和四次挥手过程中,ACK 报文中确认号要 +1,然后数据传输中 TCP 序列号和确认号的变化就不知道了。
也有很多同学跟我反馈,希望我写一篇关于 TCP 序列号和确认号变化过程的文章。大家别小看这个基础知识点,其实很多人都不知道的,因为很少书详细说明这个,即使讲了,也没有说明白规律。
所以,这次就跟大家聊聊以下过程中,TCP 序列号和确认号是如何变化的?
-
三次握手中 TCP 序列号和确认号的变化
-
数据传输中 TCP 序列号和确认号的变化
-
四次挥手中 TCP 序列号和确认号的变化
万能公式
我根据经验总结了一条万能公式。发送的 TCP 报文:
-
公式一:序列号 = 上一次发送的序列号 + len(数据长度)。特殊情况,如果上一次发送的报文是 SYN 报文或者 FIN 报文,则改为上一次发送的序列号 + 1。
-
公式二:确认号 = 上一次收到的报文中的序列号 + len(数据长度)。特殊情况,如果收到的是 SYN 报文或者 FIN 报文,则改为上一次收到的报文中的序列号 + 1。
可能有点抽象,接下来举一些实际的场景,加深对这个万能公式的理解。
先给大家看看 TCP 序列号和确认号在 TCP 头部的哪个位置。可以看到,这两个字段都是 32 位。
TCP 头部
这里重点关注这三个字段的作用:
-
序列号:在建立连接时由内核生成的随机数作为其初始值,通过 SYN 报文传给接收端主机,每发送一次数据,就「累加」一次该「数据字节数」的大小。用来解决网络包乱序问题。
-
确认号:指下一次「期望」收到的数据的序列号,发送端收到接收方发来的 ACK 确认报文以后,就可以认为在这个序号以前的数据都已经被正常接收。用来解决丢包的问题。
-
控制位:用来标识 TCP 报文是什么类型的报文,比如是 SYN 报文、数据报文、ACK 报文,FIN 报文等。
三次握手阶段的变化
先来说说三次握手中 TCP 序列号和确认号的变化。
假设客户端的初始化序列号为 client_isn,服务端的初始化序列号为 server_isn,TCP 三次握手的流程如下: