ビジネス開発者必須講座

P2P/ブロードバンド時代の新・TCP/IP 入門
村上 健一郎第3回

NTT 先端技術総合研究所 主幹研究員

インターネットの仕組みはリアルタイム通信には向かない？

連載 2 回目は、「TCP/IP は高速なデータ転送に耐えられるか」「IPv6 の今後」について解説しましたが、いかがでしたか？

また、キャズムについて、IPv6 という具体例で理解できたことと思います。

さて、最近、IP 電話導入の話題が多い中で、その導入後の評価がなかなか定まっていないようです。今回は、その理由について、インターネットの本来の仕組みがどのようになっているかを振り返りながら、考えてみましょう。

[Q1]
インターネットが普及し始めた頃は、メールやファイルなどの非リアルタイム通信が主流でした。しかし、現在では、音声や映像などのリアルタイム通
信 が 多 く な って き ま し た が 、TCP/IP で大丈夫なのでしょうか？

[A1]
IP 電話導入の実感は？

読むのが趣味なのですが、面白いものをに無理があるから問題が発生しているの見つけました。これは、ソリューションビです。その無理というのは、インターネッジネス系の雑誌で、その特集は IP 電話トの仕組みに由来しています。

だったのです。しかし、その編集後記
は、本音とも懺悔の言葉ともとれるもの
で、「ある IP 電話のユーザー企業に電話

リアルタイム通信用に設計されていないインターネットした際に、声が遠い、音声が途切れると言ったら、これまでの固定電話からかけそもそもインターネットは、電話のよう直してきた」とか、「IP 電話を早期に導入なリアルタイムのストリーム型通信のためし な がら 、従 来 型 の 構 内 電 話 交 換 機に 作 ら れ た の で は ありま せ ん 。コンPBX（Private Branch Exchange）を復ピュータ同士がファイルを転送したり、電活させた企業も多いようです」というもの

子メールを交換したり、遠隔からコンでした。なぜ、このようなことが起こるのピュータを利用したりするために作られでしょうか？

たのです。これは、パケットを単位としたIP 電話というキーワードで検索してみると、「タダ」「便利」「コストを大幅に削「バケツリレー式」と言われる方法でデータを転送するものです（図 1）。

最近よく話題にのぼるものに、IP（イン減」という言葉が踊っています。それらにパ ケットは 、ル ーターと呼 ば れ る パターネット）電話やインターネットでの動埋もれて、「IP 電話の導入をくやんでいるケットの中継装置によっていったん蓄積画配信といった、リアルタイムでデータをのは誰？」というのもひっかかってきまされ、転送先のコンピュータへと続く経転送するアプリケーションがあります。リす。それには「実は後悔しているとは、路上にある次のルーターに送られます。

アルタイムとは実時間性とも訳されます

導入を決めた担当者としては口が裂けてこのルーター同士は専用回線によって接が、たとえば電話のように今話しているも言えないのかもしれない」と、笑えな続されています。

内容が相手に遅延なく伝わることを言いい話も書いてあります。

ます。
筆者は、いろいろな雑誌の編集後記を104 │ iNTERNET magazine │ 2005 │ 05 │次のルーターへ接続されている回線にいずれにしても、インターネットをリアパケットを送り出す場合には、待ち行列ルタイム通信に利用することには、どこかと言われるパケットを蓄積しておく場所

インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

にいったん入れます。順番に待っているので待ち行列と言われているのです。
ルーターはその待ち行列から 1 個ずつパケットを取り出して回線へ送り出しまUDP と同じレイヤーに TCPというプロトコルがあります
が、なぜこのプロトコルが必要なのでしょうか？

（図 2）。
メール転送やウェブなどのアプリケーションでは、送ったデータと同じものが受信側で復元できることだけを要求してす。待ち行列に何もなければ、パケットいて、転送の完了に少々時間がかかってはすぐに転送されますが、他のパケットも問題はなく、転送がリアルタイムであるがあれば、順番を待たなければなりませ[A2]

必要もありません。たとえば、メールの転ん。待ち行列にあるパケットが多ければ多いほど、待ち時間も長くなります。その待ち行列の長さは状況によって異なり送が 2 秒で終ろうと 20 秒で終ろうと、気「まちがったら再送」などの制御を行う TCPにする人はあまりいないでしょう。要は、最終的に送信元のコンピュータ上のデーますから、待ち行列に入ってから送り出タが、誤りなく手元のコンピュータ上でしが完了するまで中継にかかる時間は保ここまで説明してきた音声の転送に証できません。場合によっては、待ち行は 、誤りの 訂 正 をし な い U D P（ U s e r

図 2 のように、TCP では、送信側のパ列が規定以上の長さになり、パケットがDatagram Protocol）が 利 用 され ます。

