Tweet
Tweet

Slide 1

Slide 1 text

Chap. 24 TCPのその他の機能と性能 + TCP Fast Open & TLS False Start 詳解TCP/IP Vol.1 プロトコル @utushiiro

Slide 2

Slide 2 text

▷ Table of contents ○ Path MTU Discovery with TCP ○ Long Fat Pipe ○ Transaction TCP ■ TCP Accelerated Open ■ Truncate TIME_WAIT Delay ○ TCP Fast Open ○ TLS on TCP (TLS False Start)

Slide 3

Slide 3 text

パスMTUディスカバリ ▷ パスMTU ○ 2 台のホスト聞の経路上に存在するネットワーク中で 最も小さい M T U ○ ルータが転送するIPデータグラムをフラグメント化 するかを調べるためには, IPヘッダのDF(don’t fragment)ビット を使用する. ○ DFが設定されているデータグラムのサイズがルータのMTUを 超える場合, ICMPエラー(※)を返す. ※ Destination Unreachable/Fragmentation needed and Don’t Fragment was set

Slide 4

Slide 4 text

パスMTUディスカバリ 1. コネクション確立後, 送信インタフェースのMTUから計算したMSSと, 他方のエンドから通知されるMSSのうち小さいものを セグメントサイズの初期値とする. 2. 初期値設定後, そのコネクションのTCPで送られる(すべての) IPデータグラムにDFビットが設定される. 3. 中継ルータがフラグメント化が必要になる場合に ICMPにより送信元にそのホップのMTUを通知する. 4. これを受けてMTUを更新する.

Slide 5

Slide 5 text

▷ パスMTU機能のON/OFF ○ net.ipv4.ip_no_pmtu_disc (Linux) ○ net.inet.tcp.path_mtu_discovery (Mac) ▷ 最小MSS ○ net.ipv4.route.min_pmtu (Linux) ○ net.inet.tcp.minmss (Mac) MTU関連のカーネルパラメータ

Slide 6

Slide 6 text

DF bit on Mac & Linux TCPコネクションではパスMTUが有効だと DF ビットが設定される. ▷ Linux ○ すべてのIPデータグラムで設定される ▷ Mac ○ 一部のIPデータグラムには設定されていない ※ tcpdump tcp -vvvv で確認

Slide 7

Slide 7 text

Long Fat Pipe ▷ 帯域遅延積 ○ 通信帯域幅 ✕ RTT ▷ Long Fat Network (LFN) ○ 帯域遅延積の大きなネットワーク ○ RFC1072で10^5以上のものがLFN ▷ Long Fat Pipe ○ LFN上でのTCPコネクション

Slide 8

Slide 8 text

Long Fat Pipe上での問題点と対応 ▷ windowサイズ(16bit field)では不十分 ○ Window Scale Option ▷ パケット損失のコストが大きい ○ Selective Acknowledgement ▷ RTTの計測の間隔(window毎に一回)が長くなる ○ Time Stamp Option ▷ シーケンス番号だけでは一意に識別できない恐れ ○ Protection Against Wrapped Sequence これらはChap17, 18のスライドで説明済

Slide 9

Slide 9 text

Transaction/TCP TCPは仮想回線(コネクション指向)トランスポートサービス → コネクション確立・終了処理が伴う 数回のRequest/Responseで終わるような単純なサービスでは これらの処理はオーバーヘッドといえる よって, この種のサービスではUDPを使用することが多かった (e.g. DNS, SNMP) ただし, UDPを使うと信頼性を担保するためには 自前でそれらの機能を実装する必要がある

Slide 10

Slide 10 text

Transaction/TCP そこで, この種のサービスに適したTCPの拡張機能を作ろう → Transaction TCP(T/TCP, RFC1644) ※ここでのtransactionはDBの話で出てくるものとは関係ない T/TCPが提唱する機能は主に以下の２つ ▷ TCP Accelerated Open(TCP高速オープン) ○ 一定期間内での二回目以降のコネクション確立の際の 3 way handshakeを省略する仕組み ▷ TIME_WAIT状態とそれに要求される2MSL待ちを短縮する

