简介：面向燕山大学计算机网络三级项目的TCP传输数据包实践资料，适合正在学习传输层协议、需要完成课程设计或网络编程入门的高校学生。内容围绕TCP连接建立与释放、数据分片与重组、滑动窗口流量控制、拥塞控制及确认重传机制展开，可帮助读者从协议原理过渡到可运行的客户端/服务器通信程序，并理解慢启动、快速重传与快速恢复等算法的实现思路。压缩包共60个文件，约27.88MB，包含C++源文件与头文件、Visual Studio解决方案及项目配置，另带运行日志、调试符号和程序数据库等中间产物；服务端与客户端工程相互独立，目录结构便于对照阅读、编译和复现实验。已有1355人学习下载，适合用作课程项目参考与TCP通信调试排错，通过修改参数、模拟不同网络环境观察传输性能变化，加深对可靠传输机制的理解。

1. 字节流里的“包”：TCP传输数据包为什么先把边界藏起来

做计算机网络三级项目时，多数人第一次抓包都会卡在同一个地方：明明应用层只调用了一次send()，抓包结果里却躺着两三个 TCP 段；反过来，一次recv()读出来的内容，又可能横跨好几个段。这是 TCP 有意为之——它向上提供的是有序字节流，而不是消息队列。所谓“TCP 传输数据包”，抓包软件里看到的那个 segment，既不是“应用层发出的一条消息”，也不是“按长度切成的一个包”，它只是“当前能塞进窗口的一批字节”。理解这一点，后面所有序列号、确认号、重传、窗口的机制才立得住。这个项目真正有价值的地方，是把“数据包”这三个字从直觉理解拽回到字节偏移的账本上：可靠性不是靠“包编号 + 重发”实现的，而是靠“字节序号 + 累计确认 + 窗口”共同维持的一个不变式。

2. 首部字段的字节账本：seq 和 ack 到底在数什么

TCP 首部里最容易被误解的两个 32 位字段就是序号和确认号。很多同学第一次写实验报告时会写“seq 是包编号”，这句话在抓包分析里几乎必然导致后面全部推理错误。正确的理解是：seq 标记的是本报文段第一个数据字节在整个字节流中的偏移，ack 标记的是“我已经连续收到这个位置之前的全部字节，下一个想要的是这个位置”。它们数的是字节，不是包。

2.1 序号空间与“累计确认”的含义

TCP 为每个连接维护一个 32 位序号空间，回绕靠模运算处理。发送端初始序号（ISN）并不是从 0 开始，而是由时钟和四元组哈希生成，目的是避免旧连接的迟到报文被新连接误认。三次握手时双方各自交换自己的 ISN：SYN 报文本身消耗一个序号，所以 SYN 的 seq 是 ISN，而它携带的数据（如果有）从 ISN+1 开始；FIN 同样消耗一个序号。这也是为什么抓包里看到“纯 ACK 段 seq 不变”是正常的——没有数据就没有字节推进。

确认号是累计的，这一点决定了 TCP 的确认粒度。假设接收端收到[1000, 2000)和[3000, 4000)两段，但[2000, 3000)丢了，那么它回给发送端的 ack 只能是 2000，不能是 4000。这就是“累计确认”的代价：一个洞会把后面已经到达的数据全部挡在确认之外。后面要讲的快速重传和 SACK，本质上都是在给这个代价打补丁。

提示：抓包时判断“有没有丢包”，最直接的依据不是看有没有 Retransmission 标记，而是看 ack 号是否长时间停在同一个值上不动。

2.2 用一段脚本把 seq 增量还原成字节流

实验报告里只贴 Wireshark 截图说明不了问题，真正能验证“seq 数的是字节”的办法，是把 pcap 读出来，自己维护一个期望序号，检查每次到达的段是否连续。下面这段脚本用 Scapy 做这件事，重点不在解析，而在那个expect_seq变量：

from scapy.all import rdpcap, TCP, IP # 读取项目里抓到的 pcap，只处理 TCP 层 pkts = rdpcap("tcp_demo.pcap") expect_seq = None # 接收端视角：下一个期望的字节偏移 for p in pkts: if not p.haslayer(TCP): continue ip, tcp = p[IP], p[TCP] payload_len = len(bytes(tcp.payload)) # 应用层真实字节数 flags = tcp.sprintf("%TCP.flags%") # 有数据或带 SYN/FIN 的段才推进序号空间 consumes = payload_len + (1 if "S" in flags else 0) + (1 if "F" in flags else 0) if expect_seq is not None and payload_len > 0 and tcp.seq != expect_seq: # 序号对不上：丢包、乱序或重传，三者要结合时间戳区分 print(f"gap: expect={expect_seq} got={tcp.seq} flags={flags}") print(f"{ip.src}:{tcp.sport}->{ip.dst}:{tcp.dport} " f"flags={flags} seq={tcp.seq} ack={tcp.ack} len={payload_len}") # 关键一行：下一个期望字节 = 当前 seq + 本段消耗的序号数 if consumes: expect_seq = (tcp.seq + consumes) & 0xFFFFFFFF

