3 Minutes NetWorking
No.44

3Minutes NetWorking

第44回レイヤ4 UDP

■ TCPの弱点

インター博士

第37回で少し話したように、TCP/IPではレイヤ4では2つのプロトコルが実装されている。
もちろん、覚えているよな。

ネット助手

TCPと。
UDP…、でしたっけ?

インター博士

そうだ。
User Datagram Protocol、UDPだ。

ネット助手

やりぃ。

インター博士

UDPの話をする前に、TCPの弱点について話しておいた方が、UDPの理解が深まるだろう。
なので、まずはTCPの弱点だ。

ネット助手

TCPに弱点なんてあるんですか?
正確・確実」が謳い文句のまるでイヤミな優等生委員長のようなプロトコルなのに。

インター博士

ふむ。そうだな。
とりあえず、ネット君が優等生になにかトラウマを抱えていることは十分わかった。

ネット助手

ななな、何を根拠にそのような…。

インター博士

すくなくとも、ネット君が善でもなく悪でもなく、一見して脇役なキャラなのは十分わかるぞ。
言うならば、ギャルゲーでヒロインの情報を教えてくれる役のような。

ネット助手

うぅ、その一見わからない様で、何故か納得してしまうような例えはやめてください。

インター博士

好きな女の子に告白しても、「優しそうな人だけど…」という、それ自体全く無意味なフォローの後に玉砕しそうな、というか。

ネット助手

ぐはっ…。

インター博士

そういうネット君だから、イヤミで優等生で委員長という個性のある人間が嫌いなのはよくわかる、という話だ。

ネット助手

わかってほしくないですっ!!
…。それで、TCPの弱点ってなんなんですか?

インター博士

ふむ、想像したより立ち直りが早いな。
ともかく、TCPの弱点とは、その優等生な所だ。つまり正確・確実がアダになる。

ネット助手

正確・確実なのがアダ?

インター博士

そうだ。
その正確・確実なためにTCPは何をしている?

ネット助手

え〜っと。
スリーウェイハンドシェイクに、確認応答に、フロー制御、輻輳制御ですよね。

インター博士

そうだ。
どれをとっても、面倒くさいだろう?

ネット助手

面倒くさいって…。
確かにそうですけど。

インター博士

特に、確認応答の待ち時間が致命的だ。
なにをしようにも、一定時間待つことになるからな。

確認応答を待つための時間

[Figure44-01:確認応答を待つための時間]

インター博士

右と左を見比べてみればわかる。左は確認応答を待つ間に1つセグメントを送っている。
もし確認応答にもっと時間がかかれば、確認応答を待つ間にいくつもセグメントを送ることができる。

確認応答を待たない場合

[Figure44-02:確認応答を待たない場合]

ネット助手

確かにそうですけど。でも、ウィンドウサイズを大きくすればいいんじゃないですか?
ほら、ウィンドウサイズが大きいと、確認応答をあまり待つ必要がなくなるでしょ?

インター博士

確かにそうだ。
だが、ウィンドウサイズをあまり大きくすることはできない

ネット助手

何故ですか?

インター博士

ウィンドウサイズが大きいということは、データの送受信用のバッファを大きくするということだ。理想を言えば、送るデータのサイズと同じだけのウィンドウサイズがあればいいのだが、それほど大量のメモリを使えない

ネット助手

最近のパソコンはメモリが大きいじゃないですか。

インター博士

いやいや。
転送するデータ1つにつきだぞ。メモリが大きいといっても、通信だけで使い切るわけにはいかんだろう。

ネット助手

ははぁ。

インター博士

つまりTCPこそがスループットの低下を引き起こす ことがある、ということだ。
特に、確認応答に時間がかかる、ルータをいくつも越えた先の遠隔地とのやりとりではそれが顕著になる。

ネット助手

するーぷっとの低下。

インター博士

ADSLだ、FTTHだと回線がどんなに早くなっても、こればかりはどうしようもならない。
TCPの仕組み自体がそうなってしまっているからな。

ネット助手

確認応答という、正確・確実を記すための仕組みが、スループットの頭打ちの原因になってしまうなんて、皮肉な結果ですね。

■ UDPヘッダ

インター博士

そういうわけで、UDPの話だ。
まず、UDPヘッダをみてもらおう。

送信元ポート番号(16)宛先ポート番号(16)
セグメントサイズ(16)チェックサム(16)

[Table44-01:UDPヘッダ]

ネット助手

えっと。
これだけ?

インター博士

これだけだ

ネット助手

ポート番号以外なにもないじゃないですか

インター博士

なにもないな

ネット助手

なんですか、こりゃ?

インター博士

そう、TCPにはあった、シーケンス番号も確認応答番号も、ウィンドウサイズも、制御ビットも、オプションすらない。
ネット君、これらのヘッダ部分は何をするためにあった?

ネット助手

え〜。シーケンスと確認応答番号は、ハンドシェイクで決定して、TCP通信ならどこでも。
ウィンドウサイズは、ウィンドウ制御(フロー制御)に。制御ビットは、スリーウェイハンドシェイクにも必要ですよね。

