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
800
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
600
メールの仕組み
utsushiiro
4
940
Dynamic Routing Protocols
utsushiiro
0
110
TCP
utsushiiro
0
99
Other Decks in Programming
See All in Programming
AI時代のUIはどこへ行く?
yusukebe
18
8.8k
Azure SRE Agentで運用は楽になるのか?
kkamegawa
0
2.2k
FindyにおけるTakumi活用と脆弱性管理のこれから
rvirus0817
0
500
Kiroの仕様駆動開発から見えてきたAIコーディングとの正しい付き合い方
clshinji
1
210
Performance for Conversion! 分散トレーシングでボトルネックを 特定せよ
inetand
0
140
詳解!defer panic recover のしくみ / Understanding defer, panic, and recover
convto
0
240
ソフトウェアテスト徹底指南書の紹介
goyoki
1
150
Introducing ReActionView: A new ActionView-compatible ERB Engine @ Rails World 2025, Amsterdam
marcoroth
0
680
「待たせ上手」なスケルトンスクリーン、 そのUXの裏側
teamlab
PRO
0
500
CloudflareのChat Agent Starter Kitで簡単!AIチャットボット構築
syumai
2
480
print("Hello, World")
eddie
2
530
Kiroで始めるAI-DLC
kaonash
2
580
Featured
See All Featured
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
51
5.6k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
48
9.7k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Become a Pro
speakerdeck
PRO
29
5.5k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
61k
How to train your dragon (web standard)
notwaldorf
96
6.2k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
4k
Bash Introduction
62gerente
615
210k
Writing Fast Ruby
sferik
628
62k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
188
55k
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