QUIC Geek FAQ (和訳)

の和訳

  • アドバイスを頂きました mumumu-tan さんに感謝します。

QUIC Geek FAQ

QUIC Geek FAQ (for folks that know about UDP, TCP, SPDY, and stuff like that)

QUIC Geek FAQ (UDP, TCP, SPDY といった要素が分かる人向け)

What is QUIC?

  • QUIC とは何ですか?

QUIC is the name for a new experimental protocol, and it stands for Quick UDP Internet Connection. The protocol supports a set multiplexed connections over UDP, and was designed to provide security protection equivalent to TLS/SSL, along with reduced connection and transport latency. An experimental implementation is being put in place in Chrome by a team of engineers at Google.

QUIC は新しい実験プロトコルの名前で、 Quick UDP Internet Connection の略です。プロトコルUDP 上で多重化された一連の接続をサポートしていて、かつ TLS/SSL と同等のセキュリティ保護を提供し、加えて、接続や転送の待ち時間を削減します。実験的な実装が Google のエンジニアチームによって Chrome の適切な場所に含められます。

What are some of the distinctive techniques being tested in QUIC?

  • QUIC でテストされている特徴的な技術は何ですか?

QUIC will employ bandwidth estimation in each direction into congestion avoidance, and then pace packet transmissions evenly to reduce packet loss. It will also use packet-level error correction codes to reduce the need to retransmit lost packet data. QUIC aligns cryptographic block boundaries with packet boundaries, so that packet loss impact is further contained.

QUIC は輻輳回避に方向毎の帯域幅推定を使っていて、パケット損失を抑えるのに均等にペースパケットを送ります。また、失われたパケットデータの再送信を減らすためにパケットレベルの誤り訂正符号を使用します。QUIC が暗号ブロック境界をパケットの境界に揃えるのは、パケットロスの影響があるからです。

Doesn’t SPDY already provide multiplexed connections over SSL?

  • SPDY が既に SSL 上での多重接続を提供しているのではないですか?

Yes, but SPDY currently runs across TCP, and that induces some undesirable latency costs (even though SPDY is already producing lower latency results than traditional HTTP over TCP).

はい、しかし SPDY は今のところ TCP 上で動作し 、それは幾つかの望ましくない待ち時間コストが発生します。(SPDY は既存の HTTP over TCP よりは低いレイテンシをもたらしていますが…)

Why isn’t SPDY over TCP good enough?

  • なぜ SPDY over TCP では充分でないのですか?

A single lost packet in an underlying TCP connection stalls all of the multiplexed SPDY streams over that connection. By comparison, a single lost packet for X parallel HTTP connections will only stall 1 out of X connections. With UDP, QUIC can support out-of-order delivery, so that a lost packet will typically impact (stall) at most one stream. TCP’s congestion avoidance via a single congestion window also puts SPDY at a disadvantage over TCP when compared to several HTTP connections, each with a separate congestion window. Separate congestion windows are not impacted as much by a packet loss, and we hope that QUIC will be able to more equitably handle congestion for a set of multiplexed connections.

TCP 接続の元では、ただ一つのパケットロスで、その接続で多重送信された SPDY のストリームが全て詰まります。それに比べ、X 個の並列な HTTP 接続でひとつパケットを無くした場合は 、X 個の接続のうち 1つが詰まるだけです。UDP を用いて QUIC は out-of-order の配送に対応していて、通常、パケットを無くしても 1つのストリームにだけ影響(詰まる)があります。また、単一の輻輳ウィンドウを通した TCP輻輳回避は、別々の輻輳ウィンドウをもった複数の HTTP 接続に比べて、 TCP 上 の SPDY を不利な立場に置きます。輻輳ウィンドウを分ける事でパケット損失を同じ位の影響に抑えられます、そして、QUIC が 1まとまりの多重送信された接続で起こる輻輳をより公正に扱う事を期待します。

Are there any other reasons why TCP isn’t good enough?

  • TCP では十分でない他の理由はありますか?

