TCP がセッションを確立すると、そのセッション内の会話を追跡できるようになります。 TCP は実際の会話を追跡できるので、ステートフル プロトコルと見なされます。 ステートフル プロトコルは、通信セッションの状態を追跡するプロトコルです。 たとえば、TCP を使用してデータが伝送された場合、送信側はデータを受信したという宛先からの確認応答があることを期待します。 TCP は、どの情報を送信し、どの情報に対して確認応答があったのかを追跡します。 確認応答がない場合、送信側はそのデータが到達しなかったと見なし、それを再送信します。 ステートフル セッションは、セッションの確立で始まり、そのセッションがセッションの終了で閉じられたときに終わります。
注：この状態情報を維持するためには、UDP などのステートレス プロトコルには必要のないリソースが必要になります。
TCP は、これらの機能を使用するために余分なオーバーヘッドを発生させます。 図に示すように、TCP の各セグメントには、アプリケーション層のデータをカプセル化するヘッダー内に 20 バイトのオーバーヘッドがあります。 これは、オーバーヘッドが 8 バイトしかない UDP のセグメントよりもかなり大きなものです。 この余分なオーバーヘッドは次のとおりです。
- シーケンス番号（32 ビット） - データの再構成に使用されます。
- 確認応答番号（32 ビット） - 受信されたデータを示します。
- ヘッダー長（4 ビット） - 「データ オフセット」と呼ばれます。 TCP セグメントのヘッダーの長さを示します。
- 予約済み（6 ビット） - このフィールドは将来のために予約されています。
- 制御ビット（6 ビット） - TCP セグメントの目的と機能を示すビット コード（フラグ）が含まれます。
- ウィンドウ サイズ（16 ビット） - 一度に受け入れ可能なセグメントの数を示します。
- チェックサム（16 ビット） - セグメントのヘッダーとデータのエラー チェックに使用されます。
- 緊急（16 ビット） - データが緊急を要するものかどうかを示します。
TCP を使用するアプリケーションの例としては、Web ブラウザ、電子メール、およびファイル転送があります。