计算机网络期末小小知识点之确认号（Ack Num）：从TCP三次握手到拥塞控制的深度解析

计算机网络期末小小知识点之确认号（Ack Num）：从TCP三次握手到拥塞控制的深度解析

作者：培风图南以星河揽胜
发布时间：2026-04-26
标签：计算机网络、TCP协议、确认号、ACK、期末复习、CSDN博客、网络传输控制

---

前言：为什么“确认号”是TCP协议的灵魂？

在计算机网络的期末考试中，传输层（Transport Layer）无疑是重中之重，而传输层中最核心的协议莫过于TCP（Transmission Control Protocol）。在TCP协议的所有字段中，确认号（Acknowledgment Number, Ack Num）堪称“灵魂所在”。

如果你只记住了“TCP是可靠的”，却搞不懂“可靠性是如何通过确认号实现的”，那么你在面对计算题、分析题甚至简答题时，往往会感到力不从心。很多同学在学习TCP时，容易混淆序列号（Sequence Number）和确认号（Acknowledgment Number），导致在分析报文段交互、计算窗口大小、理解滑动窗口机制以及排查网络故障时频频出错。

本文将带你从零开始，系统梳理确认号的每一个维度。我们将深入探讨确认号的定义、取值规则、与序列号的微妙关系、在TCP连接建立（三次握手）与断开（四次挥手）中的关键作用、在滑动窗口机制中的动态调整，以及在丢包重传、超时重传、快速重传等复杂场景下的行为逻辑。

无论你是准备期末考、考研，还是想彻底吃透TCP协议，这篇文章都将是你不可或缺的复习指南。我们将通过大量的图解、公式推导、Wireshark抓包实例和历年真题解析，帮你把“确认号”这个看似简单的概念，变成你手中的“必杀技”。

💡本文目标：

• 彻底厘清确认号（Ack Num）与序列号（Seq Num）的本质区别；
• 详解确认号在TCP三次握手、数据传输、四次挥手中的具体数值变化；
• 深入剖析确认号与滑动窗口、流量控制、拥塞控制的协同工作机制；
• 结合真实案例演示丢包、乱序、重复ACK等场景下的确认号行为；
• 提供大量高难度练习题与详细解析，助你举一反三，满分通关。

---

第一章：TCP协议基础与确认号的诞生背景

1.1 为什么需要确认号？

在OSI七层模型或TCP/IP四层模型中，网络层（IP协议）提供的服务是不可靠的、无连接的、尽最大努力交付的。这意味着：

• IP数据包可能会丢失；
• IP数据包可能会乱序到达；
• IP数据包可能会重复；
• IP数据包可能会损坏。

如果上层应用直接依赖IP协议，那么应用程序将不得不处理所有这些复杂的错误情况，这将导致应用层代码极其臃肿且难以维护。因此，我们需要一个可靠的传输层协议来屏蔽底层的不可靠性。

TCP协议正是为了解决这个问题而诞生的。它通过一系列机制来保证数据的可靠传输，其中核心机制包括：

1. 序号（Sequence Number）：给每个字节编号，确保顺序；
2. 确认应答（Acknowledgment）：接收方告诉发送方“我收到了哪些数据”；
3. 超时重传（Retransmission）：发送方没收到确认就重发；
4. 校验和（Checksum）：检测数据是否损坏；
5. 流量控制（Flow Control）：防止发送太快淹没接收方；
6. 拥塞控制（Congestion Control）：防止网络过载。

而确认号（Ack Num），就是实现“确认应答”这一机制的关键字段。它是接收方发给发送方的“回执单”，告诉发送方：“我已经成功接收了直到某个位置之前的所有数据，请从这个位置继续发送。”

1.2 TCP报文段结构回顾

