「Maximum Transmission Unit」の版間の差分

通信中にデータのが破損をした場合、検出すると、通常および再送はパケット単位で再送を行なうわれるのが普通である。したがって不安定な伝送路では、小さなパケットに分割して通信する方が、再送の負荷を軽減できる。反面、エラーがほとんど発生しないような伝送路では、パケット長を大きくして少数のパケットにまとめる方が、パケット化のオーバーヘッドを軽減できる。このような理由から、通信メディアは各々の特性に応じてMTUを設定されている。さらに前述のように、カプセル化もMTUを減少させる。

IPではRFC 1191で定義される経路MTU探索（Path MTU Discovery）を使うことで、終端まで断片化を行わずに転送できるMTUを動的に検出できる。これは、パケットに断片化禁止のフラグ（Don't Fragment = DFフラグ）を設定しておき、MTUの問題で転送できない経路に到達した際はその旨を[[Internet Control Message Protocol|ICMP]]パケットで送信元に通知して、フレーム長を再調整するという仕組みである。ICMPは、転送できなかったルーターから、送信元ホストへ送信される。

転送できなかったことを通知するICMPパケットは、Type 3（Destination Unreachable Message）のCode 4（fragmentation needed and DF set）である。「Datagram Too Big」などと呼ばれることもある。ただし元々RFC 792の形式では未使用となっていた領域に、RFC1191では「Next-Hop MTU」を割り当てている。この値は、断片化を必要とした伝送路のMTUなので、送信元が再試行する際に経路MTUの次の候補値として使用できる。RFC 4884は、この変更を反映している。もしルータが古い形式にしか対応しておらず、Next-Hop MTUに未使用領域として0を格納している場合、次の候補値を選ぶためには、何らかの推測を行なうことになる。結果として、再試行の回数が増えたり、最適値より小さめのMTUを選択したりする可能性が発生すある。

経路MTU探索は、RFC 1191で定義されたとおりに動作すれば、断片化を必要としない最大のMTUを検出することができる。しかし現実には、設定の問題で正常に機能しない場合が珍しくない。問題がある場合の典型的な挙動は、通信を開始することはできるが、経路MTUより大きなサイズのフレームが現れた時点でタイムアウトするというものが典型的な挙動である。主な問題と対応策はRFC 2923にまとめられている。

いくつかある問題の中でも、Path MTU Discovery Black Hole（経路MTU探索ブラックホール）と呼ばれるケースは特に有名である。このケースは[[ファイアーウォール]]等でICMPパケットをフィルタしている場合に発生する。「Datagram Too Big」メッセージが送信元に届かないため、送信元はパケットが失われたことに気付かず、タイムアウトしてしまう。ICMPをフィルタする場合でも、少なくとも上記のType 3 Code 4のものだけは通す必要がある。もしそれができないのであれば、経路MTU探索をやめて断片化を許す設定に変更することになるだろう。

ただし現実には、自ホストの設定を変更することはできても、通信相手の設定に問題を変更理解させて修正してもらうことは難しい。そこで、設定に問題がある場合でも通信するための回避策として、TCPの[[Maximum Segment Size]]（MSS）オプションを使った回避策う方法が知られている。TCPはコネクションを開始する際、自ホストが受信できる最大のセグメント長（TCPおよびIPのヘッダは除く）を通知することができる。通信相手からMSSオプションが送られてきた場合、その長さを超えるTCPデータグラムを送出してはならない。[[IPv4]]の場合、通常はTCPヘッダ20バイト、IPヘッダ20バイトなので、MSS + 40バイトがMTUに相当する。前述のフレッツ網を例にとると、MSSとして1414バイトを送っておけば、相手が経路MTU探索の候補とする値を1414 + 40 = 1454バイト以内に制限することができる。