当前位置：首页 > news >正文

计算机网络期末救命稻草：深度解析TCP中的Seq与Ack机制

news 2026/4/26 9:01:53

计算机网络期末救命稻草：深度解析TCP中的Seq与Ack机制

作者：培风图南以星河揽胜
发布日期：2026-04-25
标签：#计算机网络 #TCP协议 #期末考试 #Seq #Ack #可靠传输 #网络编程 #CSDN原创

前言：为什么Seq和Ack是TCP的“灵魂”？

在计算机网络的浩瀚星海中，传输控制协议（Transmission Control Protocol, TCP）无疑是最璀璨的恒星之一。它是互联网基石，负责在不可靠的网络层之上构建起可靠的、面向连接的字节流传输服务。而在TCP协议的众多字段中，序列号（Sequence Number, Seq）和确认号（Acknowledgment Number, Ack）无疑是两颗最核心的原子。

如果你正在备战计算机网络期末考试，或者正在深入理解TCP的工作原理，那么这两个概念是你必须跨越的门槛。很多同学在复习时，往往只记住了死板的公式：“Ack = Seq + 1”或“SYN占一个序号”，却忽略了其背后的设计哲学和动态交互过程。这导致在面对复杂的拥塞控制、滑动窗口、重传机制等高级问题时，常常感到云里雾里。

本文旨在通过深度剖析，结合大量实战案例、报文段交互图解以及常见的考试陷阱，将Seq和Ack讲深、讲透、讲活。我们将不仅仅停留在“是什么”，更要探究“为什么”和“怎么做”。无论你是为了应付即将到来的期末考试，还是为了夯实网络编程的基础，这篇文章都将是你不可或缺的“通关秘籍”。

让我们跟随“培风图南以星河揽胜”的脚步，一起穿梭于数据的海洋，去探寻TCP可靠传输背后的逻辑之美。

第一章：TCP协议栈中的位置与核心使命

在深入Seq和Ack之前，我们需要先站在宏观的角度，理解TCP在整个网络模型中的角色，以及它为什么要引入这两个字段。

1.1 从IP到TCP：从“尽力而为”到“可靠交付”

IP协议（Internet Protocol）位于网络层，它的核心设计思想是“尽最大努力交付”（Best Effort）。这意味着IP数据包在传输过程中可能会丢失、乱序、重复，甚至出现损坏。IP协议本身并不保证数据一定能到达目的地，也不关心数据包的顺序。

而TCP协议位于传输层，它的使命正是为了解决IP层带来的这些问题。TCP需要实现以下核心功能：

可靠传输：确保数据无差错、不丢失、不重复、按序到达。
流量控制：防止发送方发送速度过快，导致接收方缓冲区溢出。
拥塞控制：防止过多的数据注入到网络中，使网络中的链路或路由器不过载。
全双工通信：允许数据同时在两个方向上传输。

要实现上述功能，尤其是“可靠传输”，TCP必须建立一种机制来追踪数据的状态。这就好比你在寄快递时，不仅需要一个收件人地址（IP），还需要一个运单号（Seq）来记录包裹的顺序，并且每次快递员收到包裹后都要给你打个电话确认（Ack）。

1.2 报文段结构概览

TCP报文段（Segment）的结构相对复杂，包含头部数据和载荷数据。我们重点关注头部中与Seq和Ack相关的字段：

字段名	长度	说明
Source Port	16 bit	源端口号
Destination Port	16 bit	目的端口号
Sequence Number (Seq)	32 bit	序列号：本报文段所发送的数据的第一个字节的序号
Acknowledgment Number (Ack)	32 bit	确认号：期望收到对方下一个报文段的第一个数据字节的序号
Data Offset	4 bit	数据偏移量（即首部长度）
Reserved	6 bit	保留字段
Flags	9 bit	标志位（URG, ACK, PSH, RST, SYN, FIN等）
Window	16 bit	窗口大小（用于流量控制）
…	…	其他校验和、紧急指针等

可以看到，Seq和Ack各占用了32个比特位。32位的空间意味着序列号的范围是2322^{32}232，大约为42亿。这个巨大的空间设计是为了防止在网络传输时间较长时，序列号发生回绕（Wrap-around），从而导致混淆。

第二章：序列号（Seq）的深度解析

2.1 Seq的定义与本质

根据教科书和标准定义：Seq（Sequence Number）标记发送数据起始字节的序号。

这句话看似简单，实则蕴含了三个关键层面的意义：

