【図解】UDPのMTU/MSSやフラグメント(パケット分割),サイズの考え方,EDNS0やQUICの例

前提知識
UDP と MTU/MSS
DNS のパケットサイズ
QUIC のパケットサイズ
IT/インフラエンジニアの地位とスキル向上のために

前提知識

TCP と MTU/MSS に関する基礎知識については以下をご参照下さい。

【図解】MTUとMSS, パケット分割の考え方 ~IPフラグメンテーションとTCPセグメンテーション~

MTU と MSS の違い MTU (Maximum Transmission ...

UDP と MTU/MSS

TCP には MSS という仕組みでパケットサイズを調整する機能があります。

アプリ開発者は、OS の各種ソケット API (WinSock 等) を使えば上位プロトコルが何であろうとバッファ内のデータを MSS の値に区切って TCP で送信します。

また、ネットワークエンジニアはルータの MSS 調整 (tcp adjust-mss) 設定を使って最適な TCP セグメンテーションが行われるようにします。

もし経路途中でパケットより小さな MTU のルータがある場合は Path MTU Discovery もしくは IP フラグメンテーションを使って送信を試みます。

一方、UDP には MSS という概念がありません。そのため、基本的にはプロトコル策定者やアプリケーション開発者側での考慮が必要となり、そこで対応できない場合は Path MTU Discovery もしくは IP フラグメンテーションを使って送信を試みます。

NTP や DHCP, VoIP 等はやり取りするときの 1 パケットあたりの通信量は大したことないのでそもそも問題にはなりません。

ですが例えば TFTP で大容量のファイルを送る場合などはパケットサイズが適切でないと通信が非効率、もしくは不可となります。

そこで RFC 1350 規格では、送信時のサイズをデフォルトで 512 バイトと定めています。

Any transfer begins with a request to read or write a file, which also serves to request a connection. If the server grants the request, the connection is opened and the file is sent in fixed length blocks of 512 bytes.

一方、Ethernet を使う場合の多くは MTU が 1500 バイトであり、512 バイトでは効率が悪いということで RFC 2348 ではオプションとしてサイズを変更できると書かれています。

However, the choice of a 512-octet blocksize is not the most efficient for use on a LAN whose MTU may 1500 octets or greater. This document describes a TFTP option which allows the client and server to negotiate a blocksize more applicable to the network medium.

これと似たような話があります。DNS のパケットサイズです。

DNS のパケットサイズ

DNS ももともとはサイズの上限は 512 バイトまでと定められています。

TFTP もそうですが、当時の『IP に対応している』基準として『最低限 512 バイトの IP パケットを受信できること』という要件があったため、そこに標準を合わせていました。(いわゆる 512 バイトの壁)

RFC 1035 の "2.3.4 Size limit" には以下のように書かれています。

UDP messages 512 octets or less

この値を超える場合は TCP にフォールバックしなさい、となっていました。

ですが最近では DNSSEC や IPv6 (AAAA) 対応で DNS の 1 パケットあたりのデータ量が増えてきており、EDNS0 (RFC6891) という拡張が為されました。EDNS0 というオプションによりどのサイズまで受け取れるかを指定できるようになりました。

これにより 4096 バイトまでは UDP で送信してよいことになりました。

QUIC のパケットサイズ

QUIC では現在ドラフトで議論中 (WIP : Work in Progress) です。

draft 24 では最低のサイズは 1200、Path MTU Discory がサポートされてないなら 1280 より大きいパケットを投げるべきではない、としています。

An endpoint SHOULD use Datagram Packetization Layer PMTU Discovery ([DPLPMTUD]) or implement Path MTU Discovery (PMTUD) [RFC1191] [RFC8201] to determine whether the path to a destination will support a desired message size without fragmentation. In the absence of these mechanisms, QUIC endpoints SHOULD NOT send IP packets larger than 1280 bytes.

一般的な Path MTU Discovery では ICMP によりルータから適切な MTU サイズが通知されますが、ICMP の届かない環境においては通信に支障をきたします。そこで、ICMP に頼らず、自ら手探りで適切な MTU 値を探索する「Packetization Layer Path MTU Discovery」という規格が RFC4821 として定められましたが、これは TCP 層で効果を発揮する仕組みでした。