剥き出しのパケットに「鎧」を着せる：TLSハンドシェイクが織りなす極限の暗号化戦略
ネットワークの深淵を覗くとき、私たちはしばしば「HTTP/1.1の確立」というフェーズに幻想を抱く。TCPの3ウェイ・ハンドシェイクが完了し、`SYN/ACK`が交換された瞬間、すべてが安全になったと錯覚する。しかし、現実のインターネットは荒野だ。暗号化されていないデータは、中継するルーターや悪意ある中間者（MitM）にとって格好の餌食となる。
本稿では、TCPコネクションが確立されたその直後、まさにパケットが流れる前の「静寂の数ミリ秒」で何が起きているのか、そして、我々アーキテクトがこのTLSハンドシェイクをいかに最適化すべきかについて、プロトコルの深層から紐解いていく。
—
TLSハンドシェイク：暗号化の「儀式」が費やす代償
TLS 1.2/1.3のハンドシェイクは、単なる鍵交換ではない。これはネットワークのRTT（Round Trip Time）を容赦なく削り取るコストの塊だ。
1. ClientHelloの重み
クライアントから送られる`ClientHello`には、サポートするCipher Suite（暗号スイート）やTLSバージョン、そして重要な`SNI (Server Name Indication)`が含まれる。ここで注目すべきは、パケットサイズだ。拡張機能（Extensions）を盛り込みすぎると、パケットがMTU（通常1500バイト）を超え、フラグメンテーションが発生する。これはTCPの初期輻輳ウィンドウ（initcwnd）の制限を食いつぶす悪手だ。
2. 暗号化までの「レイテンシ」を削る
TLSハンドシェイクは、往復回数に比例して遅延が増大する。
- TLS 1.2: 2往復（計2 RTT）が必要。
- TLS 1.3: 1往復（計1 RTT）に短縮。さらに`0-RTT`（Early Data）という劇薬も存在する。
アーキテクトとして推奨すべきは、当然ながらTLS 1.3の強制採用だ。これに加え、`Session Resumption`（セッション再開）を適切に構成することで、ハンドシェイクを省略し、0 RTTに近いレスポンスを実現できる。
—
現場で差がつく：Linuxカーネルとバッファのチューニング
TLSハンドシェイクを最適化しても、TCPスタックがボトルネックになっては意味がない。特に高トラフィックな環境では、以下のsysctlパラメータの調整が「勝負の分かれ目」となる。
TCPの初期輻輳ウィンドウを10に設定し、ハンドシェイク直後のバーストを許容する
これにより、TLSハンドシェイク完了後のデータ転送が劇的に高速化する
net.ipv4.tcp_init_cwnd = 10
メモリを潤沢に使い、TLSの暗号化負荷に耐えるためのバッファ拡大
128MBまでスケーリングを許可し、高RTT環境でもスループットを維持する
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
TCP Fast Openを有効化し、ハンドシェイクのRTTを1つ削減する
ただし、アプリケーション側が対応していることが前提
net.ipv4.tcp_fastopen = 3
—
ヘッダー圧縮とセキュリティの「諸刃の剣」
HTTP/1.1におけるヘッダーは冗長だ。リクエストごとに数キロバイトのテキストがそのまま流れる。ここで注意すべきは、圧縮アルゴリズム（HPACKなど）を狙った攻撃だ。
特に、圧縮前のデータと暗号化後のパケットサイズから元の値を推測するCRIME攻撃やBREACH攻撃は、今なお脅威である。HTTPレベルの圧縮（Gzip/Brotli）を有効にする際は、機密性の高いCookieやトークンが含まれるヘッダーを圧縮対象から除外（`Vary: Cookie`の適切な管理）する設計が、セキュリティスペシャリストとしての最低限の防衛線となる。
—
結論：パケットに「意図」を宿らせる
TLSハンドシェイクは、単なる通信の準備運動ではない。それは、通信の信頼性、速度、そしてセキュリティの品質を決定づける「設計図」そのものだ。
- TLS 1.3への完全移行
- TCP Fast Openと適切なバッファ設計
- MTUを考慮したClientHelloの最適化
これらを疎かにすることは、エンジンのチューニングをせずにレースカーを走らせるようなものだ。ネットワークアーキテクトに求められるのは、プロトコルスタックの隅々までを見通し、パケットが通過するあらゆるゲートウェイで、妥協のないチューニングを施すことにある。
次回の更新では、HTTP/2以降で重要視される「ストリーム多重化」と、その裏で暗躍する「HOLブロッキング」の解消策について、さらに深いレイヤーから切り込んでいこうと思う。技術の進化に置いていかれるな。常にパケットの先を走れ。
コメント