定位：它告诉接收方，这个数据包里的数据是从整个数据流的第几个字节开始的。
排序：接收方可以根据Seq的大小，将乱序到达的数据包重新排列成正确的顺序。
去重与重传依据：如果收到一个Seq已经处理过的数据包，说明是重复包，直接丢弃；如果某个Seq对应的数据包超时未收到ACK，发送方就知道需要重传该Seq开始的数据。

2.2 初始序列号（ISN）的产生

TCP连接建立之初，双方都需要确定一个初始序列号（Initial Sequence Number, ISN）。这个值并不是固定的0，而是随机生成的。

为什么ISN要随机？
这是一个非常重要的安全机制。如果ISN是固定的（比如总是从0开始），攻击者就可以轻易地预测对方的序列号，从而发起“TCP会话劫持”攻击，伪造数据包插入到合法的连接中。

ISN是如何生成的？
RFC 793建议ISN应该基于时钟和某种秘密密钥进行计算，使得ISN随时间变化且难以预测。在现代操作系统中，ISN通常由内核生成，结合了系统启动时间、当前时间戳、随机数等因素。

考试考点提示：

问：TCP三次握手时，第一个SYN包的Seq是多少？
答：是一个随机生成的初始序列号（ISN），记为xxx。
问：第二个SYN包（来自服务器）的Seq是多少？
答：是服务器自己的初始序列号，记为yyy。

2.3 Seq的计数单位：字节流

这是初学者最容易混淆的地方。TCP的Seq是按“字节”计数的，而不是按“报文段”计数的。

想象一下，你有一个巨大的文件要发送，被切分成了多个TCP报文段。

第1个报文段携带了数据A(长度为100字节)，它的Seq是1000。
第2个报文段携带了数据B(长度为200字节)，它的Seq应该是多少？
- 错误答案：1000 + 1 = 1001
- 正确答案：1000 + 100 = 1100

为什么？
因为第1个报文段消耗了1000到1099这100个字节的序号。第2个报文段紧接着就是第1100个字节。

特殊情况：控制标志位占用序号
虽然普通数据是按字节计数，但在TCP协议中，SYN和FIN标志位虽然是控制信息，不携带有效载荷数据，但它们也要占用一个序列号。

SYN（同步）：用于建立连接。当SYN=1时，Seq表示初始序列号，该SYN包本身消耗1个序号。
FIN（终止）：用于关闭连接。当FIN=1时，该FIN包本身也消耗1个序号。

记忆口诀：

数据看长度，SYN/FIN各一长。
正常传数据，Seq加长度。
握手挥手时，Seq加一忙。

2.4 Seq在重传机制中的作用

当发送方发出一个报文段后，会启动一个定时器。如果在超时时间内没有收到对该报文段的确认（ACK），发送方就会认为该报文段丢失了，需要进行重传。

此时，重传的报文段有什么特点？

Seq不变：重传的报文段，其Seq字段必须与第一次发送时完全一致。这样接收方才能识别出这是之前那个没收到的包，或者是之前收到了但没发ACK的包。
数据内容相同：除了Seq和可能的Checksum变化外，数据载荷必须完全一样。

场景模拟：

客户端发送Seq=1000，Len=100的数据。
网络拥堵，该包丢失。
客户端超时，再次发送Seq=1000，Len=100的数据。
服务器收到，发现Seq=1000已处理过（或者刚好这次才到），回复ACK=1100。

2.5 常见误区辨析

误区一：Seq是报文段的编号。

纠正：Seq是字节流的编号。一个报文段可能包含多个字节的序号范围。

误区二：SYN和FIN不占用序号。

纠正：它们占用序号。这是考试中的高频陷阱题。例如，SYN包虽然只有头部，没有数据，但它的Seq+1才是下一个数据包的Seq。

误区三：Seq可以无限增大。

纠正：32位限制，最大值为232−12^{32}-1232−1。达到最大值后会回绕到0。因此，ISN的设计必须考虑到回绕周期足够长，避免新旧连接混淆。

第三章：确认号（Ack）的深度解析

如果说Seq是发送方的“路标”，那么Ack就是接收方的“回执单”。

3.1 Ack的定义与本质

Ack（Acknowledgment Number）告知对方已收到所有前置数据，期待接收的下一个Seq编号。

这句话同样包含三层含义：

