メインコンテンツへスキップ
検索

私は、イーサネットの最大伝送単位(MTU)とTCPの最大セグメントサイズ(MSS)の間にいくつかの混乱があることに気づきました。もしあなたがまだ混乱している(または今混乱している)のであれば、コメントを追加するか、私に明確化を求める電子メールを送ることを躊躇しないでください。

まず、STCPは、ローカルサブネット上のホストに送信されるTCPセグメントと、リモートサブネット上のホストに送信されるセグメント、すなわちルータを介して送信されるセグメントを区別します。ローカルサブネット上のホストに送信されるセグメントは、イーサネットのMTUに関連するMSSを持っています。具体的には、MSSはMTU - IPヘッダサイズ - TCPヘッダサイズです。17.1より前のリリースでは(17.1についてはもう少し詳しく)、MSSは1500 - 20 - 20または1460と等しくなります。リモートサブネット上のホストに送信されるセグメントは、536のMSSを使用します。STCPは、RFC 791とRFC 879の要件により、リモートセグメントでより小さいMSSを使用します。私は、2004 年 6 月の Stratus Customer eNewsletter に掲載された記事で、MSS を調整 (増加) する方法と潜在的な問題について説明した。記事のコピーはこちらから入手できる。この記事は VOS リリース 14.7 の例を用いて書かれたものであるが、内容はまだ有効である (OpenVOS のリリースは 17.1 である)。

OpenVOSの17.1リリースでは、ジャンボイーサネットフレームのサポートが追加されました。ジャンボフレームは、イーサネットフレーム内の1500バイト以上、つまりイーサネットMTUの増加を可能にします。デフォルトのMTUは1500のままですが、"-mtu"引数を使用することで、インターフェースが設定されているときに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の設定

 

アダプタタイプ エムティーユー
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の10進数です)。


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) を超えて増やすことはできません。

as: set_stcp_param min_mss 9160
set_stcp_param: 引数が許可された範囲内にありません。でのエラーです。
     'param_value'を使用します。500-1480] 許可されています。
として。

 

接続の双方がより大きな MSS を広告しない限り、実際の効果はありません。例えば、FTPサーバが9200のMTUで構成されていて、9160のMSSを広告していても、クライアントは1460(0x5b4)のMSSを広告しているので、これはサーバがセグメントで送信する最大バイト数です。


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を広告していても、各フレームに最大量のデータが含まれている保証はありません。例えば、クライアントとサーバの両方が9160のMSSを広告していますが、アプリケーションが送信するように設計されている最大のMSSなので、セグメントは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.

メニューを閉じる

© 2020ストラタステクノロジー.