「Maximum Transmission Unit」の版間の差分

出典: フリー百科事典『ウィキペディア(Wikipedia)』
削除された内容 追加された内容
Alexbot (会話 | 投稿記録)
m ロボットによる: 細部の編集
Nagae (会話 | 投稿記録)
全体的に加筆
10行目: 10行目:
}}
}}
</ref>。
</ref>。

== MTUと通信パフォーマンス ==
[[パケット通信]]を用いて一定サイズのデータを送受信する場合、パケット長の決定が通信パフォーマンスに影響する。

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

[[インターネット]]ようなWAN環境では、パケットが宛先に到着するまでの間に、様々MTUの伝送を通る可能性がある。もしフレーム長がMTUを超えていた場合、Internet Protocol(IP)のような上位層は通常、パケットの断片化・再統合を行う。しかし、このようなパケットの再構成はルーターの処理負荷増加および通信パフォーマンス低下の原因となるため、断片化の起こらないパケット長がわかっている場合は、あらかじめパケット長を制限して送信するという考え方もある。ただし、その値は宛先および経路よって異なるためあらかじめ静的設定しておくには、何らか割り切りが必要になる可能性がある。


== 経路MTU探索 ==
== 経路MTU探索 ==
IPではRFC 1191で定される経路MTU探索(Path MTU Discovery)を使うことで、終端まで断片化を行わずに転送できるMTUを動的に検出できる。これは、パケットに断片化禁止のフラグ(Don't Fragment = DFフラグ)を設定しておき、MTUの問題で転送できない経路に到達した際はその旨を[[Internet Control Message Protocol|ICMP]]パケットで送信元に通知して、フレーム長を再調整するという仕組みである。ICMPは、転送できなかったルータから、送信元ホストへ送信される。
前述とおり、MTU通信メディアやカプセル化の有無などによって変わる。このため[[パケット]]を中継していく途中MTU小さに遭遇する可能性がある。Internet Protocol(IP)のような上位層は通常、パケットの断片化・再統合を行うことで、MTUを超えるパケットを転送する。しかし、このようなパケットの再構成は通信パフォーマンス低下の原因となるため、断片化の起こらないパケット長がわかっている場合は、あらかじめパケット長を制限して送信するという考え方もある。に、必要以上短いパケット長制限することは、パケット数を増加させ、またネットワーク帯域使用率を低下させることになる。


転送できなかったことを通知する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を選択したりする可能性が発生する。
IPではRFC 1191で定される経路MTU探索(Path MTU Discovery)を使うことで、終端まで断片化を行わずに転送できるMTUを動的に検出できる。これは、パケットに断片化禁止のフラグを設定しておき、MTUの問題で転送できない経路に到達した際はその旨を[[Internet Control Message Protocol|ICMP]]パケットで送信元に通知して、フレーム長を再調整するという仕組みである。


=== 経路MTU探索に関する問題 ===
ところが経路上の[[ルーター]]や[[ファイアーウォール]]の設定によっては、Path MTU Discoveryが使用できず、タイムアウトするなどの問題が発生する。典型的なケースは、ICMPを破棄してしまうような設定で、Path MTU Discovery Black Holeと呼ばれる。主な問題と対応策はRFC 2923にまとめられている。
経路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のヘッダは除く)を通知することができる。[[IPv4]]の場合、通常はTCPヘッダ20バイト、IPヘッダ20バイトなので、MSS + 40バイトがMTUに相当する。前述のフレッツ網を例にとると、MSSとして1414バイトを送っておけば、経路MTU探索の候補値を1414 + 40 = 1454バイト以内に制限することができる。

MSSは本来、TCPコネクションの両端が設定する項目である。しかし最近のブロードバンドルーター等は、TCPセグメントの転送時にMSSオプションを書き換える機能を持っている。この機能を使えば、さらにMTUの小さな伝送路を通ったり、通信相手がMSSオプションを無視したりしない限り<ref>{{Cite web
|author=阿蘇和人
|date=2009年9月14日
|url=http://itpro.nikkeibp.co.jp/article/NEWS/20090914/337188/
|title=Microsoft Updateが遅くなるトラブルが発生
|publisher=日経BP ITpro
|accessdate=2009年9月19日
}}
</ref>、
経路MTU探索に由来する問題を回避できる。


