端末（スマホ・PC）— 通信の出発点

中級の「アプリは直接ネットに触れない」を、上級では接続を見分ける単位まで下ろします。端末が始点/終点として成り立つのは、1台の中で複数の通信を混ぜずにさばく仕組みがあるからです。

1. アプリはOSにソケット※1 を作ってもらい、その口を通してのみ送受信する
2. 送信時、OSは宛先IPと宛先ポートに加え、送信元ポートを1つ選んで結びつける
3. OSは1本の接続を、送信元IP・送信元ポート・宛先IP・宛先ポートの4つ組※2 として管理する
4. 返ってきたパケットは、この4つ組の一致で「どのソケット宛か」が一意に決まる。だからタブを何枚開いても、同じサーバの443宛でも、返事が混ざらない

ポート番号が「どのアプリ宛か」を示すのは中級どおりですが、上級の要点は宛先ポートだけでは足りないこと。同じ相手・同じ宛先ポートへ複数つなぐ場面では、送信元ポートの違いが接続を分けています。

登場人物メモ（※の説明）:

• ※1 ソケット — アプリとOSのネットワークスタックをつなぐ抽象的な口。ファイルのように読み書きの対象として扱える
• ※2 4つ組 — 送信元IP・送信元ポート・宛先IP・宛先ポートの組。TCP接続を一意に識別する鍵。ここにプロトコル種別を足して「5つ組」と呼ぶこともある

⚠️ イレギュラー（仕分けの綻び）:

• 待ち受け側と接続側でポートの意味が違う — サーバはよく知られたポート（443など）で待ち受けて固定、クライアントは接続のたびに一時ポートを借りる。同じ「ポート」でも役割が逆
• 同じポートを複数プロセスで待ち受ける — 通常は1つのポートは1プロセスだが、負荷分散のため明示的に共有する設定（ポート再利用）も存在する

中級では住所としてIPとMACを区別しました。上級では、端末がその住所を実際にどう受け取り、何種類抱えているかを見ます。始点/終点であるには、まず自分の住所が要ります。

1. 端末は起動・接続直後、まだ自分のIPを持たない。そこでDHCP※1 で「住所をください」と同一リンク内に問い合わせる
2. DHCPサーバ（多くは家庭用ルーター）が、IPアドレス・サブネット・デフォルトゲートウェイ・DNSサーバの場所をまとめて貸し出す（リース※2、期限付き）
3. いまどきの端末はIPv4とIPv6を同時に持つ（デュアルスタック）。IPv6はDHCPv6やルーター広告（RA）で受け取ることが多い
4. どちらの系統でも、外に出られる住所とは別に、同一リンク内だけで使うリンクローカルアドレス※3 を必ず1つ持つ

つまり端末は「1台に1つのIP」ではなく、用途の違う住所を複数抱えています。宛先が両対応なら、IPv6とIPv4を並行して試して先につながったほうを使う（Happy Eyeballs）挙動も普通です。

登場人物メモ（※の説明）:

• ※1 DHCP — 起動時にIP等の設定一式を自動で貸し出す仕組み。手動設定（静的IP）を選ぶこともできる
• ※2 リース — DHCPで借りた住所には期限があり、使い続けるには更新（リニュー）が要る。期限切れやネットワーク移動で住所は変わりうる
• ※3 リンクローカルアドレス — 同一リンク内だけで有効な住所（IPv6ならfe80::、IPv4なら169.254.x.x）。ルーターを越えられず、外の宛先には届かない

⚠️ イレギュラー（住所取得のつまずき）:

• DHCPに応答がない — 住所が取れず、端末が苦し紛れにリンクローカル（169.254.x.x）を自己割り当てする。ネットは見えないのに「IPはある」状態になり、原因が見えにくい
• IPv6は通るがIPv4だけ不調（またはその逆） — デュアルスタックゆえ、片系統だけの不調で「一部サイトだけ遅い／開かない」が起きうる