这段代码有三个地方值得在报告里讲清楚。第一，payload_len取的是tcp.payload的字节数，而不是 IP 总长度减去首部，后者会把 TCP 选项算进去导致偏差。第二，consumes把 SYN 和 FIN 各算 1，这是很多同学写解析器时漏掉的地方，一旦连接建立或拆除，期望序号就会错位。第三，& 0xFFFFFFFF是序号回绕处理，短连接抓包看不出来，长连接或高吞吐场景下必然遇到。

2.3 首部里那些“看起来没用”的字段

数据偏移（首部长度）是 4 位，单位是 4 字节，所以 TCP 首部最长 60 字节，基础 20 字节，剩下 40 字节留给选项。窗口字段 16 位，最大 65535，这就是为什么高带宽时延积链路上必须开窗口缩放选项，否则吞吐被硬卡在 64KB 级别。校验和覆盖首部加数据再加一个伪首部（源 IP、目的 IP、协议号、TCP 长度），这个伪首部是 TCP 和 UDP 共有的设计，目的是让传输层能间接校验 IP 层的关键字段没被改坏。理解这些字段的位宽限制，比背“首部有哪些字段”有用得多——它们直接决定了后面窗口和吞吐的上限。

3. 可靠性机制：重传定时器为什么不能拍脑袋定

“丢了就重传”这句话没错，但工程上真正难的是什么时候判定丢了。定太短，正常延迟抖动会被误判成丢包，触发无谓重传，把网络越搞越堵；定太长，吞吐上不去。TCP 的答案是让 RTO（重传超时）跟着 RTT 自适应，这是整个可靠性机制里最像控制论的部分。

3.1 SRTT 与 RTTVAR：把 RTT 的均值和抖动分开跟踪

早期 TCP 用固定 RTO，结果在跨洋链路上频繁误重传。后来引入的做法是同时维护 RTT 的平滑均值和均值偏差：均值告诉你“大概多久能回”，偏差告诉你“这个估计有多不靠谱”。RTO 取“均值 + 4 倍偏差”，偏差大就把超时拉长。

# RFC 6298 的自适应 RTO 实现，ALPHA/BETA/K 是经典经验值 ALPHA, BETA, K = 1/8, 1/4, 4 srtt = None # 平滑 RTT rttvar = None # RTT 偏差 def update_rto(rtt_sample, clock_granularity=0.001): global srtt, rttvar if srtt is None: # 第一个样本：直接初始化，偏差取一半 srtt = rtt_sample rttvar = rtt_sample / 2 else: # 先更新偏差，再更新均值，顺序不能反 rttvar = (1 - BETA) * rttvar + BETA * abs(srtt - rtt_sample) srtt = (1 - ALPHA) * srtt + ALPHA * rtt_sample # RTO 下限取 200ms，避免低延迟链路上过度重传 return max(srtt + max(clock_granularity, K * rttvar), 0.2)

参数的含义值得展开：ALPHA=1/8意味着新样本只占 12.5% 权重，均值变化平缓；BETA=1/4让偏差对突变更敏感；K=4是保守系数，覆盖绝大多数正常抖动。大多数实现还会设一个 1 秒的初始 RTO 和 60 秒上限，并在连续超时后做指数退避——每次重传把 RTO 翻倍，这就是为什么严重丢包时你会看到重传间隔按 1s、2s、4s、8s 拉开。这个退避机制是网络拥塞时的一种自我克制，避免大量连接同时疯狂重传把链路压垮。

3.2 快速重传：不等超时，用重复 ACK 提前发现洞

RTO 最短也是 200ms 量级，一个丢包等超时太奢侈。TCP 的第二个手段是快速重传：接收端每收到一个乱序段，就立刻重复发一次当前期望的 ack。发送端如果连续收到 3 个相同的重复 ACK，就推断“这个 ack 之后的那段大概率丢了”，不等定时器，直接重传那一段。选 3 而不是 1，是因为乱序也会产生重复 ACK，阈值取 3 是在“反应速度”和“误判率”之间做的一个折中，这个数字背后是早期实测得出的经验。

快速重传只能一次补一个洞，如果一次丢了多段，发送端会陷入“重传一段、再收重复 ACK、再重传一段”的低效循环。SACK（选择性确认）选项就是为解决这个问题加的：接收端在 ACK 里附带“我还收到了哪些区间”，发送端据此知道哪些段其实已经安全到达，只补真正的空洞。这也是为什么现代抓包里经常能看到 SACK 块，而很多老教材还在只讲累计确认。

