リクエスト多重化の系譜

「1本の接続で複数のリクエストを重ねたい」という同じ主題が、HTTPの歴史で形を変えて 3度実装された系譜を辿る順路です。個々の仕様は独立の発明に見えますが、並べると 同じ問題への周回として読めます。

最初の周回はHTTP/1.1のpipeliningです。永続接続を前提に、応答を待たずに複数の リクエストを送ることを認めましたが、サーバーは受け取った順に応答を返す必要が ありました出典。のちのHTTP/2の仕様は、この方式が並行性を部分的にしか 解決せず先頭の詰まり（head-of-line blocking）が残ったこと、実際にはクライアントが 複数の接続を張って並行性を確保していたことを記録しています出典。

2度目の周回はSPDYを出発点とするstream多重化です。HTTP/2は1本のTCP接続の上で 複数のstreamを混在させ、アプリケーション層の多重化を実現しました出典。 それでも輸送層がTCPである限り、1つのパケット損失がすべてのやり取りを止める 詰まりは残りました出典。

3度目の周回は、輸送層ごと作り直す道です。QUICはstream単位の多重化とflow control を輸送層に組み込み、その上のHTTP/3は、あるstreamの損失が他のstreamを止めない形に 到達しました出典。

この順路を3行で言うと——

1. 主題は一貫して「1本の接続で複数のリクエストを重ねる」。HTTP/1.1のpipelining （1997〜1999年）が最初の周回だった。

2. 周回ごとの差分は実装の層。応答順序に縛られたpipeliningから、アプリケーション層の stream多重化（SPDY・HTTP/2、2009〜2015年）へ、そして輸送層の多重化（QUIC・HTTP/3、 2021〜2022年）へと、詰まりの場所が一段ずつ深く特定されていった。

3. 周回はおよそ12年おきに始まっている（1997年・2009年・2021年）。同じ主題が 層を掘り下げながら回る、螺旋の系譜である。