Slide 11

Slide 11 text

T/TCPでのTCP Accelerated Open Connection Count(CC)と呼ばれる32bitのカウンタを利用 コネクションが確立される毎にCCは増加する → コネクション毎にCCの値は異なる ※CCは各ホスト(C1,C2,S)で独立, 上記の”増加”, “異なる”は特定ホスト内の話 C1 S CC: X C2 CC: Y SでのCCキャッシュ C1 = X C2 = Y

Slide 12

Slide 12 text

T/TCPでのTCP Accelerated Open C3 S CC: Z’ SでのCCキャッシュ C3 = Z C4 = None C4 CC: W ▷ Z’ > Z なら 3-way-handshake を省略 そうでないなら3-way-handshake実行 ▷ 該当ホストのCCキャッシュが そもそも存在しないなら3-way-handshake実行

Slide 13

Slide 13 text

T/TCPでのTCP Accelerated Open TCP Accelerated Open は要するに, 一度コネクションが確立できたら, 以後一定期間 そのホスト間での新規のコネクションの確立には 確立処理(3-way-handshake)をしなくても 確立できると考えて省略する仕組み. ※前スライドではCCのみを簡単に説明したが 　実際はもう少し色々あるのでRFC参照

Slide 14

Slide 14 text

T/TCPでのTIME_WAITの短縮 TIME_WAITとは アクティブクローズを行ったホストが, 自分から相手へのコネクショ ンは切断し終わり(FIN&ACK), 相手からのコネクション切断要求の FINが来て, ACKを送り返した状態. この状態で一定時間経過後に, 双方のコネクションが切断された状 態(CLOSED)に遷移する.

Slide 15

Slide 15 text

終了の状態遷移 FIN_WAIT_1 TIME_WAIT LAST_ACK CLOSE_WAIT FIN_WAIT_2 CLOSED CLOSED

Slide 16

Slide 16 text

TIME_WAIT → CLOSED はタイムアウトで遷移するが, このタイムアウト時間は 2MSL (Maximum Segment Linetime) MSL：TCPセグメントがネットワークで生存可能な時間の上限 FIN_WAIT_1 TIME_WAIT LAST_ACK CLOSE_WAIT FIN_WAIT_2 CLOSED CLOSED

Slide 17

Slide 17 text

なぜ 2 MSL ？ ▷ 最後のACKが喪失 → FIN が再送のケース ○ 最後のACKが相手に届くのに(最高でも)1MSL ○ これが損失して, 再送のFINが送られてくるのに1MSL ( ACKが２回以上紛失したらどうなるんだろうか？ 謎) CLOSED TIME_WAIT LAST_ACK CLOSED

Slide 18

Slide 18 text

この仕組みによって “信頼性の備えたコネクションの切断” を実現 もう一つのTIME_WAITの目的は “ネットワーク上の古い重複したセグメントの 期限切れを保証し, 再接続後の通信を阻害しない”

Slide 19

Slide 19 text

TCPは再送制御により, セグメントの重複が起きうる. あるコネクションを切断後に, 同一のIP・Portで新規接続する際に, 前のコネクションの重複したパケットが, 新しいコネクションに到着し て処理される恐れ(※)がある. このため, TCPは通信を行うホストの一方でもTIME_WAIT状態に ある場合は接続を拒否する. ※恐れ, としたのは基本的にはSequencingで弾かれる 　(sequence番号が不正でRSTを返す)ため.

Slide 20

Slide 20 text

サーバ等を再起動する際に , ソケットをTIME_WAITの状態にあるポートにbindしようと すると, EADDRINUSE(※)というエラーになる. とはいえ主要なTCPサーバソフトはこれを回避できる SO_REUSEADDRというオプションを有効にしているので, あんま起きない. ※Address already in use, アドレスは既に使用中です