TCP, and TLS/SSL, routinely require one or more round trip times (RTTs) during connection establishment. We’re hopeful that QUIC can commonly reduce connection costs towards zero RTTs. (i.e., send hello, and then send data request without waiting).

TCPTLS / SSLは常に、接続の確立中に1つ以上の round trip times(RTTs)が必要です。私たちは、QUIC がゼロRTTに向けて接続コストを全般的に削減するのを期待します。 (即ち、hello を送信して、待ち無しでデータ要求を送信します)。

Why can’t you just evolve and improve TCP under SPDY?

  • なぜ、TCP under SPDY を進化、改善出来ないのでしょう?

That is our goal. TCP support is built into the kernel of operating systems. Considering how slowly users around the world upgrade their OS, it is unlikely to see significant adoption of client-side TCP changes in less than 5-15 years. QUIC allows us to test and experiment with new ideas, and to get results sooner. We are hopeful that QUIC features will migrate into TCP and TLS if they prove effective.

それが私たちの目標です。 TCP サポートはオペレーティングシステムカーネルに組み込まれています。世界中のユーザーが自分の OS をゆっくりアップグレードする事を考えると、クライアント側の TCP が変更される事は 5〜15年以内では殆ど無いでしょう。QUIC によって私たちはテストし、新しいアイデアを試し、その結果をすぐ得ることができます。私たちは、効果が証明され、QUIC の機能が TCP および TLS に移植されることを期待しています。

Why didn’t you build a whole new protocol, rather than using UDP?

  • 何故、UDP を使うより、完全に新しいプロトコルを構築しなかったのですか?

Middle boxes on the Internet today will generally block traffic unless it is TCP or UDP traffic. Since we couldn’t significantly modify TCP, we had to use UDP. UDP is used today by many game systems, as well as VOIP and streaming video, so its use seems plausible.

昨今のインターネットにあるミドルボックス*1は、TCPUDP 以外のトラフィックをブロックします。私たちは TCP をガラリと変更することができなかったので、UDP を使用しなければなりませんでした。UDP は 多くのゲームシステムや今どきの VOIP やストリーミングビデオで使われているので、使用するのは妥当です。

Why does QUIC always require encryption of the entire channel?

  • なぜ QUIC は常にチャネル全体の暗号化が必要なのでしょうか?

As we learned with SPDY and other protocols, if we don’t encrypt the traffic, then middle boxes are guaranteed to (wittingly, or unwittingly) corrupt the transmissions when they try to “helpfully” filter or “improve” the traffic.

私たちが SPDY や他のプロトコルで学んだように、もし、トラフィックを暗号化しないと、ミドルボックスが「役立つ」フィルタやトラフィックの「改善」を試みて、伝送を(故意、又は無意識に)確実に壊すでしょう。

UDP doesn’t have congestion control, so won’t QUIC cause Internet collapse if widely adopted?

  • UDP輻輳制御を持っていないので、QUIC が普及するとインターネットの崩壊を引き起こしませんか?

QUIC employs congestion controls, just as it employs automatic retransmission to support reliable transport. QUIC will attempt to be fair with competing TCP traffic. For instance, when conveying Q multiplexed flows, and sharing bandwidth with T concurrent TCP flows, we will try to use resources in the range of Q / (Q+T) bandwidth (i.e., “a fair share” for Q additional flows).

QUIC は輻輳制御を採用していて、信頼性の高いトランスポートをサポートするために自動再送信を採用しています。QUIC は TCPトラフィックと公正な競合を試みます。 例えば、転送時にフローを Q 個に多重化し、T 個の並列の帯域幅を共有する TCP フローに対して、Q /(Q + T)の帯域幅(すなわち、Q 個追加したフローの"公正な取り分")の範囲内でリソースを使用しようとします。

Why didn’t you use existing standards such as SCTP over DTLS?

  • なぜ SCTP over DTLS 等の既存の標準を使用しなかったのですか?

