※この記事は『インターネットマガジン2005年4月号』（2005年2月28日発売）に掲載されたものです。文中に出てくる社名、サービス名、その他の情報は当時のものです。

 

本質的問題は今も変わらない

――TCP/IP はコンピュータ間の通信プロトコルにとどまらず、我々の生活のさまざまな部分に適用されようとしています。TCP/IP に求められることに関し、開発当時と現在で、何か違いを感じることはありますか。

●TCP 開発の最初の目標は、複数のネットワークで構成されるネットワーク上で、信頼性のある通信を確保する方法を見つけることでした。このため、パケットの重複受信、パケットの断片化、情報の再構成などの問題に対処する必要がありました。統一的なアドレスづけ（グローバルアドレッシング）の考え方もIP アドレスという形で組み込みました。

これらの要素はすべて当初の設計に組み込まれていますし、現在でもこれらが基本要件であることにはまったく変わりがありません。インターネット環境における通信を扱うかぎり、当時とまったく同一の問題に対処していかなければならないと思います。

――放送分野などの人は、インターネットが「ベストエフォート」という考え方に立っていることに拒絶反応を示します。こうした反応をどう思いますか。

●そういう人たちは、絶対的な保証が欲しいとでも言うのでしょうか。では核戦争が起きたらどうしますか。太陽の黒点の影響によって通信が妨害されたら？「ベスト」の努力に勝る努力をすることは不可能です。これはTCP の問題ではなく、それぞれのパケットネットワークやその集合体がどのように実装されているかという問題です。コーディングや再送信の機能を強化したいと考える人はいるでしょう。それは今のプロトコルの枠内で実現できることなのです。

アプリケーションとTCP の間の問題

――しかし、インターネットは信頼性に欠けると考えている人はたくさんいます。

●パケットスイッチングを初めて見た人たちは、よくそう言っていました。彼らは、回線交換なら自動的に伝送が保証されるかのような前提に基づいて、「回線交換でないなら使いものにならない」と言ったのです。しかし、これは長い1 つの回路を確立することと、複数の短い回路を確立することのどちらを選択するかという問題です。

最終的には伝送路の品質次第なのです。遅延が大きすぎてデータが使いものにならないというなら、帯域を広げたり、中継点を減らしたり、バッファリングを調整したりするなど、ネットワークを再設計して遅延を減らさなければなりません。つまり、提供したいサービスに応じた伝送路の設計をすべきだということです。

――現在、高速ネットワークにおけるTCP/IP の性能の限界が指摘されています。たとえばインターネットのバックボーンなど、10Gbps といった高帯域の伝送に対応するため、ウィンドウサイズ（注1）を広げる改善がなされていますが、ほかによい対処方法はないのでしょうか。

注1 ウィンドウサイズ
TCP は、受信側からの確認応答（ACK）を受けながらデータを送信することで、送信の信頼性を確保している。「ウィンドウサイズ」とは、この確認応答を受ける前に送るパケットの量のこと。ウィンドウサイズを増加させれば転送速度が上がり、効率が上がるが、いったん再送しなければならない事態に陥った場合、再送しなければならないデータの量も大きくなるので、転送効率が低下してしまうという問題がある。

●たしかに帯域が広がれば、ウィンドウサイズを広げたとしても、再送信の際に大量のデータを送らねばならず、その際に性能が低下します。対策としては、何らかのエラー制御チャンネルを構築して伝送路の信頼性を高めること、そして同時に、アプリケーションが、再送信メカニズムを選択的に利用できるようにすることだと思います。

広帯域下で音声トラフィックを扱う場合、1 つのパケットがなくなったからと言ってたいした問題は生じません。特に、どこかでいったんファイル化してから聞くようなやり方をとるなら、一部のパケットが失われたとしても、再送信を待ってファイルに取り込んでから聞かせることができます。

もし伝送路が非常に不安定ならば、信頼性を大幅に向上させるために、コーディングを工夫しなければならないでしょう。そのうえで、それぞれのアプリケーションが、自分の望む形でパケットの制御をすればいいのです。

