TCP(Transmission Control Protocol)
・IPによる通信は 不確実
　・TCPは、不確実なIP網で、 正確で効率的な通信を実現するための機能を持ち、様々な制御を行う
・TCPの機能
　・ 　ポート管理　　機能（トランスポート層に共通の機能）
　・ コネクション管理機能
　・ 　　通信制御　　機能
---------------------------------------------------------------------------------
・ 送達　　　確認
・ 再送　　　制御　　　　　 　正確な通信　を実現するための制御
・ 順序　　　制御
---------------------------------------------------------------------------------
・ ウィンドウ制御
・ 流量　　　制御　　　　　 効率の良い通信を実現するための制御
・ 輻輳　　　制御
---------------------------------------------------------------------------------

TCPのコネクション管理機能
・ コネクション
　・アプリケーションが使う 論理的（ 仮想的）な通信路

① セグメント

・TCP通信の開始から終了まで

① コネクションの確立
② コネクションの切断

・コネクションの確立（作成）
　・ 3ウェイハンドシェークで、双方向の通信路を作る

① 　 SYN 　
② ACK + SYN

TCPヘッダ
・SYN,ACKの正体はヘッダ内の コントロールフラグ


TCPのコネクション管理機能
・コネクションの切断（解放）
　・コネクションの切断は、 双方向それぞれ独立に行われる

① FIN + ACK
② 　　ACK　　
③ 完了していないかもしれない

送達確認
・送信データが届いたかどうか、逐一確認

① 確認応答受信
② 確認応答送信


・データセグメントが失われた場合

① RTO( Retrans mission Time Out)
② 再送信

確認応答がなければ再送
・確認応答が失われた場合

① RTO

・RTOが経過した後、確認応答が帰ってきた

① 無視する
② 既にセグメントが届いている

再送タイムアウトはどうやって決める？
・再送タイムアウト（RTO：Retransmission Time Out）
・セグメントの往復時間（① RTT： Round Trip Time）の平均と、その ゆらぎ（変動）を考慮して決定
　・ゆらぎが大きいとき、① RTTは大きく変化する　→　 平準化が必要
　・決定方法はOSにより異なり、現在も改良が続けられている


送達確認の仕組み
・ シーケンス番号と 確認応答番号で確認
　・ シーケンス番号　・・・　 送信するセグメントのデータ位置
　　・送信側が更新
　　・初期値はコネクション確立時にランダムに決定
　・確認応答番号　・・・　 次に受信すべきセグメントのデータ位置
　　・受信側が更新
　　・受信セグメントのシーケンス番号 ＋ 受信データサイズ

① 1201
② 1701

・データセグメント送受信時


・コネクションの確立と切断時


・シーケンス番号と確認応答番号で確認
　・シーケンス番号　・・・　送信するセグメントのデータ位置
　　・ 送信側が更新
　　・初期値はコネクション確立時にランダムに決定
　・確認応答番号　・・・　次に受信すべきセグメントのデータ位置
　　・ 受信側が更新
　　・受信セグメントのシーケンス番号＋受信データサイズ

① MSS
② 経路MTU探索
③ 確立時
④ IP

再送制御とシーケンス番号
・確認応答が返ってこない場合

① RTO

・受信セグメントが壊れていた場合


TCPのエラーチェック
・TCPのエラーチェックは、 データ部分も含める


TCP通信の効率化
・送達確認、再送制御が確実な通信を実現
　but. これは効率が悪い

① 数ms～ 数100ms
② 数μs～ 数100μs
③ ACKを待たず連続して送信

・セグメントを連続受信するには バッファが必要

① MSSの整数倍


① 送信データ

・スライディング・ウィンドウ制御（ ウィンドウ制御）

① ウィンドウ
② 16
③ MSS
④ 受信
⑤ 送信

ウィンドウ制御と再送制御
・確認応答が失われた場合
　・ウィンドウサイズがある程度以上あれば、確認応答が多少失われても、再送処理は 行われない


・送信セグメントが失われた場合
この現象は「 ヘッドオブラインブロック」と呼ばれる
（失われたセグメントの再送が完了するまで、後続セグメントの送信ができない）

① RTO
② 失われたセグメント

・送信セグメントが失われた場合（ SACKの利用）

① SACK
② シーケンス
③ 送受信双方
④ 届いていない
⑤ 送信済み

・送信セグメントが失われた場合（ 高速再送制御）

① 3つ
② 重複確認応答

通信状態に合わせた速度調節
・相手の処理速度に合わせる
　・ウィンドウ制御では、 送信側の都合でセグメントを送信
　・このとき、受信側が高負荷になっていると...
　　・セグメントの取りこぼし → セグメント再送 → 効率低下
　・ 受信側の能力に応じて通信量を制御（ 流量制御）
・ネットワークの状態に合わせる
　・混雑している状態で、大量のセグメント送信
　　・混雑増長 → セグメント喪失増加 → 再送増加 → 効率低下
　・ 混雑状況に応じて通信量を制御（ 輻輳制御）

流量制御（フロー制御）
・流量制御は 受信側が主導
・ ウィンドウサイズを変化させることで速度を制御
　・受信可能なウィンドウサイズを送信側に通知
　　・ウィンドウ更新通知
　・速度を落としたい
　　・ウィンドウサイズを 小さくする
　・速度を上げたい
　　・ウィンドウサイズを 大きくする
　・送信を止めたい
　　・ウィンドウサイズを 0にする（ ゼロウィンドウ）
　　　・ウィンドウ更新通知が失われると問題も...