QUIC incorporates many techniques in an effort to reduce latency. SCTP and DTLS were not designed to minimize latency, and this is significantly apparent even during the connection establishment phases. Several of the techniques that QUIC is experimenting with would be difficult technically to incorporate into existing standards. As an example, each of these other protocols require several round trips to establish a connection, which is at odds with our target of 0-RTT connectivity overhead.

QUIC は待ち時間を減らすための努力で多くの技術が組み込まれています。 SCTP 及び DTLSは、遅延を最小限に抑えるように設計されておらず、それは接続確立フェーズからして明らかです。 QUIC で実験している幾つかのテクニックは既存の標準規格に組み込むことは技術的に困難です。 例えば、それらのプロトコルは各々接続を確立するために幾つかのラウンドトリップを必要とするので、0-RTT 接続オーバーヘッドの目標と相容れません。

How much do QUIC’s techniques reduce latency?

  • QUIC の技術はどの位待ち時間を削減するのですか?

This is exactly the question we are investigating at the moment, and why we are experimenting with various features and techniques in Chromium. It is too early to share any preliminary results - stay tuned.

その質問はまさに私たちが丁度調査している事で、様々な機能や技術を Chromium で実験している理由です。その序盤の結果を共有するのは時期尚早です。結果をお楽しみに!

Is there any way to disable QUIC, if I really want to avoid running it on my Chromium browser?

  • Chromium ブラウザで実際に動作しないよう QUIC を無効にする方法はありますか?

Yes. You can visit about:flags and set the “Experimental QUIC protocol” to “Disabled.”

はい。about:flags を辿って “Experimental QUIC protocol” を "Disabled" に設定して下さい。

Where can I learn more about QUIC?

  • 何処で QUIC についてより詳細を学ぶことができますか?

If you want a lot of background, and need material to help you sleep, you can look at the QUIC Design Document and Specification Rationale. For cryptographers that wonder how well the i’s are dotted, and t’s crossed, there is a QUIC Crypto Specification. If you’d rather see client code, you can take a look at the Chromium source directory. If you’re wondering about what a server might have to do, there is some prototype server code. Finally, if you just want to think about the bits on the wire, and how this might look, there is an evolving wire specification.

あなたが多くのバックグランドを欲し、かつ安眠出来る材料が欲しいのであれば、QUIC Design Document and Specification Rationale を閲覧できます。詳細まで把握したい暗号作成者のためには、QUIC Crypto Specification があります。クライアントコードを見る方が良ければ、Chromium のソースディレクトリを見ることができます。あなたがサーバがしなければならないと疑問を抱いている場合、幾つかのプロトタイプのサーバコードがあります。最終的に、回線上のビットとそれがどう見えるべきかを考えたくなった時には、発展中の Wire Layout Specification があります。

Is there a news group for discussing QUIC?

Yes. proto-quic@chromium.org a.k.a., https://groups.google.com/a/chromium.org/d/forum/proto-quic

はい。 proto-quic@chromium.org 又は https://groups.google.com/a/chromium.org/d/forum/proto-quic です。

変更履歴

  • 2013年
  • 6/28: 初版 (Nifty翻訳とGoogle翻訳を混ぜて少し修正)
  • 6/29: wire をワイヤと訳してたのを回線に修正
  • 6/29: "i’s are dotted, and t’s crossed" が直訳だったのを修正
  • 6/29: middle を中央と訳してたのを中間に修正
  • 6/29: 仕様ドキュメントやソースコードへのリンクを追加
  • 6/30: 公平〜の訳が意味不明なので修正
  • 6/30: commonly の訳を一般的から全般的に変更
  • 7/1: 混雑を輻輳に修正 (恥かしい (/ω\)
  • 7/2: improve の訳を向上から改善に変更
  • 2016年
  • 10/29 くどい言い回しを平易に した
  • 10/29 ミドルボックスを訳さずにそのままにした (用語なので中間のマシンと訳さないでおく)

*1:https://ja.wikipedia.org/wiki/Middlebox 伝送ポリシーを強制的に適用するためのインターネットの装置