たとえば、データを受信してディスプレイに表示するアプリケーションで、パケットがまったくおかしな順番で届いたとしましょう。一般的なTCP の実装では、こうしたパケットはすべて正しい順序に並び替えられなければ表示されません。しかし、パケットが十分な速さで送られてきているなら、ランダムな順序でディスプレイに表示しても、ユーザーは問題なく見ることができるはずです。

つまり、焦点はアプリケーションが何であるか、そして適切な肯定応答やバッファリングなどを行うために、受信者側において、TCP とアプリケーションとの間で、どのようなやり取りが行えるかということになると思います。

――TCP の構成要素であるシーケンス番号（注2）に関するセキュリティが問題となりました。これについては、何か抜本的な解決方法があると考えていますか。

注2 シーケンス番号
TCP では、パケットの順番を特定し、受信側での再構成を可能にするために、特定のデータの流れにおける位置を示す情報を各パケットに埋め込んで送信することになっている。これを「シーケンス番号」という。このシーケンス番号を推測し、TCP コネクションを乗っ取ることで不正なパケットを送りつける攻撃が表面化したことがある。これについてはシーケンス番号の生成方法を変更するなどの対策がとられた。

●それを言うなら、通信事業者は通信路を遮断することまでできてしまいます。つまり、通信事業者を利用すること自体がセキュリティー上の問題を生むと言えなくもありません。しかし、どんなシステムであっても、利用していくかぎり、どこかに信頼を置かなければなりません。シーケンス番号だけが特別なセキュリティー上の問題を生じるわけではないと思います。通信事業者は、シーケンス番号などを使わずに、もっと大きなセキュリティー上の問題を起こすことができます。

衛星を使ったパケット通信を始めた頃、同様な質問を受けたことがあります。誰かが、「これは非常に脆弱なのではないだろうか。誰かが妨害できる可能性がある」と質問したのです。これに対して我々は、「それはパケットかどうかとは関係なく発生する問題だ」と答えました。

あるとき、軌道上で回転してしまう衛星との通信を試したことがあります。このとき、回線交換の仕組みでは、衛星のアンテナが回転によって地球から見えなくなるたびに通信が切れたわけですが、パケット通信では、衛星のアンテナが地球を向いている瞬間に、タイミングを計ってデータを送ることにより、信頼性の高い通信を実現できたのです。

TCP はあらゆるアプリケーションを支えるプロトコルにしたかった

――TCP/IP の開発プロセスを振り返って、違うやり方もあったなと思うことがあるとすれば、それは何ですか？

●まず、もっと迅速に開発を進められればよかったと思います。そうすれば、今頃もっと先のことが見えていたでしょうから。

もう1 つはアドレスの数に関する点です。我々は当時、現在とはまったく違った環境にいました。現在の貨幣価値で言えば、数千万ドルもするようなコンピュータしかなかったのです。1973 年にインターネットを始めたとき、我々はアドレスフィールドを32 ビットと決めましたが、これで永遠に十分だろうと考えました。

32 ビットのうち8 ビットをネットークの識別に当てて、残りの24 ビットをホストコンピュータのアドレスとして割り当てることにしました。8 ビットでは256 のネットワークを識別できます。当時私は世界中で多分6から12くらいのネットワークが生まれるく思います。通信事業者は、シーケンス番号などを使わずに、もっと大きなセキュリティー上の問題を起こすことができます。

衛星を使ったパケット通信を始めた頃、同様な質問を受けたことがあります。誰かが、「これは非常に脆弱なのではないだろうか。誰かが妨害できる可能性がある」と質問したのです。これに対して我々は、「それはパケットかどうかとは関係なく発生する問題だ」と答えました。

あるとき、軌道上で回転してしまう衛星との通信を試したことがあります。このとき、回線交換の仕組みでは、衛星のアンテナが回転によって地球から見えなくなるたびに通信が切れたわけですが、パケット通信では、衛星のアンテナが地球を向いている瞬間に、タイミングを計ってデータを送ることにより、信頼性の高い通信を実現できたのです。

