MTU 值是什么意思？1500、1492 与对网速的影响
MTU 值（Maximum Transmission Unit，最大传输单元）是一个网络接口一次能发出的最大 IP 包长度，单位是字节，包含 IP 首部，不含以太网帧头。以太网默认 1500，PPPoE 拨号要多占 8 字节封装，所以是 1492。MTU 合适时对网速几乎没有影响，路径上某段 MTU 偏小、发送方又收不到通知时，才会出现网页打不开、大文件传不动。
MTU 值是网络接口一次能发送的最大 IP 包长度（Maximum Transmission Unit，最大传输单元），以字节计，包括 IP 首部和里面的 TCP、UDP 首部，但不包括以太网帧头和校验字段。普通以太网的 MTU 是 1500，意思是一个以太网帧最多装 1500 字节的 IP 包；IP 包比路径上某一段的 MTU 大，IPv4 要么分片、要么丢弃并通知发送方，IPv6 的路由器不分片，只能由发送方自己切小。家用宽带 PPPoE 拨号多了 8 字节封装，MTU 变成 1492。绝大多数服务器保持默认的 1500 即可，需要动 MTU 的是隧道、VXLAN、PPPoE 和存储网巨帧这几类场景。
MTU 1500 是什么意思：1500 字节里装了什么
以一个满长度的 TCP 报文为例，看看线路上的一帧由哪些部分组成，哪些算进 MTU：
| 部分 | 字节 | 算不算进 MTU |
|---|---|---|
| 前导码与帧起始定界符 | 8 | 不算，只占线路时间 |
| 以太网头：目的 MAC、源 MAC、类型 | 14 | 不算 |
| 802.1Q VLAN 标签（带标签时） | 4 | 不算 |
| IPv4 首部 | 20（IPv6 为 40） | 算 |
| TCP 首部 | 20，带时间戳选项时 32 | 算 |
| 应用数据 | 1460，带时间戳选项时 1448 | 算 |
| 帧校验序列 FCS | 4 | 不算 |
| 帧间隙 | 12 | 不算，只占线路时间 |
所以 MTU 1500 对应的以太网帧是 1518 字节（带 VLAN 标签 1522），在线路上实际占 1538 字节的时间。
这里有个常见的混淆：MTU 是三层概念，帧长是二层概念。Linux 上 ip link 显示的 1500 指 IP 包；不少交换机在端口上配置的是最大帧长，开巨帧时常见的 9216 就包含了二层头。服务器设成 9000 时，交换机端口至少要能收 9018 字节的帧（带 VLAN 标签 9022）。各厂商接口命令里的“MTU”算不算二层头并不统一，以设备文档为准。
查看本机 MTU：
ip link show eth0 # 输出中的 mtu 1500
cat /sys/class/net/eth0/mtunetsh interface ipv4 show subinterfacesMTU 值 1492 和 1500 的区别，以及 MTU 的取值范围
1492 比 1500 少的 8 字节
区别就在 PPPoE 的 8 字节：PPPoE 头 6 字节（版本与类型、代码、会话 ID、长度），再加 PPP 协议字段 2 字节。以太网帧的数据部分仍然最多 1500 字节，扣掉这 8 字节，留给 IP 包的只剩 1492（RFC 2516）。
| 链路 | 以太网帧数据部分 | 封装开销 | IP 包最大（MTU） | TCP 的 MSS（IPv4） |
|---|---|---|---|---|
| 普通以太网 | 1500 | 0 | 1500 | 1460 |
| PPPoE 拨号 | 1500 | 8 | 1492 | 1452 |
1492 不是“更好”或“更差”的数值，它是由链路决定的，设错才会出问题：
- 拨号接口是 1492，内网口仍是 1500。电脑按 1500 发出的 TCP 包到了路由器装不进 PPPoE，所以家用路由器和光猫一般会在拨号接口上自动改写 TCP 握手里的 MSS（MSS 钳制），让连接一开始就用 1452 的数据段，电脑上不用改。
- 机房服务器一般不涉及 1492。服务器是静态地址接入，MTU 为 1500；访问它的家庭用户在 PPPoE 后面，他们握手时带过来的 MSS 已经是 1452，服务器的 TCP 会自动按小的那个发。
- 有的运营商支持 1500 的 PPPoE。RFC 4638 允许两端在支持 1508 字节以太网载荷时让 PPPoE 承载完整的 1500，是否可用以运营商为准。
MTU 值范围与常见取值
| 场景 | MTU（IP 包，字节） | 来由 |
|---|---|---|
| IPv4 最小值 | 68 | RFC 791 要求每条链路至少能不分片地传 68 字节 |
| IPv6 最小值 | 1280 | RFC 8200 规定，达不到的链路必须在下层自行分片重组 |
| 以太网标准 | 1500 | 服务器、交换机、宽带的默认值 |
| PPPoE 拨号 | 1492 | 多 8 字节封装 |
| GRE 隧道 | 1476 | 外层 IPv4 首部 20 + GRE 头 4 |
| IPIP、6in4 隧道 | 1480 | 外层 IPv4 首部 20 |
| VXLAN（承载网 MTU 1500） | 1450 | 见下文“机房里什么时候需要调整” |
| WireGuard | 常见默认 1420 | 按 IPv6 外层预留 80 字节；外层是 IPv4 时实际开销 60 字节 |
| IPsec | 视算法和模式而定 | 加密算法、认证算法和隧道模式不同，开销不同，以实测为准 |
| 巨帧 | 常见 9000 | 不是 IEEE 标准值，网卡和交换机支持的上限各不相同，以规格书为准 |
MTU 和 MSS 是什么关系
MSS（Maximum Segment Size，最大报文段长度）是 TCP 一个报文段里能装的数据量，由 MTU 减去 IP 首部和 TCP 首部得到：IPv4 是 1500 − 20 − 20 = 1460，IPv6 是 1500 − 40 − 20 = 1440。双方在三次握手的 SYN 里各自告诉对方“我能收多大的段”，发送时取对方通告的 MSS 和本端路径 MTU 中较小的那个。Linux 默认开启 TCP 时间戳，每段还要再让出 12 字节，所以实际每段装 1448 字节。
一条已建立连接实际在用的值，可以直接看：
ss -tin dst 203.0.113.10
# 输出里的 mss:1448 pmtu:1500 分别是当前每段的数据量和这条路径的 MTUMSS 和 MTU 的关系决定了 MSS 钳制这个常用手段：在隧道或拨号的网关上，把经过的 SYN 里的 MSS 改小，两端就会主动发小包，不必等分片或丢包。例如 GRE 隧道 MTU 为 1476，对应 MSS 1436：
iptables -t mangle -A FORWARD -o gre1 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1436思科路由器在接口下用 ip tcp adjust-mss 1436，其他厂商有类似命令，以设备文档为准。要注意 MSS 钳制只对 TCP 有效，UDP 和 ICMP 的大包照样超长，基于 UDP 的业务要靠应用自己控制包长。
MTU 不匹配会怎样：分片、PMTUD 黑洞与“网页打不开”
Linux 的 TCP 默认在 IPv4 包上设置 DF（禁止分片）位，靠路径 MTU 发现（PMTUD，RFC 1191）找到合适的包长：
- 发送方按本机 MTU 1500 组包，并设置 DF 位。
- 路径上某台路由器的出接口 MTU 只有 1476，例如要进入 GRE 隧道，装不下，就丢弃这个包，回一条 ICMP 类型 3、代码 4 的“需要分片但设置了 DF”消息，里面写着 1476。
- 发送方收到后，把这条路径的 MTU 记为 1476，切小重发，连接继续。
- 如果第 2 步的 ICMP 被沿途的防火墙或安全组过滤掉，发送方永远收不到通知，只会一遍遍重传同样大小的包。这就是 PMTUD 黑洞。
IPv6 同理，通知消息是 ICMPv6 类型 2（包过大），而且 IPv6 路由器从不替你分片，拦掉它就一定是黑洞。黑洞的症状很有辨识度，共同点是“小包能过、满长度的包过不去”：
| 现象 | 原因 |
|---|---|
| ping 正常、SSH 能登录，一查看大文件或输出很多内容，终端就卡住 | 敲命令和回显都是小包，大段输出才会凑成满长度的包 |
| 网页能打开一部分，大页面、图片加载到一半停住 | 前面的小包通过了，后面满长度的包被丢 |
HTTPS 卡在 TLS 握手，curl -v 停在 Client hello 之后 |
服务器发回的证书链通常有几 KB，要拆成多个满长度的包 |
| scp、rsync 进度停在 0% | 一开始传的就是满长度的数据包 |
| VPN 连上了，能 ping 通对端内网，内网网页和文件共享打不开 | 隧道封装让路径 MTU 变小 |
没有设置 DF 的 IPv4 包会被路由器分片转发，不会形成黑洞，但任何一片丢失整个包就作废，按端口过滤的防火墙也可能丢弃不带端口信息的后续分片。
定位时先用 tracepath 看路径 MTU 在哪一跳变小，再用禁止分片的 ping 验证：
tracepath -n 203.0.113.10
ping -M do -s 1472 -c 3 203.0.113.10 # 1472 + 8（ICMP 头）+ 20（IP 首部）= 1500
tcpdump -nni eth0 'icmp[icmptype] == 3 and icmp[icmpcode] == 4' # 有没有收到“需要分片”的通知tracepath 的输出类似下面这样（示例），第 2 跳出现 pmtu 1476，最后的 Resume 行给出整条路径的 MTU：
1?: [LOCALHOST] pmtu 1500
1: 198.51.100.1 0.418ms
2: 192.0.2.9 1.902ms pmtu 1476
2: 192.0.2.9 2.015ms
3: 203.0.113.10 9.877ms reached
Resume: pmtu 1476 hops 3 back 3tracepath 同样依赖 ICMP 通知，已经形成黑洞时它看不出变化，这时以 ping 的结果为准：1472 发出去没有任何回应、减小到某个值才通，那个值加 28 就是路径 MTU。处理方法按优先顺序：
- 放行 ICMP 类型 3 代码 4 和 ICMPv6 类型 2，让 PMTUD 正常工作，例如
iptables -A INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT。 - 在隧道或拨号的网关上做 MSS 钳制。
- 在服务器上设置
net.ipv4.tcp_mtu_probing=1，内核检测到黑洞后自动改用更小的包探测（RFC 4821），默认值 0 表示关闭。 - 把发送端网卡 MTU 调小。它会影响这台机器的全部流量，作为最后的手段。
MTU 值对网速有什么影响
先算一笔账：在线路上，每个帧除了 IP 包还要占 38 字节（以太网头 14、FCS 4、前导码 8、帧间隙 12），IP 包里又要扣掉 52 字节的 IPv4 和 TCP 首部（含时间戳选项）。不同 MTU 下，线路时间里真正用来传数据的比例是：
| MTU | 线路上每帧占用 | 每帧 TCP 数据 | 有效载荷占比 |
|---|---|---|---|
| 9000 | 9038 | 8948 | 99.0% |
| 1500 | 1538 | 1448 | 94.1% |
| 1492（PPPoE，帧内多 8 字节封装） | 1538 | 1440 | 93.6% |
| 1400 | 1438 | 1348 | 93.7% |
| 1280 | 1318 | 1228 | 93.2% |
结论很直接：在 1280 到 1500 之间，MTU 设多少，带宽利用率只差 1 个百分点左右。把 MTU 从 1500 降到 1400，速度不会有可感知的变化；反过来，在公网上也不可能靠调大 MTU 提速，因为路径上的大多数链路就是 1500。真正让网速“变慢”的是 MTU 不匹配：被丢的包要等超时重传，TCP 又把丢包当成拥塞而降速，严重时连接直接卡死。
巨帧的收益也不主要在带宽上，而在包数量上。10 Gbps 跑满时，1500 的 MTU 每秒约 81.3 万个包，9000 的 MTU 每秒约 13.8 万个，只有前者的六分之一左右，主机处理中断和协议栈的开销随之下降。现代网卡普遍有 TSO、GRO 等分段卸载功能，大包的切分和合并交给网卡完成，巨帧带来的 CPU 节省比这个比例小，实际效果以压测为准。
机房里什么时候需要调整 MTU：隧道、VXLAN 与巨帧
需要调整的情况，几乎都来自“包外面又套了一层”。常见封装的开销，以及想让里面的业务继续用 1500 时，承载网至少要多大：
| 封装 | 额外开销（字节） | 承载网为 1500 时内层可用的 MTU | 内层要保持 1500，承载网至少 |
|---|---|---|---|
| 802.1Q VLAN 标签 | 4，加在帧上，不占 IP 包 | 1500 | 交换机能收 1522 字节的帧，支持 802.1Q 的交换机都满足 |
| QinQ 双层标签 | 8，同上 | 1500 | 交换机能收 1526 字节的帧 |
| PPPoE | 8 | 1492 | 1508 |
| GRE（IPv4 外层） | 24 | 1476 | 1524 |
| IPIP、6in4 | 20 | 1480 | 1520 |
| VXLAN（IPv4 承载） | 50 | 1450 | 1550 |
| VXLAN（IPv6 承载） | 70 | 1430 | 1570 |
| WireGuard（IPv4 外层） | 60 | 1440 | 1560 |
VXLAN 的 50 字节是这样来的：它把内层的整个以太网帧（14 字节帧头加 IP 包）装进外层 UDP，再加上 VXLAN 头 8、UDP 头 8、外层 IPv4 首部 20，比内层 IP 包多出 14 + 8 + 8 + 20 = 50 字节。
处理隧道和 VXLAN 有两种思路：
- 调大承载网 MTU：数据中心内部的交换机都在自己手里时，把承载网设到 1600 或直接开巨帧，租户和虚拟机继续用 1500，不用逐台修改。这是优先选择。
- 调小内层 MTU：承载网改不了（例如跨公网的隧道）时，把内层设为 1450 之类的值，可以通过 DHCP 选项 26 下发给虚拟机，同时在网关上做 MSS 钳制。
开巨帧要守住几条规则：
- 只在封闭的二层范围内用：存储网（iSCSI、NFS、Ceph 集群网）、虚拟化迁移网、备份网；公网接口和上联运营商的接口保持 1500。
- 同一网段的主机和交换机端口一起改：主机 9000，交换机端口按帧长设到设备支持的上限。二层交换机丢弃超长帧时不会发任何 ICMP 通知，只在端口计数里留下记录，比三层的黑洞更难发现。
- 改完逐对验证：
ping -M do -s 8972 10.50.0.12（9000 − 28 = 8972），每一对需要通信的主机都要通。
在管理系统里怎么落地
MTU 问题难查，往往是因为不知道一台服务器到底经过了哪些设备、在哪个网段。Toplink DCIM 的交换机管理把服务器和交换机端口的对应关系登记在一起，在服务器列表里就能查到它的上联交换机、端口号、所属 VLAN 和端口速率，需要核对接口 MTU 或超长帧计数时，可以在浏览器里打开这台交换机的 SSH 终端执行 display、show 命令，会话全程录像。存储网、VXLAN 承载网这类有特殊 MTU 规划的网段，可以在 IP 地址管理里给地址段打上“存储网 · MTU 9000”这样的标签，并登记所在 VLAN 和网关设备，装机的人查这个地址段时，就能看到它的 MTU 要求，不必再去翻网络规划文档。
常见问题
把 MTU 改小能降低游戏延迟吗？
基本不能。在 1 Gbps 端口上发出一个 1500 字节的满长度帧只需约 12 微秒，100 Mbps 上约 0.12 毫秒；游戏数据包本身通常只有几十到几百字节，根本用不到 MTU 的上限。延迟主要由距离、路由和拥塞决定。
Wi-Fi 的 MTU 也是 1500 吗？
通常是。Wi-Fi 帧本身能装下比 1500 更多的数据，但无线网络要和以太网桥接互通，系统里无线网卡的 MTU 一般也显示为 1500。
MTU 和 MRU 有什么区别？
MTU 管发送，MRU（最大接收单元）管接收。PPP、PPPoE 链路在建立时由双方协商 MRU，拨号设备上看到的 1492 往往就是协商出来的；以太网接口一般只配置 MTU。