== 脚注 ==
== 脚注 ==
25行目: 48行目:
* RFC 1981 - Path MTU Discovery for IP version 6
* RFC 1981 - Path MTU Discovery for IP version 6
* RFC 2923 - TCP Problems with Path MTU Discovery
* RFC 2923 - TCP Problems with Path MTU Discovery
* RFC 4884 - Extended ICMP to Support Multi-Part Messages


== 関連項目 ==
== 関連項目 ==
* [[Maximum Segment Size]](MSS)
* [[Maximum Segment Size]](MSS)

== 参考文献 ==
* {{Cite book|和書
|author=W・リチャード・スティーヴンス
|authorlink=W・リチャード・スティーヴンス
|others=橘康雄訳、井上尚司監訳
|title=詳解TCP/IP Vol.1 プロトコル
|origyear=1994
|date=2000-12-20
|edition=新装版
|publisher=ピアソン・エデュケーション
|isbn=4-89471-320-9
}}


{{Internet-stub}}
{{Internet-stub}}

2009年9月20日 (日) 23:50時点における版

Maximum Transmission Unit (MTU)は、ネットワークにおいて1回の転送(1フレーム)で送信できるデータの最大値を示す伝送単位のこと。

MTUの値は利用される通信メディアやカプセル化の有無などによって変わる。たとえばイーサネットでは最大1,500バイトオクテット)がIP通信に利用できる。PPPoEを使うとカプセル化のために8バイトを使うため、1,492バイトとなる。WANではさらに別の制約が入る場合もあり、たとえばNTT東日本およびNTT西日本が提供するフレッツシリーズのIP網は1,454バイトとなっている[1]

MTUと通信パフォーマンス

パケット通信を用いて一定サイズのデータを送受信する場合、パケット長の決定が通信パフォーマンスに影響する。

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

インターネットのようなWAN環境では、パケットが宛先に到着するまでの間に、様々なMTUの伝送路を通る可能性がある。もしフレーム長がMTUを超えていた場合、Internet Protocol(IP)のような上位層は通常、パケットの断片化・再統合を行う。しかし、このようなパケットの再構成はルーターの処理負荷増加および通信パフォーマンス低下の原因となるため、断片化の起こらないパケット長がわかっている場合は、あらかじめパケット長を制限して送信するという考え方もある。ただし、その値は宛先および経路によって異なるため、あらかじめ静的に設定しておくには、何らかの割り切りが必要になる可能性がある。

経路MTU探索

IPではRFC 1191で定義される経路MTU探索(Path MTU Discovery)を使うことで、終端まで断片化を行わずに転送できるMTUを動的に検出できる。これは、パケットに断片化禁止のフラグ(Don't Fragment = DFフラグ)を設定しておき、MTUの問題で転送できない経路に到達した際はその旨を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探索に関する問題

経路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のヘッダは除く)を通知することができる。IPv4の場合、通常はTCPヘッダ20バイト、IPヘッダ20バイトなので、MSS + 40バイトがMTUに相当する。前述のフレッツ網を例にとると、MSSとして1414バイトを送っておけば、経路MTU探索の候補値を1414 + 40 = 1454バイト以内に制限することができる。

MSSは本来、TCPコネクションの両端が設定する項目である。しかし最近のブロードバンドルーター等は、TCPセグメントの転送時にMSSオプションを書き換える機能を持っている。この機能を使えば、さらにMTUの小さな伝送路を通ったり、通信相手がMSSオプションを無視したりしない限り[2]、 経路MTU探索に由来する問題を回避できる。

脚注

  1. ^ IP通信網サービスのインタフェース 第一分冊 (第6版)” (PDF). 東日本電信電話株式会社 (2009年4月20日). 2009年9月13日閲覧。
  2. ^ 阿蘇和人 (2009年9月14日). “Microsoft Updateが遅くなるトラブルが発生”. 日経BP ITpro. 2009年9月19日閲覧。

RFC

  • RFC 1191 - Path MTU Discovery
  • RFC 1981 - Path MTU Discovery for IP version 6
  • RFC 2923 - TCP Problems with Path MTU Discovery
  • RFC 4884 - Extended ICMP to Support Multi-Part Messages

関連項目

参考文献

  • W・リチャード・スティーヴンス『詳解TCP/IP Vol.1 プロトコル』橘康雄訳、井上尚司監訳(新装版)、ピアソン・エデュケーション、2000年12月20日(原著1994年)。ISBN 4-89471-320-9