Transmission Control Protocol
1 2 "Transmission Control Protocol (TCP) ... TCP provides a reliable, in-order, byte-stream service to applications. ... TCP is connection oriented" RFC 9293.
↑ Vinton G. Cerf, Robert E. Kahn, (May 1974). “A Protocol for Packet Network Intercommunication”. IEEE Transactions on Communications 22 (5): 637-648. http://ece.ut.ac.ir/Classpages/F84/PrincipleofNetworkDesign/Papers/CK74.pdf.
↑ "TCP uses port numbers to identify application services and to multiplex distinct flows between hosts." RFC 9293.
1 2 3 4 5 6 7 8 Comer, Douglas E. (2006). Internetworking with TCP/IP:Principles, Protocols, and Architecture. 1 (5th ed.). Prentice Hall.
通常、TCPは送信すべきデータが最大セグメントサイズ (MSS) まで溜まるか、200ミリ秒経過するまで待つ(Nagleアルゴリズムで小さいメッセージを単一パケットにまとめようとするため)。これは例えばファイル転送のような一定の送信が要求される場合に問題となることがある。例えば、送信ブロックが一般的な4KBで、MSSも一般的な1460バイトだとする。すると1ブロックが3セグメントで送信され、最後の1セグメントはMSSに満たないことになる。すると、2パケットまでは約1.2ミリ秒で送信され、1176バイトの3パケット目は197ミリ秒待ってから送信ということになる。
Telnetの場合、ユーザーがキーを押下するたびに通信先からエコーバックされて画面に文字が表示される。すると、1文字押下するたびに200ミリ秒待たされることになり、非常にストレスになる。
この場合、ソケットのオプション TCP_NODELAY を使ってデフォルトの200ミリ秒の送信遅延を変更することができる。
RFCには PSH フラグを使って「受信側TCPスタックでそのデータを即座にアプリケーションに送る」という機能が定義されている。しかしソケットにはこれを制御するインタフェースがなく、プロトコルスタックの実装に任されている。
IPスプーフィングを使い、悪意を持って作ったSYNパケットを繰り返し送信することで、偽の接続に対処するために対象サーバの多大な量のリソースを消費させることができる。これを SYN flood 攻撃と呼ぶ。この問題への対策として提案された方法として、SYN cookies や暗号的パズルがある。Sockstress も類似の攻撃法だが、システムのリソース管理によって効果を和らげることができる。オンラインマガジン Phrack 66号では、TCPの Persist Timer に存在する脆弱性を利用した改良型DoS攻撃の分析を行っている。
シーケンス番号(32ビット) – 2つの役割がある。 SYNフラグがセットされている場合 (1)、初期シーケンス番号である。実際の先頭データバイトのシーケンス番号と対応する確認応答の確認応答番号は、このシーケンス番号に1を加えた値になる。 SYNフラグがセットされていない場合 (0)、このセッションにおけるこのパケットの先頭データバイトの累積シーケンス番号である。
確認応答番号(32ビット) – ACKフラグがセットされている場合、受信側が期待する次のシーケンス番号を格納している。(もしあれば)それまでの全バイト列の受信を確認済みであることを示す。最初に互いにACKを送る際は、相手側の初期シーケンス番号を確認するだけで、データは含めない。
ヘッダ長(4ビット) – TCPヘッダのサイズを32ビットワード単位で表す。ヘッダの最小サイズは5ワードで、最大サイズは15ワードである。すなわち、ヘッダ部は20バイトから60バイトまでの大きさであり、21バイトめからの40バイトはオプションとなる。TCPセグメント内の実際にデータが始まる位置を示すことにもなるため、データオフセットとも呼ぶ。
予約(3ビット) – 将来の利用のために予約されたビット列であり、常に 0 をセットする。
フラグあるいは制御ビット列(9ビット) – 9個の1ビットのフラグがある。 NS(1ビット) – ECN-nonce 輻輳保護(RFC 3540 でヘッダに追加) CWR(1ビット) – 輻輳制御ウィンドウ縮小 (Congestion Window Reduced)。
IPv6上のTCPの場合、チェックサム計算法は RFC 2460 で示すように変更されている。
チェックサム計算にIPヘッダのアドレスを含める上位層のプロトコルでは、IPv4の32ビットアドレスの代わりにIPv6の128ビットのアドレスを使うよう変更しなければならない。
チェックサム計算で使うIPv6ヘッダを真似た擬似ヘッダは次のようになる。
送信元IPアドレス - IPv6ヘッダにあるもの
あて先IPアドレス - 最終送信先。ルーティングヘッダがある場合、TCPは最終のあて先アドレスを使用する。発信元ノードでは、そのアドレスはルーティングヘッダの最後の要素にあり、受信側ではIPv6ヘッダの着信アドレスフィールドにある。
パケット長 - TCPのヘッダとデータをあわせた全長
次のヘッダ - TCPのプロトコル番号
“When The CRC and TCP Checksum Disagree”. Sigcomm. http://dl.acm.org/citation.cfm?id=347561&dl=ACM&coll=DL&CFID=67856317&CFTOKEN=90549758.
↑ RFC 879
↑ TCP window scaling and broken routers lwn.net
↑ Gont, Fernando (2008年11月). “On the implementation of TCP urgent data”. 73rd IETF meeting. 2009年1月4日閲覧。
↑ Peterson, Larry (2003). Computer Networks. Morgan Kaufmann. pp. 401. ISBN 155860832X
↑ Richard W. Stevens (2006). TCP/IP Illustrated. Vol. 1, The protocols. Addison-Wesley. pp. Chapter 20. ISBN 978-0-201-63346-7. https://books.google.com/books?id=b2elQwAACAAJ 2011年11月14日閲覧。
↑ Tanenbaum, Andrew S. (2003-03-17). Computer Networks (Fourth ed.). Prentice Hall.