Skip to content

TCP

Jump to bottom Edit New page
oraccha edited this page Jan 14, 2013 · 1 revision

TCP/IP

Transmission Control Protocol

資料

研究者

  • [http://roland.lerc.nasa.gov/~mallman/ Mark Allman]

  • [http://www-nrg.ee.lbl.gov/floyd/ Sally Floyd]

    • [http://www.icir.org/floyd/tcp_small.html Other changes proposed to TCP]

  • [http://www.psc.edu/~mahdavi/ Jamshid Mahdavi]

  • [http://www.psc.edu/~mathis/ Matt Mathis]

  • [http://www.csm.ornl.gov/~dunigan/ Tom Dunigan]

  • [http://public.lanl.gov/feng/ Wu-chun Feng]

  • [http://www.research.microsoft.com/%7Epadhye/ Jitendra Padhye]

  • [http://www.anarg.jp/ 村田研] (阪大)

Linux における実装

Windows における実装

  • [http://support.microsoft.com/default.aspx?scid=kb;ja;224829 Windows 2000 の TCP 機能について] (MicroSoft)
  • [http://www.microsoft.com/japan/technet/community/columns/cableguy/default.mspx The Cable Guy] (MicroSoft)

=== TCP ヘッダ === {{{ 0 15 16 31 +-------------------------------+---------------------------------+ | 送信元ポート番号 (16) | 宛先ポート番号 (16) | +-------------------------------+---------------------------------+ | シーケンス番号 (32) | +-------------------------------+---------------------------------+ | 確認応答番号 (32) | +--------+----------+-+-+-+-+-+-+---------------------------------+ |ヘッダ長| 予約 |U|A|P|R|S|F| ウィンドウサイズ (16) | | (4) | (4) |R|C|S|S|Y|I| | | | |G|K|H|T|N|N| | +-------------------+-+-+-+-+-+-+---------------------------------+ | チェックサム (16) | 緊急ポインタ (16) | +-------------------------------+---------------------------------+ | オプション | +-----------------------------------------------------------------+ }}}

シーケンス番号

  • バイトストリームの各バイトを識別するための 32bit 整数．
  • 確認応答(ACK)を返すことで，信頼性を確保する．

ヘッダ長

  • 可変長オプションになるので必要．
    • オプションの最大サイズは40バイト．つまり，TCPヘッダの最大サイズは60バイト．
    • オプションを含めたヘッダ長がワード長の倍数になるように、NOPオプション(1バイト)でパディングする。
  • 32bit word 単位で指定する．

ウィンドウ型フロー制御

  • 各エンドがウィンドウサイズを広告する．

    • 選択的，あるいは否定的な確認応答が返せないスライディングウィンドウプロトコル．確認応答番号は受信に成功したシーケンス番号 + 1 になる．
    • SACK は選択的応答確認を可能にする TCP オプション．

  • 受信側: ウィンドウサイズを広告する．

  • 送信側: 送信側が管理する輻輳ウィンドウ(cwnd)と受信側が広告したウィンドウサイズを比較して，小さい方のウィンドウサイズで実際に通信する．

セルフクロッキング(self clocking)

最適なウィンドウサイズは?

  • ウィンドウサイズが帯域遅延積と等しければ最適だが，これを正確に求めることは不可能．
  • 受信側のウィンドウサイズは受信側の空きバッファ容量を正確に反映できる．
  • では，輻輳ウィンドウサイズをどう決定する?
    • 輻輳が起きた時点のウィンドウサイズが帯域遅延積になる．

=== コネクション状態遷移 === TCP のコネクション状態は次の 11 状態を持つ状態マシンで管理されている．

  • CLOSED クローズ状態．
  • LISTEN コネクションへの待機 (passive open)
  • SYN_SENT SYN を送信した (active open)
  • SYN_RECV SYN を送受信し，ACKを待っている．
  • ESTABLISHED コネクションを確立した(データ転送)．
  • CLOSE_WAIT FIN を受信し，アプリケーションが close するのを待っている．(passive close)
  • LAST_ACK FIN を受信してコネクションを閉じて，ACK を待っている．
  • FIN_WAIT1 コネクションを閉じて，FIN を送信し，ACK と FIN を待っている．(active close)
  • FIN_WAIT2 close し，FIN を待っている．
  • TIME_WAIT active close 後の 2MSL 待ち状態．
  • CLOSING 同時 close し，ACK を待っている．

メモ

  • コネクションの確立は 3-way handshake．切断は FIN/FIN+ACK で行うが，全二重通信なので双方向で行う必要がある．片方向だけを閉じた状態を half close と呼び，close(2) の代わりに shutdown(2) を使う．
  • FIN を受信したプロセスは，EOF を受け取る．half close は，次の rsh の例で示すような場合に用いられる．sort を実行しているリモートプロセスは，EOF を受け取る必要があるが，完全にコネクションを close してしまうと，ローカルプロセスに結果を出力できない． {{{ $ rsh hoge sort < file }}}

=== 関連 RFC ===

  • [http://www.postel.org/pipermail/end2end-interest/2003-October/003607.html RFC List] (e2e ML)

  • [http://www.networksorcery.com/enp/protocol/tcp.htm ここ]がまとまっている

  • RFC:4614 ロードマップ。関連RFCの要約にもなっているので、RFCを漁るにはここから始めるとよいかも。

基本

  • RFC:793 基本スペック
  • RFC:1122 TCP の必要条件と Nagle アルゴリズム
  • RFC:5681 (obsolete RFC:2581) TCP Congestion Control . いわゆるReno。スロースタート，輻輳回避，高速再送，高速リカバリの四つの輻輳制御アルゴリズム．その他のトピックスとして通信アイドル後のリスタート(スロースタートすべし)，遅延ACK(最大500ms)，partial ACK，SACKなどにも触れられている．
  • RFC:2873 TCP Processing of the IPv4 Precedence Field
  • RFC:2988 Computing TCP's Retransmission Timer

推奨拡張

  • RFC:1323 TCP Extensions for High Performance . 新しい TCP オプションの追加．

    • window scaling: 広告ウィンドウサイズが 64k(16bit) までなので，スケールファクタを追加する．
    • RTTM(Round Trip Time Measurement):
    • PAWS(Protect Against Wrapped Sequences): シーケンス番号(32bit)がラップアラウンドしてないかのチェック．
    • タイムスタンプ: シーケンス番号の拡張としてコネクションのタイムスタンプを利用する．

  • RFC:2675 IPv6ジャンボグラム対応

  • RFC:3390 (obsolete RFC:2414) Increasing TCP's Initial Window

    • min (4MSS, max (2MSS, 4380 bytes))

  • RFC:3782 (obsolete RFC:2582) The NewReno Modification to TCP's Fast Recovery Algorithm . 世の中のTCP実装のほとんどはNewRenoベースになっていそうだが，StandardなのはRFC 2581までで，NewRenoはExperimentalという位置づけ．RFC 3782でexperimentalからstandard trackに昇格した。

  • RFC:2309 Recommendations on Queue Management and Congestion Avoidance in the Internet

  • RFC:2861 TCP Congestion Window Validation

  • RFC:2914 Congestion Control Principles

  • RFC:1146 TCP alternate checksum options

  • RFC:4821 Packetization Layer Path MTU Discovery

数学的モデリング

  • ./レスポンス関数

  • [http://www.statslab.cam.ac.uk/~frank/ Frank Kelly's Home Page]

  • [http://www.icir.org/tmrg/ The Transport Modeling Research Group] (ICIR)

    • [http://www.ietf.org/internet-drafts/draft-irtf-tmrg-metrics-04.txt Metrics for the Evaluation of Congestion Control Mechanisms] とか実験する前に読むと役立つかも．

  • [http://wil.cs.caltech.edu/pfldnet2007/slides/Tutorial_Low.pdf Flow Control Theory for Practitioners] (PFLDnet2007) . Steven Low 教授によるチュートリアル．

Add a custom footer
Add a custom sidebar
Clone this wiki locally