先上一个“人话版”总结：
MTU 就是某一条链路上，单个 IP 包能“塞”的最大尺寸上限。
太大会被拆包甚至“黑洞”，太小又浪费性能。
它不是只一个数字，而是：链路层帧大小限制 + 各种头部开销 + 设备实现差异共同决定的结果。
一、MTU 到底是什么？别再只记“1500”了
1. 官方一点的说法
MTU（Maximum Transmission Unit，最大传输单元）：
某条链路上 一次能承载的“网络层数据包”的最大大小（常指 IP 包大小），不含二层头部。
通俗点说：
在这条链路上，一辆“IP 货车”最多能装多少字节的货物（IP 头 + 传输层头 + 应用数据）。
2. 千万别混淆：MTU ≠ 帧长（Frame Size）
以最常见的以太网为例：
以太网帧结构大致是：
[前导码7][SFD1][二层头14][VLAN标签4 可选][IP包(=MTU上限)][FCS 4]以太网 MTU 默认 1500 指的是：
IP 层这块（IP头 + 上层数据）最大 1500 字节，
不包含二层头（MAC 源/目的、类型）、FCS、前导码、IFG 等。
所以：
以太网标准帧长 ≈ 1518 字节（不算前导码/IFG）
MTU = 1500 是其中“IP 这一截”的上限
二、MTU由哪些部分“构成”？为什么会变小？
你在配置设备 MTU 时，其实是在做一个“减法题”：
链路物理最大承载能力 – 各种额外头部 = 剩下留给 IP 包的空间（MTU）
典型链路上的“扣减项”包括：
二层封装头
以太网头：14 字节
VLAN tag（802.1Q）：4 字节
QinQ：8 字节
这些通常不计入 MTU，但会影响“帧长上限”。
隧道 / VPN / 额外封装头（真 MTU杀手）
GRE 头：4 字节
新增一个外层 IP 头：20 字节
IPsec ESP 头/尾/对齐：几十字节起步
VXLAN：50 字节左右
举例：在 1500 的基础上如果你套了一层 IPv4 GRE 隧道：
外层IPv4头 20 + GRE头 4 = 24字节 额外开销 → 内层IP包最大 ≈ 1500 - 24 = 1476协议自身要求的保留空间
IPv6 要求链路 MTU 不能低于 1280
有些链路层（如 PPPoE）自己会吃掉一点空间
最终你能配置的 MTU，是在硬件 + 协议上限下折腾出的一个折中值。
三、常见技术场景下的“默认 MTU 数值”一览
下面是网络工程师一定要心里有数的几个典型：
一个硬核记忆点：
看到 PPPoE、GRE、IPsec、VXLAN 时，你脑子里就要自动弹出：
“MTU 有被吃掉空间，TCP MSS 要配合调。”
四、不同设备上的 MTU 有什么差别？
1. 交换机 vs 路由器 vs 防火墙
二层交换机（L2）
更多关心的是“帧长/巨帧支持不支持”，
CLI 上有时叫mtu，但本质是 L2 帧大小。三层交换机 / 路由器（L3）
一般接口 MTU 指 IP 层 MTU，
需要和路由、MSS、Path MTU Discovery 配合。防火墙 / VPN 网关
经常叠加 IPsec/GRE/SSL 等隧道封装，
所以有效可用 MTU 通常比边缘路由器小，
不调好容易出现“VPN 某些网页打不开”的奇怪问题。
2. 不同厂商、不同操作系统的区别
Linux
ip link show/ifconfig看到的是 IP 层 MTU通常默认 1500
ip link set dev eth0 mtu 1400可随时调整
Windows
默认 1500（以太网）
通过
netsh interface ipv4 set subinterface修改对 VPN/拨号连接会单独拉低 MTU
华为 / H3C / Cisco / Juniper
有的区分
mtu（二层） 和ip mtu（三层）有的对物理口和逻辑口（Vlanif、Tunnel）单独设置
高端机型还有“巨帧开关”“BD/EVPN场景专用 MTU”
小坑提醒：
有的设备你改了物理口 MTU，逻辑三层接口（SVI/Vlanif）还要单独跟着改，不然看到的是两个值，会导致：
“二层没问题，三层跑大包却丢”。
五、平时怎么测试不同 MTU？
MTU 测试的核心思路只有一句话：
用“不能分片”的大包去 ping，看看在哪个大小开始失败。
因为：
一旦超过路径某跳的 MTU，上面设置了“不可分片（DF 位）”
中间设备就要么返回 ICMP Fragmentation Needed，要么直接“黑洞”丢。
下面分别给出 Linux / Windows / 华为交换机 的实际命令。
1. Linux 下测试路径 MTU
命令示例：
# 使用 DF，不允许分片
ping -M do -s 1472 10.1.1.1解释：
-M do：设置 DF（Don't Fragment），禁止分片-s 1472：ICMP 数据部分大小为 1472 字节实际 IP 包大小 = 1472 + 8(ICMP头) + 20(IP头) = 1500
如果 1472 OK，再试 1473：
ping -M do -s 1473 10.1.1.1如果开始报
Frag needed或超时 → 路径 MTU = 1500 左右如果 1400 正常，1472 不行 → 路径 MTU ≈ 1428（1400+28）
还有更方便的：
tracepath 10.1.1.1会自动探测 Path MTU 并显示每一跳的限制。
2. Windows 下测试 MTU（经典命令）
ping 10.1.1.1 -f -l 1472解释：
-f：设置 DF，不允许分片-l 1472：发送 1472 字节的 ICMP 数据
1472 是一个常用试探值，因为：
1472 + 28（IP+ICMP）≈ 1500。
如果 1472 通过，但 1473 不通过 → 路径 MTU ≈ 1500
如果 1400 通过，1472 不通过 → 路径 MTU 更小，需加以排查/调整。
同时可以发现，mtu增大后，延迟也会增加
3. 华为交换机 / 路由器测试 MTU
VRP 设备的 ping 通常支持：
ping -a <源IP> -s <数据长度> -f <目的IP>例：
ping -a 192.168.1.1 -s 1472 -f 10.1.1.1-s 1472：ICMP 数据部分 1472 字节-f：设置 DF，不允许分片
根据回显：
如果提示需要分片、或者不通 → MTU 不够
通过不断调整
-s，你可以精确测出路径可用 MTU。
六、MTU 会对什么产生影响？不搞清楚很容易踩坑
1. 对 TCP 连接与 MSS 的影响（最常见）
TCP 在握手时会互相通告 MSS（Max Segment Size）：
MSS = MTU - IP头 - TCP头
以 IPv4 为例：
IP 头 20 字节 + TCP 头 20 字节
MTU = 1500 → MSS = 1460
如果中途某段链路 MTU 变小但不通知：
TCP 报文可能在中间被分片
如果禁用 IP 分片/ICMP 被丢弃 → 某些网站“怎么都打不开”、文件传输卡死
这就是经典的：
“MTU 不匹配 + PMTUD 被防火墙挡掉 → TCP 黑洞”
2. 对吞吐性能的影响
粗略理解：
MTU 大
每个包负载更多，头部占比少
CPU/中断压力小
吞吐更高（对大流量、存储/备份非常有利）
MTU 小
同样流量要分成更多包
每包都要处理头部 → CPU 压力大
性能容易上不去
这也是为什么：
数据中心、存储网络喜欢开到 9000 Jumbo Frame
3. 对 VPN / 隧道 / IPsec 的影响
凡是有隧道（GRE/IPsec/VXLAN）的地方，你都要特别警惕 MTU：
VPN 里常见现象：
小包 OK，大文件卡、部分网页打不开
ping 64 bytes 正常，ping 大包 + DF 直接超时
解决思路常见两种：
降低隧道接口 MTU（比如改成 1400）
在入口处调整 TCP MSS（如 1360）
只改一边往往不够，
完整方案是：接口 MTU + TCP MSS 双管齐下。
4. 对实时业务（语音/视频）的影响
MTU 过小：
包数多，开销大
但丢包重传更细粒度，某些场景更好
MTU 过大：
单包一旦丢失，影响整段语音/视频帧
适合网络质量较好的内网，但不一定适合复杂公网
一般语音/实时业务更多是控制“编码和带宽”，
MTU 调优更多是为 VPN/大流量数据服务。
七、工程实践中的 MTU 调优建议（给网工的“经验版”）
内网纯以太网：1500 就是默认最佳，不要乱改。
有 PPPoE / IPsec / GRE：
把隧道两端接口 MTU 适当调小（1400/1476）
同时配置
tcp mss 1360之类的值
数据中心 / 存储网：
整条链路统一开启 Jumbo Frame（9000 左右）
严格保证“从端到端所有设备都支持且已开启”
遇到“网页打不开/下载中断/只小包通”的怪问题：
第一时间想到：是不是 MTU / MSS / PMTUD 问题
用大包 + DF 的 ping 把路径 MTU 测一遍
调整 MTU 一定要“端到端”看，而不是在某个设备上单点乱改。
小结：用一句话收尾
MTU 是一条链路“单次能装多少”的硬指标，本质是“带宽利用率”和“协议负担”的平衡点。
对纯内网是性能问题，对复杂公网 + 隧道则可能演变成“业务时好时坏、怪问题频出”的根因。
只要你掌握了：
MTU 的构成逻辑
常见默认值
各类设备的 MTU 差异
用 ping/tracepath 正确测试路径 MTU
知道它会影响 MSS、吞吐和 VPN
你就已经比大多数“只会把 MTU 改成 1400 然后祈祷”的网工，专业至少高一档。