Transcript Document
自律分散協調システム論 第10回「TCPと輻輳制御」 中村 修 [email protected] TCPと輻輳制御 • 輻輳制御の重要性 • 輻輳制御の困難さ • TCPによる輻輳制御 輻輳制御の重要性 (1/2) • 輻輳は悪化していく傾向がある 玉突き事故 三次災害 二次災害 輻輳発生 輻輳制御の重要性 (2/2) • ネットワークに自律的な輻輳回復機能がない – ネットワークはできるだけ仕事をしない • エンドノードが輻輳を回避する必要がある • エンドノードは故意に輻輳を起こせる – DoSアタック 輻輳制御技術の大まかな歴史 • 初期のインターネット:輻輳制御技術なし • 1980年初 輻輳崩壊の発生が指摘される • 1980年後半 エンドノード主体による輻輳制御技術の出現 • 1990年後半 中継ノード主体による輻輳制御技術の出現 • 現在 広帯域・低遅延要求アプリケーションの台頭 インターネット速度記録（TCP高速化技術） 輻輳制御の困難さ (1/2) • エンドノードはネットワークの状態が分からない – 自分で推測してネットワークに送出するだけ パケットを少なく出すのか？ パケットを多く出すのか？ ネットワークは教えてくれない IPネットワーク 輻輳制御の困難さ (2/2) なぜインターネットの状態は分かりにくい？ • IPの特徴 – 様々な通信媒体の性質を抽象化 • 上位プロトコルから通信媒体の性質が見えにくい – 中継システムの簡素化 • ネットワークの許容量が不明 • ネットワークの混雑度が不明 アプリケーションとトラフィックパターン • TCP – インタラクティブデータフロー • パケットを直ちに送出 – アプリケーション例：SSH, Telnet などコンソールアプリケーション – バルクデータフロー • フロー制御によってパケットを送出 – アプリケーション例：http, ftp, メール など • UDP – フロー制御・輻輳制御を行わない – アプリケーション例：ストリーミング, VoIP など それぞれが異なるトラフィックパターンを有する アプリケーショントレンドの推移 トラフィックの推移 100% 90% ポート番号からサービス 特定がしにくい時代 80% 70% データ量(%) 60% Others Napster SMTP HTTP/HTTPS FTP P2P登場 50% 40% WWW全盛 30% 20% 出典: WIDE報告書(1994-1999) 2000-2005はdaily sampling 10% 0% 1994 1995 1996 1997 1998 1999 2000 年 2001 2002 2003 2004 2005 15年前のアプリケーションモデル • サーバ・クライアントモデル – サービスを提供する側と受ける側に役割を分担 – 情報(データ)は「提供する側」に存在 • 情報(データ)のありか – 情報(データ)が格納されているサーバは「何らかの方法」で探し出す • archie プログラム – サーバ数が多くない上、有名なサーバには様々な種類の情報(データ)が大量に存在 • 情報(データ)の集まり方 – 情報(データ)が一箇所に集まるので、利用者も一箇所に集中してアクセスする ソフトウェアファイル サーバAから ソフトウェアを ダウンロードしよう ドキュメントファイル 巨大なサーバ： A サーバAから ドキュメントを ダウンロードしよう インターネット 利用者 クライアント クライアント 利用者 10年～5年前のアプリケーションモデル • サーバ・クライアントモデル – – • 「置き場所」としてのサーバは変化せず 能動的なクライアントも変化せず 情報の分散化 – 情報(データ)は、「リンク」が含むようになり、分散したサーバ間で情報が有機的に結びつけられるようになった • • • 情報(データ)のありか： – 情報(データ)が格納されているサーバは「何らかの方法」で探す • – • 情報提供者はリンクを意識して情報(データ)を作成 情報利用者はリンクを辿り新たな情報(データ)を取得 cf. 検索エンジン、ディレクトリサービス サーバの数が多く、大量の情報(データ)が分散して存在 情報(データ)の集まり方 – インターネット中に分散して存在するが、利用者の増加に伴い人気のある情報(データ)を持つサーバにアクセ スは集中 アドレスを指定 アドレスを指定 Webサーバ インターネット アドレスを指定 Webサーバ Webサーバ アドレスを指定 Webサーバ 最近のアプリケーションモデル • P2Pモデル – – – • 情報(データ)単位の分散化から、分割した情報(データ)の分散化 – • ファイル単位のやり取りから、ファイルの分割を前提とした断片単位のやり取りへ 情報(データ)のありか – – – • あらかじめ役割を決めない (サーバ・クライアントの両方の役割を担う) 対等な関係 断片化した情報(データ)はネットワーク上の任意のホストに存在 情報理論を応用した検索手法(分散ハッシュ etc…) P2Pのピアになるホストの数だけ分散する可能性がある 情報(データ)の集まり方 – – 完全な情報(データ)は、それをリクエストした人のところに存在 ネットワーク上には、断片化されたもの、完全なもの様々な形で存在 ファイルA ファイルA ファイルの断片化(6分割の例) メディア通信と遅延 • デッドライン – 再生を行うために間 に合わせなければな らないタイミング – これに遅れると映像 や音声が乱れる • バッファ – パケットロスや遅延な どでデッドラインオー バーが頻繁に起こら ないようにデータを一 時的に蓄積 TCPによる インターネット最高速度 • Interne2 Land Speed Record • 東京大学、WIDEプロジェクト、 JGN2(NICT)、NTTコミュニ ケーションズ などによる • 2006年12月30日 – 30000km(実際には32372km) のネットワーク – 7.67Gbpsのデータ転送速度 – 230100 terabit-meters per second (Tb-m/s) • 2006年12月31日 – 同一ネットワーク – 9.08Gbpsのデータ転送速度 – 272400 terabit-meters per second (Tb-m/s) TCPにおけるフロー制御 フローコントロール ② もちょっとゆっくり 送って。 受信者 送信者 もちょっとゆっくり ③ 送るか。 ① キュー(バッファ) 早すぎてバッファがあふれる フローコントロール ② もっとはやく 送って。 受信者 送信者 ③ じゃはやくおくるか ① キュー(バッファ) 遅いから余裕があるな ウィンドウ制御 • ウィンドウ広告 ＝ 受信バッファ残量 • ウィンドウ更新 – ACKセグメントによる • ACKを待たずに、複数セグメントを転送 – 転送効率の向上 スライディングウィンドウ 8 1 7 6 直ちに 転送可能 2 広告 ウィンドウ 3 5 4 スライディングウィンドウ 8 転送されたが 1 確認応答されていない 7 2 6 広告 ウィンドウ 3 5 4 直ちに 転送可能 スライディングウィンドウ 8 7 1 転送されて 確認応答済み 2 転送されたが 確認応答されていない 6 3 5 4 直ちに 転送可能 スライディングウィンドウ 8 7 1 転送されて 確認応答済み 2 転送されたが 確認応答されていない 6 3 5 新たに広告された ウィンドウ 4 直ちに 転送可能 TCPにおける輻輳制御 TCPの輻輳制御機能 ② もちょっとゆっくり 送ろう。 送信者 受信者 輻輳 ① 受信者からしばらく応答がない 輻輳が発生してパケットが届いて なさそうだ 輻輳制御の重要性 • 輻輳は悪化していく傾向がある 輻輳発生 二次災害 なんらかの対処をしなければ 悪化する一方 （輻輳崩壊） 玉突き事故 TCPの輻輳制御アルゴリズム • 非常に多くのアルゴリズムが存在 • 代表的な例 – TCP Tahoe • スロースタートアルゴリズム，輻輳回避アルゴリズム，高速再転送アルゴ リズム – TCP Reno (TCP NewReno) • 高速再転送アルゴリズム – TCP Vegas • RTTをベースとしたウィンドウサイズの調整 • OSによって実装されているアルゴリズムがことなることも TCPの輻輳制御アルゴリズム（時代別） • 1988年頃 – Tahoe • スロースタート、輻輳回避アルゴリズムの採用 • 高速再転送アルゴリズムの採用 • 1990年頃 – Reno • 高速リカバリ・アルゴリズムの採用 • 1996年頃 – NewReno • 高速リカバリ・アルゴリズムの修正 Linux Kernel の持つ アルゴリズム (Kernel 2.6.18の例, /usr/src/linux/net/ipv4/tcp_*.c) • Binary Increase Congestion control for TCP (BICTCP) – • TCP Reno / TCP NewReno – • Lawrence S. Brakmo and Larry L. Peterson. TCP Veno – • Tom Kelly TCP Vegas – • C.Caini, R.Firrincieli. TCP Low Priority (TCP-LP) Scalable TCP – • R.N.Shorten, D.J.Leith. TCP HYBLA – • • Sally Floyd. H-TCP – • Injong Rhee, Lisong Xu. High Speed TCP – • BSD系OSのデフォルト Binary Increase Congestion control for TCP v2.0 (TCP CUBIC) – • Lison-Xu, Kahaled Harfoush, and Injong Rhee. Linuxにおけるデフォルトアルゴリズム （変更可能） C. P. Fu, S. C. Liew. TCP Westwood+: end-to-end bandwidth estimation for TCP – Angelo Dell'Aera. TCPの輻輳制御アルゴリズム (1/2) • ネットワークの状態推測機構 – ネットワークの情報は直接手に入らない – エンド間の通信から得られる情報で推察 • 単純なアルゴリズム – パケットが落ちない • 転送量を上げる – パケットが落ちた • 転送量を落とす TCPの輻輳制御アルゴリズム (2/2) • ウィンドウサイズを増減させ転送制御 – 送信者の輻輳ウィンドウ – 受信者のウィンドウサイズ広告 • 2段階の通信状態 – スロースタート – 輻輳回避 スロー・スタート • スロー・スタート – エンドノード間の回線状態はわからない – 回線の許容量以下に送信量を制御する必要がある – ネットワークへの突発的なトラフィック流入を防止可能 • 輻輳ウインドウ（cwnd） – 送信者が送信可能なセグメント数を決定 – 送信者が管理するウィンドウ – （注）受信者の管理するウィンドウとは別 スロー・スタートの仕組み • スロー・スタートのアルゴリズム – 通信開始時 • 輻輳ウィンドウサイズを1で初期化 – Ack受信時 • 輻輳ウィンドウをAck受信毎に増加 • 輻輳ウィンドウは幾何級数的に増加 スロー・スタートの概要 初期windowサイズは1で送信 １に対してAckを返す 送信者 受信者 windowサイズを2で送信 2に対してAckを2つ返す windowサイズを4で送信 1,2,4,8,,,,と幾何級数的にウィンドウサイズを大きくする 輻輳回避状態 1. スロースタートを開始し、輻輳ウィンドウが増加 2. 送信者は、パケットロスを検知しスロースタートを停止 – – • 輻輳が発生したときの輻輳ウィンドウを記憶 輻輳ウィンドウを１に戻しスロースタートを再初期化 輻輳回避状態へ移行 – – 記憶した輻輳ウィンドウまでは通常のスロースタート 記憶した輻輳ウィンドウに達すると • • Ack受信ごとに輻輳ウィンドウを上げていかない 輻輳ウィンドウ分のAckを受信して輻輳ウィンドウを開く TCP Tahoe におけるウィンドウサイズの変化 スロースタート 輻輳回避 ネットワーク の限界 最適な ウィンドウサイズ スロースタート 閾値 t TCP Reno におけるウィンドウサイズの変化 スロースタート 輻輳回避 ネットワーク の限界 最適な ウィンドウサイズ スロースタート 閾値 t 往復時間の測定 • RTTから分かること – 輻輳の度合い – パケットロスの指標 • RTTは非線形に変化 – 外れ値の可能性 • 平滑化することでRTTを評価（RTT評価値） R = αR+(1-α)M – RはRTT評価値 – Mは新しい測定値 – αは平滑化係数（推奨値は0.9） 再転送タイムアウト値の算出 • 再転送タイムアウト値（RTT） RTO = Rβ (RFC793推奨式) – βは遅延分散係数（推奨値は2） • 再転送タイムアウトするごとに増加 – 指数バックオフ – 最大値64秒 高速再転送アルゴリズム • 受信者のTCPが順番の違うセグメントを受信 – 確認応答（重複ACK）を生成する必要 • 単に順番が入れ替わった … (a) – 受信者はセグメントを並び替えて上位層に渡す • パケットロスが発生した … (b) – 送信者は該当するセグメントを再送する必要 • 高速再転送アルゴリズム – (a)、(b)をいち早く調べる方法 • 以下の場合、パケット損失の可能性高と判断 – 重複ACKを３つ受信した場合 • 再送タイマを待たずに直ちに再送する 高速再転送アルゴリズム • 再送タイムアウトを待たずに再送 • 迅速な再送による転送効率の向上 ５ ４ 3 2 1 発信元 2番のパケットが 届いていない！ ５ ４ 2番パケットを転送 Packet loss 3 1 インターネット 3が届いた時点で1番へのACK 1番へのACKが 3が届いた時、4が届いた時、5が通ったとき の合計3回届く 宛て先 セルフクロッキング (1/3) • 経路の一番細い部分がボトルネックとなり、パケッ トギャップが発生する ボトルネック 送 信 者 ルータ 帯域が広い ルータ 帯域が狭い パ ケ ッ ト ギ ャ ッ プ 帯域が広い 受 信 者 セルフクロッキング (2/3) • 受信者はパケットギャップの間隔でAckを返してくる 送 信 者 受 信 者 ルータ 帯域が広い ルータ 帯域が狭い 帯域が広い セルフクロッキング (3/3) • Ackの受信間隔に合わせてパケットを送出する – 通信のバースト性が抑えられる 送 信 者 受 信 者 ルータ 帯域が広い ルータ 帯域が狭い 帯域が広い まとめ：TCPにおける輻輳制御 • • • • • ネットワークの状態を動的に推測 輻輳が発生すれば転送速度を落とす 輻輳が起きないギリギリまで転送速度を上げる できるだけ早く最適なウィンドウサイズに到達する ウィンドウサイズが安定すると通信も安定する