家庭やオフィスの端末の多くは、プライベートIPしか持ちません。始点/終点でありながら、外の世界には自分の顔で立っていない——この非対称が上級の勘所です。

1. 端末が持つのは192.168.x.xなどのプライベートIPだけ。これは組織の中でだけ通じる住所
2. 外向きにパケットが出る瞬間、途中のNAT機器（多くは家庭用ルーター）が送信元を1つのグローバルIPへ書き換える
3. NAT機器は「どの内部端末のどのポートを、外向けのどのポートに対応させたか」を変換表に控える。だから返事が来たら正しい端末へ戻せる
4. 結果、複数の端末が1つのグローバルIPを共有して外と話す。外のサーバから見えるのは、その共有された1つの顔だけ

だから端末自身のOSに聞いても、自分のグローバルIPは分からない。変換は端末の外で起きているからです。知りたければ外部に「私はどう見えている？」と尋ねる（後述のSTUNや確認用Webサービス）しかありません。

登場人物メモ（※の説明）:

• ※1 プライベートIP — 組織内でだけ使う住所（10.x / 172.16〜31.x / 192.168.x）。そのままではインターネットに出られない
• ※2 変換表 — NAT機器が持つ、内部アドレス・ポートと外向けポートの対応表。接続ごとのエントリで、一定時間使われないと消える

⚠️ イレギュラー（共有ゆえの制約）:

• 外から自発的に呼べない — 変換表は基本、内から外へ出た通信の折り返ししか通さない。外から端末を名指しで呼び出すには、明示的な穴あけ（ポート転送）などが要る
• 共有の道連れ — 同じグローバルIPを共有する誰かが乱暴な通信をすると、IP単位の制限（レート制限・ブロック）に巻き込まれることがある

より詳しいアドレス共有とポートの割り当ては NATとポート を参照。

最後に、始点/終点という立場ゆえに端末が突き当たる構造的な限界を整理します。中級の不調（DHCP・DNS・機内モード）に加え、上級では数の限界と移動の限界を押さえます。

• ポート枯渇 — クライアントの送信元に使える一時ポートは範囲が有限（おおむね49152〜65535あたり、OSで異なる）。同じ宛先へ短時間に大量の接続を張ると使い切り、閉じた直後のTIME_WAITで当分再利用もできず、新規接続が張れなくなる。接続の使い回し（keep-alive）や接続数の抑制で緩和する
• NAT越えの難しさ — 両端がNATの内側にいると、互いを直接名指しで呼べない。P2Pや通話では、まず外部のSTUN※1 サーバに自分の見え方（グローバルIPとポート）を教えてもらい、双方が同時に外へ穴を開けて出会う。それでも越えられない構成では中継サーバ（TURN）を挟む
• モバイルでのIP変化 — Wi-Fiから4G/5Gへ切り替わると、端末のIPやNATの外向きアドレスは変わる。従来のTCP接続は本来切れるが、アプリ側の再接続・バッファやQUICのコネクション移行で、上位が継続性を作り込んで途切れを隠している
• 住所の使い回しによる誤認 — DHCPのリース満了やNAT共有で、同じIPが時間差で別の端末を指す。IPを「個人の固定ID」と思い込むと、アクセス制限やログの突合を誤る

登場人物メモ（※の説明）:

• ※1 STUN — NAT内の端末が、自分の外向きの見え方（グローバルIPとポート）を外部サーバに教えてもらう仕組み。NAT越えの下準備に使う

まとめ——端末は通信の始点/終点であるがゆえに、内側ではソケットとポート（4つ組）で通信を混ぜずにさばき、外側ではもらい物の住所（DHCP）と借り物の顔（NAT共有）で世界に立っています。速さも到達性も、この「端っこであること」の上に成り立ち、そしてポートの数と住所の移ろいという限界も、すべて同じ端点の立場から生まれています。ここまで見えれば、中継・アドレス体系・NATの各ユニットは、この端点を支える外側の仕組みとして読み直せるはずです。