① 送信停止
② 満杯


① 通信不能
② ウィンドウプローブ

遅延確認応答
・受信直後はウィンドウサイズが 小さいことがある
　・すぐに確認応答すると効率が 低下（RTTが大きいとき顕著）


・セグメント１つ1つに確認応答する 必要はない
　・多くの実装では、 2セグメントごとに確認応答


輻輳制御
・輻輳とは
　・ネットワークが混雑し、 セグメント喪失が起きる状態
　・ 輻輳崩壊
　　・セグメントの喪失や破棄が増加 → 再送も増加
　　・再送増加が混雑に拍車 → セグメント喪失・再送の悪循環
　　・ついにネットワーク帯域の許容量を超えてダウン
　　　・この事態は絶対に避けたい（通信を止めない限り回復は困難）
・輻輳制御の目的
　・ネットワークの 状態に対応する
　　・混雑したら速度を 下げ、空いていれば速度を 上げ続ける
　・輻輳が生じない限界近くの速度を できるだけ長く保つ

輻輳制御は難しい
・TCPからはネットワークの状態把握が困難
　・ネットワークは階層構造
　　・IPが下位層を抽象化
　　　・通信媒体の性質が、上位層からは 見えにくい
・TCP/IPには 中央集権的な制御機構がない
　・混雑状況に応じて、ユーザの振る舞いを制御できない
・インターネットは巨大で複雑
　・現実的なシミュレーションができない
　　・通信媒体やネットワーク機器類が多種多様で、常に変化
　　・新しいアプリケーションが次々に登場
　・昨日のインターネットは 今日のインターネットにあらず

TCPの輻輳制御の考え方
・ネットワーク状態は不明であることが前提
　・処理はできるだけ単純に
　　・セグメントが喪失しないとき
　　　・ネットワークは 空いている → 速度を上げる（上げ続ける）
　　・セグメントが喪失するとき
　　　・ネットワークは 混んでいる → 速度を下げる
　・ 送信側が主導して制御（中央制御は不可能）
　　・速度調節は、 輻輳ウィンドウで制御
　　　・輻輳ウィンドウ
　　　　　　　確認応答なしで送信するセグメント量を決めるパラメータ
　・基本は2つのアルゴリズム
　　・ スロースタートアルゴリズム
　　・ 輻輳回避アルゴリズム

TCPの輻輳制御アルゴリズム
・スロースタートアルゴリズム
　・混雑状態への大量セグメント送信
　　・ 輻輳状態を招く恐れが大きい → 周囲は迷惑
　・ネットワークの状態を探りながら 一気に速度を上げる
　　・輻輳ウィンドウサイズの初期値は、1MSS
　　・確認応答の数だけ輻輳ウィンドウのサイズを増やす
　　　・送信セグメントの数は、 指数関数的に増加
・輻輳回避アルゴリズム
　・輻輳を回避しながら、一定範囲の速度を維持する
　　・輻輳ウィンドウサイズを1づつ増やし、 ゆっくり速度を上げる
　　　・送信セグメントの数は、 直線的に増加

スロースタートアルゴリズム


輻輳回避アルゴリズム


セグメント喪失で限界速度を判断
・2つのアルゴリズムは速度を 上げ続けるのが基本
・再送発生時点が 限界速度
　・再送発生＝セグメント喪失＝輻輳状態
　　・これ以上の速度上昇は輻輳崩壊を招く → 速度を落とす
・限界点に達したときの処理
　・再送発生の状況により2種類
　　・再送タイムアウトの発生 → 混雑状況は深刻
　　　・スロースタート 閾値（しきい値）を設定
　　　　　設定値は、その時の輻輳ウィンドウサイズの 1/2
　　　・輻輳ウィンドウを1MSSにし、 スロースタートアルゴリズムを再開
　　・重複確認応答の受信 → 混雑状況は 軽微
　　　・スロースタート閾値まで減速し、 輻輳回避アルゴリズムを再開

アルゴリズムは状況に応じて働く

① スロースタート閾値

TCPの限界
・TCPの目的は、 信頼性と効率の両立
　・but, そのままでは回線の能力を生かしきれない
・なぜか？
　・効率（速度）向上の肝は ウィンドウ制御
　・ウィンドウサイズには 上限がある
　　・ウィンドウサイズは16bit長
　　・上限は2^16 = 65535byte＝64Kbyte
　・つまり、
　　・ 連続送信できるセグメントの数に上限がある

TCPの限界
・効率を スループットで定量化してみる
　・スループット＝ 単位時間当たりの伝送量([bit/s])
・TCPの最大スループット
　・ ウィンドウサイズと RTT（ Round Trip Time）で決まる

① 最大ウィンドウサイズ
② RTT




スループットを向上させるには
・ ウィンドウサイズを大きくする
　・ ウィンドウスケールオプションを使用
　　・ウィンドウサイズを最大2^14倍(1Gbyte)まで拡張可能
　　・but...　 送受信双方でサポートしていなければ使えない
　　　　　　同じ容量の受信バッファが必要
　　　　　　→1Gbyteものメモリをスループット向上に使うのは、 非現実的
・1つの通信で同時に使う コネクション数を増やす
　・Webの場合
　　・4～16コネクションで、文字や画像など種類別に同時並行送信
・ TCPをあきらめる
　・ UDPを使う
　　・必要な通信制御はアプリケーションで