インターネットで大量のデータを送信するとき、 一般的に大きなパケットを利用するほうが効率よく動作します。 各パケットは経路の決定を反映しますが、 1 メガバイトのファイルを送信する場合、 できるだけ大きなパケットを使えば約 700 パケットになりますし、 デフォルトの最小サイズを使うと約 4000 になります。
1 パケットあたりのペイロードの最大値は 1460 バイトですが、 この値はインターネットのあらゆる部分でサポートされているわけではありません。 よって接続を最適化するには、 適用できる最大のパケットサイズを試行を通して見つける必要があります。
このプロセスは 'Path MTU Discovery' と呼ばれています。 MTU は 'Maximum Transfer Unit' の意味です。
ルータがひとまとめで送るには大きすぎるパケットを受信し、 かつそのパケットで「フラグメント不可」ビットが立っていると、 ルータは ICMP メッセージを送り、 この理由でパケットを破棄せざるを得なかったことを伝えます。 送信元のホストはこのヒントに対応し、より小さいパケットを送ります。 これを繰り返すことで、ある経路を経由する接続における、 最適なパケットサイズを発見できるのです。
これはうまく動作していたのですが、 通信を混乱させることに心血を注ぐフーリガン達がインターネットを発見すると、 状況が変わりました。 管理者達は、インターネットサービスの安全性・堅牢性の向上を行うため、 ICMP トラフィックを (間違ったやり方で) ブロックしたり絞ったりするようになってしまったのです。
これによって現在では、Path MTU Discovery が正しく動作する状況はどんどん少なくなり、 特定の経路では失敗するようになってしまいました。 この場合 TCP/IP セッションがしばらくすると落ちるなど、 妙な動作をします。
証拠はないのですが、私の経験では、この問題が生じた 2 つのサイトでは、 いずれもそのシステムの手前で Alteon Acedirectors を使っていました。 この原因については、より詳しいどなたかが手がかりを与えてくれると期待しています。
このような問題のあるサイトに行き当たったら、 手動設定で Path MTU discovery を無効にしなければなりません。 以下は Koo van den Hout の書いたものです (少々編集しています):
問題はこのようなものです: 私は借りている ppp 接続の mtu/mru を 296 にしました。 この接続は 33.6k しかなく、接続先のキューイングは操作できなかったからです。 296 にすると、キーを押したときの反応が妥当な時間に収まるようになりました。
また私の側では、(当然) Linux の、マスカレードルータが動作しています。
最近私は「サーバ」と「ルータ」を別にしました。 よってほとんどのアプリケーションは、ルーティングを行っているのとは 別のマシンで動作するようになりました。
すると irc へのログインに問題が出るようになりました。たいへんです! あれこれ調べたところ、irc への接続はできており、'connected' も 表示されているとわかったのですが、 irc からの motd を受信できないのです。 何がおかしいかをチェックしたところ、以前から特定の web サイトへの接続に、 MTU 関連で問題があったことを思い出しました。 これは MTU を 296 に設定したときに出現したものでした。 irc サーバは、直接の動作に関係のないトラフィックはすべてブロックしていました。 icmp もブロックの対象でした。
私は web サーバのオペレータに対しては、 これが問題の原因になるのだと納得させることができましたが、 irc サーバのオペレータはこの問題を修正しようとはしませんでした。
そこで、私は外に出て行くマスカレードトラフィックに対して、 より小さな mtu を与えるようにしなければなりませんでした。 ただしローカルのイーサネットトラフィックでは、 通常の mtu を使いたかったのです (例えば nfs のトラフィックなど)。
解決法:
(10.0.0.1 はデフォルトゲートウェイで、マスカレードルータの 内側のアドレス)
一般に、PMTU Discovery の設定を特定の経路に対して変更することは可能です。 例えば、あるサブネットでのみ問題があるのなら、次のようにするとよいです。
ip route add 195.96.96.0/24 via 10.0.0.1 mtu 1000 |