TCP 序列和确认号说明 | seq 和 ack 号计算方法

注：本文为 “TCP 序列” 相关文章合辑。

英文引文机翻未校。

TCP Sequence and Acknowledgement Numbers Explained

TCP 序列和确认编号说明

TCP Sequence (seq) and Acknowledgement (ack) numbers help enable ordered reliable data transfer for TCP streams. The seq number is sent by the TCP client, indicating how much data has been sent for the session (also known as the byte-order number). The ack number is sent by the TCP server, indicating that is has received cumulated data and is ready for the next segment.

TCP 序列（seq）和确认（ack）编号有助于为 TCP 流实现有序可靠的数据传输。seq 编号由 TCP 客户端发送，指示已为会话发送的数据量（也称为字节顺序号）。ack 编号由 TCP 服务器发送，表示已收到累积数据，并已准备好进行下一段。

The TCP seq and ack numbers are coordinated with one another and are key values during the TCP handshake, TCP close, and, of course, while data is transferred between the client and server.

TCP seq 和 ack 编号相互协调，是 TCP 握手、TCP 关闭期间的关键值，当然，在客户端和服务器之间传输数据时也是如此。

[By default, Wireshark converts all sequence and acknowledgement numbers into relative numbers. This means that all SEQ and ACK numbers always start at 0 for the first packet seen in each conversation.]

