linux网络报文校验由内核协议栈自动完成，无需用户配置：tcp/udp校验和、ip头校验和、以太网crc均硬编码实现，任一失败则丢包或重传；端到端完整性需应用层保障，如sha256sum校验。
Linux 网络报文校验不是靠用户手动“配置”传输层或链路层的校验逻辑，而是由协议栈自动完成的。你无法也不应修改 TCP 校验和、IP 头校验和或以太网 CRC 的计算方式——它们是内核硬编码实现的底层机制，目的就是保障内网数据在物理链路和网络路径中不被意外损坏。
理解报文校验的自动性
从应用进程发出数据开始，每层封装都会附加自己的校验字段：
- 传输层（TCP/UDP）：TCP 头含 16 位校验和，覆盖 TCP 头 + 数据 + 伪 IP 头；UDP 校验和可选但默认启用，作用类似
- 网络层（IP）：IPv4 头含 16 位校验和，只校验 IP 头（不含载荷），用于检测路由过程中头字段是否出错
- 数据链路层（以太网）：帧尾附带 4 字节 CRC-32，由网卡硬件或驱动计算，确保帧在物理线路上未被干扰或衰减破坏
这些校验全部由内核协议栈静默执行。接收端一旦发现任一校验失败，对应报文会被直接丢弃，上层应用收不到；TCP 还会触发重传。你不需要开启、关闭或调参。
真正需要你关注的完整性环节
协议栈能防线路噪声、内存翻转、网卡故障等低层损坏，但无法防范：
- 应用写入缓冲区前的数据污染（如程序 bug 导致 memcpy 越界）
- 文件传输过程中的内容篡改或换行符转换（如 Windows 编辑器保存后上传）
- 中间设备（如老旧交换机、NAT 设备）静默丢包或截断（TCP 虽重传，但若超时设置不合理可能影响体验）
因此，端到端完整性保障要落在应用层或文件层：
- 传输大文件（如 tar 包、镜像）时，在发送方生成 sha256sum 校验值：
sha256sum app.tar.gz > app.tar.gz.sha256 - 连同文件一起传到接收方，用
sha256sum -c app.tar.gz.sha256验证——注意检查命令退出码，0 才表示一致 - 脚本中务必加引号：
sha256sum -c "$file.sha256"，避免空格路径导致校验对象错误
排查内网传输异常的实用步骤
当发现业务数据“似乎不完整”（如 JSON 解析失败、tar 解包报 checksum error、网页乱码），按此顺序排查：
- 确认是否为应用层问题：用
tcpdump -i eth0 -w capture.pcap port 8080抓包，Wireshark 打开看 HTTP 响应体是否完整，排除服务端输出截断 - 检查文件换行与编码：接收方运行
file -i your_file和head -1 your_file | od -c，确认是text/plain; charset=utf-8且末尾为\n，非\r\n或 BOM - 验证传输后文件大小：对比
ls -l输出，大小不一致说明传输中断或 rsync/sftp 未启用校验模式 - 禁用 offload 特性辅助诊断（仅临时）：
ethtool -K eth0 tx off rx off gso off，防止某些网卡硬件卸载引发校验绕过假象
为什么不用 md5sum 做传输校验
MD5 已被证实存在碰撞漏洞，攻击者可在已知明文前提下构造不同内容产生相同哈希。它只适合离线防误操作，比如本地备份前后比对。内网虽相对可信，但若传输的是部署包、密钥或配置，仍建议统一使用 sha256sum 或更进一步用 gpg --detach-sign 建立信任链。生产环境的任何校验脚本，都应把 sha256sum -c 的退出状态作为唯一判断依据，而非解析 stdout。