累积确认：Ack代表的是“我已经收到了直到Ack-1的所有数据”。这是一种累积确认机制（Cumulative Acknowledgment）。只要收到了Ack=N，就意味着N之前的所有字节都正确到达了。
期望值：Ack的值等于期望收到的下一个字节的序号。
单向性：Ack是针对特定方向的。A发给B的数据，需要B返回Ack；B发给A的数据，需要A返回Ack。TCP是全双工的，所以每个方向都有独立的Seq和Ack。

3.2 Ack的计算公式

这是本章的核心公式，也是期末考试必考的计算题：

Ack=对方Seq+接收数据长度 \text{Ack} = \text{对方Seq} + \text{接收数据长度}Ack=对方Seq+接收数据长度

注意细节：

对方Seq：指刚才收到的那个报文段的Seq字段值。
接收数据长度：指该报文段中实际携带的有效数据长度（Payload Length）。
特殊情况：如果该报文段带有SYN或FIN标志，即使数据长度为0，也要视为长度为1。

公式推导示例：
假设客户端发送了一个报文段：

Seq = 1000
Data Length = 200 bytes
Flags = 0 (普通数据)

服务器收到后，计算Ack：
Ack=1000+200=1200 \text{Ack} = 1000 + 200 = 1200Ack=1000+200=1200
服务器回复的报文段中，Ack字段即为1200。这表示：“我收到了1000到1199的所有数据，请从1200开始继续发送。”

特殊场景示例（SYN/FIN）：
假设客户端发送SYN包建立连接：

Seq = 1000 (ISN)
Data Length = 0
Flags = SYN

服务器收到后，计算Ack：
Ack=1000+1=1001 \text{Ack} = 1000 + 1 = 1001Ack=1000+1=1001
这里加了1，因为SYN占用了1个序号。

同理，如果客户端发送FIN包关闭连接：

Seq = 5000
Data Length = 0
Flags = FIN

服务器收到后，计算Ack：
Ack=5000+1=5001 \text{Ack} = 5000 + 1 = 5001Ack=5000+1=5001

3.3 Ack的ACK标志位

在TCP头部有一个专门的标志位叫ACK。

当ACK=1时，Ack字段才有效。
当ACK=0时，Ack字段的内容被忽略（通常出现在连接建立的第一阶段，即第一个SYN包，因为它还没有收到任何数据，不需要确认）。

考试陷阱：
题目问：“在三次握手的第二步中，服务器的ACK标志位是1吗？”
答：是的。服务器发送的报文段是SYN=1, ACK=1。它既要确认客户端的SYN（设置Ack=ISN_client+1），又要发起自己的SYN（设置Seq=ISN_server）。

3.4 延迟确认与捎带确认

为了提高效率，TCP实现中通常会采用两种优化策略，这也常作为简答题的考点。

3.4.1 延迟确认（Delayed ACK）

接收方不一定每收到一个报文段就立即回复ACK。它可以等待一小段时间（通常是200ms），看看是否有数据要发送给发送方，或者有多个报文段到达，这样可以减少ACK报文的数量，节省带宽。

规则：通常每收到两个完整大小的报文段，或者等待一定时间后，发送一个ACK。
例外：对于乱序到达的包，或者某些特定的应用层协议（如SSH），可能需要立即确认。

3.4.2 捎带确认（Piggybacking）

如果接收方也有数据要发送给发送方，它可以将ACK信息“捎带”在这个数据报文段中一起发送，而不需要单独发送一个纯ACK报文段。

优势：减少了网络中的分组数量，提高了传输效率。
场景：全双工通信中非常常见。

3.5 Ack在滑动窗口中的应用

TCP的流量控制依赖于滑动窗口机制。窗口的大小决定了发送方在未收到ACK的情况下可以发送多少数据。

接收窗口（rwnd）：接收方在ACK中通告自己的剩余缓冲区大小。
发送窗口：发送方根据收到的ACK和rwnd，调整自己的发送窗口。

当发送方收到Ack=N时，意味着窗口向前滑动了，N之前的数据已被确认，发送方可以释放这些内存，并允许发送新的数据。

关键点：
如果收到重复的ACK（Duplicate ACK），说明中间可能有丢包。TCP的快速重传机制（Fast Retransmit）就是基于此：如果连续收到3个相同的ACK，发送方会立即重传丢失的包，而不需要等待超时。

第四章：Seq与Ack的完美配合——三次握手与四次挥手

理论再好，不如实战演练。我们将通过TCP最著名的两个场景——三次握手和四次挥手，来串联Seq和Ack的使用规则。

4.1 三次握手：建立连接

目标：客户端（Client）与服务器（Server）同步双方的初始序列号，确认双方收发能力正常。

第一步：Client -> Server (SYN)