ソコン A やサーバー上にある TCP と対捨てられるという事態も発生します。

これに対し、メール転送やウェブなどの向する受信側の TCP が協力して、転送コンピュータ同士の通信の場合は、こアプリケーションには、TCP（Transmis-

途中でのパケットの損失やパケットの到の方法でも構わないのです。なぜならsion Control Protocol）が使用されます。

着の逆転といった問題を解決します。

ば、パケットが破棄された場合、あとで送信側と受信側のコンピュータ上にあさらに TCP の重要な役割として、エ再度同じパケットを送ればよいからです。

る TCP では、ルーターがパケットを破棄

ラーからの回復以外に、パケットのフ得られればよいのです。

ところが、IP 電話のようなリアルタイムしたり、送り出した間隔と異なる間隔でロー（流量）制御を行い、ネットワーク全のストリーム通信の場合には、このようなパケットが到着したり、場合によっては到体の負荷を最適に保つことがあります。

仕組みは不都合なものとなります。IP 電

着が逆転したりすることは想定済みです

これによって、最短時間ですべてのデー話ではコンピュータ同士が通信するのではなく、パソコンや IP 電話機を通じて人間同士が通信するものだからです。

パケット

たとえば、IP 電話の音声は一定の間隔インターネット

パソコンCでデジタル化され、パケットに入れられてインターネットへ送り出されます。これは、同じ間隔でデジタルの音声から元のパケットパケットアナログの音声に戻されて（復号されて）、元の音声と同じになるようにスピー

パソコンAルーター

ルーター

パソコンBカーを鳴らすことが期待されています。
しかし、インターネット上で中継されていパケットるうちに、パケットはその時々によって異パソコンDなる遅延や廃棄処理といった影響を受けるのです。到着が逆転することもあり他のルーターからルーターます。IP 電話はこれに対応する仕組みになってはいるものの、限度を超えてし待ち行列
他のルーターからパケット次のルーターへまうと元のアナログ音声には戻せないのです。

[Q2]

他のルーターから待ち行列の溢れによる破棄

ルーター内の待ち行列の様子

T C P / I P プ ロト コ ル に は 、
図 1 バケツリレー方式と待ち行列

インターネットマガジン／株式会社インプレスR&D

P2P/ブロードバンド時代の新・TCP/IP
入門 │ iNTERNET magazine │ 2005 │ 05 │ 105©1994-2007 Impress
R&D

タの転送を完了することができます。

せん。

だけではなく、自分（受信側）もそうだか

受信側の TCP では、パケットを受信す

このウィンドウサイズは、受信側のパソらです。特に問題なのは、ネットワークがると、それに対する確認応答（ACK）を返コンで利用できるパケットのバッファー長

一度過負荷に陥ると、なかなか元へ戻らしますが、その中には、次に受信するこを示していますが、実は、ネットワークがないことです。そればかりか、負荷の上とを期待する順序番号と、その順序番号

混雑している場合には、さらに小さい値

昇とともにパケットの中継にかかる時間以降でどれだけのデータ量（バイト数）がが指定されます。これにより、ネットワーが急上昇してしまいます。

受信可能かを示す値（ウィンドウサイズ）

ク側の保護を行い、過負荷（輻輳状態、このような理論に興味がある方は、レが入っています。これを受信したパソコ

ネットワークの渋滞状態）に陥らないよう

ナード・クラインロックの名著『待ち行列ンやサーバー側では、指定されたウィンにしているわけです（図 3）。なぜならば、システム理論（上、下）』（マグロウヒル好ドウサイズ以下のデータしか送信できま

過負荷で犠牲となるのは、他人（送信側）

学社、1979 年）をご覧ください。ただし、この本は絶版のようなので図書館で探すことが必要かもしれません。

インターネット

TCP

パケット

伝送路（バーチャルサーキット）

逆転や遅延のゆらぎ

1

オーバーヘッドが大きい TCP と小さい UDP

TCP

TCP では、誤りからの回復という機能
3 2 1

パソコンA破棄

電子メールやファイル

3

1 3

パソコンB

2を上位のアプリケーションに提供します
が、そのために通信手順が複雑になっています。

2

ここまで説明したこと以外にも、たとえば通信の前に「コネクション（接続関【送信側パソコンAのTCP】（1）電子メール*1やファイルの転送*2を行う場合、それぞれTCPの提供する「土管」（エラーのない伝送路＝バーチャルサーキット）を利用する〔連載の第1回（2005年3月号）参照〕。
（2）TCPはパケットを、その下位にあるIP（Internet Protocol）を利用してパソコンBやサーバーまでルーターを介して転送する。
（3）ルーターは中継の途中にパケットを捨ててしまうこともある（パケット2）。
（4）パケット1のように別のルートを通って迂回してしまい、パケット3よりもパケット1のほうが遅れて到着する「逆転現象」も起こる。
（5）ある時間以内にパソコンBから返される確認応答パケット（ACK：Acknowledge）を受信できない場合、同一パケットの再転送を行う。その結果、全部のデータがパソコンBまで送られる。