为了准确理解确认号，我们先快速回顾一下TCP报文段的头部结构。TCP首部最小长度为20字节，其关键字段如下：

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Offset | Reserved | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Window Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Urgent Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (if any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

其中，我们关注的两个核心字段是：

• Sequence Number(Seq Num)：32位，表示本报文段第一个数据字节的序号。
• Acknowledgment Number(Ack Num)：32位，表示期望收到的下一个字节的序号。

🌟核心口诀：

• Seq Num= “我发的第一个字节是多少？”
• Ack Num= “我下一个想要的是哪个字节？”

这两个字段共同构成了TCP“累计确认”（Cumulative Acknowledgment）机制的基础。

---

第二章：确认号（Ack Num）的核心定义与取值规则

2.1 确认号的精确定义

在TCP协议中，确认号（Ack Num）是一个累积确认的值。它的含义非常明确：

确认号 N 表示：接收方已经正确接收了序号小于 N 的所有字节数据，并且期望发送方从序号 N 开始发送下一个数据字节。

换句话说，如果接收方发送了一个Ack = N的报文段，它意味着：

• 序号0到N-1的数据都已经安全到达；
• 序号N及之后的数据尚未收到（或者正在等待）；
• 发送方应当立即停止重传N之前的任何数据，并开始发送N及其之后的数据。

2.2 确认号的取值逻辑

2.2.1 正常数据传输

假设主机A向主机B发送数据：

1. A发送一个报文段，Seq = 100，Len = 500。
   • 该报文段包含字节序号：100, 101, …, 599。
2. B正确接收到该报文段。
3. B回复一个ACK报文段，Ack = 600。
   • 含义：B已经收到了100~599，期待下一个字节是600。

关键点：确认号的值总是等于已接收数据的最后一个字节序号 + 1。
Ack=Last_Received_Seq+Length \text{Ack} = \text{Last\_Received\_Seq} + \text{Length}Ack=Last_Received_Seq+Length
或者更准确地说：
Ack=Next_Expected_Seq \text{Ack} = \text{Next\_Expected\_Seq}Ack=Next_Expected_Seq

2.2.2 零长度报文段（纯ACK）

TCP允许发送没有数据载荷的报文段，仅用于携带确认信息。

• 此时，Seq字段代表当前发送方的下一个序列号；
• Ack字段代表期望接收的下一个序列号。
• 这种报文段通常被称为纯ACK（Pure ACK）。

例如，B收到A的数据后，B可能暂时没有数据要发给A，但它必须回复确认。此时B发送：

• Src Port: 80,Dst Port: 1234
• Seq = 5000(B自己的下一个发送序号)
• Ack = 600(B确认收到A的600之前)
• Data Length = 0

2.2.3 确认号不前进的情况

如果接收方收到了乱序的报文段（例如，收到了序号为600的数据，但还没收到500-599），它会怎么做？

• 根据TCP标准，接收方会重复发送上一个正确的确认号。
• 例如，之前确认到了500，现在收到了600，但500-599没到。接收方会再次发送Ack = 500。
• 这被称为重复ACK（Duplicate ACK），是触发快速重传机制的重要信号。

2.3 确认号与序列号的“镜像”关系

TCP是全双工通信，两端都有独立的序列号和确认号流。

• A -> B: A使用Seq_A，B回复Ack_A(确认A的数据)
• B -> A: B使用Seq_B，A回复Ack_B(确认B的数据)

重要误区警示：
很多同学在分析题目时，容易混淆"A的确认号”和“对A的确认号”。

• A发送的报文段中的Ack字段：是A告诉B“我收到了你什么数据”。
• B发送的报文段中的Ack字段：是B告诉A“我收到了你什么数据”。

在分析交互过程时，务必分清方向：

• 当看A发给B的包时，关注的是B的确认号（即B期望A发什么）；
• 当看B发给A的包时，关注的是A的确认号（即A期望B发什么）。

---

第三章：确认号在TCP连接管理中的关键作用

TCP的连接建立和断开过程（三次握手和四次挥手）是考试中的绝对热点，而确认号在这些过程中的数值变化是解题的关键。

3.1 三次握手（Three-Way Handshake）

三次握手的目标是同步双方的初始序列号（ISN），并交换确认信息。

步骤一：SYN（Client -> Server）

• 客户端发送SYN报文段。
• 标志位：SYN=1, ACK=0。
• Seq：随机生成的初始序列号，设为x。
• Ack：无效（因为ACK=0）。
• 含义：“我要发起连接，我的初始序号是x。”

📝注意：SYN报文段虽然不携带数据，但消耗一个序列号。这是考试中最容易忽略的细节！

步骤二：SYN+ACK（Server -> Client）

• 服务器收到SYN后，回复SYN+ACK报文段。
• 标志位：SYN=1, ACK=1。
• Seq：服务器自己的初始序列号，设为y。
• Ack：x + 1。
• 含义：“我收到了你的SYN（序号x），我确认收到的是x+1（即我期待你发x+1，但实际上SYN已占位，所以下一个是x+1）。同时，这是我的SYN，我的初始序号是y。”

🔍深度解析：
为什么是x+1？因为SYN标志位占用了一个序列号。虽然SYN包里没有数据负载，但在序列号空间上，它占据了一个位置。所以服务器确认的下一个字节是x+1。

步骤三：ACK（Client -> Server）

• 客户端收到SYN+ACK后，发送最终的ACK报文段。
• 标志位：ACK=1, SYN=0。
• Seq：x + 1（因为第一步的SYN占了1个号）。
• Ack：y + 1。
• 含义：“我收到了你的SYN（序号y），确认收到的是y+1。连接建立完成。”

✅总结三次握手的确认号规律：

1. 客户端SYN：无确认号。
2. 服务端SYN+ACK：确认号为客户端ISN + 1。
3. 客户端ACK：确认号为服务端ISN + 1。

考试陷阱：如果题目问“第三次握手后的确认号是多少”，答案通常是服务端ISN + 1。如果问“第二次握手后的确认号是多少”，答案是客户端ISN + 1。

3.2 四次挥手（Four-Way Termination）

四次挥手比三次握手更复杂，因为TCP是全双工的，关闭连接需要双方分别确认。

步骤一：FIN（Client -> Server）

• 客户端发送FIN报文段。
• 标志位：FIN=1, ACK=1（通常携带ACK确认之前的数据）。
• Seq：u（客户端当前的序列号）。
• Ack：v（客户端期望收到的服务器数据）。
• 含义：“我不再发送数据了，我的最后确认序号是u（FIN占1位，所以实际结束于u+1）。”

⚠️注意：FIN同样消耗一个序列号。

步骤二：ACK（Server -> Client）

• 服务器收到FIN后，先回复ACK。
• 标志位：ACK=1, FIN=0。
• Seq：w（服务器当前的序列号）。
• Ack：u + 1。
• 含义：“我收到了你的FIN，确认序号为u+1。但我还有数据要发，稍后再关。”

📌考点：此时连接处于CLOSE_WAIT(Server) 和FIN_WAIT_1(Client) 状态。

步骤三：FIN（Server -> Client）

• 服务器数据发完后，发送FIN报文段。
• 标志位：FIN=1, ACK=1。
• Seq：z（服务器当前的序列号，可能因中间发送数据而增加）。
• Ack：u + 1（保持不变，因为还在确认客户端的FIN）。
• 含义：“我也关闭了，我的最后序号是z。”

步骤四：ACK（Client -> Server）

• 客户端收到FIN后，回复ACK。
• 标志位：ACK=1。
• Seq：u + 1。
• Ack：z + 1。
• 含义：“我收到了你的FIN，确认序号为z+1。连接彻底关闭。”

🔄特殊状态：客户端发送完ACK后，进入TIME_WAIT状态，持续2MSL（最大报文段寿命），确保服务器能收到最后的ACK。

考试技巧：在分析挥手过程时，务必注意FIN消耗序列号这一规则。如果题目给出具体的Seq值，记得加1来计算确认号。

---

第四章：确认号与滑动窗口、流量控制

4.1 滑动窗口机制简介

TCP的可靠性不仅依赖于确认号，还依赖于滑动窗口（Sliding Window）机制。

• 发送窗口：发送方可以连续发送但不需要等待确认的最大数据量。
• 接收窗口：接收方缓冲区的大小，告诉发送方“我还能收多少”。

确认号在滑动窗口中扮演着窗口移动指针的角色。

4.2 确认号如何驱动窗口滑动

假设：

• 发送方窗口起始点（Base）为S_base；
• 接收方通告窗口大小为Win；
• 接收方发送确认号Ack = N。

动作：

1. 发送方收到Ack = N，意味着N之前的数据都已确认。
2. 发送方的窗口左边界（Base）向前移动到N。
3. 发送方可以立即发送新的数据，只要不超过N + Win。

公式：
Send Window=[Ack,Ack+Window_Size) \text{Send Window} = [\text{Ack}, \text{Ack} + \text{Window\_Size})Send Window=[Ack,Ack+Window_Size)

🧩举例：

• 初始：Base=100, Win=1000。可发区间 [100, 1100)。
• 收到 Ack=300。
• Base变为300。新窗口 [300, 1300)。
• 发送方可以继续发送300~1300之间的数据。

4.3 零窗口探测（Zero Window Probe）

如果接收方缓冲区满了，它会发送一个Window Size = 0的报文段，告诉发送方“停！别发了！”

• 此时，确认号Ack依然会递增（如果有新数据到达），但窗口大小为0。
• 发送方收到零窗口后，会启动零窗口定时器。
• 定时时间到期后，发送方发送一个探测报文段（Probe Segment），其中不包含数据，但携带最新的确认号，询问接收方：“你现在有空了吗？窗口变大了吗？”
• 这是一个典型的死锁避免机制。

📝考点：零窗口探测的确认号必须是当前最新的确认号，否则无法正确推进。

---

第五章：确认号在差错控制中的高级应用

5.1 超时重传（RTO）

如果发送方发出数据后，在往返时间（RTT）内没有收到对应的确认号，就会认为数据丢失，进行重传。

• 超时时间（RTO）的计算与RTT密切相关。
• 当发生重传时，确认号不会改变（因为接收方根本没收到那个包）。
• 发送方重新发送从Ack开始的后续数据。

5.2 快速重传（Fast Retransmit）

这是TCP优化性能的关键机制，完全依赖于重复确认号。

场景：

• 发送方发送了数据段1, 2, 3, 4, 5。
• 接收方收到1, 2, 3, 5。
• 由于网络乱序，4丢失了。
• 接收方收到5后，发现缺了4，于是它知道“我收到了5，但我还需要4”。
• 接收方发送Ack = 4（重复之前的确认号）。
• 发送方收到3个重复的ACK（即收到3次Ack=4），立刻判断4丢失，无需等待超时，直接重传4。

关键点：

• 这里的Ack = 4就是重复确认号。
• 只有当收到3个重复ACK时，才触发快速重传。
• 第4个重复ACK之后，如果还没收到确认，才会触发超时重传。

5.3 选择性确认（SACK, Selective Acknowledgment）

标准的TCP确认是累积确认（Cumulative ACK），只能确认“连续的”数据。如果中间丢了，后面收到的都要重传，效率低。
SACK选项允许接收方告诉发送方：“除了ACK N之外，我还收到了 [M1, M2] 和 [M3, M4] 这些不连续的数据块。”

• SACK Option格式：包含多个“开始-结束”范围。
• 作用：发送方只需重传真正丢失的部分，而不需要重传整个窗口。
• 考试趋势：现代操作系统默认开启SACK，考试中可能会涉及SACK选项的分析。

---

第六章：实战演练与典型例题解析

6.1 基础选择题

例题1：TCP报文段中，确认号字段的作用是？

A. 指示本报文段包含的第一个数据字节的序号
B. 指示本报文段包含的最后一个数据字节的序号
C. 指示期望收到的下一个数据字节的序号
D. 指示发送方下一次发送的序号

✅答案：C
解析：确认号是累积确认，表示“下一个期望收到的序号”，即“已接收的最大序号+1”。

例题2：在TCP三次握手中，若客户端初始序列号ISN=1000，则服务端在SYN+ACK报文段中的确认号应为？

A. 1000
B. 1001
C. 1002
D. 1003

✅答案：B
解析：SYN标志位消耗一个序列号，所以确认号为ISN + 1 = 1001。

例题3：接收方收到一个乱序的报文段，但尚未收到前面的数据，此时接收方应如何处理？

A. 丢弃该报文段
B. 立即重组并向上层交付
C. 缓存该报文段，并发送重复的确认号
D. 发送NAK（否定确认）

✅答案：C
解析：TCP不支持NAK，而是通过缓存乱序数据和发送重复ACK来触发快速重传。

6.2 综合计算题

例题4：已知TCP连接建立后，客户端发送数据段，Seq=100，Len=500。服务器收到后，回复ACK。请问服务器回复的ACK报文段中，Seq和Ack分别是多少？（假设服务器之前未发送数据，且服务器发送的Seq=2000）

解：

1. 客户端发送：Seq=100, Len=500。数据范围 [100, 599]。
2. 服务器接收：确认收到 [100, 599]。
3. 服务器回复：
   • Ack：期望下一个字节是 600。所以Ack = 600。
   • Seq：服务器自己的初始序列号（假设刚建立连接或独立计数），题目给定Seq = 2000。
   • Flags：ACK=1。

✅答案：Seq=2000, Ack=600。

例题5：某TCP连接中，发送方发送了三个报文段，长度分别为100、200、300字节。初始Seq=1000。接收方收到了前两个，但第三个丢失。随后接收方又收到了第四个报文段（长度100，Seq=1300）。

(1) 接收方发送的确认号是多少？
(2) 发送方收到几个重复ACK？
(3) 发送方何时触发重传？

解：

1. 确认号：

   • 收到第一段 (100-199)，第二段 (200-399)。
   • 期望下一个是400。
   • 收到第四段 (1300-1399)，但缺了400-1299。
   • 接收方仍确认到399，发送Ack = 400。
   • 答案：Ack = 400。

2. 重复ACK数量：

   • 收到第二段时，发送第一次ACK=400（非重复）。
   • 收到第四段时，发现缺400，再次发送Ack=400。这是第1个重复ACK。
   • 如果网络中有更多乱序到达，或者发送方重传后，接收方再次收到乱序数据，会继续发重复ACK。
   • 题目问“收到几个”，通常指在触发快速重传前。
   • 修正：题目描述较简略。通常逻辑是：收到400->ACK=400（正常）；收到1300->ACK=400（第1个重复）；如果再收到一个乱序（比如1400），ACK=400（第2个重复）；再收到一个（第3个重复），触发快速重传。
   • 本题中，只收到一个乱序段（1300），所以目前只有1个重复ACK。但如果题目隐含“后续还有乱序”，则需具体分析。通常考试中，若只提到收到一个乱序，则回答“收到1个重复ACK，尚未触发快速重传”。

3. 重传触发：

   • 需要收到3个重复ACK才触发快速重传。
   • 如果一直收不到第3个重复ACK，则等待超时（RTO）后重传。

✅答案：
(1) Ack = 400
(2) 收到1个重复ACK（基于题目描述的单次乱序）。
(3) 需再收到2个重复ACK（共3个）触发快速重传；否则等待超时重传。

6.3 高级分析题：Wireshark抓包分析

（此处模拟Wireshark截图分析）

场景：

• 捕获到一个TCP会话。
• 包1：Client -> Server, Seq=100, ACK=0, SYN=1
• 包2：Server -> Client, Seq=5000, ACK=101, SYN=1, ACK=1
• 包3：Client -> Server, Seq=101, ACK=5001, ACK=1
• 包4：Client -> Server, Seq=101, ACK=5001, PSH=1, Data=“Hello” (Len=5)
• 包5：Server -> Client, Seq=5001, ACK=106, ACK=1

问题：

1. 解释包2中ACK=101的含义。
2. 解释包5中ACK=106的含义。
3. 计算包4中数据的实际字节数。

解析：

1. 包2 ACK=101：Server收到Client的SYN（Seq=100），SYN占1位，所以确认下一个字节是101。
2. 包5 ACK=106：Server收到Client的数据（Seq=101, Len=5），数据范围101-105。确认下一个字节是106。
3. 包4数据长度：Seq从101开始，ACK=106，说明接收方期望106，故数据长度为106 - 101 = 5字节。

✅结论：确认号的差值即为数据长度（在无其他标志位干扰的情况下）。

---

第七章：常见误区与避坑指南

7.1 误区一：认为ACK=Seq

• 真相：ACK和Seq是两个独立的计数器。ACK确认的是对方发来的数据，Seq是自己准备发（或已发）的数据。只有在特定时刻（如三次握手第三步），ACK的值才等于对方的Seq+1，但这不等于自己的Seq。

7.2 误区二：忽略SYN/FIN的序列号占用

• 真相：SYN和FIN标志位虽然没有数据负载，但它们都占用一个序列号。计算确认号时必须加1。
• 口诀：SYN/FIN，占一位，确认号，要加一。

7.3 误区三：认为ACK必须随数据一起发送

• 真相：TCP支持延迟确认（Delayed ACK）。接收方可以等待一小段时间（如200ms），看是否有数据要回传，将ACK合并发送。也可以每收到两个报文段发送一个ACK。这会导致ACK发送频率降低，但不影响正确性。

7.4 误区四：混淆“确认号”和“窗口大小”

• 真相：确认号告诉发送方“发到哪里了”，窗口大小告诉发送方“还能发多少”。两者配合决定发送窗口的位置和大小。

---

第八章：未来展望与IPv6时代的确认号

虽然本文主要讨论IPv4/TCP，但在IPv6环境下，确认号的机制基本保持不变。

• IPv6扩展首部：TCP在IPv6中通常作为扩展首部的一部分，但确认号字段依然在TCP头部。
• Jumbo Payload：IPv6支持更大的MTU，可能导致单个报文段数据量极大，确认号的累加速度更快，对32位序列号空间的耗尽风险增加（尽管概率极低）。
• QUIC协议：基于UDP的新协议，虽然也使用类似确认的机制，但其确认逻辑更加灵活，支持多路复用和更细粒度的确认，是未来可能的替代方案。

---

第九章：总结与备考策略

9.1 核心知识点清单

知识点	核心内容	考试频率
定义	期望收到的下一个字节序号	★★★★★
计算	Ack = Last_Seq + Length	★★★★★
SYN/FIN	消耗序列号，Ack = ISN + 1	★★★★★
重复ACK	触发快速重传的条件（3个）	★★★★☆
滑动窗口	Ack驱动窗口移动	★★★★☆
零窗口	零窗口探测机制	★★★☆☆
SACK	选择性确认机制	★★★☆☆

9.2 备考建议

1. 画图法：遇到复杂的数据交互，务必画出时序图，标出Seq和Ack的变化，这是解决难题的最有效方法。
2. 记口诀：SYN/FIN占一位，确认号里要加一。
3. 多练真题：重点练习三次握手、四次挥手的数值推导题。
4. 理解原理：不要死记硬背，理解“累积确认”和“滑动窗口”的内在逻辑。

9.3 推荐资源

• 《计算机网络》（谢希仁）：经典教材，必读。
• Wireshark官方文档：动手抓包，直观观察。
• RFC 793：TCP协议原始文档，适合进阶研究。

---

结语：确认号虽小，责任重大

确认号（Ack Num）虽然只是TCP头部中的一个32位字段，但它却是TCP协议实现可靠性的基石。它像一位严谨的“监工”，时刻监控着数据的流向，确保每一个字节都不丢失、不乱序。

掌握确认号的机制，不仅是为了应对期末考试，更是为了理解互联网底层运行的奥秘。当你下次看到Wireshark中绿色的ACK标记，或者在网络故障排查中看到重复ACK时，希望你能会心一笑，因为你知道，这正是确认号在默默守护着数据的完整与安全。

🌟记住：细节决定成败，确认号虽小，却承载着万千数据的信任。

---

作者简介：
培风图南以星河揽胜，热爱网络技术，专注分享高质量编程与网络知识。愿与你一起探索星辰大海，共赴技术之巅。

欢迎点赞、收藏、转发！
评论区留言你的疑问，我会逐一解答！

---

📌声明：本文内容基于公开资料整理，旨在帮助学习者掌握计算机网络核心知识，如有不当之处，敬请指正。

---

附录：TCP确认号相关公式速查表

1. 确认号计算公式：
   Ack=Seqreceived+Length \text{Ack} = \text{Seq}_{\text{received}} + \text{Length}Ack=Seqreceived​+Length
   （若收到SYN/FIN，Length=1）

2. 发送窗口右边界：
   Right_Edge=Ack+Window_Size \text{Right\_Edge} = \text{Ack} + \text{Window\_Size}Right_Edge=Ack+Window_Size

3. 快速重传触发条件：
   收到3个重复的ACK（即相同的Ack值）。

4. 超时重传时间（RTO）：
   RTO=SRTT+4×RTTVAR \text{RTO} = \text{SRTT} + 4 \times \text{RTTVAR}RTO=SRTT+4×RTTVAR
   （SRTT：平滑往返时间，RTTVAR：往返时间偏差）

5. 拥塞窗口（cwnd）：

   • 慢启动：指数增长
   • 拥塞避免：线性增长
   • 快恢复：减半后线性增长

---

(本文字数统计：约12000字，涵盖理论、实践、例题及拓展)