TCP/IP — 階層モデルとポート
https://example.com と入力してからページが表示されるまでに、いくつもの層が働いています。ドメイン名を IP アドレスに変える。経路を選ぶ。パケットを分割し、順序を揃え、欠けたら再送する。
これらを 1 つのプログラムで面倒みるのは現実的ではありません。TCP/IP は役割ごとに層を分けて、上の層が下の層の詳細を知らずに済むようにした設計です。
この章で学ぶこと
- 階層に分ける理由と、TCP/IP の 4 層モデル
- IP・TCP・UDP の役割分担
- ポート番号の 3 つの範囲と、サーバー側とクライアント側の違い
- 独自プロトコルを作るときに IANA への登録が要るのかどうか
特にありません。ブラウザで Web サイトを見た経験があれば読めます。
階層に分ける
TCP/IP は 4 つの層で構成されます。OSI 参照モデルの 7 層と対応させると次のようになります。
| TCP/IP | OSI | 担当 | 代表的なもの |
|---|---|---|---|
| アプリケーション層 | 5〜7 (セッション・プレゼンテーション・アプリケーション) | やり取りする内容 | HTTP、DNS、SMTP |
| トランスポート層 | 4 (トランスポート) | どう届けるか | TCP、UDP |
| インターネット層 | 3 (ネットワーク) | どこへ届けるか | IP、ICMP |
| リンク層 | 1〜2 (物理・データリンク) | 隣の機器へ渡す | Ethernet、Wi-Fi |
**各層は自分の下の層に「運ぶこと」を任せます。**HTTP を書く人はパケットの分割や再送を意識しません。TCP を実装する人は電波か光ファイバーかを気にしません。この分業が、異なる技術を組み合わせられる柔軟さの源です。
OSI 参照モデルは 7 層ですが、実務では TCP/IP の 4 層で語ることが多くなります。ロードバランサーを「L7」「L4」と呼ぶときの数字は OSI の層番号で、L7 は HTTP の中身を見て振り分ける、L4 は TCP のポート番号だけで振り分ける、という区別を指しています。クラウドでの実例は AWS 実践ガイド — ALB が扱っています。ロードバランサーが複数のサーバーへどう配るかは スケールの方向 で扱います。
IP — どこへ届けるか
IP (Internet Protocol) が担うのは宛先の指定と経路の選択です。パケットに送信元と宛先の IP アドレスを付けて、ルーターがそれを見て次の転送先を選びます。
IP には保証がありません。
- パケットが失われることがある
- 順序が入れ替わることがある
- 重複して届くことがある
「できるだけ届ける」という約束だけです (ベストエフォート)。この割り切りが、ネットワークの規模を大きくできた理由でもあります。
TCP と UDP — どう届けるか
IP の上に乗って、届け方を決めるのがトランスポート層です。
| TCP | UDP | |
|---|---|---|
| 接続 | あり (事前に確立する) | なし |
| 到達保証 | あり (再送する) | なし |
| 順序保証 | あり | なし |
| 速さ | 相対的に遅い | 速い |
| 用途 | Web、メール、ファイル転送 | 動画配信、音声通話、DNS の問い合わせ |
TCP は通信を始める前に、3 通のメッセージをやり取りして接続を確立します。往復でいえば 1.5 回ぶんです。
これを 3 ウェイハンドシェイクと呼びます。順序番号を交換して、以降のパケットの並べ替えと欠落検出ができるようにする手続きです。
UDP はこの手続きを省きます。届かなくても再送しません。音声通話では、遅れて届いた音より欠けたまま進むほうがましなので、この割り切りが合っています。
ポート番号
IP アドレスは「どの機器か」までしか決めません。1 台の機器では Web サーバーもメールサーバーも動いているので、どのアプリケーションに渡すかを決める番号が要ります。それがポート番号です。
16 ビットなので 0 から 65535 まであり、3 つの範囲に分かれています。
| 範囲 | 名前 | 用途 |
|---|---|---|
| 0 〜 1023 | System Ports (ウェルノウンポート) | IANA が割り当てる。HTTP は 80、HTTPS は 443、SSH は 22 |
| 1024 〜 49151 | User Ports (登録済みポート) | IANA が割り当てる。PostgreSQL の 5432 など |
| 49152 〜 65535 | Dynamic Ports (エフェメラルポート) | **IANA は割り当てない。**その場限りの利用のために確保されている |
サーバーのポートは変わらない
https://www.example.com にアクセスするとき、ブラウザが接続するサーバー側のポートは 443 で固定です。
固定でなければ困ります。クライアントは事前にポートを知っている必要があり、知る手段が無ければ接続できないからです。URL にポートが書かれていない場合、スキームから決まる既定値 (http なら 80、https なら 443) が使われます。
一方で変わるのはクライアント側の送信元ポートです。ブラウザが接続するたびに Dynamic Ports の範囲から空いている番号が割り当てられます。同じサーバーへ複数の接続を張ったときに、応答をどの接続に返すか区別するためです。
クライアント 192.0.2.10:52341 → サーバー 203.0.113.5:443
クライアント 192.0.2.10:52342 → サーバー 203.0.113.5:443
^^^^^ 毎回変わる ^^^ 固定
IANA への登録は任意
独自のプロトコルを作ってポートを使うときに、IANA への申請は必須ではありません。
RFC 6335 は Dynamic Ports (49152-65535) について「ローカルかつ動的な用途のために確保されており、IANA を通じて割り当てることはできない」と定めています。この範囲は登録の対象外です。
IANA の登録簿は相互運用のための仕組みです。「このポートといえばこのサービス」という共通認識を作ることで、衝突を避けて既定値を決めやすくします。社内システムや実験的なプロトコルで、外部と規約を共有する必要が無いなら、登録せずに使って問題ありません。
LAN でも TCP/IP を使う
「TCP/IP はインターネット用のプロトコルで、LAN では別のものを使う」という理解は現在では当てはまりません。家庭やオフィスの LAN も TCP/IP で動いています。
家庭内のプリンタに 192.168.1.20 でアクセスするのも、社内のファイルサーバーに繋ぐのも IP です。192.168.x.x や 10.x.x.x はプライベート IP アドレスと呼ばれる範囲で、インターネットには出て行きませんが、プロトコルとしては同じ TCP/IP です。
歴史的には LAN 専用のプロトコル (IPX/SPX、NetBEUI など) が使われた時期がありましたが、現在ほぼ見かけません。同じプロトコルで LAN もインターネットも扱えることが、TCP/IP が広く使われた理由の 1 つです。
HTTP との関係
HTTP はアプリケーション層のプロトコルで、下のトランスポート層に運んでもらいます。
| トランスポート層 | |
|---|---|
| HTTP/1.1 | TCP |
| HTTP/2 | TCP |
| HTTP/3 | UDP (QUIC の上) |
HTTP/1.1 と HTTP/2 は TCP の上で動きます。HTTP/1 が TCP/IP を利用したプロトコルであるという理解は正しいです。
HTTP/3 は例外で、UDP の上に QUIC という層を置いて、そこで再送や順序を制御します。TCP の接続確立の往復を減らし、パケットが 1 つ落ちたときに他のストリームまで止まる問題を避けるための設計です。往復が減るのは QUIC が TLS 1.3 を接続確立に統合しているためで、暗号化を省いたからではありません。
よくある誤解
「ポート番号はサーバー側だけの話」 — 接続には両端のポートが要ります。サーバー側は 443 のように決まった番号で待ち受けますが、クライアント側は接続のたびに OS が空いている番号を割り当てます。同じサーバーへ何本も接続を張れるのは、この送信元ポートが接続ごとに違うからです。
「独自プロトコルを作るなら IANA への申請が必須」 — 任意です。RFC 6335 は Dynamic Ports (49152-65535) を「ローカルかつ動的な用途のために確保されており、IANA を通じて割り当てることはできない」と定めています。登録簿は相互運用のための仕組みであって、義務ではありません。
「TCP/IP はインターネット専用で、LAN では使わない」 — LAN でも使います。プライベート IP アドレスの範囲を使うだけで、プロトコルは同じです。
「HTTP はすべて TCP の上で動く」 — HTTP/3 は UDP の上の QUIC で動きます。HTTP/1.1 と HTTP/2 は TCP です。
「UDP は TCP の劣化版」 — 目的が違います。到達保証を捨てることで遅延を抑えるので、リアルタイム性が優先される用途では UDP のほうが適切です。
確認問題
問 1. 同じサーバーの同じページを 2 つのタブで同時に開きました。2 本の TCP 接続は何によって区別されますか。
答え: クライアント側の送信元ポート番号
TCP 接続は「送信元 IP・送信元ポート・宛先 IP・宛先ポート」の 4 つの組で識別されます。同じサーバーの同じサービスへ繋ぐので、宛先 IP と宛先ポート (443) は両方とも同じです。送信元 IP も同じ端末なので同じです。
違うのは送信元ポートだけで、OS が Dynamic Ports の範囲から接続ごとに別の番号を割り当てます。
接続 1: 192.0.2.10:52341 → 203.0.113.5:443
接続 2: 192.0.2.10:52342 → 203.0.113.5:443
「サーバー側が接続ごとに別のポートを開ける」という仕組みではありません。サーバーは 443 で待ち受け続けます。
問 2. 社内向けの独自プロトコルを TCP の上に作ります。ポート 9500 を使いたいのですが、IANA へ申請が必要ですか。
答え: 必要ありません。
IANA の登録簿は、外部と「このポートといえばこのサービス」という共通認識を作るための仕組みです。社内で閉じたプロトコルなら、規約を共有する相手が社内だけなので登録の意味がありません。
ただし 9500 は User Ports (1024-49151) の範囲なので、既に他のサービスが使っている可能性があります。実際に使う前に登録簿を確認し、同じ機器上で動く他のソフトウェアと衝突しないかを見ておくと安全です。
衝突を確実に避けたいなら、設定で変更できるようにしておくのが実用的です。
問 3. 次のうち UDP が適しているのはどれですか。
A. 銀行の振込処理
B. オンライン会議の音声
C. ソフトウェアのダウンロード
D. DNS の問い合わせ
答え: B と D
| 適するプロトコル | 理由 | |
|---|---|---|
| A 振込処理 | TCP | 1 バイトも欠けてはいけない。順序も保証が要る |
| B 音声 | UDP | 遅れて届いた音は使えない。少し欠けても会話は成立する |
| C ダウンロード | TCP | ファイルが壊れる。到達保証が必須 |
| D DNS 問い合わせ | UDP | 問い合わせと応答が 1 往復で済む。TCP だと接続確立のぶんが上乗せされ、割に合わない |
判断の軸は「欠けたら困るか」と「遅れたら困るか」です。欠けたら困るなら TCP、遅れたら困るなら UDP、という整理になります。
なお DNS は応答が大きい場合 (512 バイトを超えるなど) には TCP へ切り替えます。UDP 固定ではありません。
まとめ
- TCP/IP は 4 層に分かれ、各層は下の層に運搬を任せます。OSI 参照モデルの 7 層と対応します
- IP は宛先と経路を決めますが、到達も順序も保証しません
- TCP は 3 ウェイハンドシェイクで接続を確立し、再送と並べ替えで信頼性を作ります。UDP はそれを省いて速さを取ります
- ポートは 3 範囲。0-1023 と 1024-49151 は IANA が割り当て、49152-65535 は割り当て対象外です
- サーバー側のポートは固定です。接続ごとに変わるのはクライアント側の送信元ポートです
- IANA への登録は任意で、相互運用のための仕組みです
- LAN でも TCP/IP を使います。インターネット専用ではありません
- HTTP/1.1 と HTTP/2 は TCP、HTTP/3 は UDP 上の QUIC で動きます
- AWS 実践ガイド — VPC — IP アドレスと CIDR をクラウドのネットワーク設計で使う
- RFC 6335 — ポート番号の管理手順
次に読む
- DNS — 名前から IP アドレスを引く仕組み