Maximum Transfer Unit，指的是“最大传输单元”，在路由器上通常指的是某个路由器向外发送的最大IP数据报文长度。例如某台路由器的某个接口MTU=1500，那么从这个接口发送出去的最大IP数据报文长度就是1500，如果待发送的IP数据报文大于这个MTU，那么该报文将被分片（保证每一片小于等于1500），然后再发送。
但是谈到MSS，也许许多人就不是很清楚，实际上这个MSS的英文是Maximum Segment Size，中文是“最长报文大小”，它是TCP的一个属性。具体来说，在TCP数据报文中，参看下图：
图3 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+20（TCP包头）+20（IP包头）不大于MTU。
但是谈到MSS，也许许多人就不是很清楚，实际上这个MSS的英文是Maximum Segment Size，中文是“最长报文大小”，它是TCP的一个属性。具体来说，在TCP数据报文中，参看下图：
图3 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+20（TCP包头）+20（IP包头）不大于MTU。
MSS在TCP报文中是可选项，不是必选项。换句话说，MSS是可协商项，而且在协商过后，该选项内容可以改变，也可以没有。在协商MSS时，一般是建立TCP连结的两端发送[Syn]标志报文时互相通报，然后选取最小MSS作为双方的约定。如果双方都不通报，或有一方不通报，一般选择MSS的默认值536。
mtu
最大传输单元（Maximum Transmission Unit，MTU）是指一种通信协议的某一层上面所能通过的最大数据报大小（以字节为单位）。最大传输单元这个参数通常与通信接口有关（网络接口卡、串口等）。
因特网协议允许IP分片，这样就可以将数据报分成足够小的片段以通过那些最大传输单元小于该数据报原始大小的链路了。这一分片过程发生在IP层（OSI模型的第三层，即网络层），它使用的是将分组发送到链路上的网络接口的最大传输单元的值。原始分组的分片都被加上了标记，这样目的主机的IP层就能将分组重组成原始的数据报了。
在因特网协议中，一条因特网传输路径的“路径最大传输单元”被定义为从源地址到目的地址
所经过“路径”上的所有IP跳的最大传输单元的最小值。或者从另外一个角度来看，就是无需进一步分片就能穿过这条“路径”的最大传输单元的最大值。
RFC 1191描述了“路径最大传输单元发现方法”，这是一种确定两个IP主机之间路径最大传输单元的技术，其目的是为了避免IP分片。在这项技术中，源地址将数据报的DF（Don't Fragment，不要分片）位置位，再逐渐增大发送的数据报的大小——路径上任何需要将分组进行分片的设备都会将这种数据报丢弃并返回一个“数据报过大”的ICMP响应到源地址——这样，源主机就“学习”到了不用进行分片就能通过这条路径的最大的最大传输单元了。
不幸的是，越来越多的网络封杀了ICMP的传输（譬如说为了防范DDOS攻击）——这使得路径最大传输单元发现方法不能正常工作，其常见表现就是一个连接在低数据流量的情况下可以正常工作，但一旦有大量数据同时发送，就会立即挂起（例如在使用IRC的时候，客户会发现在发送了一个禁止IPtcpip协议就是指传输控制协议欺骗的ping之后就得不到任何响应了，这是因为该连接被大量的欢迎消息堵塞了）。而且，在一个使用因特网协议的网络中，从源地址到目的地址的“路径”常常会为了响应各种各样的事件（负载均衡、拥塞、断电等等）而被动态地修改——这可能导致路径最大传输单元在传输过程中发生改变——有时甚至是反复的改变。其结果是，在主机寻新的可以安全工作的最大传输单元的同时，更多的分组被丢失掉了。
对于时下大多数使用以太网的局域网来说，最大传输单元的值是1500字节。但是像PPPoE这样的系统会减小这个数值，这就使得在使用最大传输单元发现方法时可能会产生这样的结果：一些处于配置不当的防火墙之后的站点变得不可达了。对于这种情况，还是可能到变通的方法的，但这取决于你控制的是网络的哪一部分。这些方法包括改变用来在防火墙一端建立TCP连接的第一个分组的MSS（Maximum Segment Size，最大分段大小）。
对于一些支持老版本以太网协议的IBM系统（例如XSeries），可能只有在把最大传输单元设为1492之后才能在当下常见的局域网上进行运作。
[编辑本段]
如何检测网关的MTU
在本机打开dos窗口，执行： ping -f -l 1472 192.168.0.1 其中192.168.0.1是网关IP地址，1472是数据包的长度。请注意，上面的参数是“-l”（小写的L），而不是“-1”。 如果能ping通，表示数据包不需要拆包，可以通过网关发送出去。 如果出现： Packet needs to be fragmented but DF set. 表示数据包需要拆开来发送。此时，减少数据包长度，再执行上面
的ping命令。从1400到1472之间多试几次，就能到合适的数据包长度了。把数据包长度加上数据包头28字节，就得到MTU的值。 如果检测到网关的MTU值是1500，不需要修改。 如果网关有防火墙ping不通，可以试试直接把MTU设为1400。
[编辑本段]
如何修改本机的MTU
修改方法如下：
（1）、运行regedit （2）、浏览到： HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces
（3）、Interfaces下有多个子项，每个子项对应一个网卡。请按如下方法选择网卡： （a）确定本机用来连接Internet的网卡或拨号连接的IP，如192.168.0.19； （b）用鼠标点击Interfaces上的子项，查看键值列表中的IPAddress项； （c）如果IPAddress的键值与（a）中的IP相同，即192.168.0.19，则该子项就是要的网卡。 （4）、进入该子项，在右边的
窗口里按鼠标右键，选择“新建”->“双字节值”，输入名称“MTU”，按回车。再用鼠标双击“MTU”，弹出修改窗口： 如图3： 填入MTU的值。填写前请先把基数设为十进制。 设置好后，需要重启机器才能生效。
Linux下可使用如下命令修改 需要root权限
ifconfig 网卡 MTU值
如 ifconfig eth0 mtu 1460
MaxMTU是最大的TCP/IP传输单元，在TCP/IP协议中，将要传输的数据分成较小的组进行传输，每个组的大小为576字节。Windows默认的字节为1500，这是以太网的分组标准。ADSL使用的 PPPoE略小于这个数值，一般为1492。而某些网站采用的MaxMTU大于1492，所以，可能导致某些网页不能访问。修改Windows默认的MaxMTU可以解决这个问题。不论是 PC机上安装的PPPoE软件或者是内置在Modem的 PPPoE软件，在使用中都有可能遇到这个问题。 如果使用路由器出现此种情况, 请在 防火墙配置 => 基本设定 里, 将MTU改为手工, 设置为 1492 即可. 那如何确定路由器从ISP获得的 MTU 为 1500, 请见附件圈出的位置.
>
>Louie, Thanks for your comments and for framing the question more
>clearly.
>
>Let's assume we do want to do 1500-byte frames on the virtual interfaces
>and go on to an ugly aspect of implementing it.
>
>Longer frames seem to require that the physical interface "know" that
>1504-byte frames should be allowed when the VLAN or 802.1p driver is
>above it but prohibited otherwise. Conversely, the VLAN driver should
>"ask" before assuming that the physical interface can handle the larger
>frames so that it can fail the open in those cases where the driver can't
>handle them?
>
>Is there any existing mechanism for "negotiation" of MTU between the
>physical layer and virtual layer? If not, should there be? I suppose we
>could crank the MTU of all physical interfaces up to whatever they can
>really handle instead of artificially limiting them to 1500 bytes, but
>that sounds icky.
>
>In short, it seem kind of gross to have to hack the source code of the
>physical driver when you intend to use it with a virtual driver above it.
>Is it worth making an elegant solution to this or should we just let the
>few who need longer frames continue futzing the source of the physical
>drivers?
>
Well the actual solution isn't very elegant, is it? But there doesn't seem to be
a simple way to fix this. A _new_ MTU will require the existing drivers to be
>physical layer and virtual layer? If not, should there be? I suppose we
>could crank the MTU of all physical interfaces up to whatever they can
>really handle instead of artificially limiting them to 1500 bytes, but
>that sounds icky.
>
>In short, it seem kind of gross to have to hack the source code of the
>physical driver when you intend to use it with a virtual driver above it.
>Is it worth making an elegant solution to this or should we just let the
>few who need longer frames continue futzing the source of the physical
>drivers?
>
Well the actual solution isn't very elegant, is it? But there doesn't seem to be
a simple way to fix this. A _new_ MTU will require the existing drivers to be
modified anyways, but as things go more and more NICs should support 802.1Q
tagging.
In my opinion VLANs are most useful (and were designed, I believe) for bridging
segments (that includes trunking), thus 802.1Q tagging should be done by the
bridge module.
If you follow IEEE (a document that goes by the name P802.3ac/D3.1, "Frame
Extensions for VLAN Tagging on 802.3 Networks) it is the Ethernet frame that
gets bigger, not the IP packet that gets smaller. (my 2c :).
Tarik.
> Thanks,
tagging.
In my opinion VLANs are most useful (and were designed, I believe) for bridging
segments (that includes trunking), thus 802.1Q tagging should be done by the
bridge module.
If you follow IEEE (a document that goes by the name P802.3ac/D3.1, "Frame
Extensions for VLAN Tagging on 802.3 Networks) it is the Ethernet frame that
gets bigger, not the IP packet that gets smaller. (my 2c :).
Tarik.
> Thanks,
>
> Bob
>
>"Louis A. Mamakos" wrote:
>
>> You've got the wrong alternatives considered.
>>
>> The two to choose between are:
>>
>> 1. The IPv4 MTU for packets on an Ethernet are always 1500 bytes. To
>> this, the ethernet driver adds various link-layer headers (source
>> and destination MAC addresses, Ethernet Type/802.3 length) as well as
>> trailers (Ethernet CRC).
>>
>> For some ethernet links which use VLAN trunking, there are additional
> Bob
>
>"Louis A. Mamakos" wrote:
>
>> You've got the wrong alternatives considered.
>>
>> The two to choose between are:
>>
>> 1. The IPv4 MTU for packets on an Ethernet are always 1500 bytes. To
>> this, the ethernet driver adds various link-layer headers (source
>> and destination MAC addresses, Ethernet Type/802.3 length) as well as
>> trailers (Ethernet CRC).
>>
>> For some ethernet links which use VLAN trunking, there are additional
>> fields in the link layer headers which are added to support VLANs and
>> 802.1p priority. Ethernet interfaces which choose to participate in
>> explicit VLAN tagging need to be able to add and remove this header,
>> which may result in maximal length frames a few byte longer than
>> previously.
>>
>> 2. The IPv4 MTU for packets is decreased because the hardware you
>> have can't accomodate the addition of VLAN tagging when you want to
>> use explicit tagging of frames, and the IP payload is "large."
>>
>> I would argue that if your Ethernet hardware can't send and receive
>> frames with the "normal" sized payload AND the addition of VLAN tags,
>> then you have no business using it on explicitly tagged VLAN ethernet
>> segments. E.g., alternative 1 is correct.
>>
>> 802.1p priority. Ethernet interfaces which choose to participate in
>> explicit VLAN tagging need to be able to add and remove this header,
>> which may result in maximal length frames a few byte longer than
>> previously.
>>
>> 2. The IPv4 MTU for packets is decreased because the hardware you
>> have can't accomodate the addition of VLAN tagging when you want to
>> use explicit tagging of frames, and the IP payload is "large."
>>
>> I would argue that if your Ethernet hardware can't send and receive
>> frames with the "normal" sized payload AND the addition of VLAN tags,
>> then you have no business using it on explicitly tagged VLAN ethernet
>> segments. E.g., alternative 1 is correct.
>>
>> It's important to distinguish between the payload length that the
>> link layer (e.g., ethernet) offers to transport for the higher level
>> protocol (IPv4 in this discussion) with the constraints that the
>> physical layer protocol has. Ethernet MTUs have never been 1500
>> bytes; that's the IP MTU of IP packets carried inside of Ethernet
>> frames. The length of the Ethernet frame was sacred until someone
>> wanted to do VLAN tagging (which has to be consented to by the
>> parties) and they allowed the packets to grow larger to accomodate
>> this.
>>
>> This makes sense when you consider that the primary application of
>> explicit VLAN tags is on a VLAN trunk between Ethernet switches. The
>> end system using the ethernet switches should not have to care (or
>> even be aware) that the link between a couple of switches is just
>> a plain ethernet, or a VLAN trunk carrying multiple distinct
>> link layer (e.g., ethernet) offers to transport for the higher level
>> protocol (IPv4 in this discussion) with the constraints that the
>> physical layer protocol has. Ethernet MTUs have never been 1500
>> bytes; that's the IP MTU of IP packets carried inside of Ethernet
>> frames. The length of the Ethernet frame was sacred until someone
>> wanted to do VLAN tagging (which has to be consented to by the
>> parties) and they allowed the packets to grow larger to accomodate
>> this.
>>
>> This makes sense when you consider that the primary application of
>> explicit VLAN tags is on a VLAN trunk between Ethernet switches. The
>> end system using the ethernet switches should not have to care (or
>> even be aware) that the link between a couple of switches is just
>> a plain ethernet, or a VLAN trunk carrying multiple distinct
>> broadcast domains, one per VLAN.
>>
>> louie
To Unsubscribe: send mail to
with "unsubscribe freebsd-net" in the body of the message
>>
>> louie
To Unsubscribe: send mail to
with "unsubscribe freebsd-net" in the body of the message
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论