■接続の管理とアプリケーション
　　〜TCP／UDPとIPの関係

　一般に、IPネットワークにおいては、IPというプロトコルはあくまでホスト間のネットワーク接続（正確には一方向のデータ送信）を実現しているにすぎない。これだけでは、通常のアプリケーションがネットワークを利用できるとはいえない。両ホスト上のアプリケーション同士を結び付ける仕組みが必要になる。これがTCPやUDPの役割だ。

　普通「ネットワーク接続」といった場合には、実際にはTCPやUDPレベルにおける「アプリケーション間接続^＊1」を意味している。単に、どのホストと通信しているかというIPレベルのみならず、アプリケーションが別のどのホストのアプリケーションと接続を維持しているかという、TCP／UDPレベルでの「ステータス」を把握することは、ネットワーク管理上、大変重要な要素となる。

　netstatコマンドでは、これら現在ホストが実行している接続の一覧とともに、それぞれのステータスを確認することができる。

図1　TCP／UDPとアプリケーションの関係

　TCPとUDPの役割について少し整理しておこう。各アプリケーションを区別するために使用されるのが「TCP／UDPポート番号」だ。例えば、クライアントがあるアプリケーションに接続する場合には、何番のポートを使用して相手が待ち受けている（ポートをオープンしている）かを指定して接続することになる。つまり、少なくとも一方が事前にそのポート番号で待ち受けている必要がある。通常、これが「サーバ」アプリケーションとなる。この待ち受け状態を「LISTEN」と呼ぶ。LISTENしているアプリケーションがネットワーク通信を管理するOSに対して「このポート番号へのパケット・データは、私に渡してほしい」と依頼し、起動している状態だ^＊2。

　一方、接続する側、つまり「クライアント」も自身に何らかのポート番号を割り振ってネットワーク接続することになる。でなければ、逆にサーバ・プログラムからクライアント・プログラムへアプリケーションを指定してのパケット返信ができないからだ。この関連付けも、やはりOSのネットワーク機能が管理する。

　これが、TCPとUDPにおける「仮想チャネル」の基本的な考え方だ。こうした機能により、アプリケーションはポート番号を指定するだけで、特定のアプリケーションとシームレスに通信が可能になる。

　さらにTCPでは、

• コネクション指向
• バイト・ストリーム指向
• 全二重通信

をサポートしている。

　接続の両端において、コネクションの「開始」と「切断」を行って接続を維持しており、複数のパケットの送受信はそのコネクション内で自由に行える。アプリケーションから巨大なデータ送受信を指示されても、自動的に分割／送信して受信後に組み立てられるので、アプリケーションは実際のパケット構造を気にしなくてもいい。「全二重通信」とは、常に双方向のパケットの送受信が可能ということだ。つまりTCPでは、IP接続を2つ利用してこうした双方向チャネルを実現するのである。

　また、パケット・ロス時における再送機能や軋轢（あつれき）制御機能によって、IPだけでは得られない送受信データの信頼性も確保している。こうした特徴から、HTTPやSMTPなど、クライアント／サーバ・モデルと呼ばれる比較的高度なネットワーク通信のほとんどは、TCPで実装されることが多い。

　一方、UDPは、単にIPにポート番号の概念を加えただけのプロトコルだ。アプリケーションとの関連付けのみが行われると思っていい。

　UDPは、アプリケーションがUDPパケットに含まれるデータを意識しなくてはならない「パケット指向」型のサービスである。大きなデータの場合は、意識して複数パケットに分割して送信を行う必要がある。IPが提供する以上の信頼性も保証されない。アプリケーションから見ると扱いも面倒だが、パフォーマンスには優れているので、単にデータを送り付ければいいような単純な通信には向いている。現在では、DNS／SNMP／DHCP／FTPのデータコネクションなどで使用されることが多い。

　また、TCPは必然的にユニキャスト（ピア・ツー・ピアの一対一通信）が前提になるが、UDPではブロードキャスト／マルチキャストなどの一対多の送信用として使用されることも多い。

■TCP接続とステータス

　UDPでは、単にポート番号（とIPレベルでのIPアドレス）を指定したパケットを相手に送り届けるだけで、片方向の1パケットの送信のみで通信が完結する。ここには、接続の開始や終了という概念はない。つまり、UDPでは単にパケットを送っているか送っていないかというだけで、「ステータス」という概念は存在していない。

　TCPはより複雑で、「ネゴシエーション」と呼ばれる接続開始のための交渉を行い、コネクションを確立して通信が開始される。このネゴシエーションによって、通信バッファやパケットのサイズが決定される。そして実際の通信が行われた後、やはりネゴシエーションによって互いに認識し合ったうえで切断が行われる。つまりTCP通信においては、常にOSによって接続の現在のステータスが把握され、フローが制御されることになる。

図2　TCP接続開始の遷移。青い矢印が1つのTCPパケットを、矢印の上の文字が使用されるTCPフラグである。接続は、双方向同時に行われる

図3　TCP切断の遷移。ここではクライアントからの切断要求を示しているが、実際にはどちらから行われてもかまわない。先に切断する側を「Active Close」、後を「Passive Close」側と呼ぶ

　TCPの接続開始は「3ウェイ・ハンドシェイク」などと呼ばれる。3つのパケットの送信（つまり「握手」）によって接続が確立される特徴を表している。切断においては「2ウェイ」である。切断したい側からFINパケットを送信し、切断を了解した意味のACKパケットを受信すると切断が完了する。

　気を付けてほしいのは、この切断は2回行われる必要があるという点だ。TCPは全二重の通信であり、コネクションはそれぞれ双方向に行われていると認識されるためだ。つまり接続開始時点では、他方から他方への両方向の接続（「クライアント→サーバ」と「サーバ→クライアント」）があると見なされる。しかし切断は個別に行われるため、それぞれの方向ごとに切断が必要となる。

　逆をいえば、片方向が切断されても他方で通信し続けても構わないことを意味する（例えば「クライアント→サーバ」の送信のみなど）。非常に柔軟な要請にも対処可能なプロトコル設計となっている。双方向のコネクションのうち、「クライアント→サーバ」接続（能動的接続）を「Activeコネクション」、「サーバ→クライアント」接続（受動的接続）を「Passiveコネクション」と呼ぶ。

　TCPでは、コネクションはこれらいずれかのステータスに必ず属することになる。単に接続通信中（ESTABLISHED）のみだけでなく、それぞれのコネクションがどのステータスにあるのかも、ネットワーク調査をするうえでの重要な要素となる。

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

　本企画では、各種コマンド／ツール紹介やそれらを活用したTipsを順次追加、各種索引を用意して、読者の方々に手軽にご利用いただける、便利なリソース集としてアップデートしていく予定です。ぜひご期待ください。