【テクニカル・上級編】 HTTPS(TLS)ハンドシェイクとTCP接続の順序 – ネットワーク基礎とWebセキュリティ実践ガイド

「3-wayの手先で踊らされるな」：TLSハンドシェイクの深淵とRTT削減の戦い

ネットワークエンジニアの諸君、今日もパケットの海を泳いでいるか。

我々が何気なく叩く curl や、ブラウザが裏で繰り広げるHTTPS通信。その背後では、光の速さで物理的距離を往復するパケットたちが、極めて緻密なプロトコルスタックの儀式を執り行っている。

「TCP接続が確立したから安心だ」などと油断してはいないだろうか？現代のWebセキュリティにおいて、TCPの SYN/ACK が完了した時点では、まだ通信のスタートラインにすら立っていない。今回は、TCPの確立からTLS暗号化が始まるまでの「空白の数ミリ秒」に焦点を当て、インフラアーキテクトが知るべき最適化の極意を紐解いていく。

—

TCP 3-way handshake：全ての悲劇はここから始まる

まずは基本の復習だが、あえて「レイテンシ」の観点から掘り下げよう。

TCPの 3-way handshake（SYN → SYN/ACK → ACK）は、物理的な往復（RTT）を1.5回分消費する。この時間は、光ファイバーの物理的距離と、ルーター・ロードバランサーの処理能力に完全に依存する。

もし君が東京のサーバーからロンドンのクライアントに向けてサービスを提供しているなら、これだけで200ms近い遅延が確定する。まだ、アプリケーションの GET リクエストすら投げていないのにだ。

ネットワーク層でのチューニング：TCPバッファと初期ウィンドウ

Linuxカーネルにおいて、この初期接続を最適化するには、tcp_init_cwnd（初期輻輳ウィンドウ）の調整が不可欠だ。デフォルトの10セグメントでは、現代の重厚なWebページを読み込むには少なすぎる。

# sysctlでの初期輻輳ウィンドウの拡大（TCP接続直後のスループット向上）
# 10から16~20程度に引き上げることで、最初のACKを待たずに多くのデータを送り込める
sysctl -w net.ipv4.tcp_init_cwnd=16

—

TLSハンドシェイク：暗号化の代償と最適化の戦場

TCPが繋がった直後、いよいよ TLS ClientHello が放たれる。ここが「パフォーマンスの墓場」だ。

従来のTLS 1.2では、公開鍵交換や証明書検証を含め、さらに複数回のRTTが発生していた。だが、現代の基準である TLS 1.3 は、このプロセスを劇的に簡素化した。

TLS 1.3の「1-RTTハンドシェイク」

TLS 1.3では、クライアントが ClientHello と同時に鍵交換の予測値（Key Share）を送りつける。これにより、サーバー側が即座に ServerHello で応答し、暗号化通信を確立できる。

もし君のインフラが未だにTLS 1.2のネゴシエーションに固執しているなら、それはアーキテクトとしての怠慢だと言わざるを得ない。

0-RTT（Early Data）という諸刃の剣

さらなる高速化を目指すなら、TLS 1.3の 0-RTT が選択肢に入る。これは前回のセッション情報をキャッシュし、初回通信から暗号化データを送る機能だが、リプレイ攻撃への耐性には細心の注意が必要だ。

# NginxでのTLS 1.3および0-RTTの推奨設定
ssl_protocols TLSv1.3;
ssl_early_data on; # 0-RTTを有効化。副作用としてリプレイ攻撃のリスクがあるため、冪等なリクエストのみに限定せよ

—

現場のトラブルシューティング：なぜ「空白時間」は生まれるのか？

現場でよくある「妙にレスポンスが遅い」という苦情。その犯人は往々にしてMTUサイズとパケット断片化、あるいは証明書のチェーン検証にある。

1. MTUの不一致: パケットが1500バイトを超えて断片化されると、中継ルーターで再構築のオーバーヘッドが発生する。ping -M do -s 1472 で経路の最大MTUを確認する癖をつけろ。
2. 証明書の肥大化: ServerHello で送信される証明書チェーンが大きすぎると、TCPの初期ウィンドウで送りきれず、余分なRTTが発生する。中間証明書は必要最小限に絞れ。
3. OCSP Staplingの欠如: サーバーが証明書の有効性を証明するために、わざわざクライアントに検証用URLを引かせていないか？ OCSP Stapling を有効にして、サーバー側で検証結果を握りしめておけ。

—

総括：境界防御の先にある「透過的な速さ」

ゼロトラストアーキテクチャにおいて、ネットワークは常に「信頼できないもの」として扱う。しかし、その信頼できない経路をいかに高速に、かつ堅牢に維持するかは、エンジニアの腕の見せ所だ。

TCP: init_cwnd の調整と BBR 輻輳制御アルゴリズムの採用。
TLS: TLS 1.3への強制移行と OCSP Stapling の徹底。
アーキテクチャ: エッジコンピューティング（CDN）を活用し、物理的なRTTを最小化する。

パケットは嘘をつかない。君が設定したパラメーターの一つ一つが、巡り巡ってユーザーの体験とシステムのセキュリティを形作る。

次のデプロイでは、単に「繋がった」で満足せず、tcpdump でパケットのシーケンス番号とハンドシェイクの経過時間を眺めてみてほしい。そこには、君のインフラの「真の姿」が映し出されているはずだ。

健闘を祈る。