目次
QUIC (Quick UDP Internet Connections)は、グーグルが開発した新しいインターネット転送プロトコルです。QUICは、アプリケーションライターの変更をほとんど必要とせずに、現代のWebアプリケーションが直面するトランスポート層やアプリケーション層の問題の多くを解決します。QUICはTCP+TLS+HTTP2と非常に似ていますが、UDP上で実装されています。QUICを独立したプロトコルにすることで、レガシー・クライアントやミドルウェアが邪魔をするため、既存のプロトコルでは実現できないイノベーションを実現することができます。
QUIC (Quick UDP Internet Connections) is a new transport protocol for the internet, developed by Google. QUIC solves a number of transport-layer and application-layer problems experienced by modern web applications, while requiring little or no change from application writers. QUIC is very similar to TCP+TLS+HTTP2, but implemented on top of UDP. Having QUIC as a self-contained protocol allows innovations which aren’t possible with existing protocols as they are hampered by legacy clients and middleboxes.
TCP+TLS+HTTP2に対するQUICの主な利点には次のようなものがあります。
Key advantages of QUIC over TCP+TLS+HTTP2 include:
接続確立に関する完全な説明は、QUIC Crypto設計ドキュメントを参照してください。簡単に言うと、QUICハンドシェイクは、TCP+TLSの1 ~ 3往復に比べてペイロードを送信する前に常にゼロ往復を必要とします。
QUICクライアントが初めてサーバに接続したとき、クライアントは握手を完了させるために必要な情報を得るために往復握手を実行しなければなりません。クライアントは初期の(空の)クライアント・あいさつ(CHLO)を送り、サーバは拒否(REJ)を送ります。これにはクライアントが送信元アドレス・トークンとサーバの証明書などの情報が含まれています。次にクライアントがCHLOを送信すると、以前に接続されていたキャッシュされた認証データを使用してサーバに暗号化要求を即座に送信することができます。
For a complete description of connection establishment, please see the QUIC Crypto design document. Briefly, QUIC handshakes frequently require zero roundtrips before sending payload, as compared to 1-3 roundtrips for TCP+TLS.
The first time a QUIC client connects to a server, the client must perform a 1-roundtrip handshake in order to acquire the necessary information to complete the handshake. The client sends an inchoate (empty) client hello (CHLO), the server sends a rejection (REJ) with the information the client needs to make forward progress, including the source address token and the server’s certificates. The next time the client sends a CHLO, it can use the cached credentials from the previous connection to immediately send encrypted requests to the server.
QUICはプラグ&ドロップ可能な混雑状態制御を備え、混雑状態制御アルゴリズムにTCPよりも豊富な情報を提供します。現在、googleのQUIC実装ではTCP Cubicを再実装したものが使われており、代替手法の実験が行われています。
より豊富な情報の一例は、各データパケットであり、元のデータパケットであれ、再送信されたデータパケットであれ、新しいシーケンス番号を持っています。これにより、QUIC送信者は再送されたACKと元のACKを区別することができ、TCPの再送の曖昧さの問題を回避することができます。QUIC ACKはまた、パケットを受信することと受信確認を送信することとの間の遅延、および単純に増加するシーケンス番号を明示的に含みます。これにより正確な往復時間の計算が可能になります。
最後に、QUICのACKフレームは256個までのNACK範囲をサポートしているため、QUICは(SACKを使用した)TCPよりも順序付けの変更に柔軟性があり、順序付けの変更や損失時にネットワーク上でより多くのバイトを保持することができます。クライアントもサーバも、相手がどのパケットを受信したかをより正確に知ることができます。
QUIC has pluggable congestion control, and provides richer information to the congestion control algorithm than TCP. Currently, Google’s implementation of QUIC uses a reimplementation of TCP Cubic and is experimenting with alternative approaches.
One example of richer information is that each packet, both original and retransmitted, carries a new sequence number. This allows a QUIC sender to distinguish ACKs for retransmissions from ACKs for originals and avoids TCP’s retransmission ambiguity problem. QUIC ACKs also explicitly carry the delay between the receipt of a packet and its acknowledgment being sent, and together with the monotonically-increasing sequence numbers. This allows for precise roundtrip-time calculation.
Finally, QUIC’s ACK frames support up to 256 NACK ranges, so QUIC is more resilient to reordering than TCP (with SACK), as well as able to keep more bytes on the wire when there is reordering or loss. Both client and server have a more accurate picture of which packets the peer has received.
TCP上のHTTP2の大きな問題の1つは、ヘッダブロックの問題です。アプリケーションはTCP接続をバイトストリームとして扱います。TCPパケットが失われた場合、パケットが遠隔で再送受信されるまで、HTTP2接続上のいかなるストリームも前に進むことはできません。たとえこれらのストリームデータを含むパケットが到着してバッファで待機していたとしてもです。
QUICは多重化動作のために設計されているので、失われたパケットは通常、単一のストリームのデータを搬送し、その特定のストリームにのみ影響を与えます。各ストリームのフレームは、到着するとすぐにストリームにディスパッチすることができるので、損失のないストリームを再構成し続け、アプリケーション内で進展させることができます。
One of the larger issues with HTTP2 on top of TCP is the issue of head-of-line blocking. The application sees a TCP connection as a stream of bytes. When a TCP packet is lost, no streams on that HTTP2 connection can make forward progress until the packet is retransmitted and received by the far side - not even when the packets with data for these streams have arrived and are waiting in a buffer.
Because QUIC is designed from the ground up for multiplexed operation, lost packets carrying data for an individual stream generally only impact that specific stream. Each stream frame can be immediately dispatched to that stream on arrival, so streams without loss can continue to be reassembled and make forward progress in the application.
再送を待たずに損失パケットから復旧するために、QUICはFECパケットでパケットのセットを追加することができます。raid-4と非常に似ていて、FECパケットはFEC群のパケットのパリティを含みます。グループ内の1つのパケットが失われた場合、そのパケットの内容はFECパケットとグループ内の残りのパケットから回復されます。送信者は、特定のシナリオ(例えば、要求の開始および終了)を最適化するためにFECパケットを送信するかどうかを決定することができる。
In order to recover from lost packets without waiting for a retransmission, QUIC can complement a group of packets with an FEC packet. Much like RAID-4, the FEC packet contains parity of the packets in the FEC group. If one of the packets in the group is lost, the contents of that packet can be recovered from the FEC packet and the remaining packets in the group. The sender may decide whether to send FEC packets to optimize specific scenarios (e.g., beginning and end of a request).
QUIC接続は、クライアントによってランダムに生成された64ビットの接続IDによって識別されます。対照的に、TCPコネクションは、送信元アドレス、送信元ポート、送信先アドレス、および送信先ポートの4タプルによって識別されます。これは、クライアントがIPアドレスを変更した場合(例えば、wi-fiの範囲から移動し、セルラーネットワークに切り替えることによって)、またはポートを変更した場合(NATボックスが失われ、ポート関連を再バインディングすることによって)、アクティブなTCP接続はもはや有効ではないことを意味します。QUICクライアントがIPアドレスを変更すると、進行中の要求を中断することなく、新しいIPアドレスから古い接続IDを使用し続けることができます。
QUIC connections are identified by a 64 bit connection ID, randomly generated by the client. In contrast, TCP connections are identified by a 4-tuple of source address, source port, destination address and destination port. This means that if a client changes IP addresses (for example, by moving out of Wi-Fi range and switching over to cellular) or ports (if a NAT box loses and rebinds the port association), any active TCP connections are no longer valid. When a QUIC client changes IP addresses, it can continue to use the old connection ID from the new IP address without interrupting any in-flight requests.