MTU / MSS 计算器 — PPPoE、MAP-E、IPsec、WireGuard 开销
叠加 PPPoE、MAP-E/DS-Lite、GRE、WireGuard、VXLAN 与 IPsec(含真实 ESP 填充计算),得出有效 MTU 与 TCP MSS,并生成 Cisco、YAMAHA RTX、Linux 配置及验证用 DF ping。
🔒 全部在你的浏览器中运行。输入和输出都不会发送到服务器或被保存,十分安全。
明细
配置示例
用 DF ping 验证
载荷 = MTU − 28(IPv4 20 + ICMP 8)。此值能通而 +1 不通,即确认路径 MTU。
IPv4 的 MSS = MTU − 40(IP 20 + TCP 20),IPv6 为 MTU − 60。在 MTU 变小的设备上钳制 MSS,TCP 就不会发送需要分片的报文段。
关于此工具
这款 MTU 与 MSS 计算器用于算出链路被封装后实际能通过的报文大小。以链路 MTU 为起点,勾选流量实际经过的各层——PPPoE、用于 MAP-E 或 DS-Lite 的 IPv4 over IPv6、GRE、WireGuard、VXLAN、带 NAT-T 的 IPsec——即可显示有效 MTU、IPv4 与 IPv6 的 TCP MSS、逐层明细、Cisco IOS / YAMAHA RTX / Linux 配置示例,以及在线路上验证用的 DF 位 ping 命令。IPsec 按真实的 ESP 填充计算,而非粗略估计。全部在浏览器中完成。
常见问题
为什么 FLET'S PPPoE 的 MTU 是 1454 而不是 1492?
PPPoE 本身只占 8 字节,因此在以太网上理论值是 1492。但 NTT 东西仍将 1454 公布为 FLET'S 光的推荐值,多出的余量通常解释为接入网内部的额外开销。实际上 1454 是稳妥之选:牺牲几个字节的效率,换来在任何路径上都不出现分片与连接卡死。选择 FLET'S 预设即从 1454 开始计算。
什么是 MSS 钳制,为什么需要?
TCP 在握手时依据两端各自的接口协商最大报文段长度,而端点并不知道路径后方的隧道。路径 MTU 发现本应借助 ICMP「需要分片」消息来纠正,但很多网络会丢弃 ICMP,于是出现典型症状:小页面能打开,大文件下载和部分 HTTPS 站点却一直卡住。MSS 钳制会在 MTU 变小的路由器上改写经过的 SYN 报文中的 MSS,从根本上不发送过大的报文段。
IPv6 有什么不同?
有三点不同。报头大 20 字节,所以 MSS 是 MTU − 60 而非 MTU − 40。路由器在转发途中从不对 IPv6 分片,因此路径 MTU 发现是必需的——拦截 ICMPv6「Packet Too Big」会直接导致连接失败。另外每条 IPv6 链路至少要能承载 1280 字节,这也是 Cisco 示例中 IPv6 MTU 从不低于此值的原因。日本的 MAP-E 与 DS-Lite 是把 IPv4 装进 IPv6 中传输,常见的 1460 正源于此。
为什么 IPsec 的开销不是固定值?
因为 ESP 会对载荷进行填充,使其加上 2 字节尾部后正好占满整数个加密块。AES-CBC 的块大小为 16 字节,因此视报文长度,填充在 0 到 15 字节之间变化,另外还有 16 字节 IV 和认证标签。AES-GCM 只需 4 字节对齐、IV 为 8 字节,浪费更少。这就是各处资料数字不一的原因;本工具计算的是真正能装下的最大内层报文。
会向服务器发送任何内容吗?
不会。计算与配置示例都由浏览器中的 JavaScript 生成,你的网络设计信息不会离开设备,页面加载后也可离线使用。ping 命令供你自行执行,本页面不会发送任何探测包。