Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
TCPその他の機能と性能 + TCP Fast Open + TLS False Start
Search
Haru(utsushiiro)
May 01, 2017
Programming
1
650
TCPその他の機能と性能 + TCP Fast Open + TLS False Start
Haru(utsushiiro)
May 01, 2017
Tweet
Share
More Decks by Haru(utsushiiro)
See All by Haru(utsushiiro)
Webを早くする技術(HTTP)
utsushiiro
1
520
メールの仕組み
utsushiiro
4
820
Dynamic Routing Protocols
utsushiiro
0
90
TCP
utsushiiro
0
82
Other Decks in Programming
See All in Programming
Flutterを言い訳にしない!アプリの使い心地改善テクニック5選🔥
kno3a87
1
220
デザインパターンで理解するLLMエージェントの作り方 / How to develop an LLM agent using agentic design patterns
rkaga
9
1.4k
Outline View in SwiftUI
1024jp
1
350
ECS Service Connectのこれまでのアップデートと今後のRoadmapを見てみる
tkikuc
2
260
2024/11/8 関西Kaggler会 2024 #3 / Kaggle Kernel で Gemma 2 × vLLM を動かす。
kohecchi
5
970
React CompilerとFine Grained Reactivityと宣言的UIのこれから / The next chapter of declarative UI
ssssota
5
710
受け取る人から提供する人になるということ
little_rubyist
0
260
カンファレンスの「アレ」Webでなんとかしませんか? / Conference “thing” Why don't you do something about it on the Web?
dero1to
1
120
3rd party scriptでもReactを使いたい! Preact + Reactのハイブリッド開発
righttouch
PRO
1
610
TypeScript Graph でコードレビューの心理的障壁を乗り越える
ysk8hori
3
1.2k
Less waste, more joy, and a lot more green: How Quarkus makes Java better
hollycummins
0
100
Realtime API 入門
riofujimon
0
150
Featured
See All Featured
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Unsuck your backbone
ammeep
668
57k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
169
50k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
Measuring & Analyzing Core Web Vitals
bluesmoon
4
140
Intergalactic Javascript Robots from Outer Space
tanoku
269
27k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Building Your Own Lightsaber
phodgson
103
6.1k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.2k
GitHub's CSS Performance
jonrohan
1030
460k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
24k
Transcript
Chap. 24 TCPのその他の機能と性能 + TCP Fast Open & TLS False
Start 詳解TCP/IP Vol.1 プロトコル @utushiiro
▷ 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)
パス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
パスMTUディスカバリ 1. コネクション確立後, 送信インタフェースのMTUから計算したMSSと, 他方のエンドから通知されるMSSのうち小さいものを セグメントサイズの初期値とする. 2. 初期値設定後, そのコネクションのTCPで送られる(すべての) IPデータグラムにDFビットが設定される.
3. 中継ルータがフラグメント化が必要になる場合に ICMPにより送信元にそのホップのMTUを通知する. 4. これを受けてMTUを更新する.
▷ パス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関連のカーネルパラメータ
DF bit on Mac & Linux TCPコネクションではパスMTUが有効だと DF ビットが設定される. ▷
Linux ◦ すべてのIPデータグラムで設定される ▷ Mac ◦ 一部のIPデータグラムには設定されていない ※ tcpdump tcp -vvvv で確認
Long Fat Pipe ▷ 帯域遅延積 ◦ 通信帯域幅 ✕ RTT ▷
Long Fat Network (LFN) ◦ 帯域遅延積の大きなネットワーク ◦ RFC1072で10^5以上のものがLFN ▷ Long Fat Pipe ◦ LFN上でのTCPコネクション
Long Fat Pipe上での問題点と対応 ▷ windowサイズ(16bit field)では不十分 ◦ Window Scale Option
▷ パケット損失のコストが大きい ◦ Selective Acknowledgement ▷ RTTの計測の間隔(window毎に一回)が長くなる ◦ Time Stamp Option ▷ シーケンス番号だけでは一意に識別できない恐れ ◦ Protection Against Wrapped Sequence これらはChap17, 18のスライドで説明済
Transaction/TCP TCPは仮想回線(コネクション指向)トランスポートサービス → コネクション確立・終了処理が伴う 数回のRequest/Responseで終わるような単純なサービスでは これらの処理はオーバーヘッドといえる よって, この種のサービスではUDPを使用することが多かった (e.g. DNS,
SNMP) ただし, UDPを使うと信頼性を担保するためには 自前でそれらの機能を実装する必要がある
Transaction/TCP そこで, この種のサービスに適したTCPの拡張機能を作ろう → Transaction TCP(T/TCP, RFC1644) ※ここでのtransactionはDBの話で出てくるものとは関係ない T/TCPが提唱する機能は主に以下の2つ ▷
TCP Accelerated Open(TCP高速オープン) ◦ 一定期間内での二回目以降のコネクション確立の際の 3 way handshakeを省略する仕組み ▷ TIME_WAIT状態とそれに要求される2MSL待ちを短縮する
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
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実行
T/TCPでのTCP Accelerated Open TCP Accelerated Open は要するに, 一度コネクションが確立できたら, 以後一定期間 そのホスト間での新規のコネクションの確立には
確立処理(3-way-handshake)をしなくても 確立できると考えて省略する仕組み. ※前スライドではCCのみを簡単に説明したが 実際はもう少し色々あるのでRFC参照
T/TCPでのTIME_WAITの短縮 TIME_WAITとは アクティブクローズを行ったホストが, 自分から相手へのコネクショ ンは切断し終わり(FIN&ACK), 相手からのコネクション切断要求の FINが来て, ACKを送り返した状態. この状態で一定時間経過後に, 双方のコネクションが切断された状
態(CLOSED)に遷移する.
終了の状態遷移 FIN_WAIT_1 TIME_WAIT LAST_ACK CLOSE_WAIT FIN_WAIT_2 CLOSED CLOSED
TIME_WAIT → CLOSED はタイムアウトで遷移するが, このタイムアウト時間は 2MSL (Maximum Segment Linetime) MSL:TCPセグメントがネットワークで生存可能な時間の上限
FIN_WAIT_1 TIME_WAIT LAST_ACK CLOSE_WAIT FIN_WAIT_2 CLOSED CLOSED
なぜ 2 MSL ? ▷ 最後のACKが喪失 → FIN が再送のケース ◦
最後のACKが相手に届くのに(最高でも)1MSL ◦ これが損失して, 再送のFINが送られてくるのに1MSL ( ACKが2回以上紛失したらどうなるんだろうか? 謎) CLOSED TIME_WAIT LAST_ACK CLOSED
この仕組みによって “信頼性の備えたコネクションの切断” を実現 もう一つのTIME_WAITの目的は “ネットワーク上の古い重複したセグメントの 期限切れを保証し, 再接続後の通信を阻害しない”
TCPは再送制御により, セグメントの重複が起きうる. あるコネクションを切断後に, 同一のIP・Portで新規接続する際に, 前のコネクションの重複したパケットが, 新しいコネクションに到着し て処理される恐れ(※)がある. このため, TCPは通信を行うホストの一方でもTIME_WAIT状態に ある場合は接続を拒否する.
※恐れ, としたのは基本的にはSequencingで弾かれる (sequence番号が不正でRSTを返す)ため.
サーバ等を再起動する際に , ソケットをTIME_WAITの状態にあるポートにbindしようと すると, EADDRINUSE(※)というエラーになる. とはいえ主要なTCPサーバソフトはこれを回避できる SO_REUSEADDRというオプションを有効にしているので, あんま起きない. ※Address already
in use, アドレスは既に使用中です
TIME_WAITの短縮 TIME_WAITについて理解を深めたところで話を戻すと... TIME_WAITの短縮 → 2MSL(TIME_WAIT遅延)を短縮するということ ホスト間で計測されたRTTをベースに 動的にTIME_WAIT遅延を算出 MSL短縮する場合,
古いコネクションのパケットが到着するかもし れない問題があるが, T/TCPではCCでコネクションを識別できるの で, 回避できる.
TCP Fast Open T/TCPは結局今使われているの? → NO. セキュリティがガバガバ ただし, 同じようなアプローチ(※)でより精錬された プロトコルが誕生
→ TCP Fast Open (RFC 7413) これは実際に使われている. ※ 2回目以降の3-way-handshakeをbypassingするという試み
TCP Fast Open TCP Fast Openでは T/TCPのCC(Connection Count)周りを より精錬された仕組み(TFO Cookie)に昇華
TFO Cookieとは サーバ側がクライアントのIPやサーバシークレットから暗号ア ルゴリズム(AES)を用いて作成するCookie クライアントは2回目以降の接続で使用するために サーバから受け取ったCookieをキャッシュする
TCP Fast Open - 初回通信 SYN + Cookie Request SYN,
ACK + Cookie ACK サーバ側 Requestを受けて TFO Cookieを作成 クライアント側 送られてきた TFO Cookieを キャッシュする
TCP Fast Open - 初回以降の通信 SYN + Cookie + Data
SYN, ACK + Data ACK サーバ側 受信したTFO Cookieを検証する 検証をパスすれば SYN, ACKのパケットに データを付加して送信 データ送信まで1RTTかかる (これを1-RTTと呼ぶ)のを0-RTTに
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
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 に
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を 目指してるっぽい セキュリティ的にいろいろ 厳しそうだけど...
TLS補足 TLS False Startは厳密にはセキュアではなくなる RFC 7918 Sec.4 中間者攻撃を受ける恐れがあるが 上記のRFCで定めている条件下での運用であれば 深刻という程ではない(たぶん)
TLS等のセキュリティの話がわからない場合は 以下の本の内容程度は知っておこう (授業でやってるハズ) 暗号技術入門 第3版 秘密の国のアリス
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