Slide 21

Slide 21 text

TIME_WAITの短縮 TIME_WAITについて理解を深めたところで話を戻すと... TIME_WAITの短縮 → 2MSL(TIME_WAIT遅延)を短縮するということ 　 ホスト間で計測されたRTTをベースに 　 動的にTIME_WAIT遅延を算出 MSL短縮する場合, 古いコネクションのパケットが到着するかもし れない問題があるが, T/TCPではCCでコネクションを識別できるの で, 回避できる.

Slide 22

Slide 22 text

TCP Fast Open T/TCPは結局今使われているの？ → NO. セキュリティがガバガバ ただし, 同じようなアプローチ(※)でより精錬された プロトコルが誕生 → TCP Fast Open (RFC 7413) これは実際に使われている. ※ ２回目以降の3-way-handshakeをbypassingするという試み

Slide 23

Slide 23 text

TCP Fast Open TCP Fast Openでは T/TCPのCC(Connection Count)周りを より精錬された仕組み(TFO Cookie)に昇華 TFO Cookieとは サーバ側がクライアントのIPやサーバシークレットから暗号ア ルゴリズム(AES)を用いて作成するCookie クライアントは２回目以降の接続で使用するために サーバから受け取ったCookieをキャッシュする

Slide 24

Slide 24 text

TCP Fast Open - 初回通信 SYN + Cookie Request SYN, ACK + Cookie ACK サーバ側 Requestを受けて TFO Cookieを作成 クライアント側 送られてきた TFO Cookieを キャッシュする

Slide 25

Slide 25 text

TCP Fast Open - 初回以降の通信 SYN + Cookie + Data SYN, ACK + Data ACK サーバ側 受信したTFO Cookieを検証する 検証をパスすれば SYN, ACKのパケットに データを付加して送信 データ送信まで1RTTかかる (これを1-RTTと呼ぶ)のを0-RTTに

Slide 26

Slide 26 text

TLS on TCP SYN SYN, ACK ACK TLS Client Hello & etc TLS Server Hello & etc TLS Client Finished & etc Data(encrypted) TLS Server Finished & etc ▷ 通常のTLS on TCP クライアント, サーバの双方が Finishedを送受信し終えてから Dataの送受信へと進む つまり通常のTLS on TCPは 3-RTT

Slide 27

Slide 27 text

TLS False Start SYN SYN, ACK ACK TLS Client Hello & etc TLS Server Hello & etc TLS Client Finished & etc TLS Server Finished & etc Data(encrypted) ▷ TLS False Start Finishedを送信し終えたら 相手方からのFinished到着を 待たずにDataの送信を開始する これで 3-RTT が 2-RTT に

Slide 28

Slide 28 text

TCP Fast Open + TLS False Start SYN + Cookie + TLS Client Hello & etc SYN, ACK + TLS Server Hello & etc ACK + TLS Client Finished & etc Data(encrypted) TLS Server Finished & etc TFOと合わせることで 3-RTT が 1-RTT に！ TLS v3では 0-RTTを 目指してるっぽい セキュリティ的にいろいろ 厳しそうだけど...

Slide 29

Slide 29 text

TLS補足 TLS False Startは厳密にはセキュアではなくなる RFC 7918 Sec.4 中間者攻撃を受ける恐れがあるが 上記のRFCで定めている条件下での運用であれば 深刻という程ではない(たぶん) TLS等のセキュリティの話がわからない場合は 以下の本の内容程度は知っておこう (授業でやってるハズ) 暗号技術入門 第3版 秘密の国のアリス

Slide 30

Slide 30 text

Reference & Credit ▷ W. Richard Stevens. 1993. TCP/IP Illustrated (Vol. 1): The Protocols. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA. ▷ Presentation template by SlidesCarnival