TCP はあらゆるアプリケーションを支えるプロトコルにしたかった

――TCP/IP の開発プロセスを振り返って、違うやり方もあったなと思うことがあるとすれば、それは何ですか？

●まず、もっと迅速に開発を進められればよかったと思います。そうすれば、今頃もっと先のことが見えていたでしょうから。

もう1 つはアドレスの数に関する点です。我々は当時、現在とはまったく違った環境にいました。現在の貨幣価値で言えば、数千万ドルもするようなコンピュータしかなかったのです。1973 年にインターネットを始めたとき、我々はアドレスフィールドを32 ビットと決めましたが、これで永遠に十分だろうと考えました。

32 ビットのうち8 ビットをネットークの識別に当てて、残りの24 ビットをホストコンピュータのアドレスとして割り当てることにしました。8 ビットでは256 のネットワークを識別できます。当時私は世界中で多分6から12くらいのネットワークが生まれるくらいだろうと考えていましたから、256 は途方もない数字だったのです。

振り返れば、最初から128 ビット、あるいは少なくとも64 ビットで始めればよかったと思います。ただ、当時は帯域が狭すぎて、ヘッダーサイズを広く取ると回線効率が大幅に低下するという問題がありました。

また、急いで結果を示す必要がなく、技術を実証してみせる前にたとえば10年間を開発に費やせたとしたら、セキュリティー関連の問題にもっと時間を割いたと思います。特に認証に関しては、現在大きな問題になっていることを認識しています。しかし、当時セキュリティーに本格的に取り組んだとしたら、それが大幅な遅れにつながったでしょうし、多分TCP の技術を実証してみせるまでに至らなかったと思っています。

もう1 つ付け加えるならば、TCP はあらゆるアプリケーションを支えるプロトコルとして利用していくことが可能でしたが、実際にはそうなりませんでした。私がヴィント・サーフと共同で書いた論文は、TCP をバーチャルサーキット（注3）としての実装に限定していたわけではありません。

注3 バーチャルサーキット
TCP では、送信者と受信者が特定のデータの流れを識別し、仮想的な経路として管理する仕組みが用意されている。これを「バーチャルサーキット」と呼ぶ。具体的には、各パケットに送信アドレスと送信ポート、受信アドレスと受信ポートの情報が組み込まれており、これによって一続きのパケットの流れ（フロー）が識別され、このフローを単位として全パケットを確実に送り届ける作業が行われる。カーン氏がここで話しているのは、当初の論文では、パケットが喪失した場合に再送によって必ずその到達を保証することだけを目的としていたわけではないということである。

私は、後のUDP (User DatagramProtocol)と同じことがTCP の枠内でできると思っていました。アプリケーション側が確認応答（ACK）のやり方やバッファリング、再送信などに関する指示を出せるようにすればいいと思っていたのです。T C P が実装においてバーチャルサーキットと同義になってしまったのは、当時バーチャルサーキットを実現することに関するニーズが強く、これが定着してしまったからです。このため、後でUDP を付け加えなければならなくなったのです。

自分の直感を信じよ

――これからのネットワーク化社会を担っていく若い人たちに伝えたいと思うメッセージは何でしょうか。

●グローバルな情報社会が将来どのようなものになっていくのか、我々はまだその入り口に立っているだけだと思います。今我々が使っているコンピュータと20 年前のそれを比べるだけで、どんな変化が起こりうるかが分かると思います。ですから、皆さんには勇気と確信を持って行動していただきたいと考えています。

私がネットワーク分野に飛び込んだとき、先輩たちは、私が自分のキャリアを無にしようとしていると言いました。当時は巨大なバッチ処理機の時代でしたから、相互通信などはあまり求められていなかったのです。電算処理センターのスタッフで、通信をやりたいと思う人はほとんどいませんでした。しかし私はあえてこの道を選び、5 年、10 年と経つにつれて自分のしたことが大きな進歩につながりました。私は自分の直感を信じたのです。

ですから、今の環境が今後永遠に続くと思い込むことはありません。他の人が、自分の直感と違うことを言ったとしても、信じる必要はないのです。