Experimenting with QUIC (和訳)

も和訳してみました。

和訳

Thursday, Jun27, 2013
Experimenting with QUIC

2013年6月27日木曜日
QUIC を用いた実験。

At Google, we're always working to make the web faster. The SPDY protocol, which is now the foundation of the upcoming HTTP 2.0 protocol, is a significant step forward. However, despite increasing bandwidth, round trip time (RTT)--which is ultimately bounded by the speed of light--is not decreasing, and will remain high on mobile networks for the foreseeable future. To continue improving network performance we need to decrease the number of round trips, something that is difficult with protocols that currently rely on the Transmission Control Protocol (TCP).

Google で私たちは常にウェブの高速化に取り組んでいます。 SPDY プロトコル(現在、次にくる HTTP 2.0 プロトコルの基礎)は重要な一歩です。しかし、帯域幅が増大しても、究極的には光の速度で制限される round trip time (RTT)は減少せず、未来のモバイルネットワークでも高いままだと予想されます。ネットワーク性能を改善し続ける為には round trip の回数を減らす必要があり、それは現在の Transmission Control Protocol (TCP) に依存するプロトコルでは困難です。

QUIC (Quick UDP Internet Connections) is an early-stage network protocol we are experimenting with that runs a stream multiplexing protocol over a new flavor of Transport Layer Security (TLS) on top of UDP instead of TCP. QUIC combines a carefully selected collection of techniques to reduce the number of round trips we need as we surf the Internet. You can learn more in the design document, but here are some of the highlights:

QUIC (Quick UDP Internet Connection) は、TCP の代わりに UDP 上で Transport Layer Security(TLS) の新しい味付けの上にストリーム多重化プロトコルを実行し、私たちが実験している初期段階のネットワーク・プロトコルです。QUIC は、私たちがインターネットをサーフィンするのに必要な round trips の数を減少させるために厳選したテクニック集を組み合わせます。あなたは設計ドキュメントで更に学ぶことができますが、ここにハイライトの幾つかがあります:

  • High security similar to TLS
  • Fast (often 0-RTT) connectivity similar to TLS Snapstart combined with TCP Fast Open
  • Packet pacing to reduce packet loss
  • Packet error correction to reduce retransmission latency
  • UDP transport to avoid TCP head-of-line blocking
  • A connection identifier to reduce reconnections for mobile clients
  • A pluggable congestion control mechanism
  • TLS と同様の高いセキュリティ
  • TCP Fast Open と TLS Snapstart を組み合わせたのと同様の速い(しばしば 0-RTT の)接続性
  • パケット損失を抑えるペースパケット
  • 再送信待ち時間を減少させるパケット誤り訂正
  • TCP 行頭ブロッキングを避ける UDP 伝送
  • モバイルクライアントのために再接続を減らす接続識別子
  • プラグ可能な輻輳制御機構

We've been working on both a QUIC client implementation and prototype server implementation in the open source Chromium repository for the past few months. Early tests of UDP connectivity have been promising, but we have learned from past experience that real-world network conditions often differ considerably. Our next step is to test the pros and cons of the QUIC design in the real world by experimenting with using QUIC for a small percentage of Chrome dev and canary channel traffic to some Google servers, just as we did with SPDY. Users shouldn't notice any difference--except hopefully a faster load time. If we're able to identify clear performance wins, our hope is to collaborate with the rest of the community to develop the features and techniques of QUIC into network standards.

私たちは過去の数ヶ月、オープンソース Chromium レポジトリで QUIC のクライアント実装とプロトタイプサーバ実装の両方に取り組んできました。UDP 接続性の初期のテストは上手く行っていますが、私たちは過去の経験から実世界のネットワーク状態が頻繁に大きく変わる事を学んでいます。私たちの次のステップは、丁度私たちが SPDY で実行したのと同様、幾つかの Google サーバに対し Chrome dev と canary channnel トラフィックの QUIC を僅かな割合で使用する実験によって実世界での QUIC 設計の長所と短所をテストすることです。ユーザはうまくいった場合のより速いロード時間以外に少しの違いも感じるべきではありません。明確にパフォーマンスにおける勝利が分かれば、ネットワーク標準規格に導入するべく QUIC の機能や技術を開発する他のコミュニティと協力する事を私たちは望みます。

You can learn more about QUIC in our FAQ. Our hope is that what we learn from QUIC will ultimately help us to deliver a much faster... er...

あなたは QUIC に関して私たちの FAQ で更に学ぶことができます。私たちの望みは、私たちが QUIC から学んだ事が、伝送を更に速くする事です… えー…

QUICker Internet!

より迅速な(QUICKer)インターネットを！

Posted by Jim Roskind, RTT Reduction Ranger, Google

Google の RTT 削減レンジャーの Gim Roskind が投稿しました。

変更履歴

  • 2013年
  • 6/30 初版
  • 2016年
  • 10/29 予見を予想に変えて文法も平易にした
  • 10/29 「迅速な」に「(QUICKer)」を併記