简介：这份资源面向计算机网络课程学习者与 Linux 网络实验入门者，聚焦 UDP 协议的数据格式、首部字段含义及实际抓包分析，帮助读者在虚拟网络拓扑中完成从协议观察到校验和计算的完整实验闭环。压缩包共 1 个文件，为 docx 格式的实验报告文档，整体约 1.13MB，内容涵盖实验目的、步骤记录与问题分析，便于直接参考或整理成自己的实验成果。文档围绕 Linux 下 nc 命令搭建 UDP 服务与客户程序、关闭网卡 offload 功能、Wireshark 抓包等环节展开，并对源端口、目的端口、长度、校验和等首部字段逐项填表分析，还给出接收方校验用户数据报的手动计算过程，适合需要理解传输层封装细节、补齐实验报告或复习协议字段的读者。目前已有 180 人学习，可作为 UDP 协议实验的对照参考。
1. UDP 报文里那个“0x78b7”：为什么一个校验和能暴露整条链路的真相
抓包软件里看到Checksum: 0x78b7这串十六进制，多数人扫一眼就过去了。可如果你真按教科书把源 IP、目的 IP、协议号、UDP 长度、整个 UDP 首部和数据拼成伪首部，逐 16 位做反码求和，最后算出来的值对不上抓包结果，那才是真正值得停下来想一想的时刻。UDP 协议探索和分析这件事，表面是背熟八个字节的首部格式，底层却是在回答一个更硬的问题：一个无连接、不确认、不重传的传输层协议，凭什么让接收方相信这串字节没在路上被改坏？答案全压在十六位校验和这一件事上，而校验和能不能算对，又牵扯出网卡 offload、伪首部、奇数长度填充这一连串容易被忽略的机制。搞懂这条链路，你再看任何一次 UDP 通信，都能从首部字段里读出端口分配策略、进程通信时序和硬件卸载的痕迹。
2. UDP 首部八字节：为什么字段少反而更难讲清
2.1 四个字段各自承担什么职责
UDP 首部固定八个字节，源端口、目的端口、长度、校验和各占两字节，之后直接跟数据。字段少到一眼能背下来，但每个字段背后都藏着一个设计决策。源端口在客户端侧通常不是程序指定的，而是操作系统从动态端口范围里临时挑一个，这就是为什么同一条nc -u命令跑两次，抓到的源端口可能完全不同。目的端口由应用程序显式给出，服务端用nc -lvu 4499绑定 4499，客户端就必须把目的端口填成 4499，否则报文到了对端也没有进程在等它。
长度字段记录的是首部加数据的总字节数，最小值是 8（只有首部没有数据），这个字段的存在让接收方能在缓冲区里准确切出一条报文，而不依赖下层 IP 的总长度。校验和字段是唯一一个“可以填 0”的字段，填 0 表示发送方不计算校验和，接收方直接跳过验证。IPv4 下这是合法的，IPv6 下则强制要求计算，因为 IPv6 首部去掉了校验和，传输层不再有兜底。
提示：长度字段统计的是 UDP 首部加数据，不含伪首部；伪首部只参与校验和计算，不会真的出现在链路上。
2.2 伪首部为什么必须存在
单看 UDP 首部，校验和只覆盖了端口、长度和数据，完全不涉及 IP 地址。这意味着一个报文如果被错误地投递到了另一台主机，只要端口对得上，接收方根本发现不了。伪首部的引入就是为了把网络层的关键信息拉进校验范围：源 IP、目的 IP、一个填 0 的字节、协议号 17、UDP 长度，这十二个字节在计算时拼在 UDP 首部前面，算完就丢弃，不传输。
常见的实现思路是，发送方在计算校验和时临时构造这块伪首部内存，和真正的 UDP 报文一起做反码求和；接收方则从 IP 层拿到源和目的地址，重新拼一份同样的伪首部，用收到的校验和参与验证。这样任何 IP 地址层面的错投、协议号错配都会被校验和捕获。代价是 UDP 校验和的计算强依赖 IP 层信息，传输层不再完全独立，这也是它在设计上被诟病的一点，但换来的是端到端完整性的一道基本防线。
2.3 反码求和：为什么接收方算出来必须是 0
UDP 校验和用的是 16 位反码求和，不是常见的补码加法。规则是把所有 16 位字相加，溢出的进位回卷加到低位，最后取反码得到校验和。发送方算完填入首部，接收方则把所有字（包括校验和字段本身）一起再求一次反码和，如果结果为 0，说明传输无误。
这个“结果为 0 即通过”的性质来自反码运算的自反性：一个数加上它的反码，16 位全 1，再取反就是 0。所以接收方不需要单独把校验和字段摘出来比对，直接整体再算一遍就行，硬件实现极其简单。下面这段 Python 把发送方的计算过程完整还原了一遍，包括奇数长度补零和伪首部拼接：
def udp_checksum(src_ip, dst_ip, udp_bytes): # 构造伪首部：源IP + 目的IP + 0 + 协议号17 + UDP长度 pseudo = src_ip + dst_ip + b'\x00' + b'\x00\x11' + len(udp_bytes).to_bytes(2, 'big') # 奇数长度在尾部补一个全0字节，保证16位对齐 if len(udp_bytes) % 2: udp_bytes += b'\x00' data = pseudo + udp_bytes total = 0 # 逐16位字做反码加法，进位回卷 for i in range(0, len(data), 2): word = (data[i] << 8) + data[i + 1] total += word total = (total & 0xffff) + (total >> 16) return (~total) & 0xffffsrc_ip和dst_ip必须是四字节的 IPv4 地址原始字节，不是点分十进制字符串；udp_bytes是完整的 UDP 首部加数据，校验和字段在计算时先填 0。循环里的total = (total & 0xffff) + (total >> 16)就是进位回卷，把溢出到第 17 位的部分加回低 16 位。最后取反并截断到 16 位。如果算出来的结果是 0，按协议规定要写成 0xFFFF，因为全 0 在校验和字段里表示“未计算”，两者必须区分开。
3. 网卡 offload：为什么抓包看到的校验和是错的
3.1 校验和卸载把计算从 CPU 挪到了网卡
现代网卡普遍支持 checksum offload，发送方向上，操作系统不再在协议栈里算 UDP 校验和，而是把首部里的校验和字段填成一个占位值，打上标记交给网卡，由网卡硬件在真正发出前算好填进去。接收方向上同理，网卡验证完校验和再交给内核，内核省掉一次全报文扫描。
这个优化在真实流量里完全透明，但对抓包是灾难性的。Wireshark 在协议栈的上层抓包，看到的是网卡还没处理的那份报文，校验和字段要么是 0，要么是一个明显不对的随机值。很多人第一次做这个实验，对着抓包结果手算校验和，怎么算都对不上，翻来覆去检查伪首部，最后才发现是 offload 在捣鬼。实验步骤里专门要求关闭网卡 offload 功能，把运输层封装时需要的计算还给 CPU，就是为了让抓包看到的校验和是协议栈真实算出来的值，手算验证才有意义。
关闭的命令通常落在ethtool上：
# 关闭指定网卡的发送和接收校验和卸载 ethtool -K tap57C tx off rx off # 查看当前 offload 状态，确认 tx-checksumming 已变为 off ethtool -k tap57C | grep checksum-K是修改网卡特性，tx和rx分别对应发送和接收方向。在虚拟网络拓扑里，接口是 tap 设备，同样支持这套参数。执行完再用-k查一遍，确认tx-checksumming和rx-checksumming都显示 off，否则抓到的校验和依旧不可信。这一步不做，后面所有关于校验和的分析都是空中楼阁。
3.2 虚拟网络拓扑里 offload 的边界在哪
实验用 network namespace 加网桥搭拓扑，每个 namespace 里有一块虚拟接口，通过 veth pair 连到网桥。veth 是纯软件设备，它的 offload 行为取决于内核和驱动实现，默认情况下很多特性是开启的。这就带来一个容易踩的坑：你在 namespace 里关了 offload，但报文经过网桥转发到另一侧时，对端接口的 offload 状态可能还是开的，导致某一侧的抓包校验和正常、另一侧不正常。
我一般会这么理解：offload 是接口级别的属性，不是全局开关，链路上每一块参与收发的接口都要单独确认。拓扑里有几个 namespace、几块 tap 或 veth 接口，就得逐个ethtool -K关一遍。实验指导里给的脚本通常已经处理了这一点，但如果自己手搭拓扑，漏掉任何一个接口，抓包结果就会时对时错，排查起来非常费劲。
3.3 抓包位置决定了你看到的是哪一层
Wireshark 抓的是接口上的报文副本，这个副本在协议栈的哪个位置被复制出来，直接决定了校验和字段的状态。在发送端抓，如果 offload 没关，看到的是占位值；在接收端抓，如果接收 offload 没关，看到的是网卡验证前的原始值。只有在两端 offload 都关闭、且抓包点位于协议栈校验和计算之后，看到的才是可验证的值。
这也是为什么实验要求先在 ns57C 上启动 Wireshark、选 tap57C 接口抓包，再发起通信。抓包点选对了，后面分析首部字段和校验和才有依据。如果抓包点选在了错误的接口上，可能连报文都看不到，或者只看到单向流量，问题分析就无从谈起。
4. 端口分配与通信时序：动态端口是怎么被选中的
4.1 客户端源端口为什么每次都不一样
UDP 客户端调用nc -u 192.168.57.254 4499时，只指定了目的地址和目的端口，源端口留空。内核在发送第一个报文前，从本地端口范围里挑一个当前未被占用的端口绑定上去。Linux 的动态端口范围默认在/proc/sys/net/ipv4/ip_local_port_range里定义，通常是 32768 到 60999 这个区间，实验里抓到的 43990 就落在这个范围内。
这个分配是惰性的：直到真正要发包时才绑定，而且绑定后在整个 socket 生命周期内保持不变。所以同一个nc会话里发的多条报文，源端口是一致的；但退出重开一个会话，内核可能挑一个完全不同的端口。理解这一点，才能解释为什么抓包结果里客户端源端口看起来“随机”，而服务端目的端口始终是 4499。
4.2 服务端什么时候知道客户端端口
UDP 没有连接建立过程，服务端在recvfrom返回之前，根本不知道对端是谁。客户端发来的第一个报文到达时，内核从 UDP 首部里取出源端口和源 IP，连同数据一起交给服务端的 socket，服务端这时才第一次获知客户端的地址和端口。之后服务端要回包，就把这个源端口当作目的端口填进去，源端口填自己绑定的 4499。
这个时序在抓包里看得很清楚：第一个报文方向是客户端到服务端，源端口是动态分配的，目的端口是 4499；第二个报文方向反过来，源端口 4499，目的端口就是刚才那个动态端口。两个报文的首部字段互为镜像，长度字段则因为数据内容不同而不同。实验里客户端发的是hi,57C加换行，服务端回的是另一行字符，长度自然对不上，这也是为什么两张首部表里的长度值一个是 15、一个是 18。
4.3 无连接带来的状态缺失
TCP 有三次握手，双方在握手阶段就交换并确认了端口和序列号，连接状态在内核里维护。UDP 什么都没有，每个报文都是独立的，服务端不维护“这个客户端曾经来过”的状态，除非应用层自己记。这意味着如果客户端换了端口重发，服务端会把它当成一个全新的对端，回包也发到新端口上。
这种无状态设计让 UDP 极其轻量，适合实时音视频、DNS 查询这类“一问一答、丢了就丢了”的场景，但也意味着应用层如果要实现可靠传输，重传、排序、去重全得自己扛。实验里用nc做最简单的双向通信，恰好把这种“每个报文自带完整地址信息”的特点暴露得很干净。
5. 避坑与排查：校验和对不上时先看这五处
5.1 现象：手算校验和与抓包值不一致
原因几乎总是 offload 没关干净。发送端接口的tx-checksumming还开着，协议栈填的是占位值，网卡还没算真实校验和，抓包就把它抓走了。解决方法是回到拓扑里，对每一块参与收发的接口执行ethtool -K <iface> tx off rx off，再用ethtool -k <iface> | grep checksum逐个确认状态为 off，然后重新抓包。
5.2 现象：伪首部拼进去之后结果还是不对
检查 IP 地址的字节序。伪首部里的源和目的 IP 必须是网络字节序的四字节原始值，如果误用了点分十进制字符串或者主机字节序的整数，拼出来的字完全错位。另外协议号字段占两字节，值是 0x0011，不是单字节的 0x11 后面跟一个数据字节，这个位置错一位，整个求和就全乱。
5.3 现象：奇数长度报文校验和总是差一点
UDP 数据部分如果是奇数个字节，必须在尾部补一个全 0 字节凑成偶数再参与计算，但这个填充字节不写入长度字段，也不实际发送。实验里客户端发的hi,57C\n是 7 个字节，加上 8 字节首部共 15 字节，是奇数，计算时必须补一个 0 字节。漏掉这一步，求和结果会少一个 16 位字，校验和自然对不上。
5.4 现象：抓包只看到单向流量
多半是抓包接口选错了。拓扑里每个 namespace 有自己的接口，在 ns57C 上抓 tap57C 只能看到经过这块接口的报文。如果客户端和服务端之间的路径经过网桥，而抓包点不在路径上，就只能看到部分流量。确认ip netns list和brctl show的输出，理清报文实际走哪条路径，再把抓包点放到路径中间的接口上。
5.5 现象：服务端收不到客户端发的字符
先确认服务端nc -lvu 4499确实在监听，-l是监听模式，-v输出详细信息，-u指定 UDP，三个参数缺一不可。再确认客户端的目的 IP 是服务端所在 namespace 的地址，不是网桥地址或宿主地址。最后看静态路由配没配对，跨 namespace 通信依赖路由表把报文导向正确的接口，路由缺失时报文在源端就被丢弃，抓包什么都看不到。
6. 从校验和到设计取舍：UDP 到底把什么交给了上层
UDP 校验和这套机制最值得琢磨的地方，不在于它怎么算，而在于它“算到什么程度就停”。它只保证端到端字节没被改坏，不保证顺序、不保证到达、不保证不重复，甚至连校验和本身在 IPv4 下都是可选的。这种克制不是偷懒，是把复杂度推给真正需要它的应用层。DNS 自己处理超时重传，实时音视频宁可丢帧也不等重传，游戏同步在应用层做插值和预测，每个场景对“可靠”的定义都不一样，传输层统一提供反而会拖累所有人。
网卡 offload 的存在则揭示了另一层取舍：协议规范定义的是“应该怎样”，实现可以选择“在哪里做”。校验和的计算位置从 CPU 挪到网卡，语义没变，性能变了，但可观测性也变了。抓包工具看到的不再是最终报文，而是处理过程中的中间态。这提醒我们，任何“抓包看到的就是真相”的假设都值得怀疑，得先搞清楚抓包点在协议栈的哪一层、硬件在哪个环节介入。
我自己的习惯是，每次做传输层实验，先不急着看数据，先把 offload 状态、抓包接口、路由表这三样确认一遍，再开始分析首部字段。这三步走完，后面手算校验和、比对端口、看时序，基本不会翻车。那份实验资料里把拓扑搭建、静态路由、offload 关闭、抓包分析串成一条完整链路，正好是把这些底层机制一次性跑通的好材料，值得拿来对着源码和命令逐条验证。希望帮到你。
本文还有配套的精品资源，点击获取