3.3 重传二义性：为什么算 RTT 时要特别小心

Karn 算法指出了一个隐蔽问题：如果一段数据被重传过，那么收到的 ACK 到底是对第一次发送的确认，还是对重传的确认？无法区分。如果错把重传后的 ACK 当成第一次的样本，RTT 会被严重低估，RTO 随之变小，引发更多误重传，形成正反馈。所以标准做法是重传过的段不参与 RTT 采样，并且超时后把 RTO 按指数退避。这个细节在实验报告里很少被提到，但它是理解“为什么抓包看到的 RTO 会突然变大”的关键。

4. 窗口博弈：rwnd 与 cwnd 谁决定发多快

一个连接能发多少未确认数据，取决于两个窗口的较小值：接收端通告的rwnd和发送端自己维护的cwnd。前者是“对方缓冲区还剩多少”，后者是“网络大概能承受多少”。把这两个混为一谈，是做流量控制实验时最常见的概念错误。

4.1 滑动窗口：接收端能力的翻译官

接收端在每个 ACK 里带上自己的可用缓冲区大小，单位是字节。发送端维护snd_una（最早未确认）和snd_nxt（下一个要发），两者之差就是“在途字节数”。只要在途字节数小于min(rwnd, cwnd)，就能继续发。接收端缓冲区被应用层读走多少，窗口就重新张开多少——这就是“窗口更新”报文的来源。如果应用层读得太慢，窗口会一路缩到 0，发送端进入零窗口探测，定期发一个字节探路，防止窗口更新报文丢失导致双方死等。

4.2 cwnd 的四个阶段：慢启动、拥塞避免、快重传、快恢复

拥塞窗口是发送端对网络容量的估计，没有任何报文直接告诉它，只能靠 ACK 的到达节奏去推断。慢启动阶段每收到一个 ACK 就把cwnd加一个 MSS，效果是指数增长——名字叫“慢”，其实一点都不慢，只是起点低（常见初始值 10 个 MSS 左右）。涨到慢启动阈值ssthresh后进入拥塞避免，每个 RTT 只加一个 MSS，变成线性增长。一旦检测到丢包，ssthresh砍半，cwnd回退，然后根据是超时还是三次重复 ACK 走不同分支：超时最保守，直接回到 1 个 MSS 重新慢启动；快速重传则走快恢复，cwnd减半后直接进入拥塞避免，不至于从头再来。

这条曲线在实验里可以直接画出来：横轴是 RTT 轮次，纵轴是cwnd，你会看到锯齿状的上升和回落。锯齿的斜率对应增长阶段，回落幅度对应丢包类型。报告里如果能解释“为什么同样的丢包率下，不同算法的锯齿形状不一样”，深度就出来了。

4.3 Nagle 与延迟 ACK：两个优化撞在一起会互相等

这是实验里最容易踩的坑，没有之一。Nagle 算法为了减少小包，规定“如果还有未确认的小段，就先攒着不发”；延迟 ACK 为了减少纯 ACK 报文，规定“收到数据后等一小会儿，看能不能捎带确认”。两个机制各自都合理，凑在一起就会出现经典的“糊涂窗口”式等待：发送端等 ACK 才发下一段，接收端等数据才发 ACK，双方各等几十毫秒。表现是交互式应用延迟莫名变高，但抓包看又没有丢包。解决办法通常是在应用层设置TCP_NODELAY关掉 Nagle，或者把多次小写合并成一次大写。这段经历几乎是每个做网络实验的人都会有的血泪经验。

注意：TCP_NODELAY不是万能的。它只是关掉发送端攒包，如果应用层本身就在频繁发一个字节，网络上的小包数量会暴涨，这时候更该做的是应用层缓冲。

4.4 用代码把发送窗口的逻辑跑一遍

概念讲完，落到实现上其实就是一个“可用窗口”的计算。下面这段模拟代码把snd_una、snd_nxt、cwnd、rwnd四个变量的关系固定下来，改动其中一个就能观察行为变化：

class SenderWindow: def __init__(self, mss=1460): self.mss = mss self.cwnd = 10 * mss # 初始拥塞窗口，常见 10 个 MSS self.snd_una = 0 # 最早未被确认的字节 self.snd_nxt = 0 # 下一个待发送字节 self.rwnd = 65535 # 接收端通告窗口，可被窗口缩放放大 def usable(self): # 能发的量 = 较小窗口 - 已在途字节 inflight = self.snd_nxt - self.snd_una return min(self.cwnd, self.rwnd) - inflight def send(self, data_len): if data_len > self.usable(): return 0 # 窗口不足，交给上层稍后重试 self.snd_nxt += data_len return data_len def on_ack(self, ack_no): # 累计确认推进，释放窗口 self.snd_una = max(self.snd_una, ack_no)