インター博士

つまり、これらがないということは。

ネット助手

ということは?

インター博士

何もしないということだな。

ネット助手

何もしないってそんなのありなんですか?

■ なにもしない理由

インター博士

ありもなにも。
つまり、UDPとはIPにポート番号をつけただけのものなのだよ。

ネット助手

IPにポート番号をつけただけ…。
確かに、UDPヘッダにはポート番号以外なにもないですものね。

インター博士

先ほど述べたシーケンス番号やら、確認応答番号やらは、TCPの特徴である正確・確実をなすために必要な部分だったよな。
つまり、逆に言うならば、UDPはなにもしないプロトコルなのだよ。

ネット助手

確認応答や、フロー制御や、輻輳制御をしないってことですか?
ってことは、UDPは正確・確実ではないってことですよね。

インター博士

そういうことだ。

ネット助手

それって、なんかいい加減なプロトコルって感じですけど。
意味あるんですか?

インター博士

もちろんもちろん。
では、再びTCPヘッダを見てもらおう。

送信元ポート番号(16)宛先ポート番号(16)
シーケンス番号(32)
確認応答番号(32)
データオフセット(4)予約(6)制御ビット(6)ウィンドウ(16)
チェックサム(16)緊急ポインタ(16)
オプション

[Table39-01:TCPヘッダ]

インター博士

ネット君、TCPヘッダはオプションを抜くと何バイト必要だ?

ネット助手

何バイト?
え〜っと。16 + 16 + 32 + 32 + 4 + 6 + 6 + 16 + 16 + 16。160ビットなので、20バイト

インター博士

では、UDPヘッダは?

送信元ポート番号(16)宛先ポート番号(16)
セグメントサイズ(16)チェックサム(16)
ネット助手

16 + 16 + 16 + 16。
64ビットで、8バイト

インター博士

そう、つまりヘッダの大きさが4割しかない
通信時に小さいデータで済むということだな。

ネット助手

そうですね。
同じサイズのデータを送るのでも、ずいぶんと小さくなりますね。

インター博士

さらに、先ほどのTCPの弱点の原因はなんだった?

ネット助手

TCPの弱点の原因?
確認応答にかかる時間でしたよね。

インター博士

うむ。一方UDPは何もしない。つまり確認応答にかかる時間などないということだ。
これは何をしめす?

ネット助手

つまり、TCPの弱点がないってことですよね。
スループットの低下がおこらない

インター博士

よし。
それが、UDPの利点にして最大の特徴だ。

ネット助手

ははぁ。
何もしないことが利点になるなんて。

インター博士

そのUDPの特徴から導き出される答えは、UDPは高速である。これだ。
何もしない上に、ヘッダのサイズが小さい。

ネット助手

ヘッダのサイズが小さいから、全体のデータ量が小さくて済む。
何もしないから、スループットの低下がおこらない…。

■ ブロードキャスト・マルチキャスト

インター博士

もう1つ、UDPにはいいところがある。
ネット君、TCPは最初に何を行うんだった?

ネット助手

スリーウェイハンドシェイクですよね。
ハンドシェイクで、相手と送受信ができるかどうか確かめることをします。

インター博士

つまり、コネクションをとる、ということだ。
一方、UDPはなにもしないからコネクションをとらないコネクションレスという通信方式だ。

ネット助手

こねくしょんれす。
…。イーサネットや、IPが確かコネクションレスでしたよね。

インター博士

うむ。いわゆる送りっぱなしの方式だ。
これは確実に相手に届いたかどうかわからないため信頼性がないと言ってきたが、利点がある。

ネット助手

利点?

インター博士

そうだ。
以下の図を見てもらおう。

TCPでのブロードキャスト

[Figure44-03:TCPでのブロードキャスト]

インター博士

TCPでは同報通信が非常に難しい。
相手を全員知っていなければならないし、それぞれに対しコネクションを確立するため、送受信が多くなる上、ウィンドウのためのメモリ消費量も激しい。

ネット助手

100台いたら、100個のコネクション。
最大ウィンドウサイズの64Kバイトだったら、6.4Mバイトのバッファが必要ってことですね。

UDPでのブロードキャスト

[Figure44-04:UDPでのブロードキャスト]

インター博士

しかし、UDPなら可能だ。
制御をしないからな。

ネット助手

ははぁ。

インター博士

特に相手がいるかどうかもわからない、DHCPなどはコネクションの取りようがない。
なので、UDPを使うわけだな。

ネット助手

DHCPっていうと、DHCP Discoverですか。あれってDHCPサーバを探し出すものですからね。相手がいるかどうかも確かにわからないや。

インター博士

うむうむ、そういうことだ。
つまり、ブロードキャストが必要ならUDPということだな。

ネット助手

なるほど。

■ UDPの使い道

インター博士

もちろん、便利に見えるUDPだが欠点もある。
それは信頼性が低いということだ。

ネット助手

そりゃそうですよね。
だって、何もしないんだもん。

