TCP字节流与可靠传输：抓包解析序号、重传与窗口机制

简介面向燕山大学计算机网络三级项目的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 开始而是由时钟和四元组哈希生成目的是避免旧连接的迟到报文被新连接误认。三次握手时双方各自交换自己的 ISNSYN 报文本身消耗一个序号所以 SYN 的 seq 是 ISN而它携带的数据如果有从 ISN1 开始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(fgap: expect{expect_seq} got{tcp.seq} flags{flags}) print(f{ip.src}:{tcp.sport}-{ip.dst}:{tcp.dport} fflags{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_granularity0.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)参数的含义值得展开ALPHA1/8意味着新样本只占 12.5% 权重均值变化平缓BETA1/4让偏差对突变更敏感K4是保守系数覆盖绝大多数正常抖动。大多数实现还会设一个 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, mss1460): 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。维度TCPUDP基于 UDP 的自建可靠传输消息边界无需应用层切分有按报文自行定义可靠性累计确认 重传无自行实现拥塞控制内核实现算法可换无需自己写容易写错头部开销20 字节起8 字节视协议而定适用场景长连接、有序字节流短报文、实时性优先需要定制重传策略的场景这张表想说明的不是“谁更好”而是“复杂度被放在了哪一层”。选 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 章的公式就能定位到具体参数。我第一次做这类实验时图省事只在回环上跑了一遍数据漂亮得离谱报告交上去被追问“跨机验证过没有”当场答不上来。从那以后我每次测传输性能都强制先确认抓包点、再确认是不是回环、最后才看数字这三步少一步都不敢下结论。希望帮到你。本文还有配套的精品资源点击获取