係）の設定」も行います。これは、データを転送する前に、最初の順序番号を転送元と転送先で同期させるための手続きです。また、転送が完了するときには、もう送るデータがないことを互いに通知し合う、「コネクションの切断」の手続きが行【受信側パソコンBのTCP】（1）重複したパケットや破損パケットを受信した場合には、それは破棄され、破損したパケットかどうかの判断は「チェックサム」計算で行う〔連載第2回（2005年4月号）参照〕。
（2）順番が逆転して受信されたパケットは元の順番に戻される。
（3）破棄されたパケットに関しては確認応答を返さない。パソコンAのTCPが同一のパケットを再転送する。
＊1 SMTP（Simple Mail Transfer Protocol、電子メールプロトコル）で相手と通信。
＊2 FTP（File Transfer Protocol、ファイル転送プロトコル）を利用して通信。

われます。比較的多くのデータを一度に送る場合には問題ありませんが、短い時間で通信が完了する場合には、コネクションの設定や切断はオーバーヘッド（付加的な処理）が大きすぎます。

図 2 パケットの破棄、逆転、遅延のゆらぎ

また、音声や動画のように継続的にパケットを流す場合には、フロー制御が行中継時間

このあたりでは、ネットワークは過負荷状態となっています。これをネットワークの輻輳状態（渋滞状態）とも言います。
このような状態になるとパケットをうまく送れなくなってしまい、時間がかかってしまうので、パケットがこれ以上増大しないようにパケットの流れを制御（フロー制御）します。

われるために、満足する転送速度が得られないことがあります。そこで、TCP に代わって、フロー制御や誤りからの回復も、そしてコネクションの設定や切断も行わない、オーバーヘッドの軽いプロトコルが使用されます。これが UDP です。
U D P は 、単 に エラー 検 出 の た め に

0100%

ネットワークの負荷チェックサム計算だけを行います。フ
ロー制御を行うのも、誤りからの回復を

図 3 ネットワークの負荷と処理時間の変化

106 │ iNTERNET magazine │ 2005 │ 05 │インターネットマガジン／株式会社インプレスR&D©1994-2007 Impress R&D

行うのも、それを使用するアプリケー

トワークを持つという方法もあります。し原因は、何と言っても「KaZaA」（カザー）ションの責任としています。

かし、この方法では、回線費用やルーや「WinMX」（ウィン・エムエックス）、インターネットで音声や動画を転送すターなどのコスト、ネットワークのメンテ「Winny」（ウィニー）に代表される P2P

る場合には、この UDP 上で、RTP（Real-ナンス費用が別にかかってしまうので、（Peer to Peer、ピア・ツー・ピア通信）にtime Transport Protocol）と RTCP企業にとってはジレンマとなるわけです。

よるファイル交換でしょう。これは、イン（ Real-time Transport Control Proto-

ターネットを利用して不特定多数でファイ「使い放題」がもたらす弊害col）が使用されます（図 4）。

ルなどを共有するもので、大量のデータが転送されます。現在のインターネットのインターネット時代の企業のジレンマ

今は IP 電話がブームなのですが、実通信量の半分は P2P によるものだと言わは、インターネットで映像や音声を放送すれています。このために、リアルタイムのる実験は 1992 年頃から続けられてきた転送サービスの提供に影響を与えがちでインターネットは 、ベ ストエフォートのです。結局、うまく映像が中継されるす。

（Best Effort）型のサービスです。このようにするためには、調整やメンテナン

この問題は、インターネットの利用料金サービスでは、転送されるパケットの順スに非常にコストや技術力が必要だといがフラットレート、つまり「いくら使用して番や転送時間を保証しないで、ネットうことがわかりました。現在でも、画像も同額で使い放題」になっていることもワークが混雑してくるとパケットを捨ててが安定しないので未だにサービスとして関連しています。

しまいます。

離陸していません。この放送ネットワー

電話の場合には、長電話は料金がかさクを MBONE（ Multicast Backbone）とむので、それを気にしながら電話をしま呼びます。

す。実は、このことは他の利用者にとっこのような性質のサービスを音声や映像に利用すると、ネットワークが混んでいないときは大丈夫なのですが、混んでくインターネットの負荷が軽いときであれても良いことなのです。なぜならば、輻ると音がとぎれたりエコーがかかったり、ば、MBONE であれ、IP 電話であれ、問輳が発生しにくくなるからです。経済学