Client行为：随机生成ISN，设为xxx。
报文特征：
- SYN = 1
- ACK = 0(此时不需要确认对方)
- Seq = x
- Len = 0
含义：我要开始连接了，我的初始序号是xxx。

第二步：Server -> Client (SYN + ACK)

Server行为：
1. 收到Client的SYN，知道对方想连接。
2. 确认Client的SYN：Ack = x + 1(因为SYN占1个序号)。
3. 设置自己的SYN：随机生成ISN，设为yyy。
报文特征：
- SYN = 1
- ACK = 1
- Seq = y(Server自己的初始序号)
- Ack = x + 1(确认收到Client的SYN)
- Len = 0
含义：你的SYN我收到了（期待下一个Seq是x+1x+1x+1），我也同意连接，这是我的初始序号yyy。

第三步：Client -> Server (ACK)

Client行为：
1. 收到Server的SYN+ACK。
2. 确认Server的SYN：Ack = y + 1(因为Server的SYN占1个序号)。
3. 此时连接建立完成。
报文特征：
- SYN = 0
- ACK = 1
- Seq = x + 1(因为Client的SYN占1个序号，所以数据从x+1x+1x+1开始)
- Ack = y + 1
- Len = 0(通常不带数据，也可以带少量数据)
含义：你的SYN我也收到了（期待下一个Seq是y+1y+1y+1），连接正式建立，我们可以开始传数据了。

总结三次握手中的Seq/Ack规律：

每个SYN包都会让对方的Ack+1。
握手完成后，Seq从x+1x+1x+1和y+1y+1y+1开始计数数据。
最终建立的连接，双方都知道对方的初始序号，从而能够正确对齐字节流。

4.2 四次挥手：断开连接

目标：优雅地关闭连接，确保双方都没有未完成的数据。

第一步：Client -> Server (FIN)

Client行为：数据发送完毕，请求关闭。
报文特征：
- FIN = 1
- ACK = 1(通常伴随ACK，确认之前的数据)
- Seq = u(假设之前最后发送的数据结束于u-1，则此处Seq=u)
- Ack = v(确认Server之前的数据)
含义：我没有数据要发了，我要关闭了。

第二步：Server -> Client (ACK)

Server行为：收到FIN，表示同意关闭，但可能还有数据要发。
报文特征：
- FIN = 0
- ACK = 1
- Seq = v(Server自己的Seq，持续累加)
- Ack = u + 1(确认收到Client的FIN，因为FIN占1个序号)
含义：好的，我知道你要关了，但我还没发完，我先确认你的FIN。

第三步：Server -> Client (FIN + ACK)

Server行为：数据发完了，主动关闭。
报文特征：
- FIN = 1
- ACK = 1
- Seq = w(Server当前的Seq)
- Ack = u + 1(再次确认Client的FIN)
含义：我也发完了，我也要关闭了。

第四步：Client -> Server (ACK)

Client行为：收到Server的FIN，确认关闭。
报文特征：
- FIN = 0
- ACK = 1
- Seq = u + 1(Client的Seq)
- Ack = w + 1(确认Server的FIN，因为FIN占1个序号)
含义：收到你的FIN，连接彻底关闭。

注意：为什么是四次挥手？
因为TCP是全双工的。Client说“我不发了”（FIN），Server说“我知道了”（ACK），但这不代表Server也不能发了。Server必须等自己发完数据后再说“我也不发了”（FIN）。这两个动作是分开的，所以通常需要四个报文段。当然，如果Server刚好也有数据要发，可以将ACK和FIN合并在一个包中发送，变成三次挥手，但这属于优化情况。

Seq/Ack关键点回顾：

Client的FIN消耗了1个序号，Server的Ack必须是u+1u+1u+1。
Server的FIN消耗了1个序号，Client的Ack必须是w+1w+1w+1。
连接关闭后，双方进入TIME_WAIT状态，等待2MSL（最大报文段生存时间），以确保最后一个ACK能到达，并清除旧连接的残留报文。

第五章：常见考题与陷阱大扫除

在期末考试中，关于Seq和Ack的题目形式多样，以下整理了最高频的几种题型及解题思路。

5.1 计算题：已知报文段参数，求Ack

题目：
主机A向主机B发送TCP报文段，Seq=1000，数据长度为300字节，Flags=0。主机B收到后，向A发送确认报文段。请问B发送的报文段中，Ack字段和Seq字段分别是多少？（假设B之前没有向A发送过数据，B的初始Seq为5000）

解析：

