LinuCレベル4 システムアーキテクト 性能・拡張性の設計 問3
性能・拡張性の設計／性能の改善モバイル回線からの利用が多くパケット損失が頻発するWebサービスで、1本の接続で多数の小さなリソースを多重化して取得している。1つのパケットが失われると、その再送を待つ間ほかのリソースの受信まで止まってしまう現象を軽減したい。採用する方式として最も適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「性能・拡張性の設計」に対応。実際の試験問題ではありません）
- AHTTP/2を使い、1本のTCP接続の上でストリームを多重化してリソースを並行して取得する
- BHTTP/1.1のまま、ブラウザがサーバーへ張る並列のTCP接続の数を増やして取得を並行させる
- CUDP上のQUICを使うHTTP/3を採用し、ストリームごとに独立して再送と順序制御を行わせる
- Dサーバー側でTCPの初期輻輳ウィンドウを大きくし、接続直後から多くのデータを送れるようにする
正解：C
解説
HTTP/2はストリームを多重化しますが、下位のTCPが1本のバイト列として順序を保証するため、1つのパケットが失われると再送が届くまで後続のすべてのストリームのデータが待たされます（TCPレベルのヘッドオブラインブロッキング）。HTTP/3はUDP上のQUICで動作し、QUICがストリームごとに独立して再送と順序制御を行うため、損失の影響がそのパケットを含むストリームだけに限られます。QUICはTLS 1.3を組み込んで接続確立の往復を減らし、ネットワークが切り替わっても接続を維持できるといった、モバイル環境に有利な特性も持ちます。一方で、UDPの443番ポートが途中の機器で遮断されていないかを確認し、HTTP/2へのフォールバックを用意しておく必要があります。
選択肢ごとの解説
- A誤り。ストリームは多重化されますが、1本のTCP接続が順序を保証するため、パケット損失時に全ストリームが待たされる問題は残ります。
- B誤り。ブラウザが1つのサーバーに張る並列接続の数には上限があり、サーバー側から増やすこともできません。各接続では応答を1つずつ順に返すため、多数のリソースは接続ごとに順番待ちとなり、ハンドシェイクや輻輳制御のオーバーヘッドも増えます。
- C正しい。QUICはストリーム単位で再送と順序制御を行うため、1つのパケット損失がほかのリソースの受信を止めません。
- D誤り。接続直後の転送量は増えますが、パケット損失時に後続データが再送を待たされる仕組みは変わらず、損失が多い環境では効果が限られます。