ネットワーク●●○○○

TCP/IP

インターネット通信の基本プロトコル群。確実にデータを届ける仕組みの土台。

概要

TCP/IPは、インターネットで使われる通信規約(プロトコル)群の総称です。中心となるのは、IPアドレスを頼りにパケット(データの小包)を宛先まで運ぶIPと、その上で「送ったデータが順序どおり・欠落なく届いたこと」を保証するTCPの2つです。HTTPでのWeb閲覧も、メールも、データベースへの接続も、ほぼすべての通信がこの土台の上に載っています。

普段のWeb開発でTCP/IPを直接書くことはまずありません。しかし「接続がタイムアウトする」「大量アクセスでコネクションが枯渇する」「通信が遅い原因はどの層か」といったトラブルシューティングは、最終的にこの層の理解に支えられます。ネットワークの語彙の系譜をたどると、多くの線がここに集まってきます。

なぜ生まれたか

1970年代、コンピュータネットワークは組織や規格ごとに分断されており、異なるネットワーク同士を接続する共通の方法がありませんでした。米国のARPANETの研究から生まれたTCP/IPは、「途中のネットワークがどんな方式でも、パケットを次へ次へと中継すれば相手に届く」という相互接続の共通言語として設計され、1983年にARPANETの標準となりました。これが現在のインターネットの直接の祖先です。

設計上の重要な割り切りが「ネットワーク自体は信頼できないものとする」ことでした。パケットは途中で失われるかもしれないし、順序が入れ替わるかもしれない。その前提を受け入れたうえで、信頼性の確保は末端のコンピュータ同士(TCP)の責任とする。ネットワークの中身を単純に保ち、賢さを端に置くこの方針のおかげで、多様な回線や機器を際限なくつなぎ足せる拡張性が生まれました。

詳細

役割分担の層構造

TCP/IPは役割の異なる層の積み重ねとして整理されます。下から、ケーブルや無線で隣の機器と信号をやり取りする層、IPがパケットを宛先の機器まで運ぶ層、TCP(またはUDP)が機器内のアプリケーションまで届けて通信の品質を担う層、そしてHTTPなどのアプリケーション層です。各層は自分の仕事にだけ責任を持ち、上の層は下の層の詳細を知らずに済みます。Wi-Fiでも光回線でも同じHTTPがそのまま動くのは、この分業の成果です。

アプリケーション層HTTP・DNS・SMTP など — アプリ同士の会話の中身トランスポート層TCP・UDP — アプリケーションまで届け、通信の品質を担うインターネット層IP — 宛先の機器までパケットを運ぶ(ベストエフォート)リンク層Ethernet・Wi-Fi など — 隣の機器と信号をやり取り送信は上から下へ受信は下から上へ
TCP/IPの4層構造。各層は自分の仕事にだけ責任を持ち、上下の層の詳細を知らずに済む

IPの仕事は「ベストエフォートでの配達」までです。届く順序も、そもそも届くことすらも保証しません。その穴を埋めるのがTCPで、宛先のポート番号への振り分けに加えて、順序の復元・欠落の検出と再送・流量の調整を引き受けます。

コネクションの確立: 3ウェイハンドシェイク

TCPは通信に先立って、双方が「送れること・受け取れること」を確認し合うコネクション(論理的な通信路)を確立します。これが3ウェイハンドシェイクです。

サーバクライアントサーバクライアントコネクション確立 データ送受信を開始SYN 接続したいSYN+ACK 了解 こちらも準備OKACK 確認した

この往復1.5回分のやり取りを経て初めてデータを送れます。物理的に遠いサーバほどこの往復に時間がかかるため、「接続の確立コスト」はWebの高速化で常に意識されるポイントです。HTTPSではさらにTLSのハンドシェイクが重なるため、接続を使い回すキープアライブやコネクションプーリングが重要になります。通信の終了時にも FIN/ACK のやり取りで双方が合意して閉じる手順があります。

コネクション確立から、パケットが失われたときの再送までを、次のステッパーで1ステップずつ確かめられます。

⚡ 体験: 3ウェイハンドシェイクを1歩ずつ
クライアントCLOSED
(パケットなし)
サーバLISTEN
ハンドシェイク — ステップ 1 / 4

サーバはポートを開いて接続を待ち受けています(LISTEN)。「次へ」でクライアントから接続を始めます。

信頼性の仕組み: 再送・順序制御・輻輳制御

TCPは送るデータの1バイトごとに通し番号(シーケンス番号)を振り、受信側は「ここまで受け取った」という確認応答(ACK)を返します。一定時間ACKが返らなければ送信側はパケットが失われたとみなして再送し、受信側は番号を頼りに入れ替わったパケットを正しい順序に並べ直します。アプリケーションから見ると、途切れのない正しいバイトの流れがただ届くように見えます。

さらにTCPは、ネットワークの混雑(輻輳)を検知すると自ら送信ペースを落とします。パケットロスや遅延の増加を混雑のサインとみなし、送出量を絞っては少しずつ戻す。世界中の通信が我先にと帯域を奪い合ってもインターネット全体が崩壊しないのは、各TCPが行うこの自律的な譲り合いのおかげです。

実務での接点と落とし穴

アプリケーションからTCP/IPを使う窓口はソケットです。「コネクションが確立できない(ファイアウォールやポート設定の問題か)」「確立はするがデータが来ない(アプリ側の問題か)」の切り分けは、この層を意識すると格段にやりやすくなります。curl -vss、パケットキャプチャの tcpdump は、その切り分けの定番道具です。

落とし穴としては、TCPの保証範囲の誤解が代表的です。TCPが保証するのは「コネクションが生きている間の順序と欠落のなさ」であって、相手のアプリケーションが処理したことまでは保証しません。また、コネクションの確立や再送のコストを嫌う用途——リアルタイム通信や一往復で済む問い合わせ——では、あえて保証を捨てたUDPが選ばれます。近年はHTTP/3が「UDPの上に信頼性を作り直す」QUICを採用しており、TCPの設計思想を理解していることが、こうした新しい選択を評価する土台になります。