usable()这一行是整个发送逻辑的核心：两个窗口取小，再减去在途量。如果把rwnd写死成 65535 而忘了窗口缩放，高带宽链路上的吞吐会被卡死；如果把cwnd的更新逻辑去掉，就退化成一个静态窗口协议，丢包后不会退让。实验里通常要求对比“固定窗口”和“拥塞控制窗口”两种模式的吞吐曲线，差异就来自这里。

5. 抓包排查：三级项目里最容易翻车的五个现场

实验环境和真实网络最大的差别是：真实网络里“看起来正常”的东西，往往藏着你没意识到的假设。下面这几条是同类项目里反复出现的现象，按“看到什么、为什么、怎么办”整理。

现象一：抓包里大量红色重传，但代码逻辑没改过。原因多半不是真丢包，而是延迟 ACK 和 Nagle 互相等待，导致发送端 RTO 到期误判。也可能是抓包点选在了错误的网卡上，把本机回环流量和真实链路混在一起。解决方式是先确认抓包位置，再在应用层关掉 Nagle 或合并写操作，观察重传是否消失。

现象二：一次send()对端要读好几次，或者几次send()被一次读完。这是字节流没有消息边界的直接体现，不是 bug。解决方式是在应用层加长度前缀或分隔符，让接收端自己切分。指望 TCP 保留发送边界，等于要求一个字节流协议去做消息协议的事，方向就错了。

现象三：本机回环测试吞吐很高，换到两台机器就断崖式下跌。回环接口不经过真实队列，窗口和拥塞控制几乎不会被触发，测出来的数字没有参考价值。跨机测试才会暴露带宽时延积、MSS 协商、路径 MTU 等问题。实验报告里如果只放回环数据，结论基本不成立。

现象四：握手正常，传大数据时卡死，小数据却没事。典型是路径 MTU 黑洞：中间链路 MTU 较小，大包被丢弃，而 ICMP 的“需要分片”报文又被过滤掉，发送端一直按大 MSS 重传。解决方式是在两端抓包对比，必要时在防火墙上放行 ICMP，或在接口上做 MSS clamp。

现象五：seq 突然回退，看起来像协议实现错了。大概率是重传，而且是伪重传——原包其实到了，只是 ACK 迟到，发送端误判后重发了一份。判断方法是看时间戳选项和 ACK 到达时间，如果重传后很快收到覆盖该段的 ACK，基本可以确认是伪重传。这类现象说明 RTO 估计偏激进，可以对照第 3 章的公式回头检查采样逻辑。

6. 设计取舍：把可靠性压在端到端，代价与回报

TCP 把可靠性、有序性、流量控制全部放在端系统实现，链路层只负责尽力转发。这个选择来自端到端原则：网络中间设备越简单，越容易演进；复杂状态放在两端，故障域更小。代价也很明显——每个连接都要自己维护序号空间、定时器、窗口和拥塞状态，端系统负担重，而且应用层拿不到消息边界，必须自己做 framing。

这张表想说明的不是“谁更好”，而是“复杂度被放在了哪一层”。选 TCP 就是把重传、拥塞、窗口这些机制交给内核，换来的是不用自己处理 RTO 退避和伪重传；选 UDP 自建，是把控制权拿回来，但要自己承担所有边界情况。很多应用层协议最终在 UDP 上重新实现了一遍确认和重传，这件事本身就说明：可靠性是有成本的，问题只在于你愿意在哪一层付。

验证设计取舍最直接的办法是构造受控网络。用tc netem在本地注入延迟和丢包，分别在 1%、5%、10% 丢包率下跑同一份传输代码，记录吞吐和重传次数：

# 在出口网卡上注入 5% 随机丢包和 20ms 延迟，模拟弱网 sudo tc qdisc add dev eth0 root netem loss 5% delay 20ms # 实验结束后务必清理，否则会影响后续所有流量 sudo tc qdisc del dev eth0 root

命令本身很简单，关键是实验设计：固定文件大小和并发数，只改丢包率一个变量，每组跑三次取中位数。如果吞吐随丢包率下降的曲线比理论模型陡太多，八成是 RTO 下限设得太大或者拥塞窗口回退过于激进，这时候再回头看第 3、4 章的公式，就能定位到具体参数。

我第一次做这类实验时，图省事只在回环上跑了一遍，数据漂亮得离谱，报告交上去被追问“跨机验证过没有”，当场答不上来。从那以后我每次测传输性能，都强制先确认抓包点、再确认是不是回环、最后才看数字，这三步少一步都不敢下结论。希望帮到你。

本文还有配套的精品资源，点击获取