MTU

TCP 最大段大小选项 MSS，按照其定义的开销规则，通告接收端可接受的 TCP 数据大小。两个方向分别通告，数值不必相同。路由器转发 SYN 消息时可以减小这些值，使后续数据段适应受限路径。这改变的是相关连接的 TCP 行为，不会修改底层链路 MTU。把选项调整与网络本身修复区分开，才能准确说明它解决了什么。 坏掉的样子 中间瓶颈可能比两个端点接口都小。如果经典路径 MTU 反馈被过滤，连接可以成功建立，却在较大数据上停滞。降低 MSS 能帮助该 TCP 流量避开超大报文，但缺失的反馈仍然缺失。若把这个变通措施当作完整网络修复，其他协议与流量模式仍可能暴露原有问题，健康检查也可能继续遗漏受影响场景。 MSS 不是完整 IP 包大小。IPv4 路径 MTU 为 1280、普通 IPv4 与 TCP 基础头各占 20 字节时，基本计算得到通告 MSS 1240。形成真实数据段时，还要为实际 IP 或 TCP 选项另外留空间。把通告值直接等同于最终线路报文长度，可能使看似保守的设置仍然超限。应明确每个数字包含哪些头部，而不是只套一个固定减法。 方向和时机也很重要。只修改一个 SYN 方向，另一端通告仍保持原样；更新规则，也不会改写已有连接早先交换过的选项。真正的限制应降低过大通告，而不是抬高对端原本更小的上限。策略应针对真实瓶颈和相关流量，不能把一个硬编码值视为所有网络都合适，也不能假定旧连接会自动采用新配置。 快速验证 将脚本保存为 check-mss-clamp.py，准备 Docker 后运行 python3 check-mss-clamp.py。一次性环境使用 Python 3.11.16、iproute2 6.1.0、nftables 1.0.6 和 tcpdump 4.99.3，在 Linux 6.12.76 上验证。NET_ADMIN 与 SYS_ADMIN 支持四个嵌套命名空间。端点链路 MTU 为 1500，两台路由器之间的链路为 1280： ...

路径 MTU 是某条具体路由上各链路 MTU 的最小值。发送端不能只根据自身接口确定它，因为中间链路可能只能承载更小的数据包。经典 IPv4 路径 MTU 发现设置禁止分片标志，通过 ICMP“需要分片”反馈降低估计包大小。路由能够到达目的地，与发送大小适合整条路径，是两项不同条件，前者成立不能自动证明后者。 坏掉的样子 隧道或其他受限中间链路，可能使大传输失败，而 TCP 握手与小请求仍然成功。小报文能够通过瓶颈，因此这些成功没有验证完整大小的数据。反复只测短 ping 或微小健康响应，就可能漏掉影响上传、大响应或持续传输的路径 MTU 问题。应让检查包含真实负载中会触发限制的大小，避免健康探针与实际业务长期脱节。 过滤必要 ICMP 反馈，会让过大报文进入黑洞。发送端观察到没有进展，却缺少指出更小 MTU 的经典信号。其他探测机制可能提供帮助，取决于传输协议和配置，因此不能断言所有 TCP 实现遇到这种过滤都会永久卡住。作出结论前，应查明实际启用了哪一种发现或黑洞恢复机制，不能把某个实验控制条件省略后推广到所有环境。 路径信息还可能被缓存。成功发现之后进行的测试，即使防火墙改变，也可能与全新客户端表现不同。复用已有状态会隐藏反馈路径损坏。路由变化和非对称返回路径进一步增加复杂性，所以需要记录方向、来源、目的地，以及估计是在什么条件下学到的。配置变化前后的结果，只有在这些前提清楚时才适合直接比较。 快速验证 将脚本保存为 check-path-mtu.py，准备 Docker 后运行 python3 check-path-mtu.py。一次性环境使用 Python 3.11.16、iproute2 6.1.0、nftables 1.0.6 和 tcpdump 4.99.3，在 Linux 6.12.76 上验证。NET_ADMIN 与 SYS_ADMIN 支持四个嵌套命名空间，两台路由器通过新建 veth 连接端点，不修改宿主路由或接口： ...