連載第9回
TCP/IPアレルギー撲滅ドリル【下位レイヤ編】

データの過保護を
お望みでないならUDPで

福永勇二
インタラクティブリサーチ
2005/1/29


素朴な疑問
確実だけれど……
1 確かなTCPのどこがいけないのでしょうか?
シンプル&きびきびを求めて
2 TCPが犠牲にしたものとは?
3 TCP以外にはどんな方法がありますか?
UDPという選択肢
4 UDPを使うのはどんなアプリですか?
5 じゃあUDPとIPにはどんな違いがあるの?
6 ちなみにUDPパケットはどんな構造?
UDPの弱みを知っておく
7 UDPならではの注意点はありますか?
 確実だけれど……

 最近、通販を利用したときのことです。いくつか注文した中の1つの入荷が遅れ、販売店がその品の入荷を待って商品一式を発送したため、在庫が十分にあった商品まで到着が遅れてしまいました。幸いそのときは大した遅れではなく、何の問題もなかったのですが、発送を確実にするために注文品一式をまとめるのも、客にとっては良しあしだなぁと感じました。

確かなTCPのどこがいけないのでしょうか?

 実は、正確な通信を実現するTCPにも、同じような性質があります。思い出してみてください。TCPは途中のデータが抜けたら、相手に再送を依頼し、抜けたデータが送られてくるのを待ちます。この間、先に到着したデータは、ずっと待たされているんです。

 この様子を、データを受け取るプログラムから見ると「TCPって正しいデータを送ってくれるけど、いつデータが到着するかは予想できないなあ」ということになります。もし、プログラムの側から、相手からの再送を待っていることを見分けたり、それを止めさせることができれば話も違いますが、それもできません。

 シンプル&きびきびを求めて

TCPが犠牲にしたものとは?

 TCPのウリである「確かな通信を実現すること」は、基本的にどんなアプリケーションにとっても都合がいいはずです。ここで考えてみたいのは、確かな通信を実現するために、何か犠牲になっているものがないか、ということです。もし犠牲になってしまったものがアプリケーションにとって必要な機能だったら、いくら確かな通信を実現するTCPといっても、あまりうれしくないでしょう。

 TCPが犠牲にしているもの。その1つは到着したデータの引き渡しの遅れです。始めにも書いたとおり、データを本来の順序どおり取りそろえようとするTCPは、途中のデータが再送待ちになってしまうと、それ以降のデータをしばらく蓄えています。

 この様子をTCPのウィンドウの動きから考えてみましょう。連載第5回「それでも不正確なデータを受け取ったらどうするの?」にその説明があります。図3の(3)で2番のデータを受信し損なうと、3番、4番、5番のデータを受信しても、ウィンドウを移動できません。(7)で2番を受信したら、やっとウィンドウを動かすことができます。プログラムがデータを受け取ることができるのもこのタイミングになります。そのため、3〜5番のデータは受け取ったタイミングよりかなり遅れてプログラムに引き渡されたことになります。この遅れは、再送の仕組みを使う以上は、どうしても起こってしまいます。

 もし、プログラムが定期的にデータを受信することを期待しているとしたら、この待ち時間はとても厄介です。むしろ、データが多少抜けたり誤ったりしてもいいから、その後に続くデータをどんどん渡してくれる方がありがたい場合もあるでしょう。

 TCPが犠牲にしているものの2つ目は、通信を始めるときや終えるときの手間です。正確な通信を目指すTCPは、通信を始めるとき、相手と通信のコントロールに必要な情報をやり取りします。また終えるときにも、送り残しデータが発生しないよう、慎重に通信を終了します。

 正確な通信をするためには、この確認作業はとても大切です。もしこの準備作業をしなければ、相手が通信できる状態ではないのにデータを送ってしまう可能性もあり、正確な通信どころではありません。

 しかし、非常にたくさんの相手からデータを受け取って処理しなければならない場合には、これらの手間もばかになりません。データの処理能力を高めるために、多少、通信の信頼性が下がっても、開始と終了の手間を減らしたいという場合もあるはずです。

TCP以外にはどんな方法がありますか?

 データが定期的に届かない場合がある、通信の開始に手間が掛かる、といったTCPの特性が邪魔になる場合、こういった特性を持たないもう1つのトランスポートプロトコルUDPを使う方法があります。

 今回取り上げるこのUDPは、複雑な処理で正確な通信を目指すTCPとは正反対に、シンプルな処理できびきび機能する通信を目指しています。UDPは再送などの仕組みを一切持っていません。そのため再送待ちのデータの遅れは起こらず、定期的にデータを受け取りやすくなります。また通信を始めるときの準備作業も不要で、いきなり相手にデータを送ることができます。

TCP/IPアレルギー撲滅ドリル【下位レイヤ編】(9)目次
1  確実だけど……
2  UDPという選択肢

関連リンク
  連載:TCP/IPアレルギー撲滅ドリル【超実践編】(上位レイヤ編)
連載:インターネット・プロトコル詳説

連載:ルータの仕組みを学ぼう
ホストのネット接続は正しく行われているか? 〜netstatによるネットワーク設定の確認〜


「Master of IP Network総合インデックス」

@IT Special

- PR -

TechTargetジャパン

Master of IP Network フォーラム 新着記事
  • シスコのSD-WANが、分かりにくいのはなぜか (2017/2/27)
     シスコシステムズは、SD-WANに対してどのようなスタンスをとっているのか。結論から言えば、同社の既存技術の適用形態としてSD-WANを捉えており、一方で即座に活用できるソリューションを求める人々には、「Cisco Meraki」を推進するということになる
  • ネットワークの疎通を確認するには?〜ping/traceroute〜 (2017/1/30)
     マシンのネットワーク設定を行い、外部のネットワークやサーバとつながるかどうかを確認する際には、実際にネットワーク・アプリケーションを使う前に、「ping」「traceroute(tracert)」などのコマンドを用いる方法が有効だ
  • ping 〜ネットワークの疎通を確認する (2017/1/23)
     pingは、ネットワーク疎通を確認したいホストに対してIPパケットを発行し、そのパケットが正しく届いて返答が行われるかを確認するためのコマンドだ
  • SDNで物理ネットワークのテストを楽にする方法 (2017/1/18)
     ネットワーク運用をSDNによっていかに“楽に”できるかを考える本連載。最終回となる今回は、物理ネットワークにSDNを適用し、テストなどに掛かる負荷を低減する方法について解説します
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

イベントカレンダー

PickUpイベント

- PR -

アクセスランキング

もっと見る

ホワイトペーパーTechTargetジャパン

注目のテーマ

Master of IP Network 記事ランキング

本日 月間
ソリューションFLASH