TCP

たとえ話: 書留郵便

TCPは書留郵便です。送る前に相手と『これから送りますね』と確認(ハンドシェイク)し、届いたら『受け取りました』という受領確認(ACK)をもらいます。届かなければ再送します。確実に・順番通りに届くことが保証されます。

その代わり、確認のやり取りや再送で時間がかかります。これがTCPの『信頼性 vs 速度』のトレードオフです。

図を描画中...

この最初の3往復(①②③)を3-wayハンドシェイクと呼びます。通信前にこの『握手』が必要なのがコネクション指向です。

信頼性を支える仕組み

• シーケンス番号: 各パケットに通し番号を振り、順序を保証(バラバラに届いても並べ直せる)。
• チェックサム: 破損を検出。
• ACK + 自動再送: 届いたか確認し、届かなければ再送。
• フロー制御: 受信側が処理しきれないほど速く送らないよう調整。
• 輻輳制御: ネットワークが混んでいたら送信量を抑える。

これらのおかげで『全部・順番通り・無傷で』届きます。

いつTCPを選ぶか

• データが全部無傷で届く必要がある(Webページ、ファイル転送、メール)。
• ネットワークのスループットの最善推定を自動でやってほしい。

用途例: Webサーバー(HTTP)、DB、SMTP(メール)、FTP、SSH。確実さが命の通信。

Connection Pooling

ハンドシェイクは毎回コスト。そこで**一度確立した接続を使い回す(connection pooling)**ことで、接続確立のオーバーヘッドを減らせます。DBアクセスなどで定番のテクニックです。

つまずきポイント

• TCPの『遅さ』は欠陥ではなく、信頼性を保証するための必要コスト。
• 『確実に届く』が要らない、むしろ遅延が致命的な用途(音声・動画)では、TCPの再送待ちがかえって邪魔になる。そこはUDPの出番。

---

📊 図解

3-way ハンドシェイクとデータ転送(シーケンス図)

接続確立の握手と、その後のデータ転送・ACK確認の流れです。

図を描画中...

再送の仕組み(パケットが届かないとき)

ACKが返らなければ、TCPは自動で再送します。これが「確実に届く」を支えます。

図を描画中...