全2602文字

 HTTP/3は、前回解説したQUICを採用することで従来のHTTPよりも様々な点が改善されている。ここからはHTTP/3のそれぞれの利点を見ていこう(図1)。

図1●HTTP/3の主な利点
図1●HTTP/3の主な利点
接続開始時の遅延がHTTP/2よりも小さいため、大量の通信を効率的に行うことができる。また、パケットロスが発生してパケットを再送する場合でも、並行して他のパケットを送れるため、速度低下を抑えられる。ほとんどの情報を暗号化するため、攻撃を受けにくい。接続するネットワークが変わっても通信を継続できるという利点もある。
[画像のクリックで拡大表示]

 まず、接続開始時の遅延が小さい点だ。HTTP/3ではTCPを使わないため、3ウエイハンドシェークが存在しない(図2)。TLS 1.3のハンドシェークを使って通信を始める。このためハンドシェークの直後から暗号通信できる。

図2●ハンドシェークを大幅に削減
図2●ハンドシェークを大幅に削減
HTTP/3ではTCPを使わないため3ウエイハンドシェークがなく、いきなりTLS 1.3のハンドシェークを行って暗号通信を開始する。さらに、再接続の際には、TLS 1.3の0-RTTの機能を利用してハンドシェークなしで通信を開始できる。
[画像のクリックで拡大表示]

 さらに、いったん通信した相手に再び接続する際には、TLS 1.3の0-RTTの機能を利用してハンドシェークなしで通信を開始できる。そもそも0-RTTはグーグル版QUICが搭載していた機能であり、これがTLS 1.3にも採用されたという経緯がある。

 このようにハンドシェークにかかる時間を大幅に削減し、従来のHTTPよりも接続開始時の遅延を抑えている。

TCPコネクションに縛られない

 次が、パケットロス時の速度低下の軽減だ。従来のHTTPには、1組のリクエストとレスポンスしか同時に送受信できないという制限があり、これがWebアクセスに時間がかかる原因になっていた。

 これを防ぐため、HTTP/1.1にはHTTPパイプラインという機能が導入された。応答を待つことなく複数のリクエストを送る機能だ。ただし、リクエストの順番とレスポンスの順番が同じでなければならないという制限があり、これがボトルネックになっていた。

 この問題を解決したのがHTTP/2のストリームという機能だ。ストリームという仮想的な通信路を複数作り、同時に複数の通信を行える。これにより、リクエスト/レスポンスの順番を気にせずに送受信できるようになった。

 ただし、HTTP/2はTCPを利用するため、「1本のTCPコネクションでしか通信できない」という制限は依然として残っている。例えば、パケットロスが発生してパケットを再送している間、後続のパケットが送れなくなってしまうという問題がある。

 一方、HTTP/3はTCPを使わないため、このような問題が起こらない。QUICでは複数のストリームを使って並行してパケットを送れるようになっている(図3)。パケットロスが発生してパケットを再送する場合でも、他のストリームを使って後続のパケットを送ることができる。これにより、HTTP/2よりもパケットロス時の速度低下を抑えられる。

図3●複数のストリームを使って同時に通信できる
図3●複数のストリームを使って同時に通信できる
HTTP/2では1本のTCPコネクションの中で通信を行うため、例えばパケットロスが発生してパケットを再送する間は他のパケットが送れなくなってしまう。これに対してHTTP/3では複数のストリームを使って並行してパケットを送れるため、パケットロスが発生しても他のパケットが送れなくなることはない。
[画像のクリックで拡大表示]