计算Ack：
- A的Seq = 1000
- A的数据长度 = 300
- B的Ack = A的Seq + A的数据长度 = 1000 + 300 = 1300。
计算B的Seq：
- 题目给出B的初始Seq为5000。
- 如果B只是回复ACK，没有发送新数据，且之前没有发送过数据，那么B的Seq通常保持为初始值（除非之前有交互）。
- 但在本题语境下，通常考察的是B发送的ACK包中的Seq。如果B之前没有发送过数据，Seq=5000。如果B之前发送过数据，Seq需要累加。
- 修正：题目通常隐含B之前没有数据交互，或者B的Seq是基于之前交互的。若仅考虑本次交互，B的Seq取决于B之前的发送历史。若题目未提，通常假设B刚建立连接，Seq=5000。
- 更严谨的考试逻辑：如果B之前没发过数据，Seq=5000。如果B之前发了100字节，Seq=5100。
- 结论：Ack=1300，Seq=5000（假设B初始状态）。

易错点：忘记ACK标志位。如果B发送的包Flags=ACK，则Ack字段有效。如果Flags!=ACK，Ack字段无效。

5.2 判断题：SYN/FIN是否占用序号

题目：
TCP报文段中，SYN标志位和FIN标志位都不占用序列号。
A. 正确
B. 错误

解析：
选B（错误）。
根据TCP协议标准，SYN和FIN标志位在建立连接和关闭连接时，各自占用一个序列号。

SYN包：Seq+1。
FIN包：Seq+1。
普通数据：Seq+Length。

5.3 选择题：关于累积确认

题目：
关于TCP的确认机制，下列说法正确的是？
A. 每收到一个报文段都必须立即回复ACK。
B. Ack表示收到该报文段本身。
C. Ack表示收到该序号之前的所有数据。
D. 如果收到乱序报文段，接收方必须丢弃。

解析：

A错误：可以采用延迟确认。
B错误：Ack表示的是“期望收到的下一个序号”，即累计确认了Ack-1之前的所有数据，不仅仅是当前这个包。
C正确：这是累积确认的核心定义。
D错误：接收方通常会缓存乱序报文段，等到缺失的报文段到达后，再一起向上层提交。

5.4 综合题：重传分析

题目：
主机A发送Seq=1000，Len=100的数据包。主机B收到后，发送Ack=1100。但在传输过程中，B的ACK包丢失了。A超时后重传Seq=1000，Len=100的数据包。B收到重传包后，会如何处理？

解析：

B的状态：B之前已经收到了Seq=1000的数据，并发送了Ack=1100（虽然ACK丢了，但B的数据缓冲区里已经有这100字节了）。
B收到重传包：B检查Seq=1000，发现这已经是之前处理过的数据（已经在缓冲区中）。
处理方式：B会丢弃该重复的数据包，不会再次交给上层应用。
后续动作：B会再次发送Ack=1100，以通知A之前的ACK确实丢失了，A应该停止重传并继续发送新数据。

考点：TCP的去重机制和重复ACK的作用。

第六章：进阶思考——Seq与Ack在复杂网络环境下的表现

在实际的互联网环境中，网络状况千变万化，Seq和Ack的配合并非总是那么完美。我们需要了解一些高级话题，这往往是高分论文或面试中的加分项。

6.1 零窗口探测（Zero Window Probe）

当接收方的缓冲区满了，它会在ACK中通告窗口大小为0（rwnd=0）。此时发送方必须停止发送数据，进入“等待”状态。但是，发送方不能一直傻等，万一接收方处理了数据并更新了窗口，但更新后的ACK又丢失了呢？

解决方案：
发送方会启动一个“零窗口探测计时器”。每隔一段时间（通常是5秒），发送一个长度为0的探测报文段（Keep-alive probe）。

这个探测包的Seq会正常累加。
接收方收到后，必须回复ACK，其中包含最新的窗口大小。
如果接收方窗口非0，发送方恢复发送；如果仍为0，重置计时器。

6.2 选择性确认（SACK）

标准的TCP使用累积确认。如果发送方发了1, 2, 3, 4, 5五个包，其中2和4丢了。

接收方收到1，发Ack=2。
收到3，因为2丢了，3乱序，接收方无法确认3，只能再次发Ack=2（重复ACK）。
收到5，同样乱序，再次发Ack=2。
发送方收到3个重复Ack，触发快速重传，重传2。
如果2传到了，接收方发Ack=6。此时3和5已经被接收方缓存，但标准TCP不知道3和5已经到了，发送方可能会认为3和5也丢了（取决于具体实现），或者在慢启动阶段重新发送。

