scp を使用して、MTU が 552 のゲートウェイ経由でホストからファイルを送信しようとしています。ssh は DF ビット フラグが設定されたパケットを送信する必要があり、現在の MTU が小さすぎるため、接続が停止すると思われます。代わりに、パケットは断片化され、スループットが単純に低下します。ホストの tcp ダンプから見ると、DF フラグは設定されていません。
なぜこのようなことが起こるのでしょうか? 何か見落としているのでしょうか?
便利なので Debian 20 を使用していますが、他のディストリビューションでもこの動作が発生します。
答え1
通常、Linux カーネルは、ホストの MTU を検出するために Path MTU Discovery を使用する傾向があるため、IPv4 パケットに DF フラグを設定します。ただし、この場合、MTU は 552 オクテットです。IPv4 では、「ホストは最大 576 オクテットのデータグラム (全体が到着するかフラグメントで到着するかに関係なく) を受け入れる準備ができている必要があります」と規定されています。これは、非常に小さなパケットは非効率的であるためです。
その結果、IPv4 を使用するほぼすべてのプログラムは、実際の MTU に関係なく、最大 576 オクテット (ヘッダーを含む) のパケットを安全に送信および処理できると想定できます。これは、UDP データグラムの送信を想定し、誰かが小さな MTU を持つ奇妙なハードウェアを使用したという理由だけでデータグラムがドロップされることを望まない DNS などのプロトコルにとって不可欠です。
MTU が最小しきい値を下回っているため、パス MTU 検出が常に機能するわけではなく、一部のパケットを断片化する必要が生じます。 代替案としては、これらの接続が多くの場合機能しないということになりますが、これは望ましくない結果となり、多くの人を苛立たせることになるため、実装されている動作ではありません。
MTU も IPv6 のしきい値である 1280 を下回っているため、このリンクは IPv6 ではまったく機能しないことに注意してください。
答え2
あなたは遭遇しています パス MTU 検出 (PMTUD)。
TCP パケットには DF フラグが設定されており、中間ルータがパケットが大きすぎるためにパケットを破棄する必要がある場合に、「ICMP フラグメンテーションが必要」パケットが返されます。送信者は、接続のパス MTU (最大転送単位) の推定値を減らし、より小さなセグメントで再送信します。
DF が設定されていない場合、送信者は大きすぎるセグメントを送信していることに気付きません。
DF が設定されている場合、送信側が送信するパケットのサイズを縮小するだけの影響があります。これにより、MTU が小さくなっても送信が成功しなくなることはありません。