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
950
Dynamic Routing Protocols
utsushiiro
0
110
TCP
utsushiiro
0
100
Other Decks in Programming
See All in Programming
iOSエンジニア向けの英語学習アプリを作る!
yukawashouhei
0
170
WebエンジニアがSwiftをブラウザで動かすプレイグラウンドを作ってみた
ohmori_yusuke
0
170
CSC509 Lecture 05
javiergs
PRO
0
290
iOS 17で追加されたSubscriptionStoreView を利用して5分でサブスク実装チャレンジ
natmark
0
580
ネイティブ製ガントチャートUIを作って学ぶUICollectionViewLayoutの威力
jrsaruo
0
130
AI Coding Meetup #3 - 導入セッション / ai-coding-meetup-3
izumin5210
0
580
2分台で1500examples完走!爆速CIを支える環境構築術 - Kaigi on Rails 2025
falcon8823
3
3.1k
overlayPreferenceValue で実現する ピュア SwiftUI な AdMob ネイティブ広告
uhucream
0
110
Playwrightはどのようにクロスブラウザをサポートしているのか
yotahada3
7
2.3k
どの様にAIエージェントと 協業すべきだったのか?
takefumiyoshii
2
600
CSC305 Lecture 02
javiergs
PRO
1
260
ソフトウェア設計の実践的な考え方
masuda220
PRO
3
480
Featured
See All Featured
We Have a Design System, Now What?
morganepeng
53
7.8k
Fireside Chat
paigeccino
40
3.7k
Into the Great Unknown - MozCon
thekraken
40
2.1k
Art, The Web, and Tiny UX
lynnandtonic
303
21k
Site-Speed That Sticks
csswizardry
11
880
Documentation Writing (for coders)
carmenintech
75
5k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
53k
How STYLIGHT went responsive
nonsquared
100
5.8k
Agile that works and the tools we love
rasmusluckow
331
21k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
6.1k
Visualization
eitanlees
148
16k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
9
580
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