SACK选项：
RFC 2018引入了SACK选项。接收方可以在ACK报文中携带“哪些块的数据已经收到”的信息。

例如：收到1, 3, 5，缺2, 4。
发送Ack=2，并在SACK选项中声明：“我有[3, 3]和[5, 5]”。
发送方收到后，只需重传2和4，无需重传1, 3, 5。
这大大提高了在高丢包率网络下的性能。

6.3 时间戳选项（Timestamps）

为了防止序列号回绕（PAWS - Protection Against Wrapped Sequences）和精确RTT测量，TCP引入了时间戳选项。

在报文段中携带TSval（发送时的时间戳）。
在ACK中携带TSecr（回显对方发送的时间戳）。
这使得Seq和Ack的验证更加严格，即使序列号回绕，也能通过时间戳判断包的新旧。

第七章：实战代码演示（Python Socket）

光说不练假把式。我们通过一段简单的Python代码，观察Seq和Ack在真实网络交互中的变化。

importsocketimportstructdefanalyze_tcp_handshake():# 创建TCP套接字sock=socket.socket(socket.AF_INET,socket.SOCK_STREAM)# 绑定本地端口（可选，为了观察方便）# sock.bind(('localhost', 0))print("=== TCP三次握手模拟 ===")print("1. 客户端发送SYN...")# 这里我们无法直接捕获底层TCP头部的Seq/Ack数值，# 因为socket API封装了这些细节。# 但我们可以使用tcpdump或Wireshark在命令行观察。# 伪代码逻辑如下：# client_seq = random()# server_ack = client_seq + 1# server_seq = random()# client_ack = server_seq + 1print("实际运行请使用 tcpdump -i lo 'port 8080' -X")print("观察到的现象：")print("- SYN包: Seq=x, Ack=0")print("- SYN+ACK包: Seq=y, Ack=x+1")print("- ACK包: Seq=x+1, Ack=y+1")# 尝试连接一个本地服务try:sock.connect(('127.0.0.1',8080))print("\n连接建立成功！")# 发送数据data=b"Hello, TCP!"sock.send(data)print(f"发送数据:{data}")# 接收响应response=sock.recv(1024)print(f"收到响应:{response}")sock.close()exceptExceptionase:print(f"连接失败，请确保本地有监听8080端口的服务。\n错误信息:{e}")if__name__=="__main__":analyze_tcp_handshake()

如何观察真实的Seq/Ack？
由于Python的Socket库隐藏了底层细节，推荐使用Wireshark抓包工具：

启动Wireshark，选择网卡。
过滤条件：tcp.port == 8080。
在终端运行一个简单的Python脚本发送数据。
在Wireshark中点击具体的TCP包，展开"Transmission Control Protocol"部分。
你会清晰地看到Sequence Number和Acknowledgment number的具体数值，以及它们的变化规律。

典型抓包结果解读：

Packet 1:[SYN] Seq=12345678
Packet 2:[SYN, ACK] Seq=87654321 Ack=12345679(注意Ack是12345678+1)
Packet 3:[ACK] Seq=12345679 Ack=87654322(注意Seq是12345678+1, Ack是87654321+1)
Packet 4:[PSH, ACK] Seq=12345679 Ack=87654322 Len=13(发送数据，Seq延续)
Packet 5:[ACK] Seq=87654322 Ack=12345692(Ack=12345679+13)

第八章：总结与备考建议

8.1 核心知识点清单

为了应对期末考试，请务必背诵并理解以下核心要点：

Seq定义：本报文段数据第一个字节的序号。
Ack定义：期望收到的下一个字节的序号（即已收到的最大序号+1）。
计算公式：
- 普通数据：Ack=Seq+Length\text{Ack} = \text{Seq} + \text{Length}Ack=Seq+Length
- SYN/FIN：Ack=Seq+1\text{Ack} = \text{Seq} + 1Ack=Seq+1
占用规则：SYN和FIN各占用1个序号。
三次握手：
- 第一次：SYN=1, Seq=x
- 第二次：SYN=1, ACK=1, Seq=y, Ack=x+1
- 第三次：ACK=1, Seq=x+1, Ack=y+1
四次挥手：
- FIN占用1个序号。
- 两次FIN分别消耗各自的Seq+1。
可靠性保障：Seq用于排序和去重，Ack用于确认和重传触发。
累积确认：Ack表示累计确认，而非单个包确认。