mtu详解

Wireshark 显示的 Length: 1514 并不是 数据包在网线上传输的真实物理长度，而是 Wireshark 为了方便阅读，把底部的 ICMP 数据部分 也算进去了。

可以分两层来拆解这个数字：

1. 真实物理长度：1518 字节

局域网内传输的真实以太网帧，最大标准长度确实是 1518 字节。它的构成如下：

• 以太网头部 (Header)：14 字节（包含目的 MAC、源 MAC、类型）
• IP 数据报头部：20 字节
• ICMP 报文头部：8 字节
• ICMP 数据负载 (Payload) ：1472 字节
• 帧校验序列 (FCS)：4 字节（Wireshark 默认不显示）

计算公式：

14 + 20 + 8 + 1472 + 4 = 1518 字节

2. Wireshark 显示的 1514 是怎么来的？

Wireshark 里看到的 Length: 1514，其实是 Wireshark 计算的一个"逻辑长度"，它的计算公式是：

总长度 (1518) - 隐藏的 FCS 校验 (4) = 1514

当你在看 Wireshark 的 Length 列时，它通常指的是 二层数据帧的总长度（不含 FCS）。

3.PPPoE链路常见故障

• 现象判断：如果内网正常、测速正常、部分网站打不开 → 典型的"大包过不去但小包没问题"，指向 MTU 路径不匹配
• 根因方向 ：PPPoE 协商后链路 MTU 变成 1492（因为 PPPoE 头占用 8 字节），但 TCP 按 1460 MSS 发包，加上 IP 头 20 + TCP 头 20 = 1500，再经过 PPPoE 封装就超 1492 了
• DF 位的关键作用：客户端设了 DF 位的包到达防火墙后，防火墙没法再分片，只能丢包；而不带 DF 的 ping 大包能被二次分片转出去------这解释了为什么"ping 大包能通但上网慢"
• 处置方向：要么调小防火墙的 TCP MSS（MSS Clamping），要么调小客户端接口 MTU

标准以太网帧头是 14 字节（DMAC 6 + SMAC 6 + Type 2），帧尾 FCS 是 4 字节：

Ethernet Header	IP Header	TCP Header	Payload (MSS)	FCS
14	20	20	1460	4

合计 = 1518 字节（不含前导码和帧间隙）。

所以正确的账是：

PPPoE 链路有效 MTU = 1500 - 8 (PPPoE 头) = 1492
TCP MSS = 1492 - 20 (IP头) - 20 (TCP头) = 1452

思科官方给的标准解法

思科在 PPPoE 场景的推荐配置是原方向接口上做 MSS Clamping：

ip tcp adjust-mss 1452

原理：在 TCP 三次握手时，防火墙/路由器把 SYN/SYN-ACK 报文里的 MSS 选项重写为 1452，让通信双方主动按 1452 发数据，从根上避免产生 >1492 的包，也就不会有分片、不会被 DF 丢包。

💡 MSS改如果到 1300 能解决问题------1300 当然也 ≤ 1452，肯定不超 1492 ，但 1300 偏保守，会牺牲一定的传输效率。标准值是 1452，如果是多层隧道（IPSec/GRE over PPPoE）时候 1300~1400 反而是合理的，因为还有额外封装开销 。

各场景的标准取值

场景	客户端 MTU	对应 TCP MSS
纯以太网（无 PPPoE）	1500	1460
PPPoE 拨号（家庭宽带最常见）	1492	1452
PPPoE + IPSec (VPN)	1416~1420	1376~1380
PPPoE + GRE + IPSec	1374~1400	1334~1360

💡 TCP MSS 的计算公式 ：MSS = MTU - 20(IP头) - 20(TCP头)

所以 PPPoE 场景下 MSS 钳制值标准是 1452。

客户端怎么设

macOS / Linux：

# macOS
sudo ifconfig ppp0 mtu 1492

# Linux
sudo ip link set ppp0 mtu 1492

Windows：

# 查看 PPPoE 接口名
netsh interface ipv4 show interfaces

# 设置 MTU
netsh interface ipv4 set subinterface "PPP adapter" mtu=1492 store=persistent

路由器/防火墙（以思科为例）：

interface Dialer1
  mtu 1492
  ip tcp adjust-mss 1452