TCP/IP

TCP/IP とは

TCP/IP は、インターネット通信の基盤となるプロトコル群の総称である。TCP (Transmission Control Protocol) がデータの信頼性ある転送を、IP (Internet Protocol) がパケットのルーティングを担当する。2 つの名前を並べて呼ぶのは、中核が別々の層に分かれていて役割が重ならないからである。IP は宛先まで運ぶことだけを引き受け、届いたか・順番が合っているかは面倒を見ない。その面倒を上の層で見るのが TCP で、同じ位置には信頼性を引き受けない UDP も並ぶ。

4 層モデル

この層の分け方は 1989 年 10 月発行の RFC 1122 が定めたもので、リンク層・IP 層・トランスポート層を同文書が、アプリケーション層を対になる RFC 1123 が扱う。

層	プロトコル例	役割
アプリケーション層	HTTP, DNS, SMTP	アプリケーション間の通信
トランスポート層	TCP, UDP	エンドツーエンドの通信制御
インターネット層	IP, ICMP	パケットのルーティング
ネットワークインターフェース層	Ethernet, Wi-Fi	物理的なデータ転送

各層は下の層の中身を知らずに済む。だから有線から無線へ切り替わっても上の層は書き換えずに動く。この分離が設計の要点である。

OSI 参照モデルの 7 層と 1 対 1 で並べる表をよく見かけるが、対応は正確ではない。トランスポート層とインターネット層はおおむね重なる一方、アプリケーション層は OSI の上 3 層をまとめた形で、最下層の切り分け方も揃っていない。層の数と境界が違う体系だと理解しておく方が、実際のプロトコルを読むときに迷わない。

TCP vs UDP

選択の軸は速さそのものではなく、失われたデータをどう扱うかである。

観点	TCP	UDP
信頼性	あり (再送、順序保証)	なし (ベストエフォート)
接続	コネクション型 (3-way handshake)	コネクションレス
速度	中程度 (オーバーヘッドあり)	高速 (オーバーヘッド小)
用途	HTTP, SSH, DB 接続	DNS, リアルタイムの音声・映像通話, ゲーム

動画配信を UDP 側に置きたくなるが、HLS のように HTTP の上で配信する方式が広く使われており、その場合は TCP 側に入る。UDP を選ぶのは、再送を待つくらいなら古いデータを捨てて次を受け取った方が良い場面である。通話で 1 秒前の音声が今届いても価値はない。逆にファイル転送や DB 接続では 1 バイトの欠落も許されないので、TCP に任せる。

3-way ハンドシェイク

TCP はデータを送る前に、両側で初期シーケンス番号を合意する手順を踏む。

クライアント → SYN → サーバー        (接続要求)
クライアント ← SYN+ACK ← サーバー    (要求受理)
クライアント → ACK → サーバー        (接続確立)

この往復にかかる時間は、どこから数えるかで変わる。クライアントから見ると SYN を送って SYN-ACK が返るまでの 1 RTT (Round Trip Time) で接続は使える状態になり、3 通目の ACK は最初のデータと一緒に送れる。サーバーがその ACK を受け取る時点まで数えれば 1.5 RTT である。暗号化を重ねると、TLS 1.3 なら 1 RTT、TLS 1.2 なら 2 RTT がこの上に載る。

HTTP/3 は UDP 上の QUIC を使い、トランスポートと暗号化のハンドシェイクを一体化して初回でも 1 RTT で済ませる。以前つないだ相手には最初のパケットでデータを送り始める 0 RTT の選択肢もあるが、これは同じデータの再送信を防げないため、繰り返し実行されても害のない要求に限って使う。手順そのものの内訳は TCP 3-way ハンドシェイク で扱う。

パケットの流れ

データは送信時に各層でヘッダーが付与され、カプセル化される。アプリケーション層のデータに TCP ヘッダー (ポート番号、シーケンス番号) が付き、さらに IP ヘッダー (送信元・宛先 IP)、Ethernet ヘッダー (MAC アドレス) が付与されて物理層で送信される。受信側は逆順にヘッダーを剥がしてデータを取り出す。ある層のヘッダーは、その下の層にとっては中身を問わない単なるデータである。この入れ子があるから、層ごとに独立して仕様を差し替えられる。

アプリケーション: "Hello" (データ)
    ↓ TCP: セグメントに分割、シーケンス番号付与
    ↓ IP: 送信元/宛先 IP アドレスを付与、パケット化
    ↓ Ethernet: MAC アドレスを付与、フレーム化
    ↓ 物理層: 電気信号/光信号で送信

経路が一度に運べる大きさには上限 (MTU) があるため、TCP は最初からそこに収まる大きさに切って渡す。IP の層で分割すると、断片 1 つが欠けただけで元のパケット全体を送り直すことになり無駄が大きい。分割の判断を上の層に持たせているのは、そのためである。

AWS でのネットワーク

マネージドサービスの設定項目は、たいていどの層を扱うものかで整理できる。

サービス	関連する TCP/IP の概念
VPC	IP アドレス空間、サブネット
Security Group	TCP/UDP ポートのフィルタリング
ALB	TCP コネクションの終端、HTTP/2
NLB	TCP/UDP のレイヤー 4 ロードバランシング
CloudFront	TCP 接続の再利用、TLS 終端

よくあるトラブル

コネクション枯渇

関数は呼び出しごとに独立した実行環境で動くため、接続を横断して使い回しにくい。同時実行が増えればコネクション数もそれに比例して増え、DB 側の上限を超え得る。間に RDS Proxy を挟んで接続をまとめて持たせると、関数の数と DB の接続数を切り離せる。

TIME_WAIT

能動的に接続を閉じた側は、閉じた後もしばらくその接続の組み合わせを手放さない。規定では 2 × MSL の時間で、RFC 9293 は MSL を 2 分としているが、実装ではより短い値を採ることが多い。遅れて届いた古いパケットが、同じアドレスとポートの組み合わせで作られた新しい接続に混ざるのを防ぐためである。短い接続を大量に開閉すると送信元ポートを使い切るので、接続そのものを再利用する方が確実に効く。

再送や送信量の調整をどう決めているかは TCP 輻輳制御、暗号化をどこで解くかは TLS 終端、そもそも通信を起こさない工夫は HTTP キャッシュ を参照。