Transmission Control Protocol (TCP) is a transport layer network protocol defined in RFC 9293 that establishes connections through a three-way handshake and provides reliable, ordered, error-checked delivery of byte streams between applications on IP hosts by numbering every byte and retransmitting lost data. TCP carries most enterprise application traffic including web, email, and database sessions, and is also essential for core network services such as DNS zone transfers and large responses over TCP port 53, as required by RFC 7766. Managing TCP correctly is critical because misconfigurations—such as firewalls that block TCP port 53—can cause intermittent failures that are difficult to diagnose, while observability signals like retransmissions and connection resets provide early warning of packet loss or overloaded servers before users report outages.
TCPの仕組み
TCPは、パケットの到着や順序を保証しないIPの上に、アプリケーションに対して信頼性の高いバイトストリームを提供します。これは、接続を確立し、送信されるすべてのバイトを追跡することで実現されます。
- 接続の確立:クライアントは初期シーケンス番号を含むSYNセグメントを送信します。サーバーはSYN-ACKで応答し、クライアントはACKで応答します。これが3ウェイハンドシェイクです。
- データ転送:各側はデータをセグメントに分割し、バイト位置ごとに番号を付けます。受信側は、次に受信する予定のバイトを確認する確認応答を返します。
- 制御フローと輻輳:受信側は、送信側が送信中の未確認データの量を制限するウィンドウを通知します。また、送信側は、ネットワークの輻輳を示唆するデータ損失を検出した場合、送信速度を落とします。
- 損失からの回復:確認応答が時間内に到着しない場合、または確認応答の繰り返しによってデータに欠落があることが判明した場合、送信者は欠落したデータを再送信します。受信側は、データをアプリケーションに渡す前に、セグメントの順序を並べ替え、重複するデータを破棄します。
- 接続の終了:各側は送信が完了するとFINセグメントを送信し、相手側はそれに対してACKを送信します。RSTセグメントは接続を直ちに打ち切ります。
各セグメントに含まれるチェックサムにより、受信側はデータの破損を検出できます。TCPはメッセージの境界を持たないバイトストリームを伝送するため、アプリケーションは独自のメッセージをフレーム化する必要があります。ハンドシェイクや確認応答があるため、TCPはUDPと比較して遅延が生じ、接続ごとの状態管理が必要となります。
TCPに関するよくある誤解
多くの人は、DNSがTCPを使用することはないと想定しています。RFC 7766では、DNS実装がTCPをサポートすることが求められており、TCPは切り捨てられた応答、ゾーン転送、および大容量の応答に使用されます。UDPポート53のみを通すように設定されたファイアウォールは、大容量の応答において断続的な障害を引き起こす可能性があります。
TCP/IPは単一のプロトコルではなく、プロトコルのファミリーです。IPはパケットのアドレス指定とルーティングを処理し、TCPはIPの上に信頼性を追加します。UDPなどの他のトランスポートプロトコルも、IP上で動作します。
DHCPによるアドレス割り当ては、TCPではなくUDPポート67および68を介して行われます。DHCPクライアント用にTCPポートを開いてもリース失敗は解決されません。代わりに、UDPの到達可能性とリレー設定を確認してください。
TCPは低遅延ではなく、配信の保証を行います。パケット損失が発生すると再送信や輻輳制御がトリガーされ、スループットが低下したり遅延が増加したりする可能性があるため、損失の多いリンク上での信頼性の高いセッションであっても、依然として遅く感じられることがあります。
TCPハンドシェイクが成功したとしても、それは単に何かがリスニングしており、経路が接続を許可していることを示すに過ぎません。ポートの背後にあるアプリケーションが依然として正常に動作していない可能性があるため、ハンドシェイクテストだけではサービスが正しく応答していることを証明することはできません。