Our Battlefield

HTTPはわたしたちの主戦場だ。

HTTP/1.1の時代は長かった。1本のTCPコネクションで1リクエスト。並列に取りたければコネクションを複数張る。ブラウザは同一ドメインに6本までという制限があった。だからCDNのドメインを分けてシャーディングしたり、画像をスプライトにまとめたり、小手先の最適化が横行していた。

GoogleがSPDYを出してきたとき、ようやく本質的な解決が見えた。1本のコネクションで複数のリクエストを多重化する。ヘッダを圧縮する。サーバープッシュもできる。SPDYがそのままHTTP/2の土台になり、役目を終えた。いまではどのブラウザもSPDYをサポートしていない。

HTTP/3はさらに踏み込んだ。TCPをやめてQUICに乗り換えた。UDPの上に信頼性のある通信を再実装している。TCPのヘッドオブラインブロッキングから解放される。モバイルでIPアドレスが変わっても接続が切れない。理屈は美しい。

ところが現実は面倒だ。HTTP/2の検証をしていたとき、どうしても有効にならなくてどハマりしたことがある。原因は自分のPCに入れていたファイアウォールソフトだった。そのFWがTLS通信を中間者として覗くために、HTTP/2のALPNネゴシエーションを潰していたのだ。検証で延々と切り分けて、ようやく辿り着いた。HTTPのバージョンの問題ではなく、間に挟まるものの問題だった。

間に挟まるもので言えば、SSLアクセラレータという時代もあった。SSLの計算コストをケチっていた時代だ。TLSの暗号化処理が重かった頃、専用ハードウェアでオフロードする。ロードバランサでSSLを終端して、バックエンドにはHTTPで流す。LBとアプリサーバーの間は平文だ。内部ネットワークだから問題ない、ということになっていた。LBでSSLを終端する構成はいまでも多いが、当時はSSLの計算コスト自体が真剣な課題だった。

いまではLB間も暗号化するのが当たり前になりつつある。ゼロトラストの文脈で、内部通信も信頼しない。SSLを終端して平文に戻すのではなく、mTLSで端から端まで暗号化する。

HTTPの仕様はどんどん進化するが、間に挟まるものがいつも足を引っ張る。プロトコルの敵はプロトコルではなく、中間者だ。