動画にはモザイクがかかったりします。

題が顕著化しません。しかし、いつイン的に言えば、フラットレートは、「有限な音声や動画などの場合、少々の誤りが発ターネットが過負荷の状態になるかは予ネットワークの資源をそれぞれの利用者生してもデータを補完すれば目立たなく測できないのです。に最適に配分する」という資源配分の問することは可能ですが、場合によっては、通信そのものが途切れてしまいます。

過負荷（輻湊状態）では、ルーターはパ題を難しくしているのです。

ケットを捨てるのに力を使い果たし、イ

次回は、音声や映像データを TCP/IP

本来、違う目的で設計されているイン

ンターネットは著しく転送能力が低下すを使ってどのように送るのか、そのポイターネットを、リアルタイム通信に利用することになります。現在の一番の輻輳のントをまとめてみます。

るのは、シャツをパンツの代わりにはくよ
うなものではないでしょうか。もっとも、【送信側】

そういう人がいても構いませんし、慣れれば快適なものかもしれません。実際、インターネット電話でまったく困ったこと

音声

IP電話のアプリケーション
ダイヤル情報4 音声や動画のコーデック（データの圧縮/伸長）がないという豪傑も結構います。
これらは、利用者、つまりマーケットセグメント（利用目的）によって異なるので

5 RTP/RTCP（リアルタイム制御）

1 SIP（呼制御）

6 UDP（リアルタイム通信/単発の通信用）

H.323（呼制御）

2 TCP（信頼性の高い通信用）

す。個人が楽しむ分には、たとえ雑音がIP（インターネットの中核プロトコル）

少しくらいあったり通信が途切れたりしても、深刻な問題にはなりません。しか7 相手（送信先）へ

3 IP電話のサーバーへし、企業のようなミッションクリティカル（基幹業務）な環境では、それがビジネスチャンスを逃す危険性もあります。
これらの不安定さを避けるために、

1
2
3
4567

音声通信の前に相手と接続するために「呼制御」を行う（ここではSIPを使う例）。
SIPがダイヤル情報を送るのにTCPを使う。
ダイヤル情報は、IPを通ってサーバーへ送られ、相手との接続が確立する。
送信側では、音声をコーデックで圧縮する。
4の圧縮データは5RTP →6UDP、IPを通って相手に送信される。
相手側では、逆に、受信した音声データを（自分の）UDP、RTP、コーデックを通して再生する。

TCP/IP を使って音声や画像専用のネッ
図 4 リアルタイム通信のための仕組み（SIP が TCP を使った例）

インターネットマガジン／株式会社インプレスR&D

P2P/ブロードバンド時代の新・TCP/IP
入門 │ iNTERNET magazine │ 2005 │ 05 │ 107©1994-2007 Impress
R&D［インターネットマガジン バックナンバーアーカイブ］ ご利用上の注意
この PDF ファイルは、株式会社インプレス R&D（株式会社インプレスから分割）が 1994 年～2006 年まで発行した月刊誌『インターネットマガジン』の誌面を PDF 化し、「インターネットマガジン バックナンバーアーカイブ」として以下のウェブサイト「All-in-One INTERNET magazine 2.0」で公開しているものです。

http://i.impressRD.jp/bn
このファイルをご利用いただくにあたり、下記の注意事項を必ずお読みください。
z 記載されている内容（技術解説、URL、団体・企業名、商品名、価格、プレゼント募集、アンケートなど）は発行当時のものです。
z 収録されている内容は著作権法上の保護を受けています。著作権はそれぞれの記事の著作者（執筆者、写真の撮影者、イラストの作成者、編集部など）が保持しています。
z 著作者から許諾が得られなかった著作物は収録されていない場合があります。
z このファイルやその内容を改変したり、商用を目的として再利用することはできません。あくまで個人や企業の非商用利用での閲覧、複製、送信に限られます。
z 収録されている内容を何らかの媒体に引用としてご利用する際は、出典として媒体名および月号、該当ページ番号、発行元（株式会社インプレス R&D）、コピーライトなどの情報をご明記ください。
z オリジナルの雑誌の発行時点では、株式会社インプレス R&D（当時は株式会社インプレス）と著作権者は内容が正確なものであるように最大限に努めましたが、すべての情報が完全に正確であることは保証できません。このファイルの内容に起因する直接的および間接的な損害に対して、一切の責任を負いません。お客様個人の責任においてご利用ください。

このファイルに関するお問い合わせ先
All-in-One INTERNET magazine 編集部
im-info@impress.co.jp
Copyright © 1994-2007 Impress R&D, an Impress Group company. All rights reserved.