我注意到以太网最大传输单位(MTU)和TCP最大段大小(MSS)之间有一些混淆，希望下面的内容可以解释一下。如果你仍然（或现在）感到困惑，不要犹豫，添加评论或给我发E-mail要求澄清。
首先，STCP区分了发送到本地子网主机的TCP段和发送到远程子网主机（即通过路由器）的段。发送到本地子网主机上的段有一个MSS，这个MSS与以太网MTU有关；具体来说，MSS是MTU-IP头大小-TCP头大小。在17.1之前的版本中（稍后更多关于17.1的内容），这使得MSS等于1500 - 20 - 20或1460。发送到远程子网的主机的段使用536的MSS。由于RFC 791和RFC 879的要求，STCP在远程网段上使用较小的MSS。我在2004年6月Stratus Customer eNewsletter的一篇文章中讨论了如何调整（增加）MSS和潜在的问题。你可以在这里找到这篇文章的副本。虽然这篇文章是用VOS 14.7版本的例子写的，但内容仍然有效（OpenVOS的版本是17.1）。
OpenVOS的17.1版本增加了对巨型以太网帧的支持。Jumbo 帧允许以太网帧中有超过 1500 个字节，即增加了以太网 MTU。默认的MTU仍然是1500，但你可以在配置接口时使用"-mtu"参数增加它（例子1）。MTU参数的最大值是16110，这取决于你的硬件（见表1）。
ifconfig #sdlmux.m16.11-2 172.16.1.116 -netmask 255.255.255.0 -mtu 9200 -add
Adding interface %phx_vos#sdlmux.m16.11-2 with IP address 172.16.1.116
%phx_vos#sdlmux.m16.11-2: <UP, BROADCAST, RUNNING, NOFORWARDBROADCAST, KEEPALIVE
+, MTU:9200>
172.16.1.116 netmask 0xffffff00 broadcast 172.16.1.255
|
| 示例1 - 配置接口时设置MTU |
| 适配器类型 | MTU |
| V100、V200、V400中的嵌入式适配器。 | 1500 |
| V150、V250、V300、V500中的嵌入式适配器。 V2302、V2404、V4304、V4408、V6308、V6408中的嵌入式适配器。 |
9200 |
| U571V单端口10/100/1000 mbps铜线适配器。 | 1500 |
| U574V-LC双端口1000 mbps光纤适配器。 U575V双端口10/100/1000 mbps铜线适配器。 U578V四端口10/100/1000 mbps铜线适配器。 U582V 四端口10/100/1000 mbps铜线适配器 U583V四端口1000 mbps光纤适配器 |
9200 |
| U584V 双端口10,000 mbps 光纤适配器 | 16110 |
| U776V四端口1000 mbps光纤适配器 | 9200 |
| 表1 - 按硬件类型分列的MTU值 |
设置较大的MTU后，可以看到STCP会为本地连接发布较大的MSS广告，0x23c8是9160十进制。
9:04:55.912 Xmit Ether Dst 00:16:97:c4:01:aa Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 0, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 23fc, Src ac100174, Dst ac10012c
TCP from 172.16.1.116.59410 to 172.16.1.44.9182
seq 3764213089, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum d329, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 23 c8 3 3 6 4 2 8 a 18 bf 3f d6 0 <<#H<<<< <<<<??V
10 0 0 0 0
|
但远程连接还是会得到较小的MSS，0x218是536十进制。
9:20:34.051 Xmit Ether Dst 00:16:97:c4:01:aa Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 0, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 1086, Src ac100174, Dst c0a8000a
TCP from 172.16.1.116.49186 to 192.168.0.10.9182
seq 1916893234, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum de8e, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 2 18 3 3 6 4 2 8 a 0 1 69 a 0 <<<<<<<< <<< <i<
10 0 0 0 0
|
您不能将远程连接的最小MSS增加到1460以上（TCP头为1480）。
如：set_stcp_param min_mss 9160。
set_stcp_param: Argument is not within the range allowed.错误在
'param_value'.[500-1480] 允许
作为：
|
除非连接双方都宣传较大的MSS，否则没有实际效果。例如即使FTP服务器配置的MTU为9200，并且宣传的MSS为9160，但由于客户端宣传的MSS为1460(0x5b4)，这就是服务器在一个网段中发送的最大字节数。
11:02:49.758 Xmit Ether Dst 00:00:a8:42:3b:6e Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 5, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 2401, Src ac100174, Dst ac100122
TCP from 172.16.1.116.ftp-data to 172.16.1.34.49343
seq 2092638702, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum 7c62, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 23 c8 3 3 6 4 2 8 a 0 19 5c b5 0 <<#H<<<< <<< <5
10 0 0 0 0
11:02:49.758 Rcvd Ether Dst 00:00:a8:41:52:22 Src 00:00:a8:42:3b:6e Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 1bcb, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 083b, Src ac100122, Dst ac100174
TCP from 172.16.1.34.49343 to 172.16.1.116.ftp-data
seq 3565222463, ack 2092638703, window 8192, 20 data bytes, flags Syn Ack.
X/Off 0a, Flags 12, Cksum fef7, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 5 b4 3 3 6 4 2 8 a 13 cc 99 0 0 <<<4<<<< <<<<L>
10 19 5c b5 0 <5
. . . .
11:02:50.620 Xmit Ether Dst 00:00:a8:42:3b:6e Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 5dc, ID 8, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 1e5e, Src ac100174, Dst ac100122
TCP from 172.16.1.116.ftp-data to 172.16.1.34.49343
seq 2092638703, ack 3565222464, window 128, 1460 data bytes, flags Push A
+ck.
X/Off 08, Flags 18, Cksum 7467, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
. . . .
|
即使双方都宣传较大的MSS，也不能保证每个帧都包含最大的数据量。例如，客户端和服务器都宣传MSS为9160，但段只有8204字节，因为这是应用程序设计发送的最大限度。
11:33:40.492 Xmit Ether Dst 00:00:a8:43:ba:64 Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 34, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 231b, Src ac100174, Dst ac1001d9
TCP from 172.16.1.116.ftp-data to 172.16.1.217.49430
seq 851197707, ack n.a., window 8192, 20 data bytes, flags Syn.
X/Off 0a, Flags 02, Cksum d8f7, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 23 c8 3 3 6 4 2 8 a 0 20 9b 7d 0 <<#H<<<< <<< >}
10 0 0 0 0
11:33:40.493 Rcvd Ether Dst 00:00:a8:41:52:22 Src 00:00:a8:43:ba:64 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 3c, ID 33, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 231c, Src ac1001d9, Dst ac100174
TCP from 172.16.1.217.49430 to 172.16.1.116.ftp-data
seq 3989207776, ack 851197708, window 8192, 20 data bytes, flags Syn Ack.
X/Off 0a, Flags 12, Cksum d75d, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
0 2 4 23 c8 3 3 6 4 2 8 a 0 e e1 8a 0 <<#H<<<< <<< <a>
10 20 9b 7d 0 >}
. . . .
11:33:40.504 Xmit Ether Dst 00:00:a8:43:ba:64 Src 00:00:a8:41:52:22 Type 0800
+(IP)
IP Ver/HL 45, ToS 0, Len 2034, ID 37, Flg/Frg 0, TTL 3c, Prtl 6
Cksum 0320, Src ac100174, Dst ac1001d9
TCP from 172.16.1.116.ftp-data to 172.16.1.217.49430
seq 851197708, ack 3989207777, window 128, 8204 data bytes, flags Ack.
X/Off 08, Flags 10, Cksum ee81, Urg-> 0000
offset 0 . . . 4 . . . 8 . . . C . . . 0...4... 8...C...
. . . .
|
Finally just setting a large MTU on your hosts is not enough; you also have to make sure that all network devices between the two hosts are configured to allow the larger frame size. If not then what you will find is that everything will work correctly when the host uses small (<= 1460) segments, but if it transmits a larger segment, that segment will be dropped by the network device and the connection will eventually fail with a timeout condition of some kind. Larger segments may be sent because the application sends it or because STCP combines smaller segments. This can make for random and very frustrating failures.
旗下公司