なぜポート番号はそう割り当てられているか

結論 — なぜそうなったのか

横にスクロール

ポート番号の割り当てには、実は技術的な必然がほとんどありません。HTTP が 80 番で SSH が 22 番なのは、それらの番号が処理上優れているからではなく、共有された番号空間を1つの権威が台帳で管理し、申請された順に固定していったからです。異なる組織のソフトが同じ IP 上で衝突せずに出会うには、「この番号はこのサービス」という合意が世界で1つに定まっている必要があります。その合意台帳を初期は Jon Postel が個人で、現在は IANA が IETF の公式手続き（RFC 6335）に沿って維持しています。番号の3区分と特権ポートの権限要件は、いずれもこの「共有名前空間をどう統制するか」という問いへの答えとして生まれました。

当時の状況と競合 — 何が問題だったか

ARPANET から TCP/IP へ移る初期、根本の課題はランデブー問題でした。クライアントは、まだ会話していない相手のサーバーに、事前の打ち合わせなしで接続しなければなりません。「どの番号を叩けばそのサービスに届くか」を全員が同じに知っている必要があります。

考えうる選択肢は複数ありました。

初期インターネットが採ったのは3つ目です。RFC 322（1972）が使用中ソケットの申告を促し、その系譜が Assigned Numbers（RFC 1340 / RFC 1700 など、Reynolds と Postel による一連の文書）に結実します。番号は思想ではなく台帳の1行として、申請順に確定していきました。だからこそ番号の並びは体系的でなく、歴史の順序を化石のように残しています。

決定打・経緯 — 何が勝敗を分けたか

体系を1つに束ねた決定打は単一の権威と3層の区分でした。長らく Jon Postel が Assigned Numbers を事実上一人で編集し（彼の没後は組織としての IANA が継承）、番号空間は次の3範囲に整理されます。

この3区分は現在 RFC 6335（2011） が IETF の Best Current Practice として明文化しています。設計上の要は分業です。0〜1023 は「世界で1つのサービス」を厳格審査で固定し、1024〜49151 は緩やかに登録を受け付け、49152〜65535 は誰の許可も要らない私的領域として、クライアントが接続ごとに使い捨てる送信元ポートに充てます。実務で netstat を眺めると、待ち受けは若い番号、能動接続の送信元は 49152 以上、という住み分けが見えるはずです。

もう1つの決定打が、0〜1023 を 特権ポートとした BSD の判断でした。4.2BSD 系は、1024 未満の番号で待ち受けるには管理者（root）権限を要求しました。狙いは当時の信頼モデルにあります。rlogin / rsh などの r 系コマンドは、相手が 1024 未満の送信元ポートから来たことを「root 権限を持つ正規プロセスが送ったもの」と見なし、ホスト間の弱い認証材料に使っていました。一般ユーザーが特権ポートを名乗れないという制約こそが、この保証を成立させていたのです。

今への影響と教訓 — 現在どう効いているか

この設計は今も静かに効いています。ブラウザが example.com と打つだけで 443 に届くのは、番号が世界で1つに固定されているからです。コンテナやクラウドネイティブ環境では、非 root で 80/443 を開けない特権ポート制約が運用の摩擦になり、Linux の CAP_NET_BIND_SERVICE ケイパビリティ付与や、リバースプロキシ／ロードバランサでの終端、net.ipv4.ip_unprivileged_port_start の調整といった回避策が定石になりました。制約が新しい設計を生んでいるわけです。名前とポートの正式な対応関係は各プロトコルの仕様（ネットワーク）に、80/443 上で動く実体は Web に、特権と権限分離の一般原則は OS と セキュリティ にそれぞれつながります。

一段で言うと

ポート番号がそう割り当てられているのは、優れたアルゴリズムの帰結ではなく、共有された番号空間を1つの権威が台帳で統制するという統治上の選択の帰結です。番号の並びは申請の歴史を、特権ポートの権限要件は当時の信頼モデルを、それぞれ化石として保存しています。ここから学べる普遍の原則は1つ——複数の当事者が同じ資源を奪い合う共有名前空間は、権威ある統制と明確な区分がなければ衝突と偽装で崩れる、ということです。