转载来自：http://ccie911.blog.163.com/blog/static/127469709201122492513954/
关于 MTU 、 IP MTU 、 TCP MSS 探讨与分析
1. 概述
本文主要分析了二层 MTU ， IP MTU ， MSS 之间的关系和在不同网络场景中的应用，最后通过一个案例分析来进一步认识 MTU 对实际 IP 数据包转发的影响。
2. MTU
最大传输单元（ Maximum Transmission Unit ， MTU ）是指一种通信协议在某一层上面所能通过的最大数据报大小（以字节为单位），它通常与链路层协议有密切的关系。 EthernetII 帧结构如下：
| DMAC |
SMAC |
Type |
Data |
CRC |
由于以太网传输电气方面的限制，每个以太网帧都有最小的大小 64bytes ，最大不能超过 1518bytes ，对于小于或者大于这个限制的以太网帧，我们都可以视之为错误的数据帧。一般的以太网转发设备会丢弃这些数据帧。（注：小于 64Bytes 的数据帧一般是由于以太网冲突产生的 “ 碎片” 或者线路干扰或者坏的以太网接口产生的，对于大于 1518Bytes 的数据帧我们一般把它叫做 Giant 帧，这种一般是由于线路干扰或者坏的以太网口产生）。
由于以太网 EthernetII 最大的数据帧是 1518Bytes ，除去以太网帧的帧头（ DMAC 目的 MAC 地址 48bit=6Bytes+SMAC 源 MAC 地址 48bit=6Bytes+Type 域 2bytes ） 14Bytes 和帧尾 CRC 校验部分 4Bytes （这个部份有时候大家也把它叫做 FCS ），那么剩下承载上层协议的地方也就是 Data 域最大就只能有 1500Bytes ，这个值我们就把它称之为 MTU 。
这个 MTU 就是网络层协议非常关心的地方，因为网络层协议比如 IP 协议会根据这个值来决定是否把上层传下来的数据进行分片。就好比一个盒子没法装下一大块面包，我们需要把面包切成片，装在多个盒子里面一样的道理。当两台远程 PC 互联的时候，它们的数据需要穿过很多的路由器和各种各样的网络媒介才能到达对端，网络中不同媒介的 MTU 各不相同，就好比一长段的水管，由不同粗细的水管组成（ MTU 不同 ）通过这段水管最大水量就要由中间最细的水管决定。
3. IP MTU
对于网络层的上层协议而言（我们以 TCP/IP 协议族为例），网络层 IP 协议会检查每个从上层协议下来的数据包的大小，并根据本机 MTU 的大小决定是否作“ 分片” 处理。分片最大的坏处就是降低了传输性能，本来一次可以搞定的事情，分成多次搞定，所以在网络层更高一层（就是传输层）的实现中往往会对此加以注意！有些高层因为某些原因就会要求我这个面包不能切片，我要完整地面包，所以会在 IP 数据包包头里面加上一个标签： DF （ Donot Fragment ）。这样当这个 IP 数据包在一大段网络（水管里面）传输的时候，如果遇到 MTU 小于 IP 数据包的情况，转发设备就会根据要求丢弃这个数据包，然后返回一个错误信息给发送者。这样往往会造成某些通讯上的问题，不过幸运的是大部分网络链路 MTU 都是等于 1500 或者大于 1500 。
对于 UDP 协议而言，这个协议本身是无连接的协议，对数据包的到达顺序以及是否正确到达不甚关心，所以一般 UDP 应用对分片没有特殊要求。对于 TCP 协议而言就不一样了，这个协议是面向连接的协议，对于 TCP 协议而言它非常在意数据包的到达顺序以及是否传输中有错误发生。所以有些 TCP 应用对分片有要求 --- 不能分片（ DF ）。
4. MSS
MSS 是最大传输大小的缩写，它是 TCP 协议里面的一个概念。如下图 1-1 所示：
图 1-1 TCP 头部
注： URG 等参数指的是 ACK URG PSH SIN FIN RST 等参数
在 TCP 报文中 MSS 的位置就在选项的位置，根据 RFC1323 和 RFC793 规定，选项中内容有很多种， MSS 是其中的一种，用 kind=2 表示； kind=1 表示无操作， kind=4 、 5 、 6 、 7 称为选择 ACK 及回显选项，但是由于回显选项已经被时间戳选项取代，同时，目前定义的选择 ACK 选项仍未定论，也没有包括在 RFC1323 中，所以具体代表什么含义还无定论。在实际网络数据传输，要求 MSS+20TCP 包头 +20 IP 包头不大于 MTU 。 MSS 在 TCP 报文中是可选项，不是必选项，换句话说， MSS 是可协商项，而且在协商过后，该选项内容可以改变，也可以没有；在协商 MSS 时，一般是建立 TCP 连结的两端发送 Syn 标志报文时互相通报，然后选取最小 MSS 作为双方的约定，如果双方都不通报或有一方不通报。
MSS 就是 TCP 数据包每次能够传输的最大数据分段。为了达到最佳的传输效能， TCP 协议在建立连接的时候通常要协商双方的 MSS 值，这个值 TCP 协议在实现的时候往往用 MTU 值代替（需要减去 IP 数据包包头的大小 20Bytes 和 TCP 数据段的包头 20Bytes ），所以往往 MSS 为 1460 。通讯双方会根据双方提供的 MSS 值得最小值确定为这次连接的最大 MSS 值。
5. 区别及联系
由前面的叙述可知： MTU 是一个二层的概念，以太网最大的 mtu 就是 1500 （它是不包含二层头部的，加上头部应该为 1518 bytes ），当然这里说的是很常规的情况，也有些 server ，比如 server 2008 ，出来的就是 jumbo frame 了，我们在这里讨论常规情况。 IP MTU 是一个三层概念，它包含了三层头部及所有载荷，根据下层为上层服务的，上层基于下层才能做进一步的扩展的原则，尽管 IP MTU 的变化范围很大（ 68-65535 ），但也不得不照顾以太网 MTU 的限制 , 说白了就是 ip 对以太网的妥协。 MSS 是 TCP 里面的一个概念，它是 TCP 数据包每次能够传输的最大数据分段，不包含包头部分，它与 IP MTU 满足如下关系： IP MTU=MSS+20bytes （ IP 包头） +20bytes （ TCP 包头）。当然，如果传输的时候还承载有其他协议，还要加些包头在前面，简言之， mtu 就是总的最后发出去的报文大小， MSS 就是需要发出去的数据大小，比如 PPPoE ，就是在以太网上承载 PPP 协议（点到点连接协议），它包括 6bytes 的 PPPoE 头部和 2bytes 的 PPP 协议 ID 号，此时，由于以太网的 MTU 值为 1500 ，所以上层 PPP 负载数据不能超过 1492 字节，也就是相当于在 PPPOE 环境下的 MTU 是 1492 字节， MSS 是 1452 字节。
6. MTU 问题解决方法
通常情况下， MTU 不匹配会表现为两种故障情况：
- ping 大包时不通
- 无法访问某些站点
在这种情况下，通常有两种解决方法：
- 修改用户端MTU 值（不推荐使用）
- 修改传输路由所有设备MTU 值，确保路径MTU 值大于用户发送的IP 报文的长度，以保证用户报文不会因为超过设备的MTU 值被丢弃。主要要考虑下面几种情况：
· 对于纯IP 网络，要保证：路径MTU 值> 最大用户报文长度
· 对于纯MPLS 网络（没有VPN 业务），要保证路径MTU 值> 最大用户报文＋一层标签长度（4 ）
· 对于三层VPN 业务，要保证：路径MTU 值> 最大用户报文＋两层标签长度（8 ）；
· 对于二层VPN 业务，要保证：路由MTU 值> 最大用户报文长度＋两处标签长度（8 ）＋二层帧头长度（18 ）。
值得注意的是： fastethernet 接口不能调整 MTU ，所以说在有些设备中，使用 MTU 命令不能解决问题的。此外，更改 MTU 后，如果 IGP 是 OSPF 的话，不同的 MTU 可能会造成 OSPF 停留在 INIT 状态，此时需要将两端的 MTU 调整一致。
7. 案例分析
下面通过一个某公司 TCP MSS 配置不匹配导致应用不正常的案例分析，来加深对上述概念的理解。其拓扑图如下图 1-2 所示 :
图 1-2 某公司网络拓扑示意图
| 设备 |
角色 |
说明 |
| NBR2000 |
公司总出口路由器 |
l NBR2000 启用 L2TP 功能，同时在 L2TP 虚拟模板接口中配置了 TCP MSS 为 1300 。 l NBR1200 启用 2LTP 功能，同时在 L2TP 虚拟模板接口中配置了 TCP MSS 为 1400 。 l NBR1200 与 NBR2000 通过 L2TP 协议建立隧道， NBR2000 作为服务端， NBR1200 作为客户端。 |
| NBR1200 |
分公司出口路由器 |
故障现象：
l 在分公司 NBR1200 的 PC 上登录总公司 ISOFLOW 服务器，在 ISOFLOW 里签核表单的时候，会无法签核下去而导致 IE 死掉的现象。 如果碰见 ISOFLOW 单子的附件，会发现附件要过很长、很长的时间才能打开。
l 访问 ERP 系统普通表单的速度不错，但是一旦进行数据库的读写，速度极慢；数据查询时经常超时。
诊断故障原因及分析：
1. 故障诊断的思路
登录到总公司 NBR2000 和分公司 NBR1200 ，查看配置，具体如下：
NBR2000 虚拟模板配置：
interface Virtual-Template 1
mtu 1400
ppp authentication pap
ip nat inside
ip tcp adjust-mss 1300
ip unnumbered GigabitEthernet 0/0
peer default ip address pool VPDN
NBR1200 虚拟模板配置：
interface Virtual-ppp 1
pseudowire X.X.X.X 20 encapsulation l2tpv2 pw-class pw
mtu 1400
ppp pap sent-username star-net password 7 0058274d4c24
ip tcp adjust-mss 1400
ip address negotiate
故障诊断的分析
1、 判断网络层是否正常
在现场从分公司 PC PING 总公司 ISOFLOW 服务器 IP ，长 PING 没有丢包，说明网络层是正常的。
2 、应用异常
目前用户应用是通过 HTTP 来访问，出现能访问，但很慢的现象，说明是在应用层上出现了问题。一般来说，在应用层出问题，在排除软件本身问题的情况下，基本可以定位是 MTU 或 TCP MSS 不匹配原因引起。
3 、 TCP MSS 分析
一般来说 一般的应用软件，当客户端和服务器端在建立 TCP 连接的时候需要根据实际传输的报文大小来协商 TCP 的窗口大小 MSS 。在 TCP 协商的第一个报文也就是 SYN 置位的报文中会告知对方自己所能接收的最大 TCP 数据净荷（也就是 TCP 报文中的数据长度） ----MSS ，对方收到 TCP 同步报文也会回复一个 SYN 置位的 TCP 报文，其中也携带了 MSS 参数来告知对方自己能接收的最大 MSS 。根据以上分析，我们来看一下总公司与分公司路由器是怎么协商 TCP MSS 的：
（ 1 ）分公司 - 》总公司
PC 发起 TCP SYN 报文与总公司 ISOFLOW 服务器进行协商，在 TCP SYN 报文经过分公司路由器虚拟模板接口（ out 方向）时，路由器会将接口配置的 MSS 值 1400 （分公司路由器在虚拟模板接口上配置了 ip tcp adjust-mss 1400 ）与 TCP 报文中的 MSS 值 1460 （ windows XP 系统默认是 1460 ）比较，取二者的最小值 1400 。 ISOFLOW 服务器收到此 TCP 同步报文，查看其中的 MSS=1400 ，服务端在后续发送数据时封装的最大 TCP 数据载荷为 1400 。 一般来说 TCP MSS 是不分包的， DF 置位为 1 。
（ 2 ）总公司 - 》分公司
ISOFLOW 发响应 TCP SYN ACK 报文给分公司的 PC ，在 TCP SYN 报文经过总公司路由器虚拟模板接口（ out 方向）时，路由器会将接口配置的 MSS 值 1300 （总公司路由器在虚拟模板接口上配置了 ip tcp adjust-mss 1300 ）与 TCP 报文中的 MSS 值 1460 （ windows XP 系统默认是 1460 ）比较，取二者的最小值 1300 。 PC 收到此 TCP 同步确认报文，查看其中的 MSS=1300 ， PC 在后续发送数据时封装的最大 TCP 数据载荷为 1300 。 一般来说 TCP MSS 是不分包的， DF 置位为 1 。
PC 在向 ISOFLOW 发送请求，作为 ISOFLWO 的被请求端，发出的数据包括的数据文件，数据包较大，需要封装成最大 MSS 载荷传送（提高效率），在此 MSS=1400, 当数据包经过总公司 L2TP VPN 虚拟模板接口时，由于配置了 mtu 1400 ，而此时数据包的 MTU （ MTU=1400+TCP(20)+IP(20)+PPP (4)+L2TP （ 8 ） +UDP （ 8 ） +IP （ 20 ） =1480 ）远远大于总公司路由器虚拟模板接口 MTU 1400 ，且 IP 包头强制不分片位被置位，导致在出 VPN 隧道时报文被丢弃，所以现象就是能够建立 TCP 连接，但服务器端返回大数据包时，出现 IE 应用程序没有响应现象。同理，如果是从服务端发起的访问客户端口 PC ，由于客户端接收到的 TCP 同步报文中的 MSS=1300 ，那么其封装的数据经过分公司路由器 L2TP VPN 隧道时，数据包的 MTU(MTU=1300+ TCP(20)+IP(20)+PPP (4)+L2TP （ 8 ） +UDP （ 8 ） +IP （ 20 ） =1380) 小于分公司路由器隧道 MTU=1400 ，所以能够正常。