Transmission Control Protocol
Transmission Control Protocol(トランスミッション コントロール プロトコル、TCP)はIPネットワーク上のアプリ間・コネクション型・高信頼性・ストリーム指向の通信プロトコルである。伝送制御プロトコルとも呼ばれる。
TCPは有線ネットワーク向けに最適化されてきた。一般にパケット喪失はネットワーク輻輳の結果と判断され、予防のために輻輳ウィンドウサイズが大幅に縮小される。しかし無線の場合、減衰、影に入る、ハンドオーバーなどの無線特有の原因でパケットを喪失することがあり、輻輳が原因とは限らない。無線パケット喪失による(誤った)輻輳ウィンドウサイズ縮小後、輻輳回避のための保守的なウィンドウサイズの縮小も行われる可能性がある。これにより無線リンクの効率が低下する。このような問題への対策が広く研究されている。提案されている対策としては、エンドツーエンド型の対策(クライアントとサーバの修正が必要)とリンク層の対策(RLPなど)とプロキシを使った対策(端点以外のネットワークの何らかの変更が必要)がある。
Multipath TCP による冗長性は、無線ネットワークでリソースの統計多重化を可能にし、TCPのスループットを劇的に高める。マルチパスTCP はデータセンター環境にも性能面の利点をもたらす。Multipath TCP のリファレンス実装がLinuxカーネル向けに開発されている。
TCP Cookie Transactions (TCPCT) は2009年12月に提案された拡張で、サーバをDoS攻撃から守ることを意図している。SYN cookies とは異なり、TCPCTはウィンドウスケーリングなどの他のTCP拡張と共存できる。TCPCTは、短命なTCPコネクションをサーバが多数処理しなければならないDNSSECでの必要から設計された。
tcpcrypt は2010年7月に提案された拡張で、TCP自身で直接暗号化するものである。透過的に動作可能なように設計されており、設定変更は不要である。TLS (SSL) とは異なり、tcpcrypt 自体は認証機構を持たないが、そのための簡単なプリミティブをアプリケーションに提供する。2010年現在、IETF による最初のドラフトが公表されており、いくつかの主要プラットフォームでの実装が存在する。その後、2019年には実験的(Experimental)のステータスのRFC 8547およびRFC 8548が公開されている。
多くのTCP/IPスタック実装では、ネットワークカードによる自動チェックサム計算を補助的に使うオプションを用意している。これによりCPUサイクルをチェックサム計算に費やすコストを低減でき、ネットワーク性能を向上させることができる。
なお、送信時にチェックサム計算をネットワークカードに任せていると、LANアナライザがチェックサムエラーを検出することがある。
IPv4上のTCPの場合、チェックサム計算法は RFC 793 で定義されている。
チェックサム・フィールドは、ヘッダおよびテキストの全16ビットワードの1の補数の総和の1の補数の下位16ビットである。オクテット数が奇数の場合、最後のオクテットの右にゼロの列をパディングして16ビットワードにしてからチェックサムを計算する。このパディングはセグメントの一部として送信することはない。チェックサム計算時、チェックサム・フィールド自体はゼロとして計算する。
言い換えれば、正しくパディングした後、全16ビットワードを1の補数表現で加算していく。そして総和をビット毎に反転してチェックサム・フィールドに挿入する。チェックサム計算時には、IPv4パケットヘッダを真似た擬似ヘッダも含めて行うことになっている。擬似ヘッダを含めたチェックサム計算範囲を以下に示す。
上のピンクの部分はIPv4ヘッダの一部である。プロトコル番号はTCPでは 6 である。パケット長はTCPヘッダとデータの合計の長さである。