Part2では，TCPが通信の信頼性を高めるためのしくみを見てきた。一方，UDPはこれとは正反対で，信頼性を確保するしくみを持っていない。その反面，とても自由度が高いプロトコルである。Part3では，UDPの概要とともに，どんなアプリケーションに向いているのかを見ていく。
TCP編では，TCPが通信の信頼性を高めるためのしくみを見てきた。一方，UDPはこれとは正反対で，信頼性を確保するしくみを持っていない。だからといって，UDPは不要と決めつけてしまうのは早計である。どんなプロトコルにも長所と短所があり，それぞれにふさわしい用途がある。
“なにもしない”プロトコル
まずはUDPとはどんな姿をしているのか，UDPのプロトコル・フォーマットから見ていこう（図1）。
UDPは，TCPと同じくIPの上位プロトコルである。TCPのデータはセグメントと呼んだが，UDPではそれをデータグラムという。実際には，このUDPデータグラムがIPパケットのデータ部分に入ってやりとりされる。
図1を見ればすぐわかるように，UDPのヘッダー部分は非常にシンプルだ。(1)送信元ポート番号，(2)あて先ポート番号，(3)UDPデータグラムの大きさ，(4)チェックサム――という4種類のフィールドしかない。TCPヘッダーにはあったシーケンス番号やウインドウ値，制御ビットといった項目が削られている。残った4項目は，UDPがアプリケーションとの間でデータを受け渡すために最低限必要なものだけである。要するに，UDPはポート番号でアプリケーションを区別してデータを受け渡す以外，「なにもしない」プロトコルなのである。
しかし，なにもしないのは悪いことばかりではない。なにもしなければ，それだけ処理が軽くなり，TCPより高速に処理できる。例えば，UDPのヘッダー・サイズはたったの8バイトである。TCPヘッダーが標準で20バイト，オプションを使うと最大60バイトになるのに対して圧倒的に小さい。余計なヘッダーが付かない分だけアプリケーション・データを送受信できるので，通信効率はUDPの方が高くなる。
また，信頼性を確保するしくみをアプリケーションが独自に用意したい場合もあるだろう。再送処理だって，TCPに任せずにアプリケーションが独自に処理してもよい。つまり，UDPはとても自由度が高いプロトコルなのだ。
同報通信ができるのはUDPだけ
では，具体的にUDPがどんなアプリケーションに向いているかというと，大きく三つ考えられる（図2）。
まず一つ目は，複数の相手へメッセージを一斉同報するアプリケーションだ。これは向いているというよりも，TCPにはできない絶対的な利点である。TCPは1対1でTCPコネクションを張るのが前提だからだ。
メッセージの同報は，とくにLANでTCP/IPを使うときに必要になる。例えばIPアドレスをクライアント・マシンに自動で割り振るDHCPが，その代表である。そもそもクライアント・マシンはIPアドレスを持っていないから，TCPではまったく役に立たない。また，ネットワーク機器を管理するSNMPや，ルーター同士で経路情報を交換するためのRIPといったプロトコルも同様にUDPを使う。
二つ目は，ストリーミング・データを扱うアプリケーションだ。インターネット電話などでは，高速でリアルタイムにデータを送受信する必要がある。もし途中のデータが欠落しても，あとから再送してもらっていたのでは間に合わない。つまり，多少のデータ欠落は我慢してでもUDPを使った方がいいのだ。
三つ目はドメイン名からIPアドレスを調べたりするDNSである。DNSでは，1回の問い合わせに必要なデータ量がIPパケット1個分で済んでしまうくらい小さい。TCPコネクションを確立するために3パケットをやりとりすること自体がムダなのである。
結局，TCPとUDPはどちらも絶対必要なのである。
同じポート番号が同時に使える！？
