■ TCPの弱点

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

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

そうだ。
User Datagram Protocol、UDPだ。

やりぃ。

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

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

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

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

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

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

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

ぐはっ…。

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

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

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

正確・確実なのがアダ？

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

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

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

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

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

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

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

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

何故ですか？

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

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

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

ははぁ。

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

するーぷっとの低下。

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

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

■ UDPヘッダ

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

えっと。
これだけ？

これだけだ。

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

なにもないな。

なんですか、こりゃ？

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

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

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

ということは？

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

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

■ なにもしない理由

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

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

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

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

そういうことだ。

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

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

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

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

では、UDPヘッダは？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

利点？

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

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

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

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

ははぁ。

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

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

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

なるほど。

■ UDPの使い道

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

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

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

自分で持つ？

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

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

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

ははぁ。

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

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

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

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

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

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

まずスピード、ですね。

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

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

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

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

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

そうなんですか？

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

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

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

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

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

軽さ？

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

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

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

ははぁ。

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

はい

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

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