Transmission Control Protocol
後述の#チェックサムの計算も参照。 シーケンス番号と確認応答は、パケットの重複、喪失パケットの再送、データの順序通りの並べ替えなどを扱っている。受信したパケットの内容が正しいことを確認するため、TCPにはチェックサムフィールドがある。チェックサムフィールドは設定必須の項目であり省略できない。
TCPチェックサムは、現在の標準から見れば弱い。データリンク層のビット誤り率が高ければ、TCPチェックサムとは別の誤り検出訂正機能が必要である。TCP/IPの下層であるデータリンク層には一般にCRCなどのもっと強力な検査機構があり、TCPチェックサムの弱さを一部補っている(例えば、PPPやイーサネット)。しかし、だからといって16ビットのTCPチェックサムが無駄というわけではない。実際、CRCで保護された通信路でパケットに誤りが残ることはよくあるが、エンドツーエンドの16ビットTCPチェックサムがそういった単純な誤りを捉えている。これはエンドツーエンド原理が機能している例である。
TCPは複雑なプロトコルである。長年重大な改良が実施されたり提案されたりしてきたが、1974年に RFC 675 で最初の仕様が登場し、1981年9月に RFC 793 でバージョン4が登場して以来、基本的動作はほとんど変わっていない。RFC 1122 (Host Requirements for Internet Hosts) はTCPプロトコルの実装時の要求仕様を何点か明確にし、近年最も重要なTCP関連のRFCの1つである RFC 2581 (TCP Congestion Control) は輻輳を防ぐための新たなアルゴリズムを提示している。2001年、RFC 3168 で明示的輻輳通知(英語版) (ECN) が提示された。2022年8月には、RFC 675とそれ以降の拡張をまとめたRFC 9293が公開されている。
当初のTCP輻輳回避アルゴリズム(英語版)は "TCP Tahoe" と呼ばれているが、代替アルゴリズムも多数提案されている(TCP Reno、TCP Vegas、FAST TCP、TCP New Reno、TCP Hybla など)。
マルチパスTCP (MPTCP)はIETFで近年進行中の改良で、リソース利用効率と冗長性を高めるためにTCPコネクションを複数経路にする試みである。
TCPはIPネットワーク上で利用され以下の機能を提供する。これらの機能を実現する機構は#プロトコル操作を参照。