インター博士

なので、UDPを使うアプリケーションは信頼性を確保する仕組みを自分で持つ必要がある。

ネット助手

自分で持つ?

インター博士

そうだ。
TCPを使うアプリケーションの場合、TCPが信頼性を確保してくれるので必要ないからな。

ネット助手

つまり、TCPを使うアプリケーションより、UDPを使うアプリケーションのほうが手間がかかるってことですか?

インター博士

手間かどうかはわからんが。
少なくとも、データが届かなかった場合どのように補完するかの仕組みを持つ必要はあるな。

ネット助手

ははぁ。

インター博士

さて、高速ブロードキャスト可能信頼性の低さという特徴を持つUDPだが。
これらの特徴にあった使い道がある。

  1. 高速性やリアルタイムなやり取りが必要なアプリケーション
  2. ブロードキャストが必要なアプリケーション
  3. 信頼性の必要のないアプリケーション
インター博士

まず、1のスピードが必要というアプリケーションだな。
信頼性などは二の次三の次で、とりあえず早く送ることが重要なアプリケーションだ。

ネット助手

なるほど、UDPはTCPより高速ですからね。

インター博士

うむ。例えば、VoIPや、動画のストリーミング配信などがこれに当たる。
これらは、届かなかったから再送しましたと言われても既に遅いからな。

ネット助手

あはは。
VoIPだと面白いですね。再送されて届いた分だけ後に聞こえるんですから。

インター博士

そうだろう。
リアルタイムなやり取りには、TCPはまだるっこしい、ということだ。

ネット助手

まずスピード、ですね。

インター博士

次の2ブロードキャストは先ほど説明したからいいとして。
3の信頼性が必要ないというアプリケーションというのもUDPを使う。

ネット助手

信頼性が必要ない、って届かなくてもいいってことですか?

インター博士

そういうわけではないが。
これはDNSのことだ。

ネット助手

でぃーえぬえす。
どめいんねーむさーびす、でしたっけ?

インター博士

うむ。
DNSのパケットは非常に小さい。複数のセグメントに分割することなどほとんどないぐらいのサイズだ。

ネット助手

そうなんですか?

インター博士

そうなのだ。
TCPを使った場合、どんなに小さいパケットを送るのにも、まずスリーウェイハンドシェイクから始まる。

ネット助手

はい、それはそうですね。

インター博士

つまり、SYN → ACK+SYN → ACKという3つのパケットをまず最初に送受信する必要がある。
小さいパケット1つを送るのに、無駄だろ?

ネット助手

無駄っていえば、そうですけど。

インター博士

さらに、DNSは非常に頻繁に使われることが多い。そうなるともうTCPでは無駄だらけになるわけだ。
なので、軽さが必要なわけだ。

ネット助手

軽さ?

インター博士

素早く送れて、無駄が少ない。
こうなると、やはりUDPなわけだ。

ネット助手

ははぁ。
でも、届かないことがあってもいいのですか?

インター博士

よくはないが、なんとかなる。
まずは「軽さ」が重要なのだよ。

ネット助手

ははぁ。

インター博士

うむ。
というところで今回はここまでだな。

ネット助手

はい

インター博士

次回はそうだな。
レイヤ4をまとめてみよう。

ネット助手

了解。
3分間ネットワーキングでした〜♪

あまり大きく…
通常は、TCPヘッダにあるウィンドウサイズの領域は16ビット。
よって、0バイト〜65535バイトまでの値をとることができる。
つまり、64キロバイトが最大のウィンドウサイズになる。
送るデータの…
上記にあるよう、64キロバイトが最大値だが。
オプションを使う(ウィンドウスケールオプション)ことにより、最大1ギガバイトまで増やすことが可能。
スループット
[throughput]
一定時間内の転送量をあらわす言葉、概念。
実際はbpsやpps[packet per seconds]などを使うが、スループットという言葉自体は、転送効率に近い響きがある。
コネクションレス
[connection-less]
同報通信
ブロードキャスト、マルチキャストのような、複数相手に同じ内容を同時に送る通信。
ブロードキャストが…
DHCP、SNMP、RIPなどがあたります。
VoIP
[Voice over IP]
「インターネット電話」と呼ばれる音声をインターネット技術で送る技術。
ストリーミング配信
[streaming]
データをストリーム[stream](流れるように連続的に継続的に)で配信すること。
多くの場合、ダウンロードしながら同時に再生することを指す。
無駄
DNSでも1パケットが512バイトを越える場合はTCPを使います。
ネット助手ネット君の今日のポイント
  • TCPは信頼性のかわりに、スループットを犠牲にすることがある。
  • UDPはヘッダが小さく、制御をなにもしない。
  • UDPはコネクションレスである。
  • ブロードキャストはUDPで行う。
  • UDPを使うアプリケーションは以下の通り。
    • 高速性やリアルタイムなやり取りが必要。
    • ブロードキャストが必要。
    • 信頼性が必要ない。

3 Minutes NetWorking No.44

管理人:aji-ssz(at)selene.is.dream.jp