[默认情况下，Wireshark 将所有序列和确认编号转换为相对编号。这意味着对于每个会话中看到的第一个数据包，所有 SEQ 和 ACK 编号始终从 0 开始。

The picture below shows a real example of TCP sequence and acknowledgment numbers in a TCP flow diagram. The key variable is the TCP segment length for each TCP segment sent in the session.
下图显示了 TCP 流程图中 TCP 序列和确认编号的真实示例。key 变量是会话中发送的每个 TCP 分段的 TCP 分段长度。

The client sends the first segment with seq=1 and the length of the segment is 669 bytes. The server responds with an ack=670 which tells the client that the next expected segment will have a sequence number is 670.
客户端发送 seq=1 的第一个分段，该分段的长度为 669 字节。服务器以 ack=670 响应，这告诉客户端下一个预期的 segment 将具有 670 的序列号。

The next segment the client sends has seq=670 and the len is now 1460 bytes. In turn, the server responds with ack=2130 (670 + 1460). This cycle continues until the end of the TCP session.
客户端发送的下一个分段具有 seq=670，len 现在是 1460 字节。反过来，服务器以 ack=2130 （670 + 1460）响应。此循环将持续到 TCP 会话结束。

Again, note that the length value is from the TCP segment length, not the Layer 2 frame length nor the IP packet length.
同样，请注意，length 值来自 TCP 分段长度，而不是第 2 层帧长度或 IP 数据包长度。

Seq and Ack in Wireshark

Wireshark 中的 Seq 和 Ack

Client sends seq=1 and tcp segment length=669

客户端发送 seq=1 且 tcp 段长度 = 669

Server responds with ack=670

服务器响应 ack=670

Client sends segment with seq=670 and length=1460

客户端发送 seq=670 且 length=1460 的 segment

Server responds with ack=2130
服务器响应 ack=2130

This is just a simple example to get the basics of TCP sequence and acknowledgement numbers.
这只是一个获取 TCP 序列和确认编号基础知识的简单示例。

TCP 包的 seq 和 ack 号计算方法

huaishu 已于 2022-04-26 10:37:16 修改

序号（seq） 用来标识从 TCP 发端向 TCP 收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则 TCP 用序号对每个字节进行计数。序号是 32bit 的无符号数，序号到达 $2^{32}－1$ 后又从 0 开始。

当建立一个新的连接时，SYN 标志变 1。序号字段包含由这个主机选择的该连接的初始序号 ISN（Initial Sequence Number）。该主机要发送数据的第一个字节序号为这个 ISN 加 1，因为 SYN 标志消耗了一个序号。既然每个传输的字节都被计数，确认序号包含发送确认的一端所期望收到的下一个序号。因此，确认序号（ack） 应当是上次已成功收到数据字节序号加 1。只有 ACK 标志（下面介绍）为 1 时确认序号字段才有效。

发送 ACK 无需任何代价，因为 32bit 的确认序号字段和 ACK 标志一样，总是 TCP 首部的一部分。因此，我们看到一旦一个连接建立起来，这个字段总是被设置，ACK 标志也总是被设置为 1。

TCP 为应用层提供全双工服务。这意味数据能在两个方向上独立地进行传输。因此，连接的每一端必须保持每个方向上的传输数据序号。

sequence number：表示的是我方（发送方）这边，这个 packet 的数据部分的第一位应该在整个 data stream 中所在的位置。（注意这里使用的是 “应该”。因为对于没有数据的传输，如 ACK，虽然它有一个 seq，但是这次传输在整个 data stream 中是不占位置的。所以下一个实际有数据的传输，会依旧从上一次发送 ACK 的数据包的 seq 开始）
acknowledge number：表示的是期望的对方（接收方）的下一次 sequence number 是多少。
注意，SYN/FIN 的传输虽然没有 data，但是会让下一次传输的 packet seq 增加 1，但是，ACK 的传输，不会让下一次的传输 packet 加 1。

三次握手过程

TCP 连接的建立是通过三次握手来实现的

序号	方向	seq	ack	SYN	ACK
1	A->B	10000 (ISN)	0	1	0
2	A<-B	20000 (ISN)	10000+1=10001	1	1
3	A->B	100001	20000+1=20001	0	1

解释：

1：(A) –> [SYN] –> (B)

A 向 B 发起连接请求，以一个随机数初始化 A 的 seq, 这里假设为 10000，此时 ACK＝0

2：(A) <– [SYN/ACK] <–(B)

B 收到 A 的连接请求后，也以一个随机数初始化 B 的 seq，这里假设为 20000，意思是：你的请求我已收到，我这方的数据流就从这个数开始。B 的 ACK 是 A 的 seq 加 1，即 10000＋1＝10001

3：(A) –> [ACK] –> (B)
A 收到 B 的回复后，它的 seq 是它的上个请求的 seq 加 1，即 10000＋1＝100001，意思也是：你的回复我收到了，我这方的数据流就从这个数开始。A 此时的 ACK 是 B 的 seq 加 1，即 20000+1=20001

数据传输过程

序号	方向	seq	ack	数据长度	数据包长度
23	A->B	40000	70000	1460	1514
24	A<-B	70000	40000+1514-54=41460	0	54
25	A->B	41460	70000+54-54=70000	1460	1514
26	A<-B	70000	41460+1514-54=42920	0	54

解释：

23：B 接收到 A 发来的 seq=40000，ack=70000，size=1514 的数据包

24：于是 B 向 A 也发一个数据包，告诉 A，你的上个包我收到了。A 的 seq 就以它收到的数据包的 ack 填充，ack 是它收到的数据包的 seq 加上数据包的大小 (不包括：以太网协议头 = 14 字节，IP 头 = 20 字节，TCP 头 = 20 字节)，以证实 B 发过来的数据全收到了。

25：A 在收到 B 发过来的 ack 为 41460 的数据包时，一看到 41460，正好是它的上个数据包的 seq 加上包的大小，就明白，上次发送的数据包已安全到达。于是它再发一个数据包给 B。

26：B->A 这个正在发送的数据包的 seq 也以它收到的数据包的 ack 填充，ack 就以它收到的数据包的 seq (70000) 加上包的 size (54) 填充，即 ack=70000+54-54 (全是头长，没数据项)。通过 tcpdump 发现确认包 ack，确认传输过程中最后字节长度。

减去 54 的原因，以太网封装格式（链路层使用的是 Ethernet II 格式，这个格式有 14 字节以太网首部 + 4 字节以太网尾部）：
应用数据 = size-14-20-20=size-54。（假设 IP 首部和 TCP 首部都没有可选选项）

为什么不减去以太网尾部的 4 字节呢？

因为在物理层上网卡要先去掉前导同步码和帧开始定界符，然后对帧进行 CRC 检验，如果帧校验和错，就丢弃此帧。

如果校验和正确，就判断帧的目的硬件地址是否符合自己的接收条件（目的地址是自己的物理硬件地址、广播地址、可接收的多播硬件地址等），如果符合，就将帧交 “设备驱动程序” 做进一步处理。

这时我们的抓包软件才能抓到数据，因此，抓包软件抓到的是去掉前导同步码、帧开始分界符、FCS 之外的数据。

四次挥手过程

序号	方向	seq	ack	FIN	ACK
1	A->B	80000	90000	1	1
2	A<-B	90000	80000+1=80001	0	1
3	A<-B	90000	80001	1	1
4	A->B	80001	90000+1=90001	0	1

1：(A) –> [FIN/ACK] –> (B)

客户端 A 没有要发送给服务端 B 的数据了，想要关闭链接，则发送一个 FIN=1，ACK=1 的包，告诉 B 可以关闭连接了，我没有什么数据要给你了。

2：(A) <– [ACK] <– (B)

然后 B 会发送 ACK=1 的包给 A，告诉 A 我知道你没有什么想给我的了，但是我还有数据要给你，你先等下，我先不想 FINISH 呢。

3：(A) <– [FIN/ACK] <– (B)

等 B 把数据都发送给 A 之后，B 会再次发送一个包，这次 FIN=1，表示我这边也想关闭了，咱俩一起关把。在 2 和 3 之间，可能还会有很多 B->A 的传递，ack 均为 80001。

4：(A) –> [ACK] –> (B)

然后 A 回应一个 ACK，表示我知道了，一起关吧。B 收到这个 ACK 后，就会 CLOSE。但是实际上 A 不会直接 CLOSE，还会进入一个等待时间状态 TIME_WAIT，持续 2 倍的 MSL（Maximum Segment Lifetime，报文段在网络上能存活的最大时间）。过了这个状态，才会 CLOSE。

为什么要等待一段时间？原因有二：

（1）保证 TCP 的全双工连接能够可靠关闭

假如 A 发送的最后一次 ACK 丢包了，没有被 B 收到，那 B 超时之后，会再次发送一个 FIN 包，然后这个包被处于 TIME_WAIT 状态的 A 收到，A 会再次发送一个 ACK 包，并重新开始计时，一直循环这个过程，直到 A 在 TIME_WAIT 的整个过程中都没有收到 B 发过来的 FIN 包，这说明 B 已经收到了 A 的 ACK 包并 CLOSE 了，因此 A 这时候才可以安心 CLOSE。如果 A 没有 TIME_WAIT 状态而是直接 close，那么当 ACK 丢包之后，B 会再次发送一个 FIN 包，但是这个包不会被 A 回应，因此 B 最终会收到 RST，误以为是连接错误，不符合可靠连接的要求。因此需要等待 ACK 报文到达 B+BRST 是 TCP 数据报中 6 个控制位之一，6 个控制位的作用如下：

URG 紧急：当 URG=1 时，它告诉系统此报文中有紧急数据，应优先传送 (比如紧急关闭)，这要与紧急指针字段配合使用。

ACK 确认：仅当 ACK=1 时确认号字段才有效。建立 TCP 连接后，所有报文段都必须把 ACK 字段置为 1。

PSH 推送：若 TCP 连接的一端希望另一端立即响应，PSH 字段便可以 “催促” 对方，不再等到缓存区填满才发送。

RST 复位：若 TCP 连接出现严重差错，RST 置为 1，断开 TCP 连接，再重新建立连接。

SYN 同步：用于建立和释放连接，稍后会详细介绍。

FIN 终止：用于释放连接，当 FIN=1，表明发送方已经发送完毕，要求释放 TCP 连接。

（2）保证这次连接的重复数据段从网络中消失

如果 A 直接 close 了，然后向 B 发起了一个新的 TCP 连接，可能两个连接的端口号相同。一般不会有什么问题，但是如果旧的连接有一些数据堵塞了，没有达到 B 呢，新的握手连接就已经到 B 了，那么这时，由于区分不同 TCP 连接是依据套接字，因此 B 会将这批迟到的数据认为是新的连接的数据，导致数据混乱（源 IP 地址和目的 IP 地址以及源端口号和目的端口号的组合称为 套接字，新旧连接的套接字很有可能相同）如果我们终止一个客户程序，并立即重新启动这个客户程序，则这个新客户程序将不能重用相同的本地端口。服务端处于被动关闭，不会出现该状态。

总结：

通常 TCP 在接收到数据时并不立即发送 ACK；相反，它推迟发送，以便将 ACK 与需要沿该方向发送的数据一起发送（有时称这种现象为数据捎带 ACK）。

挥手关闭过程中，处于半关闭状态，被动关闭状态传输的数据 ack 都是一致的。

类型	握手 (SYN) 或终止 (FIN)	传输	数据包为 0
seq (自己发送)	上次发送 seq+1	上次发送 seq + 数据长度	上次发送 seq
ack (接收对方)	上次接收 seq+1	上次接收 seq + 数据长度	上次接收 seq

实战列表：

4、 seq：上一次发送时为【1】，【1】中 seq 为 0 且为 SYN 数据包，所以这一次的 seq 为 1（0 增加 1）。
ack：上次接收到时为【2】，【2】中 seq 为 0，且为 SYN 数据包，所以可预计，server 端下一次 seq 为 1（0 增加
1）。

5、 seq：上一次发送时为【2】，【2】中 seq 为 0，且为 SYN 数据包，所以这一次的 seq 为 1（0 增加 1）。
ack：上一次接收时为【4】，【4】中的 seq 为 1，数据包的长度为 725，所以可以预计，下一次 client 端的 seq 为
726（1+725）。

6、 seq：上一次发送时为【5】，【5】中 seq 为 1，但【5】为 ACK 数据包，所以数据长度为 0 且不会驱使 seq 加
1，所以这一次的 seq 为 1（1+0）。 ack：上一次接收时为【4】，【4】中的 seq 为 1，数据包的长度为
725，所以可以预计，下一次 client 端的 seq 为 726（1+725）。

为什么三次握手的时候 ack=seq+1

oldfish_C 于 2020-03-27 21:40:17 发布

估计很多人都知道三次握手和四次挥手的过程，但这其中有一个问题困扰了我一会（其实是 TM 很久）

按照定义，seq 是要发送的第一个字节的序号，ack 等于他收到的 seq 序列号加上字节流数据的长度，他代表期望收到的下一个字节的序号，同时他也代表这个序号前的字节我都已经收到了。

那么为什么三次握手过程中，比如第一次握手，A 向 B 发了 seq=x，B 给 A 回的 ack 是 = x+1 呢？如果有数据的话，那理应等于 x+LEN，

如果没有数据，那就应该保持不动就等于 x 才对。

答案是在三次握手过程中：

The server responds to the client with a sequence number of zero, as this is its first packet in this TCP session, and a relative acknowledgement number of 1. The acknowledgement number is set to 1 to indicate the receipt of the client’s SYN flag in packet #1.

Notice that the acknowledgement number has been increased by 1 although no payload data has yet been sent by the client. This is because the presence of the SYN or FIN flag in a received packet triggers an increase of 1 in the sequence. (This does not interfere with the accounting of payload data, because packets with the SYN or FIN flag set do not carry a payload.)

服务器端回复的这个 + 1，是代表他收到了 SYN 标示。

也就是说由于 SYN 或者 FIN 的存在，即使没有数据传输，但服务器端仍然需要通过 + 1 来回应一句 “我收到了”。因此握手过程中 seq=x 的话，ack = x+1。其他几次握手挥手也是同样道理。

P.S：SYN 和 FIN 这种标示只占 1bit

附上参考的文章

网络 | 对ACK一点疑惑 | Aryb1n’s notebook
https://aryb1n.github.io/2018/05/03/网络-对ACK一点疑惑/
“三次握手，四次挥手”你真的懂吗？ - 知乎 Stefno 编辑于 2020-08-21 17:37
https://zhuanlan.zhihu.com/p/53374516

via:

TCP Sequence and Acknowledgement Numbers Explained – MadPackets
https://madpackets.com/2018/04/25/tcp-sequence-and-acknowledgement-numbers-explained/
TCP 包的 seq 和 ack 号计算方法_tcp seq-CSDN 博客 huaishu 已于 2022-04-26 10:37:16 修改
https://blog.csdn.net/huaishu/article/details/93739446
TCP 协议中的 seq/ack 序号是如何变化的？ - 简书
https://www.jianshu.com/p/15754b4e9458
TCP 的 seq 和 ack 号计算方法_HappyRocking 的博客 - CSDN 博客_ack 号是怎么计算的
https://blog.csdn.net/happyrocking/article/details/78198776
使用 tcpdump 分析 TCP 三次握手与四次挥手_huaishu 的博客 - CSDN 博客
https://blog.csdn.net/huaishu/article/details/71475007
为什么三次握手的时候 ack=seq+1_为什么三次握手，返回时，ack 值是 seq 加 1 (ack = x+1)-CSDN 博客 oldfish_C
于 2020-03-27 21:40:17 发布
https://blog.csdn.net/oldfish_C/article/details/105150516
网络 | 对ACK一点疑惑 | Aryb1n’s notebook
https://aryb1n.github.io/2018/05/03/网络-对ACK一点疑惑/
“三次握手，四次挥手”你真的懂吗？ - 知乎 Stefno 编辑于 2020-08-21 17:37
https://zhuanlan.zhihu.com/p/53374516