Lesson3ではUDPでも通信の信頼性を確保できることを解説した。「それなら，結局TCPとUDPはどちらを使っても大差はないのでは？」と思うかもしれない。それは半分当たっているが，半分は不正解だ。
確かに，世の中にはTCPとUDPのどちらでも利用できるアプリケーションが存在する。例えば，Lesson3で登場したSIPがそう。処理が軽いということで現在は専らUDPが使われているが，規格上ではTCPも利用できる。
このようにUDPとTCPの両方で使えるアプリケーションがある一方で，UDPでしか実現できなかったり，UDPを使うメリットが大きいアプリケーションも存在する。Lesson4では，そうした「UDPならでは」の通信方法やアプリケーションについて見ていく。
TCPでは実現できない同報通信
UDPなら簡単に実現できるのに，TCPでは逆立ちしても実現できない通信方法がある。それは，ネットワーク上にいる全員にメッセージを届ける「ブロードキャスト」（同報通信）や特定グループに送る「マルチキャスト」だ。
なぜ，UDPでないとブロードキャストやマルチキャストは実現できないのか。理由は簡単，Lesson2で見たように，TCPは通信相手との間で必ずコネクションを確立して通信する。しかし，一つのメッセージをネットワーク上の複数の相手に届けるのに，それらの相手と同時にコネクションを確立できないからだ。
一方のUDPは，コネクションを確立せずに通信を行う。事前の準備なしでいつでも誰とでも同時にパケットをやりとりできる。このためブロードキャストやマルチキャストが実現できるのだ。
UDPでブロードキャストを使う典型例がWindowsネットワークだ。Windowsネットワークでは，コンピュータ名の一覧を表示したり，コンピュータ名からIPアドレスを調べたりする目的でUDPによるブロードキャストを使う（図4-1）。
 |
| 図4-1●同報通信（ブロードキャスト）ができるのはUDPだけ UDPは，通信相手と個別に接続状態を作らずにパケットを送信でき，複数の相手から同時にパケットを受け取れるので，TCPでは不可能な同報通信を実現できる。 [画像のクリックで拡大表示] |
LAN上でUDPを使うブロードキャスト・パケット（MAC（マック）フレーム）の中身も見ておこう。構造は，UDPパケットをIPパケットのデータ部に入れ，そのIPパケットがMACフレームのデータ部に入る形になる。
このなかで，あて先MACアドレスとあて先IPアドレスで共に同報用アドレスが指定されている。一方，UDPヘッダーやUDPデータにはブロードキャストを示す情報は何もない。UDPは「何もしない」ことでブロードキャストの実現を手助けしているわけだ。
リアルタイム通信もTCPは不適格
次に，UDPを使うことのメリットが大きいアプリケーションを見ていく。それは，IP電話の音声転送や映像配信といったリアルタイム系やストリーミング系のアプリケーションである（図4-2）。
 |
| 図4-2●リアルタイム通信もUDPが適している IP電話の音声パケットのやりとりやライブ映像のストリーミング配信など，リアルタイム性が高いアプリケーションは，（1）パケットを再送しても間に合わない，（2）確認応答なしに必要なタイミングで必要な量だけデータを送れる--といった理由から圧倒的にUDPが使われている。 [画像のクリックで拡大表示] |
こうしたアプリケーションでは，コンスタントに決まった数のパケットを相手に送り続ける必要がある。こうした処理にTCPは向いていない。一定数のパケットを送り続けたいのに，TCPでは勝手に再送制御やウインドウ制御が働き，送出速度が調整されたり，あとから届いても意味がないのにパケットを再送したりするからだ。
それに対してUDPは，何の問題もなくパケットを送り続けられる。ただし，UDP自体には通信の信頼性を確保するしくみや，順番が前後して届いたパケットの順序を正しく直すしくみ，さらには再生のタイミングを補正するといったしくみがない。これらの処理は上位アプリケーション側で用意する必要がある。
