QUIC ではさらに、輻輳制御と切断回復機能の向上という多大な利点があります。パケットの再送信時に、パケット シーケンス番号が再利用されることはありません。これによって不明瞭なパケット受信が発生せず、再通信タイムアウトを回避できます。結果として、接続状況が良好でない状況において QUIC は TCP よりも優れた接続を行うことができます。最も遅い 1% の接続状況においても、Google 検索ページの読み込みを大幅に削減できます。 こうしたメリットは、Youtube などの動画サービスではより顕著になります。QUIC 接続での動画視聴の際に、再バッファ時間が 30% 削減されるという報告もなされており、視聴時間が短縮されることで、繰り返し、より多くの動画を視聴できるようになっています。
現在、Chrome から Google サーバーへのおよそ半数のリクエストが QUIC で行われており、今後も QUIC のトラフィックを増やしていく方針です。最終的には QUIC を、Chrome とモバイルアプリの双方で、Google のクライアントから Google のサーバーへの通信規格のデフォルトにする予定です。インターネット標準として IETF に QUIC を正式に提案する予定ですが、その前にワイヤーフォーマットを変更したり、リファレンス実装を SPDY - QUIC から HTTP2 - QUIC に更新したりするなど、いくつかの解決すべき点があります。今後数か月で、応答確認時のオーバーヘッドを低減しサーバー側での拡張性を高め、前方誤り訂正や輻輳制御の向上、マルチパス接続のサポートの追加などに取り組む予定です。
状況を確認したり実際に試すには、
コードや
こちらのページをご確認ください。また、
[email protected]にもご参加ください。一歩ずつ、インターネットを改良し続けます。
Posted by
Eiji Kitamura - Developer Relations Team
