├── cover.jpg ├── LANGS.md ├── cover_small.jpg ├── images ├── QUIC.png ├── h2-man.jpg ├── tcp-chain.png ├── quic-stack.png ├── tcp-chain-streams.png └── quic-chain-streams.png ├── zh ├── feature-nonhttp.md ├── quic-0rtt.md ├── quic-tls.md ├── the-protocol.md ├── feature-reliable.md ├── why-secure.md ├── feature-http.md ├── feature-tls.md ├── feature-trans-app.md ├── feature-handshakes.md ├── quic.md ├── h3-prio.md ├── proc-h2.md ├── quic-userspace.md ├── quic-api.md ├── why-quic.md ├── feature-inorder.md ├── feature-streams.md ├── quic-spinbit.md ├── proc.md ├── h3.md ├── feature-udp.md ├── why-latency.md ├── h3-altsvc.md ├── h3-push.md ├── h3-https.md ├── quic-connections.md ├── h3-h2.md ├── quic-v2.md ├── why-h2.md ├── proc-ietf.md ├── h3-streams.md ├── why-ossification.md ├── specs.md ├── criticism.md ├── quic-streams.md ├── README.md ├── why-tcpudp.md ├── why-tcphol.md ├── proc-status.md └── SUMMARY.md ├── ja ├── feature-nonhttp.md ├── book.json ├── the-protocol.md ├── quic-0rtt.md ├── feature-reliable.md ├── quic-tls.md ├── why-secure.md ├── feature-trans-app.md ├── feature-http.md ├── quic.md ├── feature-tls.md ├── proc-h2.md ├── h3-prio.md ├── quic-userspace.md ├── feature-handshakes.md ├── why-quic.md ├── quic-api.md ├── quic-spinbit.md ├── feature-streams.md ├── proc.md ├── feature-inorder.md ├── why-latency.md ├── h3.md ├── feature-udp.md ├── h3-push.md ├── h3-h2.md ├── h3-https.md ├── quic-connections.md ├── why-h2.md ├── proc-ietf.md ├── h3-altsvc.md ├── quic-v2.md ├── specs.md ├── h3-streams.md ├── why-ossification.md ├── SUMMARY.md ├── why-tcpudp.md ├── criticism.md ├── why-tcphol.md ├── quic-streams.md ├── proc-status.md └── README.md ├── book.json ├── fr ├── feature-nonhttp.md ├── the-protocol.md ├── quic-0rtt.md ├── feature-reliable.md ├── quic-tls.md ├── feature-trans-app.md ├── feature-http.md ├── feature-tls.md ├── quic.md ├── why-secure.md ├── h3-prio.md ├── proc-h2.md ├── feature-handshakes.md ├── why-quic.md ├── quic-userspace.md ├── specs.md ├── feature-streams.md ├── quic-api.md ├── feature-inorder.md ├── proc.md ├── quic-spinbit.md ├── h3.md ├── why-latency.md ├── h3-h2.md ├── SUMMARY.md ├── feature-udp.md ├── h3-altsvc.md ├── h3-https.md ├── h3-push.md ├── h3-streams.md ├── why-h2.md ├── proc-ietf.md ├── README.md ├── quic-connections.md ├── quic-v2.md ├── why-tcphol.md ├── why-ossification.md ├── criticism.md ├── quic-streams.md ├── proc-status.md └── why-tcpudp.md ├── en ├── feature-nonhttp.md ├── the-protocol.md ├── quic-0rtt.md ├── feature-reliable.md ├── quic-tls.md ├── feature-tls.md ├── feature-trans-app.md ├── feature-http.md ├── quic.md ├── why-secure.md ├── feature-handshakes.md ├── h3-prio.md ├── proc-h2.md ├── why-quic.md ├── quic-userspace.md ├── quic-api.md ├── feature-streams.md ├── specs.md ├── feature-inorder.md ├── quic-spinbit.md ├── proc.md ├── h3.md ├── why-latency.md ├── h3-h2.md ├── feature-udp.md ├── SUMMARY.md ├── h3-https.md ├── h3-altsvc.md ├── h3-push.md ├── why-h2.md ├── h3-streams.md ├── quic-connections.md ├── proc-ietf.md ├── README.md ├── quic-v2.md ├── why-tcpudp.md ├── why-tcphol.md ├── why-ossification.md ├── criticism.md ├── quic-streams.md └── proc-status.md ├── README.md ├── HOWTO-TRANSLATE.md └── LICENSE /cover.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/outsideris/http3-explained/HEAD/cover.jpg -------------------------------------------------------------------------------- /LANGS.md: -------------------------------------------------------------------------------- 1 | * [English](en/) 2 | * [Français](fr/) 3 | * [简体中文](zh/) 4 | * [日本語](ja/) 5 | -------------------------------------------------------------------------------- /cover_small.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/outsideris/http3-explained/HEAD/cover_small.jpg -------------------------------------------------------------------------------- /images/QUIC.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/outsideris/http3-explained/HEAD/images/QUIC.png -------------------------------------------------------------------------------- /zh/feature-nonhttp.md: -------------------------------------------------------------------------------- 1 | ## 基于QUIC的非HTTP协议 2 | 3 | 基于QUIC传输非HTTP协议的相关工作已被推迟到第一版QUIC发布之后实现。 4 | -------------------------------------------------------------------------------- /images/h2-man.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/outsideris/http3-explained/HEAD/images/h2-man.jpg -------------------------------------------------------------------------------- /images/tcp-chain.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/outsideris/http3-explained/HEAD/images/tcp-chain.png -------------------------------------------------------------------------------- /images/quic-stack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/outsideris/http3-explained/HEAD/images/quic-stack.png -------------------------------------------------------------------------------- /images/tcp-chain-streams.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/outsideris/http3-explained/HEAD/images/tcp-chain-streams.png -------------------------------------------------------------------------------- /images/quic-chain-streams.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/outsideris/http3-explained/HEAD/images/quic-chain-streams.png -------------------------------------------------------------------------------- /zh/quic-0rtt.md: -------------------------------------------------------------------------------- 1 | # 0-RTT 2 | 3 | 先前已连接过一个服务器的客户端可能缓存来自该连接的某些参数，并在之后与该服务器建立一个无需等待握手完成就可以立即传输信息的**0-RTT**连接，从而减少建立新连接所必需的时间。 4 | -------------------------------------------------------------------------------- /ja/feature-nonhttp.md: -------------------------------------------------------------------------------- 1 | ## HTTP 以外のプロトコルを QUIC 上で動かす 2 | 3 | HTTP 以外のプロトコルを QUIC を使って通信するための対応は、QUIC のバージョン1が実際にリリースされた後に行われるよう延期されました。 4 | -------------------------------------------------------------------------------- /zh/quic-tls.md: -------------------------------------------------------------------------------- 1 | # 使用TLS的连接 2 | 3 | 在初始的数据包建立连接之后，连接发起者会马上发一个加密的帧以开始安全层握手。安全层使用TLS 1.3协议。 4 | 5 | 在QUIC中，没有方法或机制避免使用TLS连接。该设计旨在使中间设备难以篡改数据包，防止协议僵化。 6 | -------------------------------------------------------------------------------- /zh/the-protocol.md: -------------------------------------------------------------------------------- 1 | # 协议特点 2 | 3 | 本章从高层次出发概述QUIC协议。 4 | 5 | 下图是使用HTTP传输时，HTTP/2（左）和HTTP/3（右）的协议栈对比。 6 | 7 | ![QUIC logo](../images/quic-stack.png) 8 | -------------------------------------------------------------------------------- /zh/feature-reliable.md: -------------------------------------------------------------------------------- 1 | ## 可靠的数据传输‎ 2 | 3 | 虽然UDP不提供可靠的传输，但QUIC在基于UDP之时增加了一层带来可靠性的层。它提供了数据包重传、拥塞控制、调整传输节奏（pacing）以及其他一些TCP中存在的特性。 4 | 5 | 只要连接没有中断，从QUIC一端传输的数据迟早会出现在另一端。 6 | -------------------------------------------------------------------------------- /book.json: -------------------------------------------------------------------------------- 1 | { 2 | "gitbook": ">=2.0.0", 3 | "title": "HTTP/3 Explained", 4 | "pdf": { 5 | "fontSize": 14, 6 | "fontFamily": "IPAGothic" 7 | } 8 | } 9 | -------------------------------------------------------------------------------- /fr/feature-nonhttp.md: -------------------------------------------------------------------------------- 1 | ## Non-HTTP sur QUIC 2 | 3 | Les travaux d’envoi de protocoles autres que HTTP sur QUIC ont été reportés après 4 | la livraison de la version 1 de QUIC. 5 | -------------------------------------------------------------------------------- /ja/book.json: -------------------------------------------------------------------------------- 1 | { 2 | "gitbook": ">=2.0.0", 3 | "title": "HTTP/3 Explained", 4 | "pdf": { 5 | "fontSize": 14, 6 | "fontFamily": "IPAGothic" 7 | } 8 | } 9 | -------------------------------------------------------------------------------- /en/feature-nonhttp.md: -------------------------------------------------------------------------------- 1 | ## Non-HTTP over QUIC 2 | 3 | The work on sending other protocols than HTTP over QUIC has been postponed to 4 | be worked on after QUIC version 1 has shipped. 5 | 6 | -------------------------------------------------------------------------------- /ja/the-protocol.md: -------------------------------------------------------------------------------- 1 | # プロトコルの機能 2 | 3 | 高レベルからの QUIC プロトコル 4 | 5 | 下の図は、HTTP トランスポートとして使われる際の HTTP/2 ネットワークスタックを左側に、QUIC ネットワークスタックを右側に示しています。 6 | 7 | ![QUIC logo](../images/quic-stack.png) 8 | -------------------------------------------------------------------------------- /zh/why-secure.md: -------------------------------------------------------------------------------- 1 | ## 安全性 2 | 3 | QUIC始终保证安全性。QUIC协议没有明文的版本，所以想要建立一个QUIC连接，就必须通过TLS 1.3来安全地建立一个加密连接。如上文所说，加密可以避免协议僵化等拦截和特殊处理。这也使QUIC具有了Web用户所期望的所有的HTTPS安全特性。 4 | 5 | QUIC只在加密协议协商时会发送几个明文传送的初始握手报文。 6 | -------------------------------------------------------------------------------- /ja/quic-0rtt.md: -------------------------------------------------------------------------------- 1 | # 0-RTT 2 | 3 | 新しいコネクションを確立するのに必要な時間を短縮するため、以前にサーバーと接続していたクライアントは特定のパラメータをキャッシュし、そのパラメータを使ってサーバーとの **0-RTT** コネクションを確立してよいことになっています。これにより、ハンドシェイクの完了を待つことなく、クライアントからすぐにデータを送信することが可能になります。 4 | -------------------------------------------------------------------------------- /zh/feature-http.md: -------------------------------------------------------------------------------- 1 | ## HTTP/3 2 | 3 | HTTP层以HTTP风格传输内容，包括使用QPACK进行HTTP头部压缩——这和HTTP/2中使用HPACK压缩头部类似。 4 | 5 | HPACK算法依赖于数据流的有序交付，由于HTTP/3的数据流之间可能乱序，所以该算法需要修改才能使用。QPACK可被视作适用于QUIC版本的[HPACK](https://httpwg.org/specs/rfc7541.html)。 6 | -------------------------------------------------------------------------------- /zh/feature-tls.md: -------------------------------------------------------------------------------- 1 | ## TLS 1.3 2 | 3 | QUIC使用TLS 1.3传输层安全协议（[RFC 8446](https://tools.ietf.org/html/rfc8446)）。QUIC没有非加密的版本。 4 | 5 | 与更早的TLS版本相比，TLS 1.3有着很多优点，但使用它的最主要原因是其握手所花费的往返次数更低，从而能降低协议的延迟。 6 | 7 | Google的传统QUIC使用一个自行定制的加密法。 8 | -------------------------------------------------------------------------------- /ja/feature-reliable.md: -------------------------------------------------------------------------------- 1 | ## 高信頼性のデータ転送 2 | 3 | UDP は信頼性の高い転送プロトコルではありませんが、QUIC は UDP 上に信頼性をもたらすレイヤーを追加します。 4 | 5 | これはパケットの再送、輻輳制御、ペーシングおよび現在の TCP が持つこれら以外の機能を提供します。 6 | 7 | 一方のエンドポイントが QUIC を用いて転送したデータは、コネクションが維持されている限り、遅かれ早かれ他方に届きます。 8 | -------------------------------------------------------------------------------- /zh/feature-trans-app.md: -------------------------------------------------------------------------------- 1 | ## 传输层与应用层 2 | 3 | IETF版QUIC是一个传输层协议，在该协议之上可以运行其他应用层协议。初始的应用层协议是HTTP/3（h3）。 4 | 5 | 传输层协议负责连接和数据流处理。 6 | 7 | 在Google的传统QUIC中，传输层与HTTP融在一起，为包揽一切的全功能设计，它是一个更有指向性的“基于UDP传输HTTP/2帧”（send-http/2-frames-over-udp）的协议。 8 | -------------------------------------------------------------------------------- /zh/feature-handshakes.md: -------------------------------------------------------------------------------- 1 | # 快速握手 2 | 3 | QUIC提供0-RTT和1-RTT的连接建立，这意味着QUIC在最佳情况下不需要任何的额外往返时间便可建立新连接。其中更快的0-RTT仅在两个主机之间建立过连接且缓存了该连接的“秘密”（secret）时可以使用。 4 | 5 | ## 早期数据（Early data） 6 | 7 | QUIC允许客户端在0-RTT的情况下直接捎带数据。这使得客户端能尽早向对方传送数据，当然也使得服务器能更快地发回数据响应。 8 | -------------------------------------------------------------------------------- /zh/quic.md: -------------------------------------------------------------------------------- 1 | # QUIC工作原理 2 | 3 | 本章节将解释QUIC传输层协议各基本模块的功能，而不会逐比特逐字节解释协议的报文。如果你想自己实现QUIC，这些介绍会加强你对协议的理解，但有关具体细节，请参考IETF的互联网草案（Internet Draft）和RFC。 4 | 5 | 1. 建立一个[连接](quic-connections.md) 6 | 2. 协商[安全的TLS连接](quic-tls.md) 7 | 3. 使用[数据流](quic-streams.md) 8 | -------------------------------------------------------------------------------- /zh/h3-prio.md: -------------------------------------------------------------------------------- 1 | # HTTP/3优先度 2 | 3 | HTTP/3中有一种帧是优先度（`PRIORITY`）。与HTTP/2中的类似，它用于设定一个流的优先度和依赖关系。 4 | 5 | 该帧可以设定一个流依赖于另一个流，也可以设定特定流的“权重”。 6 | 7 | 服务器应该只在一个流所依赖的所有流都被关闭，或者都无法取得进展时为该流分配资源。 8 | 9 | 一个流的权重是介于1到256之间的值，有着相同父系流的流**应该**按照权重的比例分配资源。 10 | -------------------------------------------------------------------------------- /zh/proc-h2.md: -------------------------------------------------------------------------------- 1 | ## HTTP/2的经验 2 | 3 | HTTP/2规范RFC 7540发布于2015年5月，只比QUIC首次进入IETF早一个月。 4 | 5 | HTTP/2的发布为HTTP进化提供了好的经验。这一经验让大家相信，迭代更新的HTTP版本会比从第一版到第二版（花费约16年）快得多。 6 | 7 | 随着HTTP/2的发布，用户和软件堆栈不再假设HTTP是一个序列化的、基于文本的协议。 8 | 9 | HTTP-over-QUIC于2018年11月更名为HTTP/3。 10 | -------------------------------------------------------------------------------- /en/the-protocol.md: -------------------------------------------------------------------------------- 1 | # Protocol features 2 | 3 | The QUIC protocol from a high level. 4 | 5 | Illustrated below is the HTTP/2 network stack on the left and the QUIC network 6 | stack on the right, when used as HTTP transport. 7 | 8 | ![QUIC logo](../images/quic-stack.png) 9 | -------------------------------------------------------------------------------- /ja/quic-tls.md: -------------------------------------------------------------------------------- 1 | # 接続で TLS を使う 2 | 3 | 接続の設定に利用される最初のパケットが到着するとすぐに、通信の開始者はセキュアレイヤーにおけるハンドシェイクのセットアップを開始する crypto フレームを送信します。 4 | 5 | セキュリティレイヤーは TLS 1.3 セキュリティが用いられています。 6 | 7 | TLS を使用せずに QUIC コネクションを行う方法はありません。プロトコルの硬直化を防ぐためにQUIC はプロトコルレベルでミドルボックスによる通信の改ざんが難しくなるように設計されています。 8 | -------------------------------------------------------------------------------- /fr/the-protocol.md: -------------------------------------------------------------------------------- 1 | # Fonctionnalités du protocole 2 | 3 | Le protocole QUIC d'un niveau élevé. 4 | 5 | Illustré ci-dessous, la stack réseau HTTP/2 à gauche et la stack réseau QUIC à 6 | droite, quand utilisées comme transport HTTP. 7 | 8 | ![QUIC logo](../images/quic-stack.png) 9 | -------------------------------------------------------------------------------- /zh/quic-userspace.md: -------------------------------------------------------------------------------- 1 | ## 用户空间实现 2 | 3 | 在用户空间中实现一个传输层协议有助于协议的快速迭代，协议的演进更为容易，不需要客户端和服务器更新其操作系统内核才能部署新的版本。 4 | 5 | QUIC本身没有固有的东西阻碍未来在操作系统内核中实现和提供QUIC协议。 6 | 7 | ### 众多的实现 8 | 9 | 在用户空间中实现一个新的传输层协议时，一个显而易见的效果是我们会看到很多独立的实现。 10 | 11 | 在可预见的未来，不同的应用程序可能包含（或基于）不同的HTTP/3和QUIC实现。 12 | -------------------------------------------------------------------------------- /ja/why-secure.md: -------------------------------------------------------------------------------- 1 | ## セキュア 2 | 3 | QUIC は常にセキュアです。 4 | 5 | 平文版のプロトコルが存在しないので、QUIC コネクションをネゴシエートすることは TLS 1.3 を用いて暗号化とセキュリティを行うことと同義です。 6 | 7 | 上記のように、(拡張性を損なうという意味での) 硬直化や他の種類のブロックと特別な処理を防ぐと同様に、QUIC は Web ユーザーが望んでいた HTTPS のセキュアなプロパティを全て備えています。 8 | 9 | 暗号化プロトコルがネゴシエートされる前に、平文で送信されるわずかな初期ハンドシェイクパケットがあるのみです。 10 | -------------------------------------------------------------------------------- /ja/feature-trans-app.md: -------------------------------------------------------------------------------- 1 | ## トランスポートとアプリケーションレベル 2 | 3 | IETF QUIC プロトコルはトランスポートプロトコルであり、その上に他のアプリケーションプロトコルも使用可能です。 4 | 5 | 最も主要なアプリケーションレイヤープロトコルは HTTP/3 (h3) です。 6 | 7 | トランスポートレイヤーではコネクションとストリームをサポートします。 8 | 9 | 従来の Google 版の QUIC はトランスポートと HTTP が一括で動作するよう一つにまとめられており、HTTP/2 フレームを UDP 上で送ることにより特化したプロトコルでした。 10 | -------------------------------------------------------------------------------- /zh/quic-api.md: -------------------------------------------------------------------------------- 1 | # API 2 | 3 | 常规TCP与程序最成功的因素之一便是标准化的套接字（socket）API。其API有着定义良好的功能，使用它能让你轻松地在各操作系统之间移植程序，因为TCP采用同样的方式运作。 4 | 5 | 但QUIC不是如此。QUIC目前没有标准化的API。 6 | 7 | 使用QUIC时，你需要选择一个现有的库实现，并坚持使用它的API。这在某种程度上把应用“绑定”到了单一的库上。换库意味着使用另外一套API，这可能带来相当的工作量。 8 | 9 | 另外，由于QUIC一般在用户空间中实现，所以它不像现有的TCP和UDP套接字API那样能轻松扩展。使用QUIC意味着选择了套接字API之外的另一套API。 10 | -------------------------------------------------------------------------------- /ja/feature-http.md: -------------------------------------------------------------------------------- 1 | ## HTTP/3 2 | 3 | HTTP レイヤーは HTTP に準拠したトランスポートを行います。HTTP ヘッダ圧縮では QPACK を利用しており、これは HTTP/2 における HPACK に似ています。 4 | 5 | HPACK アルゴリズムはストリームが順番に届くことを前提としているため、修正せずに HTTP/3 で再利用することは不可能です。 6 | 7 | これは QUIC の提供するストリームにおいては転送がばらばらに行われるためです。 8 | 9 | QPACK は [HPACK](https://httpwg.org/specs/rfc7541.html) の QUIC 対応版といえます。 10 | -------------------------------------------------------------------------------- /ja/quic.md: -------------------------------------------------------------------------------- 1 | # QUIC の仕組み 2 | 3 | ネットワーク上でのビットやバイトに関して詳細な説明はしませんが、このセクションでは QUIC トランスポートプロトコルの基本的な要素がどのように機能するのかを説明します。 4 | 5 | 独自に QUIC スタックを実装したい場合、この説明はあなたの理解に繋がるはずですが、詳細については IETF のインターネットドラフトと RFC を参照してください。 6 | 7 | 1. [コネクション](quic-connections.md) をセットアップ 8 | 2. [TLS セキュリティ](quic-tls.md) を組み込み 9 | 3. [ストリーム](quic-streams.md) を開始 10 | -------------------------------------------------------------------------------- /ja/feature-tls.md: -------------------------------------------------------------------------------- 1 | ## TLS 1.3 2 | 3 | QUIC におけるトランスポートセキュリティには TLS 1.3 ([RFC 8446](https://tools.ietf.org/html/rfc8446)) を使用しており、暗号化されない QUIC コネクションは一切ありません。 4 | 5 | TLS 1.3 には従来の TLS と比較していくつか利点があります。 QUIC が TLS 1.3 を使用する主な理由は、1.3からはラウンドトリップ回数が少なくなるようにハンドシェイクに変更が加えられているためです。これにより、プロトコルの待ち時間を短縮することができます。 6 | 7 | かつて Google が提案した QUIC では独自の暗号化技術を使用していました。 8 | -------------------------------------------------------------------------------- /en/quic-0rtt.md: -------------------------------------------------------------------------------- 1 | # 0-RTT 2 | 3 | To reduce the time required to establish a new connection, a client that has previously 4 | connected to a server may cache certain parameters from that connection and subsequently 5 | set up a **0-RTT** connection with the server. This allows the client to send data immediately, 6 | without waiting for a handshake to complete. 7 | -------------------------------------------------------------------------------- /fr/quic-0rtt.md: -------------------------------------------------------------------------------- 1 | # 0-RTT 2 | 3 | Pour réduire le temps nécessaire à l'établissement d'une nouvelle connexion, un 4 | client déjà connecté à un serveur peut mettre en cache certains paramètres de cette 5 | connexion et établir une connexion **0-RTT** avec le serveur. Cela permet au client 6 | d'envoyer des données immédiatement, sans attendre la fin d'un handshake. 7 | -------------------------------------------------------------------------------- /zh/why-quic.md: -------------------------------------------------------------------------------- 1 | # 为何选择QUIC 2 | 3 | QUIC就是一个名字，不是什么的缩略词。它的发音与英语单词“quick”相同。 4 | 5 | QUIC在许多方面可以被视为一种新型的可靠且安全的传输层协议，它适合为形似HTTP的协议提供服务，并且可以解决一些在基于TCP和TLS传输的HTTP/2协议中存在的缺点。它是合乎情理的次世代Web传输层协议。 6 | 7 | QUIC的用途不止局限于HTTP的传输。将Web与数据更快地交付给最终用户，是创造QUIC这一新型传输层协议的最大原因和源动力。 8 | 9 | 我们接下来会解释，我们为什么要创造一个新的传输层协议，以及为什么要基于UDP来实现。 10 | 11 | ![QUIC logo](../images/QUIC.png) 12 | -------------------------------------------------------------------------------- /ja/proc-h2.md: -------------------------------------------------------------------------------- 1 | ## HTTP/2 からの経験 2 | 3 | HTTP/2 の仕様が RFC 7540 として公開されたのは2015年5月で、QUIC が IETF に最初に提出されるわずか1ヶ月前でした。 4 | 5 | HTTP/2 では、既存のHTTPを変えようという機運があり、HTTP/2 を作ったワーキンググループは新しい HTTP は、バージョンが1から2に16年かけて上がったときよりも早いものとなるだろうと確信していました。 6 | 7 | HTTP/2 の時点ではソフトウェアスタックもユーザーも HTTP が今後もテキストベースのプロトコルのまま、何かができるとは考えないようになってきました。 8 | 9 | HTTP-over-QUIC が HTTP/3 と名前が変わったのは2018年11月でした。 10 | -------------------------------------------------------------------------------- /zh/feature-inorder.md: -------------------------------------------------------------------------------- 1 | ## ‎有序交付 2 | 3 | QUIC的单个数据流可以保证有序交付，但多个数据流之间可能乱序。这意味着单个数据流的传输是按序的，但是多个数据流中接收方收到的顺序可能与发送方的发送顺序不同！ 4 | 5 | 举个例子：服务器传送流A和B到客户端。流A先启动，然后是流B。在QUIC中，丢包只会影响该包所处的流。如果流A发生了一次丢包，而流B没有，流B将继续传输直到结束，而流A将会进行丢包重传过程。而在HTTP/2中这不可能发生。 6 | 7 | 下图展示了连通两个QUIC端点的单一连接中的黄色与蓝色的数据流。它们互相独立，所以可能乱序到达，但是每个流内的信息将按序可靠到达。 8 | 9 | ![两台电脑间的两个QUIC数据流](../images/quic-chain-streams.png) 10 | -------------------------------------------------------------------------------- /zh/feature-streams.md: -------------------------------------------------------------------------------- 1 | ## 连接中的多个数据流 2 | 3 | 类似SCTP、SSH和HTTP/2，QUIC在同一物理连接上可以有多个独立的逻辑数据流。这些数据流并行在同一个连接上传输，不影响其他流。 4 | 5 | 连接在两个端点之间经过类似TCP连接的方式协商建立。QUIC连接基于UDP端口和IP地址建立，而一旦建立，连接通过其“连接ID”（connection ID）关联。 6 | 7 | 在已建立的连接上，双方均可以建立传输给对方的数据流。单一数据流的传输是可靠、有序的，但不同的数据流间可能无序传送。 8 | 9 | QUIC可对连接和数据流分别进行流量控制（flow control）。 10 | 11 | 进一步细节参见[连接](quic-connections.md)和[数据流](quic-streams.md)。 12 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | **HTTP/3 explained** is a collaborative effort to document the HTTP/3 and the 2 | QUIC protocols. Join in and help! 3 | 4 | Get the Web, PDF, or e-book versions on 5 | [gitbook.com](https://www.gitbook.com/book/bagder/http3-explained/details). 6 | 7 | The contents get updated automatically on every commit to this git repository. 8 | 9 | ![HTTP/3 explained cover](cover_small.jpg) 10 | -------------------------------------------------------------------------------- /zh/quic-spinbit.md: -------------------------------------------------------------------------------- 1 | # 旋转比特位（Spin Bit） 2 | 3 | 在QUIC工作组的设计讨论中，最长的主题之一就是旋转比特位，人们花费了数百封邮件和数百个小时来讨论它。 4 | 5 | 旋转比特位的支持者认为，两个QUIC端点之间路径上的运营商和人员需要有办法来测量延迟。 6 | 7 | 反对者则反感此功能潜在的信息泄露。 8 | 9 | ## 旋转一个比特 10 | 11 | QUIC连接的客户端、服务器这两个端点各为每一个QUIC连接维护一个旋转的值——0或1，在传送时候它们在报文中设置该值。 12 | 13 | 然后，在每一次往返时，连接双方都翻转这一比特的值。效果是观察者可以检测该比特字段的0与1脉冲。 14 | 15 | 这一观测只在发送方未被应用层或流量控制限制的情况下有效，并且网络上经过重新排序的数据包也会给数据带来噪声。 16 | -------------------------------------------------------------------------------- /ja/h3-prio.md: -------------------------------------------------------------------------------- 1 | # HTTP/3 プライオリティ制御 2 | 3 | HTTP/3 のストリームフレームの1つに `PRIORITY` があります。 4 | 5 | これはストリーム上の優先順位と依存関係を設定するために使われる HTTP/2 と似た方法です。 6 | 7 | フレームは特定のストリームを他の特定ストリームへと依存させ、"weight" を設定できます。 8 | 9 | 依存関係にあるストリームは、それらが依存するすべてのストリームのいずれかがクローズされている、またはそれ以上処理を進めることができない場合にのみ、リソースが割り当てられるべきです。 10 | 11 | ストリームの weight 値は1から256の間で設定可能で、同じ親を持つストリームにはその weight に比例してリソースが割り当てられる **べきである** と定義されています。 12 | -------------------------------------------------------------------------------- /ja/quic-userspace.md: -------------------------------------------------------------------------------- 1 | ## ユーザー空間 2 | 3 | ユーザー空間にトランスポートプロトコルを実装することで、プロトコルの開発サイクルを速めることができます。これは、クライアントとサーバー OS のカーネルをアップデートすることなくプロトコルの更新を比較的簡単に行えるためです。 4 | 5 | 技術的には、QUIC 固有の仕組みをユーザー空間ではなくカーネル空間にて実装することも可能です。一部の開発者にとってはそのほうが都合が良いこともあるでしょう。 6 | 7 | ### 多数の実装 8 | 9 | ユーザー空間に新しいトランスポートプロトコルを実装する明らかな効果は、独立した実装を多数期待できることです。 10 | 11 | 将来、種々のアプリケーションは異なる HTTP/3 や QUIC の実装を取り込むことが (最上層に実装することも) 起こりうるでしょう。 12 | -------------------------------------------------------------------------------- /en/feature-reliable.md: -------------------------------------------------------------------------------- 1 | ## ‎Reliable data transfers 2 | 3 | While UDP is not a reliable transport, QUIC adds a layer on top of UDP that 4 | introduces reliability. It offers re-transmissions of packets, congestion 5 | control, pacing and the other features otherwise present in TCP. 6 | 7 | Data sent over QUIC from one end-point will appear in the other end sooner or 8 | later, as long as the connection is maintained. 9 | -------------------------------------------------------------------------------- /ja/feature-handshakes.md: -------------------------------------------------------------------------------- 1 | # 素早いハンドシェイク 2 | 3 | QUIC は 0-RTT と 1-RTT 両方のコネクションセットアップを提供し、これは理想的には新しいコネクションを設定する際に追加のやりとりを行う必要がないことを意味します。 4 | 5 | 0-RTT ハンドシェイクはこの2つのうちで速い方で、事前にコネクションが確立し、かつ、秘密鍵がキャッシュされている状態のときのみ利用することができます。 6 | 7 | ## Early data 8 | 9 | QUIC はクライアントが 0-RTT ハンドシェイクの際にデータを含めることを許可しています。 10 | 11 | この機能により、クライアントは可能な限り速くピアにデータを配信することができます。 12 | 13 | そして、当然のことながら、サーバーは応答して、より早くデータを返すことができます。 14 | -------------------------------------------------------------------------------- /en/quic-tls.md: -------------------------------------------------------------------------------- 1 | # Connections use TLS 2 | 3 | Immediately after the initial packet setting up a connection, the initiator 4 | sends a crypto frame that starts setting up the secure layer handshake. The 5 | security layer uses TLS 1.3 security. 6 | 7 | There is no way to opt-out or avoid using TLS for a QUIC connection. The 8 | protocol is designed to be hard for middle-boxes to tamper with, in order 9 | to help prevent ossification of the protocol. 10 | -------------------------------------------------------------------------------- /zh/proc.md: -------------------------------------------------------------------------------- 1 | # 协议进展 2 | 3 | 最初的QUIC协议由Jim Roskind在Google设计并于2012年实现，经过Google的扩大试验后，于2013年向全世界公开发布。 4 | 5 | 回顾那时，QUIC还是“快速UDP互联网连接”（Quick UDP Internet Connections）的缩写，但现在已经不是了。 6 | 7 | Google实现了QUIC协议，并随后将它部署在其广泛流行的浏览器（Chrome）和最流行的服务（搜索、Gmail、YouTube等等）中。他们相当迅速地迭代该协议的版本，经过一段时间，协议的理念被许多用户的使用证明可以面向大量用户可靠运作。 8 | 9 | 2015年6月，首个QUIC的互联网草案被提交到IETF以进行标准化，但直到2016年下半年，一个QUIC工作组才被批准成立并投入工作。随后它在各方的高度关注下迅速发展。 10 | 11 | 在2017年，Google的QUIC工程师称，整个互联网中大约有7%的流量在使用该协议（Google版本）。 12 | -------------------------------------------------------------------------------- /zh/h3.md: -------------------------------------------------------------------------------- 1 | # HTTP/3 2 | 3 | 上文提到过，基于QUIC传输的第一个也是最基础的协议是HTTP。 4 | 5 | 就像HTTP/2是通过网络传输HTTP流量的一种新方式，HTTP/3是另一种通过网络传输HTTP的新方法。 6 | 7 | HTTP的范例和概念没有改变。它含有头部（header）和正文（body），请求和回复，还有动词（verb）、Cookie和缓存。HTTP/3的主要改变是将这些报文比特传送到另一端的方式。 8 | 9 | 为了使HTTP可以通过QUIC传输，协议的某些方面要进行修改，修改的结果便是HTTP/3。这些必要修改是因QUIC与TCP在某些性质上的不同所致，修改包括： 10 | 11 | - 在QUIC中，数据流由传输层本身提供，而在HTTP/2中，流由HTTP层完成。 12 | 13 | - 由于数据流互相独立，HTTP/2中使用的头部压缩算法如果不做改动，会造成队头阻塞。 14 | 15 | - QUIC流与HTTP/2略有不同。本书的HTTP/3章节会做详细介绍。 16 | -------------------------------------------------------------------------------- /ja/why-quic.md: -------------------------------------------------------------------------------- 1 | # なぜ QUIC なのか 2 | 3 | QUIC は略語ではなく名称です。英単語の "quick" と全く同じ発音です。 4 | 5 | QUIC は多くの点で、HTTP のようなプロトコルに適した、新しく信頼性の高い安全なトランスポートプロトコルであり、TCP や TLS 上で HTTP/2 を動かす上で知られるいくつかの欠点に対応できる方法と見なすことができます。 6 | 7 | Web トランスポートの進化における論理的な次のステップです。 8 | 9 | QUIC は HTTP のトランスポートだけに限定されるものではありません。この新しいトランスポートプロトコルを作り始めた、おそらく最大の理由にして最初のきっかけは、エンドユーザーに Web とデータをより早く配信したいという願望です。 10 | 11 | それでは、なぜ新しいトランスポートプロトコルなのでしょうか、なぜ UDP の上に作ったのでしょうか？ 12 | 13 | ![QUIC logo](../images/QUIC.png) 14 | -------------------------------------------------------------------------------- /en/feature-tls.md: -------------------------------------------------------------------------------- 1 | ## TLS 1.3 2 | 3 | The transport security used in QUIC is using TLS 1.3 ([RFC 4 | 8446](https://tools.ietf.org/html/rfc8446)) and there are never any unencrypted 5 | QUIC connections. 6 | 7 | TLS 1.3 has several advantages compared to older TLS versions but a primary 8 | reason for using it in QUIC is that 1.3 changed the handshake to require fewer 9 | roundtrips. It reduces protocol latency. 10 | 11 | The Google legacy version of QUIC used a custom crypto. 12 | -------------------------------------------------------------------------------- /en/feature-trans-app.md: -------------------------------------------------------------------------------- 1 | ## Transport and application level 2 | 3 | The IETF QUIC protocol is a transport protocol, on top of which other 4 | application protocols can be used. The initial application layer protocol is 5 | HTTP/3 (h3). 6 | 7 | The transport layer supports connections and streams. 8 | 9 | The legacy Google version of QUIC had transport and HTTP glued together into 10 | one single do-it-all and was a more special-purpose 11 | send-http/2-frames-over-udp protocol 12 | -------------------------------------------------------------------------------- /fr/feature-reliable.md: -------------------------------------------------------------------------------- 1 | ## Transferts de données fiables 2 | 3 | Bien qu'UDP ne soit pas un transport fiable, QUIC ajoute une couche au-dessus d'UDP 4 | qui introduit la fiabilité. Il offre la retransmission de paquets, le contrôle de 5 | congestion, la stimulation et les autres fonctionnalités présentes par ailleurs 6 | dans TCP. 7 | 8 | Les données envoyées sur QUIC depuis un point de terminaison apparaîtront dans 9 | l'autre tôt ou tard, tant que la connexion est maintenue. 10 | -------------------------------------------------------------------------------- /en/feature-http.md: -------------------------------------------------------------------------------- 1 | ## HTTP/3 2 | 3 | The HTTP layer does HTTP-style transports, including HTTP header compression 4 | using QPACK - which is similar to the HTTP/2 compression named HPACK. 5 | 6 | The HPACK algorithm depends on an *ordered* delivery of streams so it was not 7 | possible to reuse it for HTTP/3 without modifications since QUIC offers 8 | streams that can be delivered out of order. QPACK can be seen as the 9 | QUIC-adapted version of [HPACK](https://httpwg.org/specs/rfc7541.html). 10 | -------------------------------------------------------------------------------- /fr/quic-tls.md: -------------------------------------------------------------------------------- 1 | # Connections use TLS 2 | 3 | Immédiatement après le paquet initial établissant une connexion, l'initiateur envoie 4 | une trame de cryptage qui commence à établir le handshake de couche sécurisée. La 5 | couche de sécurité utilise la sécurité TLS 1.3. 6 | 7 | Il n'y a aucun moyen de vous désabonner ou d'éviter d'utiliser TLS pour une 8 | connexion QUIC. Le protocole est conçu pour être difficile à altérer par des boîtes 9 | intermédiaires, afin de prévenir l'ossification du protocole. 10 | -------------------------------------------------------------------------------- /zh/feature-udp.md: -------------------------------------------------------------------------------- 1 | ## 基于UDP的传输层协议 2 | 3 | QUIC是基于UDP在用户空间实现的传输协议。如果不观察细节，你会觉得QUIC跟UDP报文差不多。 4 | 5 | 基于UDP意味着它使用UDP端口号来识别指定机器上的特定服务器。 6 | 7 | 目前已知的所有QUIC实现都位于用户空间，这使它能得到更快速的迭代（相较于内核空间中的实现）。 8 | 9 | ## 跑得起来吗？ 10 | 11 | 有一些网络上的中间设备会拦截端口53（用于DNS）以外的UDP流量。还有一些网络会节流（throttle）UDP流量，使得QUIC的表现慢于基于TCP的协议。更多网络的表现未知。 12 | 13 | 在可预见的未来，所有基于QUIC的传输可能会配有一个优雅地回退到另一个基于TCP的后备方案的替代机制。据Google多位工程师早前的报告，协议的失败率不足10%。 14 | 15 | ## 会好起来吗？ 16 | 17 | 如果QUIC被证明确实是互联网世界的一个有益补充，用户会希望能正常使用QUIC，网络公司就可能重新解决上述的拦截。多年以来，随着QUIC取得进展，在互联网上建立和使用QUIC的成功率有所提高。 18 | -------------------------------------------------------------------------------- /zh/why-latency.md: -------------------------------------------------------------------------------- 1 | # 早期数据 2 | 3 | 与TCP的3次握手相比，QUIC提供了0-RTT和1-RTT的握手，这减少了协商和建立新连接时所需的时间。 4 | 5 | 除此之外，QUIC提供了提早传输更多数据的“早期数据”（early data）特性，并且它的使用比TCP快速打开（TCP Fast Open）更加简便。 6 | 7 | 因为数据流概念的引入，客户端不用等待前一个连接结束，便可以与同一个主机建立另一个逻辑连接。 8 | 9 | ## TCP快速打开存在的问题 10 | 11 | TCP快速打开选项由2014年12月发布的[RFC 7413](https://tools.ietf.org/html/rfc7413)定义，该规范中介绍了客户端如何通过第一个TCP SYN报文向服务器推送数据。 12 | 13 | 但在互联网上，对这个选项的实际支持仍需要时间，在2018年的今天，这个选项还是充满很多问题。想要在TCP栈上实现这个选项以获得改进的工程师，不仅要注意操作系统的版本，还要小心地处理发生问题之时，如何优雅地降级到没有该选项的状态。已知有多个网络在积极破坏这种TCP握手，从而干扰了TCP快速打开的流量。 14 | -------------------------------------------------------------------------------- /en/quic.md: -------------------------------------------------------------------------------- 1 | # How QUIC works 2 | 3 | Without explaining the exact bits and bytes on the wire, this section describes how 4 | the fundamental building blocks of the QUIC transport protocol work. If you want to 5 | implement your own QUIC stack, this description should give you a general 6 | understanding, but for all the details, refer to the actual IETF Internet Drafts 7 | and RFCs. 8 | 9 | 1. Set up a [connection](quic-connections.md) 10 | 2. ... that includes [TLS security](quic-tls.md) 11 | 3. Then use [streams](quic-streams.md) 12 | -------------------------------------------------------------------------------- /fr/feature-trans-app.md: -------------------------------------------------------------------------------- 1 | ## Niveau de transport et d'application 2 | 3 | Le protocole IETF QUIC est un protocole de transport sur lequel d'autres protocoles 4 | d'application peuvent être utilisés. Le protocole de couche d'application initial 5 | est HTTP/3 (h3). 6 | 7 | La couche de transport prend en charge les connexions et les flux. 8 | 9 | L'ancienne version de QUIC de Google regroupait le transport et le protocole HTTP 10 | dans un même fait-tout et constituait un protocole send-http/2-frames-over-udp plus 11 | spécifique. 12 | -------------------------------------------------------------------------------- /ja/quic-api.md: -------------------------------------------------------------------------------- 1 | # API 2 | 3 | 通常の TCP やそれを使うプログラムの成功要因の一つは、標準化されたソケット API です。 4 | 5 | 機能は明確に定義されており、その API を利用することで TCP 同様に、同一のプログラムを多くの異なる OS 間で動かすことができます。 6 | 7 | QUIC の場合は違います。QUIC には標準 API はありません。 8 | 9 | QUIC においては既存のライブラリ実装を一つ選択し、その API を使い続ける必要があります。 10 | 11 | これによりアプリケーションを、単一のライブラリにある程度まで「ロックイン」することになります。 12 | 13 | 別のライブラリへの変更は別の API への変更を意味し、多くの作業が必要になるかもしれません。 14 | 15 | また QUIC は通常はユーザー空間で実装されているため、ソケット API を単に拡張することも、既存の TCP や UDP の機能が行っていることと同じようなことを提供することも簡単ではありません。 16 | 17 | QUIC の使用は、ソケット API とは別の API を使おうとすることを意味します。 18 | -------------------------------------------------------------------------------- /fr/feature-http.md: -------------------------------------------------------------------------------- 1 | ## HTTP/3 2 | 3 | La couche HTTP effectue des transports de style HTTP, y compris la compression 4 | d'en-tête HTTP à l'aide de QPACK - ce qui est similaire à la compression HTTP/2 5 | appelée HPACK. 6 | 7 | L'algorithme HPACK dépend d'une livraison *ordonnée* de flux, il n'a donc pas 8 | été possible de le réutiliser pour HTTP/3 sans modifications depuis que QUIC 9 | propose des flux pouvant être livrés dans le désordre. QPACK peut être considéré 10 | comme la version de [HPACK](https://httpwg.org/specs/rfc7541.html) adaptée à QUIC. 11 | -------------------------------------------------------------------------------- /en/why-secure.md: -------------------------------------------------------------------------------- 1 | ## Secure 2 | 3 | QUIC is always secure. There is no clear-text version of the protocol so to 4 | negotiate a QUIC connection means doing cryptography and security with TLS 5 | 1.3. As mentioned above, this prevents ossification as well as other sort of 6 | blocks and special treatments, as well as making sure QUIC has all the secure 7 | properties of HTTPS that web users have come to expect and want. 8 | 9 | There are only a few initial handshake packets that are sent in the clear, 10 | before the encryption protocols have been negotiated. 11 | -------------------------------------------------------------------------------- /fr/feature-tls.md: -------------------------------------------------------------------------------- 1 | ## TLS 1.3 2 | 3 | La sécurité de transport utilisée dans QUIC utilise TLS 1.3 ([RFC 4 | 8446](https://tools.ietf.org/html/rfc8446)) et il n'y a jamais de connexions QUIC 5 | non chiffrées. 6 | 7 | TLS 1.3 présente plusieurs avantages par rapport aux anciennes versions de TLS, 8 | mais l'une des principales raisons de son utilisation dans QUIC est que la 1.3 a 9 | modifié le handshake pour exiger moins d'allers-retours. Cela réduit la latence du 10 | protocole. 11 | 12 | L'ancienne version de QUIC de Google utilisait une crypto personnalisée. 13 | -------------------------------------------------------------------------------- /zh/h3-altsvc.md: -------------------------------------------------------------------------------- 1 | # Alt-svc 2 | 3 | 替代服务（alternative service, Alt-svc:）头部和它相对应的 `ALT-SVC` HTTP/2帧并不是特别为QUIC和HTTP/3设计的。它是为了让服务器可以告诉客户端 *“看，我在这个主机的这个端口用这个协议提供相同的服务”* 而设计的。详见[RFC 7838](https://tools.ietf.org/html/rfc7838)。 4 | 5 | 如果初始连接使用的是HTTP/2（甚至HTTP/1），服务器可以响应并告诉客户端它可以再试试HTTP/3。连接可以指向相同主机或者不同但提供相同服务的主机。Alt-svc回复中有一个到期计时器，让客户端可以在指定的时间内使用建议的替代协议将后续的连接和请求直接发送给替代主机。 6 | 7 | ## 例子 8 | 9 | 一个HTTP服务器的响应中包含了如下的一个 `Alt-Svc:` 头部： 10 | 11 | Alt-Svc: h3=":50781" 12 | 13 | 这指示了同一名称的主机在UDP端口50781提供HTTP/3服务。 14 | 15 | 然后，客户端可以尝试与该端口建立QUIC连接。如果成功，后续将通过该连接继续通信，代替初始的HTTP版本。 16 | -------------------------------------------------------------------------------- /zh/h3-push.md: -------------------------------------------------------------------------------- 1 | # HTTP/3服务器推送 2 | 3 | HTTP/3的服务器推送与HTTP/2（[RFC 7540](https://httpwg.org/specs/rfc7540.html)）类似，但机制上有所不同。 4 | 5 | 服务器推送实际上就是对一个未曾发出的客户端请求做出响应！ 6 | 7 | 服务器推送仅在客户端同意的前提下才允许发出。在HTTP/3中，客户端甚至能通过通告给服务器的最大推送流ID来设置所接受推送的次数限制。超出限制将导致连接错误。 8 | 9 | 如果服务器端认为客户端可能需要某个并未要求但应该有的额外资源，服务器可以通过请求流发送一个 `PUSH_PROMISE` 帧，使该推送请求看上去像是一个响应，然后通过新的流发送实际响应。 10 | 11 | 虽然客户端之前已经表示过推送可接受，但如果客户端认为适合，每个推送流仍可以随时取消，然后发送一个 `CANCEL_PUSH` 帧到服务器。 12 | 13 | ## 问题重重 14 | 15 | 自从推送这一特性在HTTP/2中讨论、开发、部署以来，它就备受争议、讨论和抨击。为了让它有用，人们付出了许多努力。 16 | 17 | 推送从来不是没有代价的，尽管它省了半个往返的延迟，它还是会消耗带宽。服务器也很难或不可能从高层面确定一个资源是否应该被推送过去。 18 | -------------------------------------------------------------------------------- /zh/h3-https.md: -------------------------------------------------------------------------------- 1 | # HTTPS:// URL 2 | 3 | HTTP/3将使用`HTTPS://` URL履行。我们的世界里充斥着HTTPS URL，并且为新协议引入另一种URL方案被认为不切实际且完全不合理。如同HTTP/2一样，HTTP/3不会引入新的URL方案。 4 | 5 | HTTP/2是传输HTTP的一种新方式，但是它还是基于TLS和TCP，这和HTTP/1一样。而在基于QUIC的HTTP/3中，情况更加复杂，它在一些重要的地方做了一些改变。 6 | 7 | 历史遗留下来的明文`HTTP://` URL的处理方式将保持原样，随着我们迈入安全传输更加普及的未来，它的使用可能会越来越少。对HTTP URL的请求不会升级为使用HTTP/3。在实践中，因为其他一些理由，它们也很少升级到HTTP/2。 8 | 9 | ## 初始连接 10 | 11 | 当尝试连接到一个全新的、未访问过的网站时，到HTTPS:// URL的连接可能必须通过TCP（也许会有并行的一个QUIC连接）。因为主机可能是一个不支持QUIC的传统服务器，或者链路之间可能有阻碍QUIC成功连接的中间设备。 12 | 13 | 现代的浏览器和服务器可能在首次握手时协商HTTP/2协议。在连接建立并且服务器响应客户端的HTTP请求时，服务器可以通告客户端它对HTTP/3的支持与偏好。 14 | -------------------------------------------------------------------------------- /ja/quic-spinbit.md: -------------------------------------------------------------------------------- 1 | # Spin Bit 2 | 3 | QUIC ワーキンググループの中でおそらく最も長い間、多数のメールと議論の時間を費やしてきた主題の一つが、単一ビット、つまり Spin Bit です。 4 | 5 | このビットの支持者たちは、2つの QUIC エンドポイント間の経路上に存在するオペレータや人々がレイテンシの観測を出来るようになる必要がある、と主張しています。 6 | 7 | この機能の反対者たちは、その潜在的な情報漏洩が気に入らないのです。 8 | 9 | ## Spinning a bit 10 | 11 | クライアントとサーバー、双方のエンドポイントは各 QUIC コネクションごとに0か1のスピン値が保持されており、その QUIC コネクションの通信パケットは、spin bit を適切な値にセットして送信しています。 12 | 13 | 両サイドは spin bit が1往復する間は同じ値がセットされたパケットを送り、次の値にトグルします。その影響は、観測者がモニタ可能な形でビットフィールド内の0か1のパルスとして現れます。 14 | 15 | この観測は、送信者がアプリケーションやフロー制御による制限を受けていないときにのみ機能し、ネットワーク上のパケットの並び替えはデータを意図しないものにしてしまうことがあります。 16 | -------------------------------------------------------------------------------- /fr/quic.md: -------------------------------------------------------------------------------- 1 | # Comment QUIC fonctionne 2 | 3 | Sans expliquer les bits et les octets exacts sur le réseau, cette section décrit le 4 | fonctionnement des blocs de construction fondamentaux du protocole de transport 5 | QUIC. Si vous souhaitez implémenter votre propre stack QUIC, cette description doit 6 | vous donner une compréhension générale, mais pour tous les détails, référez-vous 7 | aux actuel brouillons internets et RFCs de l'IETF. 8 | 9 | 1. Configurez une [connexion](quic-connections.md) 10 | 2. ... ce qui inclut la [sécurité TLS](quic-tls.md) 11 | 3. Puis utilisez [les flux](quic-streams.md) 12 | -------------------------------------------------------------------------------- /zh/quic-connections.md: -------------------------------------------------------------------------------- 1 | # 连接 2 | 3 | QUIC连接是两个QUIC端点之间的单次会话（conversation）过程。QUIC建立连接时，加密算法的版本协商与传输层握手合并完成，以减小延迟。 4 | 5 | 在连接上实际传输数据时需要建立并使用一个或多个数据流。 6 | 7 | ## 连接ID（Connection ID） 8 | 9 | 每个连接过程都有一组连接标识符，或称连接ID，该ID用以识别该连接。每个端点各自选择连接ID。每个端点选择对方使用的连接ID。 10 | 11 | 连接ID的基本功能是确保底层协议（UDP、IP及其底层协议）的寻址变更不会使QUIC连接传输数据到错误的端点。 12 | 13 | 利用连接ID的优势，连接可以在IP地址和网络接口迁移的情况下得到保持——而这TCP永远做不到。举例来说，当用户的设备连接到一个Wi-Fi网络时，将进行中的下载从蜂窝网络连接转移到更快速的Wi-Fi连接。与此类似，当Wi-Fi连接不再可用时，将连接转移到蜂窝网络连接。 14 | 15 | ## 端口号 16 | 17 | QUIC基于UDP建立，因此使用16比特的UDP端口号字段来区分传入的不同连接。 18 | 19 | ## 版本协商 20 | 21 | 客户端的QUIC连接请求会告知服务器所希望使用的QUIC协议版本，服务器端会回复一系列支持的版本供客户端选择。 22 | -------------------------------------------------------------------------------- /fr/why-secure.md: -------------------------------------------------------------------------------- 1 | ## Sécurisé 2 | 3 | QUIC est toujours sécurisé. Il n'y a pas de version en texte clair clair du 4 | protocole, donc négocier une connexion QUIC signifie faire de la cryptographie et 5 | de la sécurité avec TLS 1.3. Comme mentionné ci-dessus, cela empêche l'ossification 6 | ainsi que d'autres types de blocages et traitements spéciaux, et garantit que QUIC 7 | possède toutes les propriétés sécurisées de HTTPS auxquelles les utilisateurs Web 8 | s'attendent et souhaitent. 9 | 10 | Il n’y a que quelques paquets handshake initiaux qui sont envoyés en clair, avant 11 | que les protocoles de cryptage aient été négociés. 12 | -------------------------------------------------------------------------------- /ja/feature-streams.md: -------------------------------------------------------------------------------- 1 | ## コネクションは複数のストリームを扱う 2 | 3 | SCTP、SSH、HTTP/2 と似たように、QUIC は単一の物理的なコネクションで別々の論理的なストリームを扱えるという特徴があります。 4 | 5 | 複数の並列ストリームは、それぞれ単一のコネクションで接続しているかのように他のストリームに影響を与えずにデータを転送できます。 6 | 7 | QUIC コネクションは、TCP コネクションと似たような仕組みで、2つのエンドポイント間でのネゴシエーションを経て確立します。 8 | 9 | QUIC コネクションは UDP ポートと IP アドレスで構成されますが、一旦コネクションが確立すると、それは自身が持つ「コネクション ID」により関連付けられます。 10 | 11 | 確立済みのコネクションを使って、どちら側もストリームを作成して相手にデータを送信できます。 12 | 13 | ストリームのデータは到着順序が保証され、また信頼性があります。 14 | 15 | しかし、異なるストリーム間では到着順序は保証されません。 16 | 17 | QUIC はコネクションとストリームの両方においてフロー制御を提供します。 18 | 19 | 詳細は [コネクション](quic-connections.md) 節と [ストリーム](quic-streams.md) 節で確認できます。 20 | -------------------------------------------------------------------------------- /ja/proc.md: -------------------------------------------------------------------------------- 1 | # これまでの歩み 2 | 3 | 最初の QUIC プロトコルは Google の Jim Roskind によって設計され、最初の実装は2012年に行われました。2013年に Google の実験として世界中に公開されました。 4 | 5 | 当時は QUIC は "Quick UDP Internet Connections" の略語だとされていましたが、そのときからこのように言われなくなりました。 6 | 7 | Google はプロトコルを実装し、それに続いて広く使われている Google 製のブラウザ (Chrome) と、広く使われている Google のサーバーサイドのサービス (Google検索、gmail、youtube などなど) に実装しました。彼らは非常に早くプロトコルを改善し、このプロトコルが大量のユーザーでも信頼性が高く動作することを証明しました。 8 | 9 | 2015年5月に最初の QUIC のドラフトが標準化のために IETF に提出されましたが、QUIC ワーキンググループが承認されスタートするのは2016年後半までかかりました。しかし、多くの人々から注目を集め QUIC ワーキンググループは早急に立ち上がりました。 10 | 11 | 2017年には Google の QUIC エンジニアが *全ての* インターネットトラフィックの約7 %がすでに Google 版の QUIC プロトコルを利用していると報告されました。 12 | -------------------------------------------------------------------------------- /zh/h3-h2.md: -------------------------------------------------------------------------------- 1 | # HTTP/3与HTTP/2的比较 2 | 3 | HTTP/3面向QUIC设计，QUIC是一个自己处理数据流的传输层协议。 4 | 5 | HTTP/2面向TCP设计，因此数据流在HTTP层处理。 6 | 7 | ## 相似之处 8 | 9 | 这两个协议为客户端提供了几乎相同的功能集。 10 | 11 | - 两者都提供数据流 12 | 13 | - 两者都提供服务器推送 14 | 15 | - 两者都有头部压缩，QPACK与HPACK的设计非常类似 16 | 17 | - 两者都通过单一连接上的数据流提供复用 18 | 19 | - 两者都提供数据流的优先度设置 20 | 21 | ## 不同之处 22 | 23 | 两个协议的主要不同点在于细节，不同之处主要由HTTP/3使用的QUIC带来。 24 | 25 | - 得益于QUIC的0-RTT握手，HTTP/3可以提供更好的早期数据支持，而TCP快速打开和TLS通常只能传输更少的数据，且经常存在问题。 26 | 27 | - 得益于QUIC，HTTP/3的握手速度比TCP+TLS快得多。 28 | 29 | - HTTP/3不存在明文的不安全版本。尽管在互联网上很少见，HTTP/2还是可以不配合HTTPS来实现和使用。 30 | 31 | - 通过ALPN拓展，HTTP/2可以直接在TLS握手时进行协商。HTTP/3基于QUIC，所以需要凭借响应中的 `Alt-Svc:` 头部来向客户端宣告。 32 | -------------------------------------------------------------------------------- /en/feature-handshakes.md: -------------------------------------------------------------------------------- 1 | # Fast handshakes 2 | 3 | QUIC offers both 0-RTT and 1-RTT connection setups, meaning that at best QUIC 4 | needs no extra round-trips at all when setting up a new connection. The faster 5 | of those two, the 0-RTT handshake, only works if there has been a previous 6 | connection established to a host and a secret from that connection has been 7 | cached. 8 | 9 | ## Early data 10 | 11 | QUIC allows a client to include data already in the 0-RTT handshake. This 12 | feature allows a client to deliver data to the peer as fast as it possibly 13 | can, and that then of course allows the server to respond and send data back 14 | even sooner. 15 | -------------------------------------------------------------------------------- /en/h3-prio.md: -------------------------------------------------------------------------------- 1 | # HTTP/3 Prioritization 2 | 3 | One of the HTTP/3 stream frames is called `PRIORITY`. It is used to set 4 | priority and dependency on a stream in a way similar to how it works in 5 | HTTP/2. 6 | 7 | The frame can set a specific stream to depend on another specific stream and 8 | it can set a "weight" on a given stream. 9 | 10 | A dependent stream should only be allocated resources if either all of the 11 | streams that it depends on are closed or it is not possible to make progress 12 | on them. 13 | 14 | A stream weight is value between 1 and 256 and it is specified that streams 15 | with the same parent **should** be allocated resources proportionally based on 16 | their weight. 17 | -------------------------------------------------------------------------------- /en/proc-h2.md: -------------------------------------------------------------------------------- 1 | ## Experience from HTTP/2 2 | 3 | The HTTP/2 specification RFC 7540 was published in May 2015, just a month 4 | before QUIC was brought to IETF for the first time. 5 | 6 | With HTTP/2, the foundation for changing HTTP over the wire was laid out and 7 | the working group that created HTTP/2 was already of the mindset that this 8 | would help iterating to new HTTP versions much faster than it had taken to go 9 | to version 2 from version 1 (about 16 years). 10 | 11 | With HTTP/2, users and software stacks got used to the idea that HTTP can no 12 | longer be assumed to be done with a text-based protocol in a serial manner. 13 | 14 | HTTP-over-QUIC was renamed to HTTP/3 in November 2018. 15 | -------------------------------------------------------------------------------- /ja/feature-inorder.md: -------------------------------------------------------------------------------- 1 | ## 到着順序の保証 2 | 3 | QUIC はストリーム内での到着順序を保証しますが、ストリーム間の順序を保証しません。 4 | 5 | これは、ストリームは送信したデータの順序を維持しますが、各ストリームが宛先に到達する順序はアプリケーションがそれらを送信したときとは異なるものになり得ることを意味します！ 6 | 7 | 例: ストリーム A と B がサーバーからクライアントに転送されました。 8 | 9 | ストリーム A は最初に処理が開始され、ストリーム B はそれに続きました。 10 | 11 | QUIC では、パケットの損失はそのパケットが属するストリームのみに影響を及ぼします。 12 | 13 | ストリーム A でパケット損失が発生し、ストリーム B では発生しなかった場合、ストリーム A がパケットの再送を行っている間もストリーム B は転送を継続し、先に完了するかもしれません。これは HTTP/2 では不可能でした。 14 | 15 | ここに、2つの QUIC エンドポイントが1つのコネクションを介して黄色のストリームと青色のストリームの転送を行う様子を示す図があります。 16 | 17 | それぞれのストリームは独立しており、異なる順序で到達する可能性がありますが、いずれのストリームも信頼性と到達順序を損なうことなくアプリケーションに配信されます。 18 | 19 | ![two QUIC streams between two computers](../images/quic-chain-streams.png) 20 | -------------------------------------------------------------------------------- /zh/quic-v2.md: -------------------------------------------------------------------------------- 1 | # QUIC v2 2 | 3 | 为了尽力专注于QUIC的核心特性，以及为了赶上发布进度，最初计划为核心协议一部分的几个特性已被推迟，计划到QUIC第二版或以后的版本中完成。 4 | 5 | 本文档的作者买的水晶球是山寨的，所以我们不能知道哪些特性会或者不会出现在第二版中。但我们可以谈谈那些在第一版中被标记为“之后做”的可能出现在第二版中的特性。 6 | 7 | ## 前向纠错（Forward Error Correction） 8 | 9 | 前向纠错（FEC）是一种通过向接收方发送冗余数据，使得接收方能快速识别出含有不明显错误的一种错误控制方式。 10 | 11 | Google在它们的原版QUIC成果中实验过该特性，但由于实验结果不理想而已经去除。此特性可供QUIC v2讨论，但可能需要有人证明它在代价不大的情况下确实有用。 12 | 13 | ## 多路径（Multipath） 14 | 15 | 多路径意味着通信可以通过多个网络路径传输，以期最大化利用资源并增加冗余。 16 | 17 | SCTP支持者可能有话说了，SCTP和现代TCP早就已经支持这一点。 18 | 19 | ## 不可靠数据 20 | 21 | 通过QUIC传输不可靠的数据流也得到过广泛讨论，这样QUIC就能在传统UDP风格的应用程序中作为代用品。 22 | 23 | ## 非HTTP适应 24 | 25 | 基于QUIC的DNS是早期被提出的非HTTP协议之一，这可能在QUIC v1和HTTP/3发布后得到更多的关注。但我想，如果我们拥有了这样的新型传输层协议，DNS远不是终点。 26 | -------------------------------------------------------------------------------- /fr/h3-prio.md: -------------------------------------------------------------------------------- 1 | # Priorisation de HTTP/3 2 | 3 | Une des trames de flux HTTP/3 s'appelle `PRIORITY`. Elle est utilisé pour définir 4 | la priorité et la dépendance à un flux d'une manière similaire à celle de HTTP/2. 5 | 6 | La trame peut définir un flux spécifique pour dépendre d'un autre flux spécifique 7 | et définir un "poids" sur un flux donné. 8 | 9 | Des ressources dépendantes doivent se voir allouer des ressources que si tous les 10 | flux dont il dépend sont fermés ou s'il est impossible de progresser sur ces flux. 11 | 12 | Un poids de flux est compris entre 1 et 256 et il est spécifié que les flux avec le 13 | même parent **devraient** se voir allouer des ressources proportionnellement en 14 | fonction de leur poids. 15 | -------------------------------------------------------------------------------- /zh/why-h2.md: -------------------------------------------------------------------------------- 1 | ## 回顾HTTP/2 2 | 3 | HTTP/2协议规范（[RFC 7540](https://httpwg.org/specs/rfc7540.html)）于2015年5月发表，在那之后，该协议已在互联网和万维网上得到广泛的实现和部署。 4 | 5 | 2018年初，最热的前一千个网站中约40%运行着HTTP/2，而在Firefox发出的HTTPS请求中，约70%的请求得到了HTTP/2响应。主流的浏览器、服务器以及代理都支持了HTTP/2。 6 | 7 | HTTP/2解决了HTTP/1中存在的一大堆缺点，其中相当一部分对于开发者来说非常麻烦。在HTTP/2出现前，开发者要用许多种变通方法来解决，而HTTP/2解决了它们。 8 | 9 | HTTP/2的一个主要特性是使用多路复用（multiplexing），因而它可以通过同一个TCP连接发送多个逻辑数据流。复用使得很多事情变得更快更好，它带来更好的拥塞控制、更充分的带宽利用、更长久的TCP连接————这些都比以前更好了，链路能更容易实现全速传输。标头压缩技术也减少了带宽的用量。 10 | 11 | 采用HTTP/2后，浏览器对每个主机一般只需要 一个 TCP连接，而不是以前常见的 六个 连接。事实上，HTTP/2使用的连接聚合（connection coalescing）和“去分片”（desharding）技术还可以进一步缩减连接数。 12 | 13 | HTTP/2解决了HTTP的队头拥塞（head of line blocking）问题，客户端必须等待一个请求完成才能发送下一个请求的日子过去了。 14 | 15 | ![http2 man](../images/h2-man.jpg) 16 | -------------------------------------------------------------------------------- /zh/proc-ietf.md: -------------------------------------------------------------------------------- 1 | ## IETF 2 | 3 | IETF为QUIC标准化成立的QUIC工作组很快就决定，IETF标准化的QUIC协议应该支持HTTP以外的其他应用层协议。Google版的QUIC只传输HTTP——在实践中，它则被用来传输符合HTTP/2帧语义的片段。 4 | 5 | 另外，工作组最初也决定IETF-QUIC应该基于TLS 1.3进行加密与安全传输，而不使用Google版QUIC定制的方法。 6 | 7 | 为满足不局限于HTTP的传输需求，IETF QUIC协议的架构被分为两个独立的层：传输层QUIC和“基于QUIC的HTTP”（HTTP over QUIC）层（有时候缩写为“hq”）。 8 | 9 | 尽管这种分层结构看似人畜无害，但这实质上造成IETF-QUIC与Google版QUIC有着诸多不同。 10 | 11 | 工作组很快发现了这一点，为保持适当关注和能按时交付第一版QUIC，工作组的重心转移到了HTTP传输，非HTTP传输将留待今后研究。 12 | 13 | 2018年3月，当我们开始写这本书的时候，第一版QUIC最终的规范计划于2018年11月发布。不过发布时间在这之后被推迟到了2019年7月。 14 | 15 | 在IETF-QUIC取得进展的同时，Google团队已经整合了IETF版本的细节并逐渐推进他们的协议版本，以期最终可能符合IETF定义的规范。尽管如此，Google在他们的浏览器和服务中继续使用自己的QUIC版本。 16 | 17 | [正在开发的大多数新实现](https://github.com/quicwg/base-drafts/wiki/Implementations) 18 | 已经决定着眼于IETF版本，与Google版本并不兼容。 -------------------------------------------------------------------------------- /fr/proc-h2.md: -------------------------------------------------------------------------------- 1 | ## Expérience depuis HTTP/2 2 | 3 | La spécification HTTP/2 RFC 7540 a été publiée en mai 2015, just un mois avant que 4 | QUIC ne soit présenté pour la première fois à l'IETF. 5 | 6 | Avec HTTP/2, les bases de la modification de HTTP sur le réseau ont été aménagés 7 | et le groupe de travail qui a créé HTTP/2 était déjà convaincu que cela aiderait à 8 | effectuer une itération sur de nouvelles versions HTTP plus rapidement qu’il a 9 | fallu pour passer de la version 1 à la version 2 (environ 16 ans). 10 | 11 | Avec HTTP/2, les utilisateurs et les stacks logiciels se sont habitués à l'idée que 12 | le protocole HTTP ne peut plus être supposé être exécuté en série avec un protocole 13 | texte. 14 | 15 | HTTP-over-QUIC a été renommé HTTP/3 en novembre 2018. 16 | -------------------------------------------------------------------------------- /fr/feature-handshakes.md: -------------------------------------------------------------------------------- 1 | # Handshakes rapides 2 | 3 | QUIC offre à la fois des configurations de connexion 0-RTT et 1-RTT, ce qui 4 | signifie qu'au mieux, QUIC ne nécessitera aucun aller-retour supplémentaire lors 5 | de la configuration d'une nouvelle connexion. Le plus rapide des deux, la 6 | négociation 0-RTT, ne fonctionne que si une connexion précédente a été établie 7 | avec un hôte et qu'un secret de cette connexion a été mis en cache. 8 | 9 | ## Données précoces 10 | 11 | QUIC permet à un client d'inclure des données déjà dans le handshake 0-RTT. Cette 12 | fonctionnalité permet à un client de transmettre les données à l'homologue aussi 13 | rapidement que possible, ce qui permet bien entendu au serveur de répondre et de 14 | renvoyer les données encore plus tôt. 15 | -------------------------------------------------------------------------------- /ja/why-latency.md: -------------------------------------------------------------------------------- 1 | # Earlier data 2 | 3 | QUIC は新規コネクションのネゴシエート時間を短縮するため、0-RTT ハンドシェイクと 1-RTT ハンドシェイクを提供します。 4 | 5 | TCP における 3-way ハンドシェイクと比較してみてください。 6 | 7 | 加えて、QUIC はより多くのデータを処理するため、最初から "early data" をサポートしており、TCP Fast Open よりも簡単に利用できます。 8 | 9 | 既存のコネクションが終了するのを待つことなく同じホストへ別のコネクションを接続できることが、ストリームのコンセプトとして挙げられています。 10 | 11 | 12 | 13 | ## TCP Fast Open の問題について 14 | 15 | TCP Fast Open は、2014年12月に [RFC 7413](https://tools.ietf.org/html/rfc7413) として公開されました。 16 | 17 | この仕様では、初回の TCP SYN パケットが既に配信されているサーバーに対して、アプリケーションがどのようにデータを渡すのかについて説明しています。 18 | 19 | 有志によるこの機能のサポートには時間がかかっており、2018年の現在でも問題が発生しています。 20 | 21 | TCP スタックの実装者やアプリケーションがこの機能の利点を利用するためには、OS バージョンに応じた有効化の方法や、問題が発生した際にどのように正常な処理に遷移するのか、の両方を理解する必要があります。 22 | 23 | いくつかのネットワークが TFO トラフィックを妨げ TCP ハンドシェイクを台無しにする事が確認されています。 24 | 25 | -------------------------------------------------------------------------------- /zh/h3-streams.md: -------------------------------------------------------------------------------- 1 | # QUIC流与HTTP/3 2 | 3 | HTTP/3针对QUIC设计，所以它可以利用QUIC流的所有好处。而HTTP/2不得不在TCP之上构建它的数据流和复用概念。 4 | 5 | 通过HTTP/3传输的HTTP请求使用一系列的数据流完成。 6 | 7 | ## HTTP/3帧（frame） 8 | 9 | HTTP/3意味着建立QUIC数据流，并将一系列帧发送给对方。HTTP/3中的数据帧种类不多且固定（截至2018年12月18日有九种）。最关键的帧可能是： 10 | 11 | - HEADERS：发送压缩的HTTP头部 12 | - DATA：发送二进制数据内容 13 | - GOAWAY：请关闭此连接 14 | 15 | ## HTTP请求 16 | 17 | 客户端通过其发起的 双向 QUIC流来发送HTTP请求。 18 | 19 | 一个请求包括一个HEADERS帧，之后可能有一两种其他的帧：一系列的DATA帧，以及可能有一个作为末尾的HEADERS帧。 20 | 21 | 发送一个请求后，客户端会关闭该数据流以进行发出。 22 | 23 | ## HTTP响应 24 | 25 | 服务器在双向流上发回其HTTP响应。其中含有一个HEADERS帧，一系列DATA帧，末尾可能有一个HEADERS帧。 26 | 27 | ## QPACK头部 28 | 29 | HEADERS含有用QPACK算法压缩的HTTP头部。QPACK与HTTP/2中的HPACK（[RFC 30 | 7541](https://httpwg.org/specs/rfc7541.html)）类似，并针对乱序流做了相应修改。 31 | 32 | QPACK本身在两个端点间使用两个额外的单向QUIC流，用于在两个方向上传递动态表信息。 33 | -------------------------------------------------------------------------------- /ja/h3.md: -------------------------------------------------------------------------------- 1 | # HTTP/3 2 | 3 | 前述のとおり、QUIC 上でトランスポートする最初の基本的なプロトコルは HTTP です。 4 | 5 | かつて HTTP/2 が完全に新しい方法を用いて、ネットワーク経由で HTTP をトランスポートするために導入されたのとよく似ていて、HTTP/3 もまた、ネットワーク上で HTTP 送信を行う新しい方法を導入します。 6 | 7 | HTTP は今でも以前と同じパラダイムとコンセプトを維持しています。 8 | 9 | ヘッダとボディがあり、リクエストとレスポンスがあります。 10 | 11 | HTTP メソッドがあり、クッキーがあり、キャッシュ機能があります。 12 | 13 | HTTP/3 で主に変わったことは、どのようにビットを伝達相手に送るかです。 14 | 15 | HTTP over QUIC を実現するために、様々な変更が必要とされ、その成果がいま私達が HTTP/3 と呼んでいるものです。 16 | 17 | これらの変更は QUIC が TCP とは異なった性質を持つために必要とされました。 18 | 19 | これらの変更は、以下のものを含んでいます。 20 | 21 | - QUIC において、ストリームはトランスポート自体により提供されますが、その一方で HTTP/2 において、ストリームは HTTP レイヤーで実行されます。 22 | 23 | - ストリームが互いに独自のものであるため、HTTP/2 で使われているヘッダ圧縮プロトコルを使用すると head-of-line ブロック状態を引き起こすようになりました。 24 | 25 | - QUIC ストリームは HTTP/2 ストリームとは僅かに異なります。HTTP/3 セクションでは、これについてやや詳細に説明します。 26 | -------------------------------------------------------------------------------- /en/why-quic.md: -------------------------------------------------------------------------------- 1 | # Why QUIC 2 | 3 | QUIC is a name, not an acronym. It is pronounced exactly like the English word 4 | "quick". 5 | 6 | QUIC is in many ways what could be seen as a way of doing a new reliable and 7 | secure transport protocol that is suitable for a protocol like HTTP and that 8 | can address some of the known shortcomings of doing HTTP/2 over TCP and 9 | TLS. The logical next step in the web transport evolution. 10 | 11 | QUIC is not limited to just transporting HTTP. The desire to make the web and 12 | data in general delivered faster to end users is probably the largest reason 13 | and push that initially triggered the creation of this new transport protocol. 14 | 15 | So why create a new transport protocol and why do it on top of UDP? 16 | 17 | ![QUIC logo](../images/QUIC.png) 18 | -------------------------------------------------------------------------------- /en/quic-userspace.md: -------------------------------------------------------------------------------- 1 | ## User-space 2 | 3 | Implementing a transport protocol in user-space helps enable quick 4 | iteration of the protocol, as it is comparatively easy to evolve the 5 | protocol without necessitating that clients and servers update their 6 | operating system kernel to deploy new versions. 7 | 8 | Nothing inherent in QUIC prevents it from being implemented and offered 9 | by operating system kernels in the future, should someone find that a 10 | good idea. 11 | 12 | ### Many implementations 13 | 14 | One obvious effect of implementing a new transport protocol in 15 | user-space is that we can expect to see many independent implementations. 16 | 17 | Different applications are likely to include (or layer atop) different 18 | HTTP/3 and QUIC implementations for the foreseeable future. 19 | -------------------------------------------------------------------------------- /zh/why-ossification.md: -------------------------------------------------------------------------------- 1 | # 协议僵化（Ossification） 2 | 3 | 互联网（Internet）——多个网络互联之网。为了保证互联网工作正常，我们需要在互联网各处搭建各种设备。这些在互联网上分布式架设的设备被称为中间设备（middle-box）。传统网络传输中两个端点之间的中间设备服务于网络数据传输过程。 4 | 5 | 这些中间设备有着许多、各式各样的用途和目的，我们简单来说，这些设备是为了实现放置人在该位置所要完成的特定目的而安置。 6 | 7 | 中间设备的目的包括：在网络之间转发（路由）数据包、阻挡恶意流量、执行地址转换（NAT）、提升性能、监视流量等等。 8 | 9 | 为了完成这些目的，这些设备必须了解网络以及它们所要监视或修改的数据包协议。它们为此依赖于一些软件——一些很少升级的软件。 10 | 11 | 虽然这些设备是将互联网“粘”在一起的关键元素，但是它们经常跟不上最新的技术。网络的核心部分与边缘部分（客户端、服务器）相比，更新很慢。 12 | 13 | 所以当这些设备决定了经过的流量是否合格时，就有些问题了——在这些设备部署之后的一段时间里，协议有了新的特征。而在这些设备引入（了解）这些新特性之前，它们会认为这种特征的数据包是非法的、恶意的，于是会将这种流量直接扔掉，或是拖延到用户不再想使用这些新特征的程度。 14 | 15 | 这种问题就被称之为“协议僵化”。 16 | 17 | 协议僵化也影响了TCP协议的改变：当客户端与远程服务器之间的某些中间设备检测到对于它们来说未知的新的TCP选项时，中间设备将拦截这些流量，因为它们不知道这些选项的作用。如果中间设备监测了协议的实现细节，它们会学习到协议的典型行为，在一段时间后，这些行为变得没法更改。 18 | 19 | 尽可能将通信加密是对抗僵化的唯一有效手段，加密可以防止中间设备看到协议传输的绝大部分内容。 -------------------------------------------------------------------------------- /zh/specs.md: -------------------------------------------------------------------------------- 1 | # 技术标准 2 | 3 | 以下是QUIC和HTTP/3各个部分的最新官方IETF草案列表。 4 | 5 | ## 不变性 6 | 7 | [Version-Independent Properties of QUIC](https://tools.ietf.org/html/draft-ietf-quic-invariants-03) 8 | 9 | ## 传输层 10 | 11 | [QUIC: A UDP-Based Multiplexed and Secure Transport](https://tools.ietf.org/html/draft-ietf-quic-transport-18) 12 | 13 | ## 自动恢复 14 | 15 | [QUIC Loss Detection and Congestion Control](https://tools.ietf.org/html/draft-ietf-quic-recovery-18) 16 | 17 | ## TLS 18 | 19 | [Using Transport Layer Security (TLS) to Secure QUIC](https://tools.ietf.org/html/draft-ietf-quic-tls-18) 20 | 21 | ## HTTP 22 | 23 | [Hypertext Transfer Protocol (HTTP) over QUIC](https://tools.ietf.org/html/draft-ietf-quic-http-18) 24 | 25 | ## QPACK 26 | 27 | [QPACK: Header Compression for HTTP over QUIC](https://tools.ietf.org/html/draft-ietf-quic-qpack-06) 28 | -------------------------------------------------------------------------------- /en/quic-api.md: -------------------------------------------------------------------------------- 1 | # API 2 | 3 | One of the success factors for regular TCP and programs using that, is the 4 | standardized socket API. It has well defined functionality and using this API 5 | you can move programs between many different operating systems as TCP works 6 | the same. 7 | 8 | QUIC is not there. There is no standard API for QUIC. 9 | 10 | With QUIC, you need to pick one of the existing library implementations and 11 | stick with its API. It makes applications "locked in" to a single library to 12 | some extent. Changing to another library means another API and that might 13 | involve a lot of work. 14 | 15 | Also, since QUIC is typically implemented in user-space, it can't easily just 16 | extend the socket API or appear similar to how existing TCP and UDP 17 | functionality do. Using QUIC will mean using another API than the socket API. 18 | -------------------------------------------------------------------------------- /ja/feature-udp.md: -------------------------------------------------------------------------------- 1 | ## UDP 上の転送プロトコル 2 | 3 | QUIC は UDP のユーザー空間に実装された転送プロトコルです。 4 | 5 | あなたのネットワークトラフィックを軽く確認してみれば、QUIC は UDP パケットとして見えるでしょう。 6 | 7 | UDP 上に実装されている以上、QUIC もまた、UDP のポート番号を利用して、与えられた IP アドレス上にある特定のサービスを識別します。 8 | 9 | 現在、既知の QUIC のすべては、ユーザー空間で動作するように実装されています。 10 | 11 | これは通常、カーネル空間で実装するよりも素早い発展が可能です。 12 | 13 | ## うまく動作しますか？ 14 | 15 | エンタープライズのネットワークなどではポート53 (DNS に使われる) 以外の UDP トラフィックをブロックするように設定していることがあります。 16 | 17 | 他にも、制御技術が QUIC の性能を TCP を利用したプロトコルよりも悪くすることがあります。 18 | 19 | このような、運用者が行うかもしれないことに関する議論には果てがありません。 20 | 21 | 近いうちに、すべての QUIC をもとにした転送の用途は、もう一つの (TCP をもとにした) 代替手段に正常に切り替えられる必要があるでしょう。 22 | 23 | これに関しては、Google のエンジニアによると、計測では1桁台前半の失敗率だったとのことです。 24 | 25 | ## 良くなりますか？ 26 | 27 | QUIC がインターネットの世界にとって価値のある追加物だと証明されれば、人々はそれを使いたいと考え、自分たちのネットワークで機能することを望み、企業はそれに対する障害について考え直すでしょう。 28 | 29 | 長年にわたり QUIC の開発は進んでおり、インターネットにおいて QUIC を利用した接続の成功率は向上しています。 30 | -------------------------------------------------------------------------------- /fr/why-quic.md: -------------------------------------------------------------------------------- 1 | # Pourquoi QUIC 2 | 3 | QUIC est un nom, pas un acronyme. Il se prononce exactement comme le mot anglais 4 | "quick". 5 | 6 | QUIC est à bien des égards ce qui pourrait être perçu comme un moyen de créer un 7 | nouveau protocole de transport fiable et sécurisé, adapté à un protocole comme HTTP 8 | et pouvant résoudre certains des inconvénients connus de HTTP/2 sur TCP et TLS. La 9 | prochaine étape logique dans l'évolution du transport Web. 10 | 11 | QUIC n'est pas limité au seul transport de HTTP. La volonté de rendre le web et les 12 | données en général plus rapides aux utilisateurs finaux est probablement la raison 13 | principale et la poussée qui a initialement déclenché la création de ce nouveau 14 | protocole de transport. 15 | 16 | Alors pourquoi créer un nouveau protocole de transport et pourquoi le faire par 17 | dessus UDP? 18 | 19 | ![QUIC logo](../images/QUIC.png) 20 | -------------------------------------------------------------------------------- /ja/h3-push.md: -------------------------------------------------------------------------------- 1 | # HTTP/3 サーバープッシュ 2 | 3 | HTTP/3 サーバープッシュは HTTP/2 で説明されているもの ([RFC7540](https://httpwg.org/specs/rfc7540.html)) と似ていますが、異なるメカニズムを利用します。 4 | 5 | サーバープッシュは、クライアントからのリクエストがなくても返すことができるレスポンスです。 6 | 7 | サーバープッシュはクライアント側が合意した場合にのみ受け取ることが可能です。 8 | 9 | 加えて HTTP/3 では、クライアントがサーバーに対してプッシュストリームの最大 ID を通知することでプッシュをいくつまで受け入れ可能か制限を設定しています。この制限を超えると、コネクションエラーとなります。 10 | 11 | サーバーが、クライアントからの要求はなかったが、いずれ必要になる追加のリソースが他にもあると判断する場合、レスポンスがプッシュであることを示す `PUSH_PROMISE` フレームをリクエストフレームを通して送ることができ、その後実際のレスポンスを新しいストリーム上で送信します。 12 | 13 | 予めクライアントによってプッシュの受け入れが可能であると通知されている場合であっても、それぞれのプッシュストリームはクライアント側の判断によって拒否することができます。 14 | 15 | その際には `CANCEL_PUSH` フレームがサーバーへ送信されます。 16 | 17 | ## 問題点 18 | 19 | サーバープッシュは HTTP/2 の開発時に当初議論され、プロトコルの策定の後インターネットへと展開されたにもかかわらず、その有用性について数えきれないほどの議論が行われ、叩かれ嫌われ続けてきました。 20 | 21 | プッシュは決して "無料" ではありません。ラウンドトリップの半分を削減することができますが、それでも帯域を使うことに変わりないからです。サーバー側にとって、リソースが実際にプッシュされるべきかどうかをハイレベルで確実に判断することは非常に難しく、おおよそ不可能です。 22 | -------------------------------------------------------------------------------- /ja/h3-h2.md: -------------------------------------------------------------------------------- 1 | # HTTP/2 と比較した HTTP/3 2 | 3 | HTTP/3 は、自身でストリームを処理するトランスポートプロトコルである QUIC に合わせた設計になっています。 4 | 5 | HTTP/2 は TCP を前提とした設計のため、HTTP レイヤーでストリームを処理します。 6 | 7 | ## 類似点 8 | 9 | この2つのプロトコルは、クライアントに対して事実上同じ機能を提供します。 10 | 11 | - どちらのプロトコルも、ストリームを提供します。 12 | 13 | - どちらのプロトコルも、サーバープッシュのサポートを提供します。 14 | 15 | - どちらのプロトコルもヘッダー圧縮が提供され、QPACK と HPACK は設計上似ています。 16 | 17 | - どちらのプロトコルも、1つの接続でストリームによる多重化が提供されます。 18 | 19 | - どちらのプロトコルも、ストリームの優先順位付けを行います。 20 | 21 | ## 相違点 22 | 23 | 差異は主に詳細にあり、HTTP/3 が QUIC を利用することによるものです。 24 | 25 | - TCP Fast Open と TLS では、一般的にあまりデータ量を送信せず、しばしば問題を引き起こす一方で、HTTP/3 は QUIC の 0-RTT ハンドシェイクのおかげで、early data のサポートがあります。 26 | 27 | - HTTP/3 は QUIC のおかげで TCP と TLS の組み合わせより高速なハンドシェイクを実現します。 28 | 29 | - HTTP/3 では全て暗号化された安全な通信です。HTTP/2 は、インターネット上においては稀なことであるにせよ、 HTTPS なしで実装することも可能です。 30 | 31 | - HTTP/2 では TLS ハンドシェイクを ALPN 拡張 を用いて、直接ネゴシエーションが可能です。一方で、HTTP/3 は 事実上、QUIC 上で動くため、クライアントにこの内容を知らせるため `Alt-Svc:` ヘッダーレスポンス が最初に必要です。 32 | -------------------------------------------------------------------------------- /en/feature-streams.md: -------------------------------------------------------------------------------- 1 | ## ‎Multiple streams within connections 2 | 3 | Similar to SCTP, SSH and HTTP/2, QUIC features separate logical streams within 4 | the physical connections. A number of parallel streams that can transfer data 5 | simultaneously over a single connection without affecting the other streams. 6 | 7 | A connection is a negotiated setup between two end-points similar to how a TCP 8 | connection works. A QUIC connection is made to a UDP port and IP address, but 9 | once established the connection is associated by its "connection ID". 10 | 11 | Over an established connection, either side can create streams and send data 12 | to the other end. Streams are delivered in-order and they are reliable, but 13 | different streams may be delivered out-of-order. 14 | 15 | QUIC offers flow control on both connection and streams. 16 | 17 | See further details in [connections](quic-connections.md) and 18 | [streams](quic-streams.md) sections 19 | -------------------------------------------------------------------------------- /en/specs.md: -------------------------------------------------------------------------------- 1 | # The specifications 2 | 3 | Here is a collection of the latest official drafts for the various parts and 4 | components of QUIC and HTTP/3. 5 | 6 | ## Invariants 7 | 8 | [Version-Independent Properties of QUIC](https://tools.ietf.org/html/draft-ietf-quic-invariants-03) 9 | 10 | ## Transport 11 | 12 | [QUIC: A UDP-Based Multiplexed and Secure Transport](https://tools.ietf.org/html/draft-ietf-quic-transport-18) 13 | 14 | ## Recovery 15 | 16 | [QUIC Loss Detection and Congestion Control](https://tools.ietf.org/html/draft-ietf-quic-recovery-18) 17 | 18 | ## TLS 19 | 20 | [Using Transport Layer Security (TLS) to Secure QUIC](https://tools.ietf.org/html/draft-ietf-quic-tls-18) 21 | 22 | ## HTTP 23 | 24 | [Hypertext Transfer Protocol (HTTP) over QUIC](https://tools.ietf.org/html/draft-ietf-quic-http-18) 25 | 26 | ## QPACK 27 | 28 | [QPACK: Header Compression for HTTP over QUIC](https://tools.ietf.org/html/draft-ietf-quic-qpack-06) 29 | -------------------------------------------------------------------------------- /fr/quic-userspace.md: -------------------------------------------------------------------------------- 1 | ## Espace utilisateur 2 | 3 | L'implémentation d'un protocole de transport dans l'espace utilisateur permet une 4 | itération rapide du protocole, car il est relativement facile de faire évoluer le 5 | protocole sans nécessiter que les clients et les serveurs mettent à jour le noyau 6 | de leur système d'exploitation pour déployer de nouvelles versions. 7 | 8 | Rien d’inhérent dans QUIC ne l’empêche d’être implémenté et proposé ultérieurement 9 | par les noyaux de systèmes d’exploitation, si quelqu'un trouve ça une bonne idée. 10 | 11 | ### De nombreuses implémentations 12 | 13 | Un des effets évidents de l’implémentation d’un nouveau protocole de transport dans 14 | l’espace utilisateur est que nous pouvons nous attendre à de nombreuses 15 | implémentations indépendantes. 16 | 17 | Différentes applications sont susceptibles d'inclure (ou de superposer) différentes 18 | implémentations de HTTP/3 et de QUIC dans un avenir prévisible. 19 | -------------------------------------------------------------------------------- /fr/specs.md: -------------------------------------------------------------------------------- 1 | # Les spécifications 2 | 3 | Voici un recueil des dernières versions officielles des différentes parties et 4 | composants de QUIC et de HTTP/3. 5 | 6 | ## Invariants 7 | 8 | [Version-Independent Properties of QUIC](https://tools.ietf.org/html/draft-ietf-quic-invariants-03) 9 | 10 | ## Transport 11 | 12 | [QUIC: A UDP-Based Multiplexed and Secure Transport](https://tools.ietf.org/html/draft-ietf-quic-transport-18) 13 | 14 | ## Récupération 15 | 16 | [QUIC Loss Detection and Congestion Control](https://tools.ietf.org/html/draft-ietf-quic-recovery-18) 17 | 18 | ## TLS 19 | 20 | [Using Transport Layer Security (TLS) to Secure QUIC](https://tools.ietf.org/html/draft-ietf-quic-tls-18) 21 | 22 | ## HTTP 23 | 24 | [Hypertext Transfer Protocol (HTTP) over QUIC](https://tools.ietf.org/html/draft-ietf-quic-http-18) 25 | 26 | ## QPACK 27 | 28 | [QPACK: Header Compression for HTTP over QUIC](https://tools.ietf.org/html/draft-ietf-quic-qpack-06) 29 | -------------------------------------------------------------------------------- /ja/h3-https.md: -------------------------------------------------------------------------------- 1 | # HTTPS:// URLs 2 | 3 | HTTP/3 は `HTTPS://` URL を利用して実行されます。 4 | 5 | 世界はすでにこれらの URL で満ち溢れていて、新しいプロトコルのために別の URL スキームを導入することは現実的ではなく、とても無理があると考えられています。 6 | 7 | HTTP/2 が新しいスキームを必要としなかったように HTTP/3 もまた同様です。 8 | 9 | HTTP/3 で状況がさらに複雑になったのは、HTTP/2 が完全に新しい方法で HTTP を転送するプロトコルであったものの、それがまだ TLS や TCP など HTTP/1 の仕様に基づいていたからです。 10 | 11 | HTTP/3 が QUIC 上で行われるということは、いくつかの重要な側面において物事を変えることになります。 12 | 13 | 従来の平文 `HTTP://` URL は現在のまま残りますが、私達が安全な転送へとさらに進んでいくにあたり、おそらく徐々に使われなくなっていくでしょう。こうした平文 URL へのリクエストは簡単には HTTP/3 へアップグレードされません。現実にはその他の理由により HTTP/2 にも稀にしかアップグレードされません。 14 | 15 | ## 最初のコネクション 16 | 17 | 以前に訪れたことがない新しい HTTPS:// URL のホストへの最初のコネクションは、おそらく TCP 経由で行われる必要があります (加えて QUIC 経由での接続を並行して試みることもあるでしょう) 。 18 | 19 | 接続先のホストは QUIC をサポートしないレガシーなサーバーかもしれませんし、その中間に QUIC コネクションの障壁となるミドルボックスが存在するかもしれません。 20 | 21 | モダンなクライアントやサーバーであれば、おそらく最初のハンドシェイクで HTTP/2 をネゴシエートします。 22 | 23 | コネクションが確立され、サーバーがクライアントの HTTP 要求に応答する時に、サーバーはクライアントに対して自身の HTTP/3 のサポートとその優先度を伝えることができます。 24 | -------------------------------------------------------------------------------- /ja/quic-connections.md: -------------------------------------------------------------------------------- 1 | # コネクション 2 | 3 | QUIC コネクションは2つの QUIC エンドポイント間における一対の対話です。QUIC のコネクションの確立は、レイテンシを低減するために、バージョンネゴシエーションと暗号化およびトランスポートハンドシェイクを組み合わせています。 4 | 5 | 実際にそのようなコネクションを介してデータ送信するには、1つまたはそれ以上のストリームを作成し、使用する必要があります。 6 | 7 | ## コネクション ID 8 | 9 | 各コネクションは一組のコネクション ID (コネクション識別子) を持ち、コネクションを識別するために、その ID を使用することができます。コネクション ID はエンドポイントにより独立して選ばれます。各エンドポイントは、ピアが使用するコネクション ID を選択します。 10 | 11 | これらのコネクション ID の主な機能は、下位のプロトコル層 (UDP、IP、 及びそれ以下) でのアドレッシングの変更が、QUIC コネクションのパケットを間違ったエンドポイントに配信しないようにすることです。 12 | 13 | コネクション ID を利用することにより、TCP が絶対にできない方法で、IP アドレスとネットワークインターフェースの間でコネクションをマイグレーションすることができます。 例えばダウンロードの進行中に、端末がモバイル回線から Wi-Fi に接続を切り替えたとき、セッションを維持しつつ、ダウンロードがより速い Wi-Fi に移行できます。その逆でも同様に、セッションを維持できます。 14 | 15 | ## ポート番号 16 | 17 | QUIC は UDP の最上層に組み込まれているので、16bit のポート番号フィールドは、着信相手を区別するために使用されています。 18 | 19 | ## バージョンネゴシエーション 20 | 21 | クライアントからの QUIC コネクションリクエストでは、どの QUIC プロトコルバージョンを使用するかサーバーに通知します。サーバーは、クライアントが次に進む際に選択できるように、自身のサポートしているバージョンのリストを返答します。 22 | -------------------------------------------------------------------------------- /ja/why-h2.md: -------------------------------------------------------------------------------- 1 | ## HTTP/2、覚えていますか？ 2 | 3 | HTTP/2 の仕様、[RFC 7540](https://httpwg.org/specs/rfc7540.html) は2015年の5月に公開され、インターネット及び Web に広く展開・実装されてきました。 4 | 5 | 2018年はじめには、世界トップ1000のウェブサイトのうちほぼ40 %が HTTP/2 で動作しており、Firefox が発行する get レスポンスのうちおよそ70 %の HTTPS リクエストを HTTP/2 が占め、すべての主要なブラウザやサーバー、プロキシが HTTP/2 をサポートしています。 6 | 7 | HTTP/2 は HTTP/1 におけるおびただしい数の欠点に対処しており、導入によって HTTP ユーザーが抱える多くの回避策を使わなくてすむようになります。 8 | 9 | HTTP/2 の主要な特徴の一つには、多重化があり、論理的な複数のストリームを物理的に単一な TCP 通信で転送することができます。 10 | 11 | 輻輳制御の動作が飛躍的に向上し、ユーザーが TCP をより効率的に使うことができるため、帯域幅を適切に使い切ることができ、 TCP コネクションをより長く持たせるようになります。 12 | 13 | 結果として、以前よりもより頻繁に最高速の通信に達することができます。 14 | 15 | ヘッダー圧縮により帯域幅をより小さくできます。 16 | 17 | HTTP/2 によって、ブラウザは、原則以前は6本だったのがホストごとに *単一の* TCP コネクションを使うようになります。 18 | 19 | 実際、HTTP/2 で使われているコネクションの統合と「デシャーディング」技術はそれよりもさらに接続数を減らすことがあります。 20 | 21 | HTTP/2 は HTTP における head-of-line ブロッキング問題 (クライアントは、次のリクエストを送信するために既存のリクエストのデータを取得し終わるまで待たなければならない問題) を解消しています。 22 | 23 | ![http2 man](../images/h2-man.jpg) 24 | -------------------------------------------------------------------------------- /zh/criticism.md: -------------------------------------------------------------------------------- 1 | # 常见批评 2 | 3 | ## UDP永远不会通 4 | 5 | 很多企业、运营商和组织对53端口（DNS）以外的UDP流量进行拦截或者限流，因为这些流量近来常被滥用于攻击。特别是一些现有的UDP协议和实现易受放大攻击（amplification attack）威胁，攻击者可以控制无辜的主机向受害者投放发送大量的流量。 6 | 7 | QUIC内置了对放大攻击的缓解处理。它要求初始数据包不小于1200字节，并且协议中限制，服务器在未收到客户端回复的情况下，不能发送超过请求大小三倍的响应内容。 8 | 9 | ## 内核处理UDP很慢 10 | 11 | 我们必须承认这在2018年的今天是一个事实。当然，UDP技术会发展，这些年开发者对UDP的重视程度也不够，这些东西都自不必说了。 12 | 13 | 对于大多数客户端来说，这个程度的“缓慢”从未被觉察到。 14 | 15 | ## QUIC太吃CPU 16 | 17 | 类似上文的“UDP很慢”，一部分原因是TCP和TLS长期以来的成熟发展、改进，以及得到硬件协助，造成UDP看上去比较慢。 18 | 19 | 我们有理由期望这会随着时间得到改善。问题在于，这额外的CPU占用会对部署者带来多大的影响。 20 | 21 | ## 只有Google在弄 22 | 23 | 并非如此。Google通过大规模的部署证明，通过UDP部署这种协议可以正常运行且表现良好，这为IETF带来了初始的规范。 24 | 25 | 在那之后，很多公司和组织的人员都在这个利益方中立的IETF组织下推进标准化。在这个阶段，虽然Google的雇员也有参与，但Mozilla、Fastly、Cloudflare、Akamai、微软、Facebook、苹果等等很多公司的员工也参与进来，共同推进互联网的传输层协议。 26 | 27 | ## 进步太小 28 | 29 | 这个是一个观点，而不是批评。也许进步是很小，这可能与相距HTTP/2的发布很近有着关系，时间太短了。 30 | 31 | HTTP/3在高丢包的网络中可能表现更好，它提供了更快的握手，所以能改善可感知和实际的延迟。这些进步足够推动人们在服务器和服务上部署HTTP/3的支持吗？时间以及未来的性能测试会给我们答案！ 32 | -------------------------------------------------------------------------------- /zh/quic-streams.md: -------------------------------------------------------------------------------- 1 | # 数据流 2 | 3 | 数据流（Streams）在QUIC中提供了一个轻量级、有序的字节流的抽象化。 4 | 5 | QUIC中有两种基本的数据流类型： 6 | 7 | - 从发起者到对等端（Peer）的单向数据流。 8 | 9 | - 双向均可发出数据的双向数据流。 10 | 11 | 连接端点的任意一方都可以建立这两种数据流，数据流之间可并行、交错地传输，并且可以被取消。 12 | 13 | 通过QUIC发送数据需要建立一个或多个数据流。 14 | 15 | ## 流量控制（Flow control） 16 | 17 | 每个数据流都有独立的流量控制，端点可以通过此实现内存控制和反压（back pressure）。数据流的创建本身也有流量控制，连接双方可以声明最多愿意创建几个流ID。 18 | 19 | ## 流标识符 20 | 21 | 数据流通过一个无符号的62比特整数标识，也称流ID。流ID的最低2位比特用于识别流的类型（单向或双向）和流的发起者。 22 | 23 | 流ID的最低1位比特（0x1）用于识别流的发起者。客户端发起双数（最低位置0）流，服务器发起单数（最低位置1）流。 24 | 25 | 第2个比特（0x2）识别单/双向流。单向流始终置1，双向流则置0。 26 | 27 | ## 流并发 28 | 29 | QUIC允许任意数量的并发流。端点通过闲置最大流ID来控制并发活动的传入流数量。 30 | 31 | 每个端点指定自己的最大流ID数，并只对对等端端点有效。 32 | 33 | ## 收发数据 34 | 35 | 端点使用流来收发数据，这是流的最终用途。QUIC数据流是有序的字节流抽象。但是，不同流之间是无序的。 36 | 37 | ## 流优先度 38 | 39 | 如果正确设置了各流的优先度，流复用机制可以显著提升应用的效率。使用其他多路复用协议（如HTTP/2）的经验表明，有效的优先度划分策略对效率具有显著的正面影响。 40 | 41 | QUIC本身没有提供交换优先度信息的报文。接收优先度信息依赖于使用QUIC的应用层。应用层可以定义所有复合其语义的优先度方案。 42 | 43 | 基于QUIC使用HTTP/3时，优先度信息在HTTP层完成。 44 | -------------------------------------------------------------------------------- /ja/proc-ietf.md: -------------------------------------------------------------------------------- 1 | ## IETF 2 | 3 | IETF によってプロトコルの標準化が始まり、QUIC ワーキンググループが発足した当初から、QUIC を HTTP "だけ" ではなく他のプロトコルにも適用し、標準化することにしていました。Google-QUIC は HTTP だけを対象にしていましたが、実際は HTTP/2 のフレーム構文を利用し、HTTP/2 でも効果的に動作していました。 4 | 5 | また、IETF-QUIC では Google が "カスタム" した手法ではなく、TLS 1.3 に基づいた暗号化とセキュリティを取り入れることにしました。 6 | 7 | HTTP 以外のプロトコルにも適用したいという要求を満たすため、IETF QUIC プロトコルのアーキテクチャは2つの異なるレイヤーに分割されました。"transport QUIC" レイヤーと "HTTP over QUIC" レイヤーです (後者は "hq" と呼ばれることがあります)。 8 | 9 | このレイヤー分割は、一見無害のようにも見えますが、IETF-QUIC と Google-QUIC で大きな差分を生み出しました。 10 | 11 | ワーキンググループは QUIC の最初のバージョンを予定通りに提供するために、HTTP に範囲を絞り、HTTP で無いものは後に回すことにしました。 12 | 13 | 私達がこの本を書き始めた2018年3月には QUIC バージョン1の仕様の最終版は2018年11月にリリースされることになっていましたが、現在は延期されて2019年7月となっています。 14 | 15 | IETF-QUIC の作業が進むに連れ Google チームは IETF 版から詳細を取り込み、IETF 版が目指している QUICバージョンにプロトコルを近づけています。Google は Google 版の QUIC を 彼らのブラウザやサービスで引き続き運用しています。 16 | 17 | [開発中の新しい実装のほとんど](https://github.com/quicwg/base-drafts/wiki/Implementations) は IETF バージョンにフォーカスすると決めており、Google バージョンとの互換性はありません。 18 | -------------------------------------------------------------------------------- /ja/h3-altsvc.md: -------------------------------------------------------------------------------- 1 | # Alt-svc 2 | 3 | Alternate service (Alt-svc:) ヘッダとそれに対応する `ALT-SVC` HTTP/2 フレームは、QUIC や HTTP/3 用に設計されたわけではありません。 4 | 5 | これらはサーバーがクライアントに対して*「ちなみに私は同じサービスをこのホスト、プロトコル、ポートでも実行していますよ」*と伝えるための、既に設計・作成されているメカニズムの一部です。 6 | 7 | 詳細は [RFC 7838](https://tools.ietf.org/html/rfc7838) を参照してください。 8 | 9 | このような Alt-svc 応答を受け取ったクライアントは、クライアントが代替プロトコルをサポートしておりかつそれを希望する場合に、指定されたプロトコルで当該ホストへバックグラウンドで並行接続をし、その接続が成功した場合には最初のコネクションの代わりにそのプロトコルへと切り替えを行います。 10 | 11 | 最初のコネクションが HTTP/2、または HTTP/1 を使用している場合、サーバーはクライアントに対してHTTP/3 で再接続可能であると伝えることができます。それは同じホストに対してかもしれませんし、そのオリジンを提供することが可能な別のホストかもしれません。 12 | 13 | こうした Alt-svc 応答で与えられる情報には、ある特定の期間だけクライアントが提案された代替プロトコルを使用して後続のコネクションおよび要求を代替ホストに直接指示できるよう、有効期限が設けられます。 14 | 15 | ## Example 16 | 17 | HTTP サーバーはレスポンスヘッダに `Alt-Svc:` を含みます: 18 | 19 | Alt-Svc: h3=":50781" 20 | 21 | これは HTTP/3 がこのレスポンスを得るために使われた同じホスト名の UDP ポート 50781 番で利用可能であることを示します。 22 | 23 | クライアントはその宛先ホストに対して QUIC コネクションの確立を試みることが可能で、成功した場合は最初の HTTP バージョンではなく、確立されたその代替接続でオリジンと通信を続けることができます。 24 | -------------------------------------------------------------------------------- /zh/README.md: -------------------------------------------------------------------------------- 1 | # HTTP/3详解 2 | 3 | 本书的编撰自2018年3月开始，计划是提供HTTP/3以及其底层协议QUIC的文档，介绍它们的目的、原理、协议细节以及实现等。 4 | 5 | 本书完全免费，并且是一个协作项目，欢迎所有愿意帮忙的人前来协助！ 6 | 7 | ## 先导知识 8 | 9 | 本书假定读者对TCP/IP网络、HTTP以及Web技术有着基本的理解。关于HTTP/2的更多知识和细节，我们推荐首先阅读[HTTP/2详解](https://daniel.haxx.se/http2/)。 10 | 11 | ## 作者 12 | 13 | 本书作者为[Daniel Stenberg](https://daniel.haxx.se/)，他是世界上最流行的HTTP客户端软件[curl](https://curl.haxx.se/)的创造者与牵头开发者。Daniel在HTTP与互联网协议中已有20余年的开发经验，他也是[HTTP/2详解](https://daniel.haxx.se/http2/)的作者。 14 | 15 | 译者：[Yi Bai](https://github.com/yi-bai) 16 | 17 | ## 主页 18 | 19 | 本书的主页位于[daniel.haxx.se/http3-explained](https://daniel.haxx.se/http3-explained)。 20 | 21 | ## 帮助我们 22 | 23 | 如果您发现了本书中的任何纰漏、遗漏、错误或公然的谎言，欢迎您将受影响章节的修正版本传给我们，我们将酌情修改。我们将为提供帮助的每个人给予适当的表彰。我们希望随着时间推移，这份文档越来越好。 24 | 25 | 提交[问题](https://github.com/bagder/http3-explained/issues)或者[拉取请求](https://github.com/bagder/http3-explained/pulls)到本书的Github页面是最好的反馈方式。 26 | 27 | ## 许可协议 28 | 29 | 本文档及其所有内容遵循[知识共享 署名 4.0 许可协议](https://creativecommons.org/licenses/by/4.0/)授权。 30 | -------------------------------------------------------------------------------- /zh/why-tcpudp.md: -------------------------------------------------------------------------------- 1 | ## 用TCP还是UDP 2 | 3 | 如果我们无法解决TCP内的队头阻塞问题，那么按道理，我们应该在网络栈中发明一个UDP和TCP之外的新型传输层协议。或者我们应该用IETF在[RFC 4 | 4960](https://tools.ietf.org/html/rfc4960)中标准化的[SCTP](https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol)传输层协议，它也有多个我们所需的特征。 5 | 6 | 但在近些年来，因为在互联网上部署遭遇很大的困难，创造新型传输层协议的努力基本上都失败了。用户与服务器之间要经过许多防火墙、NAT（地址转换）、路由器和其他中间设备（middle-box），这些设备有很多只认TCP和UDP。如果使用另一种传输层协议，那么就会有N%的连接无法建立，这些中间设备会认为除TCP和UDP协议以外的协议都是不安全或者有问题的。如此高的的失败率一般被认为不值得再做出努力。 7 | 8 | 另外，网络栈中的传输层协议改动一般意味着操作系统内核也要做出修改。更新和部署新款操作系统内核的过程十分缓慢，需要付出很大的努力。由IETF标准化的许多TCP新特性都因缺乏广泛支持而没有得到广泛的部署或使用。 9 | 10 | ## 为什么不基于UDP使用SCTP 11 | 12 | SCTP是一个支持数据流的可靠的传输层协议，而且在WebRTC上已有基于UDP的对它的实现。 13 | 14 | 这看上去很好，但与QUIC相比还不够好，它： 15 | 16 | - 没有解决数据流的队头阻塞问题 17 | - 连接建立时需要决定数据流的数量 18 | - 没有稳固的TLS/安全性支持 19 | - 建立连接时候需要4次握手，而QUIC一次都不用（0-RTT） 20 | - QUIC是类TCP的字节流，而SCTP是信息流（message-based） 21 | - QUIC连接支持IP地址迁移，SCTP不行 22 | 23 | 若要了解更多SCTP与QUIC的差异，请参阅[A Comparison between SCTP and QUIC](https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00) 24 | -------------------------------------------------------------------------------- /ja/quic-v2.md: -------------------------------------------------------------------------------- 1 | # QUIC v2 2 | 3 | コアの QUIC プロトコルに重点を置き、予定通りリリースできるようにするため、もともとコアプロトコルの一部として計画されていたいくつかの機能の実装が延期されました。延期された機能は QUIC バージョン2もしくはそれ以降のバージョンで実装される予定です。 4 | 5 | しかし、この文書の著者はかなり不完全な水晶玉を持っているため、バージョン2ではどのような機能が実装されるのか正確に予測できません。 6 | 7 | ただし、v1 から明示的に削除された機能や事柄については「今後実装する」とも言えます。それらはバージョン2にて再び実装される可能性があります。 8 | 9 | ## 前方誤り訂正 10 | 11 | 前方誤り訂正 (FEC) は、送信機が冗長データを送信し受信機がエラーを含まないデータのみを認識する、データ送信においてエラーを制御する方法です。 12 | 13 | Google はオリジナルの QUIC の動作でこれを実験しましたが、その後実験はうまくいかなかったため再度削除されました。この機能は QUIC v2 の議論の対象となりますが、おそらく誰かが多くのペナルティなしで有用な追加になることを証明する必要があります。 14 | 15 | ## マルチパス 16 | 17 | マルチパスとは、トランスポート自体が複数のネットワーク経路を使用してリソースの使用率を最大化することで、冗長性を高めることを意味します。 18 | 19 | 世界中の SCTP 支持者達は、SCTP はマルチパスを備えていると主張していますが、現代の TCP もマルチパスを備えています。 20 | 21 | ## 信頼できないデータ 22 | 23 | 「信頼できない」ストリームをオプションとして提供することが検討されているため、UDP スタイルのアプリケーションを QUIC へ置き換えることができます。 24 | 25 | ## HTTP 以外の対応 26 | 27 | DNS over QUIC は、QUIC v1 と HTTP/3 がリリースされる際に注目されるかもしれない非 HTTP プロトコルの1つでした。 28 | 29 | しかし、新しいトランスポートが世界中にもたらされれば、他にもこのようなトランスポートが登場するかもしれません。 30 | -------------------------------------------------------------------------------- /fr/feature-streams.md: -------------------------------------------------------------------------------- 1 | ## ‎Plusieurs flux au sein de connexions 2 | 3 | Semblable à SCTP, SSH et HTTP/2, QUIC propose des flux logiques séparés au sein des 4 | connexions physiques. Un certain nombre de flux parallèles pouvant transférer des 5 | données simultanément sur une seule connexion sans affecter les autres flux. 6 | 7 | Une connexion est une configuration négociée entre deux points de terminaison, 8 | similaire au fonctionnement d'une connexion TCP. Une connexion QUIC est établie sur 9 | port UDP et une adresse IP, mais une fois établie, la connexion est associée à son 10 | "ID de connexion". 11 | 12 | Sur une connexion établie, chaque côté peut créer des flux et envoyer des données à 13 | l'autre terminaison. Les flux sont livrés dans l'ordre et ils sont fiables, mais 14 | différents flux peuvent être livrés dans le désordre. 15 | 16 | QUIC offre un contrôle de flux sur la connexion et les flux. 17 | 18 | Voir plus de détails dans les sections [connexion](quic-connections.md) et 19 | [flux](quic-streams.md) 20 | -------------------------------------------------------------------------------- /en/feature-inorder.md: -------------------------------------------------------------------------------- 1 | ## ‎In order delivery 2 | 3 | QUIC guarantees in-order delivery of streams, but not between streams. This 4 | means that each stream will send data and maintain data order, but each stream 5 | may reach the destination in a different order than the application sent it! 6 | 7 | For example: stream A and B are transferred from a server to a client. Stream 8 | A is started first and then stream B. In QUIC, a lost packet only affects 9 | the stream to which the lost packet belongs. If stream A loses a packet but 10 | stream B does not, stream B may continue its transfers and complete 11 | while stream A's lost packet is re-transmitted. This was not possible 12 | with HTTP/2. 13 | 14 | Illustrated here with one yellow and one blue stream sent between two QUIC 15 | end-points over a single connection. They are independent and may arrive in a 16 | different order, but each stream is reliably delivered to the application in order. 17 | 18 | ![two QUIC streams between two computers](../images/quic-chain-streams.png) 19 | -------------------------------------------------------------------------------- /fr/quic-api.md: -------------------------------------------------------------------------------- 1 | # API 2 | 3 | L’un des facteurs de succès du TCP classique et des programmes qui l’utilisent est 4 | l’API de socket standardisé. Il a des fonctionnalités bien définies et à l'aide de 5 | cette API, vous pouvez déplacer des programmes entre de nombreux systèmes 6 | d'exploitation différents, car TCP fonctionne de la même manière. 7 | 8 | QUIC n'est pas là. Il n'y a pas d'API standard pour QUIC. 9 | 10 | Avec QUIC, vous devez choisir l’une des implémentations de bibliothèque existantes 11 | et s'en tenir à son API. Cela rend les applications "verrouillées" à une 12 | seule bibliothèque dans une certaine mesure. Le passage à une autre bibliothèque 13 | signifie une autre API, ce qui peut nécessiter beaucoup de travail. 14 | 15 | De plus, étant donné que QUIC est généralement implémenté dans l'espace utilisateur, 16 | il ne peut pas simplement enrichir l'API de socket ou sembler similaire à la 17 | fonctionnalité existante des protocoles TCP et UDP. L'utilisation de QUIC signifie 18 | l'utilisation d'une autre API que l'API socket. 19 | -------------------------------------------------------------------------------- /zh/why-tcphol.md: -------------------------------------------------------------------------------- 1 | ## TCP队头阻塞（head of line blocking） 2 | 3 | HTTP/2是基于TCP实现的。相比之前的版本，HTTP/2使用的TCP连接数少了很多。TCP是一个可靠的传输协议，基本上，你可以将它视为在两台计算机间建立的一个虚拟链路，由一端放到网络上的内容，最终总会以相同的顺序出现在另一端。（或者遭遇连接中断） 4 | 5 | ![两台计算机间的TCP链路](../images/tcp-chain.png) 6 | 7 | 采用HTTP/2时，浏览器一般会在单个TCP连接中创建并行的几十个乃至上百个传输。 8 | 9 | 如果HTTP/2连接双方的网络中有一个数据包丢失，或者任何一方的网络出现中断，整个TCP连接就会暂停，丢失的数据包需要被重新传输。因为TCP是一个按序传输的链条，因此如果其中一个点丢失了，链路上之后的内容就都需要等待。 10 | 11 | 如下图所示，我们一个用链条来表现一个连接上发送的两个流（传输），红色的与绿色的数据流： 12 | 13 | ![不同颜色的链条代表着不同的链路](../images/tcp-chain-streams.png) 14 | 15 | 这种单个数据包造成的阻塞，就是TCP上的队头阻塞（head of line blocking）。 16 | 17 | 随着丢包率的增加，HTTP/2的表现越来越差。在2%的丢包率（一个很差的网络质量）中，测试结果表明HTTP/1用户的性能更好，因为HTTP/1一般有六个TCP连接，哪怕其中一个连接阻塞了，其他没有丢包的连接仍然可以继续传输。 18 | 19 | 在限定的条件下，在TCP下解决这个问题相当困难。 20 | 21 | ## 独立的数据流避免阻塞问题 22 | 23 | 使用QUIC时，两端间仍然建立一个连接，该连接也经过协商使得数据得到安全且可靠的传输。 24 | 25 | ![两台电脑间的一条QUIC链路](../images/tcp-chain.png) 26 | 27 | 但是，当我们在这个连接上建立两个不同的数据流时，它们互相独立。也就是说，如果一个数据流丢包了，只有那个数据流必须停下来，等待重传。 28 | 29 | 下面是两个端点间的示意图，黄色与蓝色是两个独立的数据流。 30 | 31 | ![两台电脑间的两个QUIC数据流](../images/quic-chain-streams.png) 32 | -------------------------------------------------------------------------------- /ja/specs.md: -------------------------------------------------------------------------------- 1 | # The specifications (仕様) 2 | ここでは QUIC や HTTP/3 の構成に関する最新のドラフトをまとめています。 3 | 4 | ## Invariants (不変事項) 5 | 6 | [Version-Independent Properties of QUIC (バージョンに依存しない QUIC の要素)](https://tools.ietf.org/html/draft-ietf-quic-invariants-03) 7 | 8 | ## Transport (トランスポート プロトコル) 9 | 10 | [QUIC: A UDP-Based Multiplexed and Secure Transport (QUIC: UDP をベースにした多重でセキュアなトランスポートプロトコル)](https://tools.ietf.org/html/draft-ietf-quic-transport-18) 11 | 12 | ## Recovery (パケットの修復) 13 | 14 | [QUIC Loss Detection and Congestion Control (QUIC のパケットロスの検知機能と輻輳制御)](https://tools.ietf.org/html/draft-ietf-quic-recovery-18) 15 | 16 | ## TLS 17 | 18 | [Using Transport Layer Security (TLS) to Secure QUIC (TLS を用いたセキュアな QUIC)](https://tools.ietf.org/html/draft-ietf-quic-tls-18) 19 | 20 | ## HTTP 21 | 22 | [Hypertext Transfer Protocol (HTTP) over QUIC](https://tools.ietf.org/html/draft-ietf-quic-http-18) 23 | 24 | ## QPACK 25 | 26 | [QPACK: Header Compression for HTTP over QUIC (QPACK: HTTP over QUIC のためのヘッダー圧縮方法)](https://tools.ietf.org/html/draft-ietf-quic-qpack-06) 27 | -------------------------------------------------------------------------------- /fr/feature-inorder.md: -------------------------------------------------------------------------------- 1 | ## Livraison dans l'ordre 2 | 3 | QUIC garantit la livraison des flux dans l'ordre, mais pas entre les flux. Cela 4 | signifie que chaque flux enverra des données et maintiendra l’ordre des données, 5 | mais chaque flux pourra atteindre la destination dans un ordre différent de celui 6 | que l’application a envoyé! 7 | 8 | Par exemple: les flux A et B sont transférés d'un serveur à un client. Le flux A 9 | est démarré en premier, puis ensuite le flux B. Dans QUIC, un paquet perdu affecte 10 | uniquement le flux auquel appartient le paquet perdu. Si le flux A perd un paquet 11 | mais pas le flux B, le flux B peut poursuivre ses transferts et se terminer pendant 12 | que le paquet perdu du flux A est retransmis. Ce n'était pas possible avec HTTP/2. 13 | 14 | Illustré ici avec un flux jaune et un flux bleu envoyés entre deux points de 15 | terminaison QUIC sur une seule connexion. Ils sont indépendants et peuvent arriver 16 | dans un ordre différent, mais chaque flux est livré de manière fiable, dans l'ordre, 17 | à l'application. 18 | 19 | ![deux flux QUIC entre deux ordinateurs](../images/quic-chain-streams.png) 20 | -------------------------------------------------------------------------------- /en/quic-spinbit.md: -------------------------------------------------------------------------------- 1 | # Spin Bit 2 | 3 | One of the perhaps longest design discussions within the QUIC working group 4 | that has been the subject of several hundred mails and hours of discussions 5 | concerns a single bit: the Spin Bit. 6 | 7 | The proponents of this bit insist that there is a need for operators and 8 | people on the path between two QUIC endpoints to be able to measure latency. 9 | 10 | The opponents to this feature do not like the potential information leak. 11 | 12 | ## Spinning a bit 13 | 14 | Both endpoints, the client and the server, maintain a spin value, 0 or 1, for 15 | each QUIC connection, and they set the spin bit on packets it sends for that 16 | connection to the appropriate value. 17 | 18 | Both sides then send out packets with that spin bit set to the same value 19 | for as long as one round trip lasts and then it toggles the value. The effect 20 | is then a pulse of ones and zeroes in that bitfield that observers can 21 | monitor. 22 | 23 | This measuring only works when the sender is neither application nor flow 24 | control limited and packet reordering over the network can also make the data 25 | noisy. 26 | -------------------------------------------------------------------------------- /ja/h3-streams.md: -------------------------------------------------------------------------------- 1 | # QUIC ストリームと HTTP/3 2 | 3 | HTTP/2 では完全なストリームと多重化のコンセプトを TCP 上で独自に設計する必要がありました。 4 | 5 | 一方 HTTP/3 は QUIC 用に作られたので、QUIC のストリームを最大限に活用することができます。 6 | 7 | HTTP/3 を介して行われる HTTP リクエストはストリームの特定のセットを利用します。 8 | 9 | ## HTTP/3 フレーム 10 | 11 | HTTP/3 はつまり QUIC ストリームを作成し、フレームのセットを通信先の相手へ送信することを意味します。 12 | 13 | HTTP/3 にはいくつかの (2018年12月18日の時点では9個！) フレームが存在します。中でも最も重要なものは次のとおりです: 14 | 15 | - HEADERS 圧縮された HTTP ヘッダを送信 16 | - DATA バイナリデータを送信 17 | - GOAWAY このコネクションをシャットダウンしてください 18 | 19 | ## HTTP リクエスト 20 | 21 | クライアントは、自身が開始した *双方向* QUIC ストリーム上で HTTP リクエストを送信します。 22 | 23 | 1つのリクエストは1つの HEADERS フレームで構成され、場合によっては他に1、2つのフレームが続きます: 一連の DATA フレーム、またはトレーラー用の 最後の HEADERSリクエストを送信した後、クライアントはストリームを閉じます。 24 | 25 | ## HTTP レスポンス 26 | 27 | サーバーは、HTTP レスポンスを双方向ストリーム上で返します。 28 | 29 | 一連の DATA フレーム、またはトレーラー HEADERS フレームからなる1つの HEADERS フレーム。 30 | 31 | ## QPACK ヘッダ 32 | 33 | HEADERS フレームには QPACK アルゴリズムにより圧縮された HTTP ヘッダが含まれています。 34 | 35 | QPACK は HTTP/2 で使われている HPACK 圧縮 ([RFC7541](https://httpwg.org/specs/rfc7541.html)) と似ていますが、送信されるストリームの順序に関わらず動作するように変更されています。 36 | 37 | QPACK は エンドポイント間で2つの単方向 QUIC ストリームを加えて利用します。 38 | 39 | これらのストリームは動的なテーブル情報をそれぞれ伝えるために使われます。 40 | -------------------------------------------------------------------------------- /en/proc.md: -------------------------------------------------------------------------------- 1 | # Process 2 | 3 | The initial QUIC protocol was designed by Jim Roskind at Google and was 4 | initially implemented in 2012, announced publicly to the world in 2013 when 5 | Google's experimentation broadened. 6 | 7 | Back then, QUIC was still claimed to be an acronym for "Quick UDP Internet 8 | Connections", but that has been dropped since then. 9 | 10 | Google implemented the protocol and subsequently deployed it both in their 11 | widely used browser (Chrome) and in their widely used server-side services 12 | (Google search, gmail, youtube and more). They iterated protocol versions 13 | fairly quickly and over time they proved the concept to work reliably for a 14 | vast portion of users. 15 | 16 | In June 2015, the first internet draft for QUIC was sent to the IETF for 17 | standardization, but it took until late 2016 for a QUIC working group to 18 | get approved and started. But then it took off immediately with a high degree 19 | of interest from many parties. 20 | 21 | In 2017, numbers quoted by QUIC engineers at Google mentioned that around 7% 22 | of *all* Internet traffic were already using this protocol. The Google version 23 | of the protocol. 24 | -------------------------------------------------------------------------------- /en/h3.md: -------------------------------------------------------------------------------- 1 | # HTTP/3 2 | 3 | As mentioned previously, the first and primary protocol to transport over QUIC 4 | is HTTP. 5 | 6 | Much like HTTP/2 was once introduced to transport HTTP over the wire in a 7 | completely new way, HTTP/3 is yet again introducing a new way to send HTTP over 8 | the network. 9 | 10 | HTTP still maintains the same paradigms and concepts like before. There are 11 | headers and a body, there is a request and a response. There are verbs, 12 | cookies and caching. What primarily changes with HTTP/3 is how the bits gets 13 | sent over to the other side of the communication. 14 | 15 | In order to do HTTP over QUIC, changes were required and the results of this 16 | is what we now call HTTP/3. These changes were required because of the 17 | different nature that QUIC provides as opposed to TCP. These changes include: 18 | 19 | - In QUIC the streams are provided by the transport itself, while in HTTP/2 20 | the streams were done within the HTTP layer. 21 | 22 | - Due to the streams being independent of each other, the header compression 23 | protocol used for HTTP/2 could not be used without it causing a head of block 24 | situation. 25 | 26 | - QUIC streams are slightly different than HTTP/2 streams. The HTTP/3 section 27 | will detail this somewhat. 28 | -------------------------------------------------------------------------------- /zh/proc-status.md: -------------------------------------------------------------------------------- 1 | # 标准化进展情况 2 | 3 | QUIC工作组自2016年底以来在积极标准化该协议，现计划于2019年7月之前完成。 4 | 5 | 到2018年11月为止，还没有过大型的HTTP/3互通性测试。目前来说，只有2个实现进行过测试，且这两个实现不基于浏览器和主流的开源服务器软件。 6 | 7 | QUIC工作组的wiki页面目前列出了大约15种QUIC实现（[QUIC实现列表](https://github.com/curl/curl/wiki/QUIC-implementation)），但距离它们都能与最新版的规范草案互操作仍有很长的路。 8 | 9 | 实现QUIC并不容易，且到目前为止，协议本身还在不断演变。 10 | 11 | ## 服务器 12 | 13 | Apache和Nginx还没有对QUIC支持的公开声明。 14 | 15 | ## 客户端 16 | 17 | 还没有任何主流浏览器的任何状态的任何版本支持IETF版本的QUIC或者HTTP/3协议。 18 | 19 | Google Chrome在数年前已经支持Google版的QUIC，但是该版本不能与官方的QUIC版本互操作，且它的HTTP实现与HTTP/3不同。 20 | 21 | ## 实现的障碍 22 | 23 | 为了避免重复发明轮子，以及依靠可信赖的现有协议，QUIC决定使用TLS 1.3作为它的加密和安全协议层。不过工作组决定大幅精简QUIC中TLS的使用，只使用“TLS信息”（TLS Messages）而不是协议中的“TLS记录”（TLS Records）。 24 | 25 | 这听上去可能人畜无害，但也事实上成为了很多QUIC堆栈实现者的重大障碍。现存的支持TLS 1.3的TLS库都没有提供此功能的API并允许QUIC访问它。有一些QUIC的实现由大型机构完成，这些机构可能有自己的TLS协议栈，但并不是所有实现都能如此。 26 | 27 | 例如，主流的重量级开源软件OpenSSL就没有这些API，且到目前（2018年11月）为止，没有表达过在任何时间点提供这些API的意愿。 28 | 29 | 这最终将成为QUIC协议栈部署的障碍。因为QUIC要么基于其他TLS库，要么使用补丁版OpenSSL或者等待OpenSSL版本更新。 30 | 31 | ## 操作系统内核、CPU负载 32 | 33 | 据Google和Facebook称，与基于TLS的HTTP/2相比，它们大规模部署的QUIC需要近2倍的CPU使用量。 34 | 35 | 对此的进一步解释包括： 36 | 37 | - Linux内核的UDP部分没有得到像TCP堆栈那样的优化，因为传统上没有使用UDP进行如此高速的信息传输。 38 | 39 | - TCP和TLS有硬件加速（负载卸载到硬件，offload），而这对于UDP很罕见，对于QUIC则基本不存在。 40 | 41 | 就上述理由，我们可以相信QUIC的CPU使用量能随着时间的推移得到改善。 42 | -------------------------------------------------------------------------------- /en/why-latency.md: -------------------------------------------------------------------------------- 1 | # Earlier data 2 | 3 | QUIC offers both 0-RTT and 1-RTT handshakes that reduce the time it takes to 4 | negotiate and setup a new connection. Compare with the 3-way handshake of TCP. 5 | 6 | In addition to that, QUIC offers "early data" support from the get go which is 7 | done to allow more data and it is used more easily than TCP Fast Open. 8 | 9 | With the stream concept, another logical connection to the same host can be 10 | done at once without having to wait for the existing one to end first. 11 | 12 | ## TCP Fast Open is problematic 13 | 14 | TCP Fast Open was published as [RFC 7413](https://tools.ietf.org/html/rfc7413) 15 | in December 2014 and that specification describes how applications can pass 16 | data to the server to be delivered already in the first TCP SYN packet. 17 | 18 | Actual support for this feature in the wild has taken time and is riddled with 19 | problems even today in 2018. The TCP stack implementors have had issues and so 20 | have applications trying to take advantage of this feature - both in knowing 21 | in which OS version to try to activate it but also in figuring out how to 22 | gracefully back down and deal when problems arise. Several networks have been 23 | identified to interfere with TFO traffic and they have thus actively ruined 24 | such TCP handshakes. 25 | -------------------------------------------------------------------------------- /fr/proc.md: -------------------------------------------------------------------------------- 1 | # La procédure 2 | 3 | Le protocole QUIC originel a été conçu par Jim Roskind chez Google et a été 4 | initialement mis en œuvre en 2012, puis annoncé publiquement au monde en 2013 5 | lorsque l'expérimentation de Google s'est élargie. 6 | 7 | À l'époque, il était toujours prétendu que QUIC était l'acronyme de "Quick UDP 8 | Internet Connections", mais il a été abandonné depuis. 9 | 10 | Google a mis en œuvre le protocole et l'a ensuite déployé à la fois dans son 11 | navigateur beaucoup utilisé (Chrome) et dans ses services côté serveur beaucoup 12 | utilisés (Google search, gmail, youtube, etc...). Ils ont répété les versions du 13 | protocole assez rapidement et, avec le temps, ils ont prouvé que le concept 14 | fonctionnait de manière fiable pour une grande partie des utilisateurs. 15 | 16 | En juin 2015, le premier brouillon Internet pour QUIC a été envoyé à l'IETF pour 17 | une standardisation, mais il a fallu attendre la fin de l'année 2016 pour qu'un 18 | groupe de travail QUIC soit approuvé et lancé. Mais ensuite, il a immédiatement 19 | décollé avec beaucoup d'intérêt de la part de nombreux partis. 20 | 21 | En 2017, des chiffres cités par les ingénieurs de QUIC chez Google ont indiqué 22 | qu'environ 7% de *tout* le trafic Internet utilisait déjà ce protocole. La version 23 | de Google du protocole. 24 | -------------------------------------------------------------------------------- /zh/SUMMARY.md: -------------------------------------------------------------------------------- 1 | * [导言](README.md) 2 | * [为什么需要QUIC](why-quic.md) 3 | * [回顾HTTP/2](why-h2.md) 4 | * [TCP队头阻塞](why-tcphol.md) 5 | * [用TCP还是UDP](why-tcpudp.md) 6 | * [协议僵化](why-ossification.md) 7 | * [安全性](why-secure.md) 8 | * [减少延迟](why-latency.md) 9 | * [协议进展](proc.md) 10 | * [IETF](proc-ietf.md) 11 | * [HTTP/2的经验](proc-h2.md) 12 | * [标准化进展情况](proc-status.md) 13 | * [协议特点](the-protocol.md) 14 | * [基于UDP](feature-udp.md) 15 | * [可靠性](feature-reliable.md) 16 | * [数据流](feature-streams.md) 17 | * [有序交付](feature-inorder.md) 18 | * [快速握手](feature-handshakes.md) 19 | * [TLS 1.3](feature-tls.md) 20 | * [传输层与应用层协议](feature-trans-app.md) 21 | * [QUIC之上的HTTP协议](feature-http.md) 22 | * [QUIC之上的非HTTP协议](feature-nonhttp.md) 23 | * [QUIC工作原理](quic.md) 24 | * [连接](quic-connections.md) 25 | * [使用TLS的连接](quic-tls.md) 26 | * [数据流](quic-streams.md) 27 | * [0-RTT](quic-0rtt.md) 28 | * [旋转比特位](quic-spinbit.md) 29 | * [用户空间实现](quic-userspace.md) 30 | * [API](quic-api.md) 31 | * [HTTP/3](h3.md) 32 | * [HTTPS:// URL](h3-https.md) 33 | * [使用Alt-svc自举](h3-altsvc.md) 34 | * [QUIC流与HTTP/3](h3-streams.md) 35 | * [优先度](h3-prio.md) 36 | * [服务器推送](h3-push.md) 37 | * [与HTTP/2的比较](h3-h2.md) 38 | * [常见批评](criticism.md) 39 | * [技术标准](specs.md) 40 | * [QUIC v2](quic-v2.md) 41 | -------------------------------------------------------------------------------- /fr/quic-spinbit.md: -------------------------------------------------------------------------------- 1 | # Spin Bit 2 | 3 | Peut-être l'une des discussions de conception les plus longues au sein du groupe de 4 | travail QUIC, qui a fait l'objet de plusieurs centaines de mails et d'heures de 5 | discussions, concerne un seul bit: le Spin Bit. 6 | 7 | Les partisans de ce bit insistent sur le fait qu'il est nécessaire que les 8 | opérateurs et les personnes se trouvant entre deux terminaisons QUIC puissent 9 | mesurer le temps de latence. 10 | 11 | Les opposants à cette fonctionnalité n'aiment pas la potentielle fuite 12 | d'informations. 13 | 14 | ## Faire tourner un bit 15 | 16 | Les deux points de terminaison, le client et le serveur, conservent une valeur de 17 | rotation, 0 ou 1, pour chaque connexion QUIC, et définissent le bit de rotation sur 18 | les paquets qu'il envoie pour cette connexion sur la valeur appropriée. 19 | 20 | Les deux côtés envoient ensuite des paquets avec ce bit de rotation défini sur la 21 | même valeur pendant toute la durée d'un aller-retour, puis la valeur est modifiée. 22 | L'effet est alors une impulsion de uns et de zéros dans ce champ binaire que les 23 | observateurs peuvent surveiller. 24 | 25 | Cette mesure ne fonctionne que lorsque l'expéditeur n'est ni limité par 26 | l'application ni par le contrôle de flux, la réorganisation des paquets sur le 27 | réseau peut également rendre les données tumultueuses. 28 | -------------------------------------------------------------------------------- /ja/why-ossification.md: -------------------------------------------------------------------------------- 1 | # 硬直化 2 | 3 | インターネットは「ネットワーク同士のネットワーク」です。 4 | 5 | このネットワーク同士のネットワークを想定通り確実に動作させるため、インターネット上の実に様々な場所に機器が設置されています。 6 | 7 | ネットワーク上に散りばめられたこれら機器のことを「ミドルボックス」と呼びます。 8 | 9 | 2つのエンドポイント間のあちこちに存在しているこれらミドルボックスが、旧来からのネットワークデータ転送に関わっています。 10 | 11 | ミドルボックスは様々な目的で様々な動作をしていますが、それらはインターネットを正しく動作させるために必要だと誰かが考えた結果設置されたものだ、と広い意味で捉えることができると思います。 12 | 13 | ミドルボックスはネットワーク間で IP パケットのルーティングを行います。 14 | 15 | また、悪意のあるトラフィックをブロックします。 16 | 17 | NAT (Network Address Translation) を行ったり、パフォーマンスを向上させたり、通過するトラフィックを監視したり、それ以外にも様々なことを行います。 18 | 19 | これらの役割を担うため、ミドルボックスは「ネットワーク間がどうつながっているのか」や、監視・管理の対象である、プロトコルの詳細について知らなければなりません。 20 | 21 | こういった目的で、ミドルボックスはソフトウェアを動かします。 22 | 23 | これらのソフトウェアは必ずしも頻繁にアップデートされるとは限りません。 24 | 25 | ミドルボックスはインターネットを維持するための接着剤の役割を果たしていますが、最新技術に追従できていないこともよくあります。 26 | 27 | 世界中のクライアントとサーバーの間にあるミドルボックスは、一般的には末端の機器ほどすぐに変化しません。 28 | 29 | ネットワークプロトコルのうち、ミドルボックスにプロトコルを分析させ、通信を許可・ブロックさせたいものはすべて、以下の問題を抱えます。 30 | 31 | ミドルボックスは設置した当時の仕様で動作するという問題です。 32 | 33 | 当時知られていなかった、新しい仕様の追加や振る舞いの変化があると、その機器にとっては不具合や不正といったリスクと見なされます。 34 | 35 | このようなトラフィックは、単に捨てられたり、あるいはその機能を使用したくないと思うほど遅延させられたりします。 36 | 37 | このような状況は「プロトコルの硬直化」と呼ばれます。 38 | 39 | TCP も硬直化によって変化が難しい状況にあります。 40 | 41 | クライアントとサーバーの間にある機器が、新しい TCP オプションを不明なものとしてブロックするかもしれません。 42 | 43 | プロトコルの詳細が分析できると、それを取り巻くシステムはプロトコルの一般的な振る舞いを学習していき、やがてプロトコルの変更を不可能にしてしまいます。 44 | 45 | この硬直化と「戦う」ための真に効果的な唯一の方法は、可能な限り通信を暗号化し、ミドルボックスにそこを通過するプロトコルの詳細を観察させないようにすることです。 46 | -------------------------------------------------------------------------------- /fr/h3.md: -------------------------------------------------------------------------------- 1 | # HTTP/3 2 | 3 | Comme mentionné précédemment, le premier et principal protocole pour transporter 4 | sur QUIC est HTTP. 5 | 6 | Tout comme HTTP/2 a été introduit pour transporter HTTP sur le réseau d’une manière 7 | totalement nouvelle, HTTP/3 introduit encore une fois une nouvelle façon d’envoyer 8 | HTTP sur le réseau. 9 | 10 | HTTP maintient toujours les mêmes paradigmes et concepts qu'avant. Il y a des 11 | en-têtes et un corps, il y a une demande et une réponse. Il y a les méthodes, les 12 | cookies et la mise en cache. Ce qui change principalement avec HTTP/3, c'est la 13 | manière dont les bits sont envoyés de l'autre côté de la communication. 14 | 15 | Pour pouvoir utiliser HTTP sur QUIC, des modifications étaient nécessaires et le 16 | résultat de ceci est ce que nou sappelons maintenant HTTP/3. Ces modifications 17 | étaient nécessaires en raison de la nature différente fournie par QUIC par 18 | opposition à TCP. Ces changements incluent: 19 | 20 | - Dans QUIC, les flux sont fournis par le transport lui-même, tandis que dans 21 | HTTP/2, les flux étaient créés dans la couche HTTP. 22 | 23 | - Les flux étant indépendants les uns des autres, le protocole de compression 24 | d'en-tête utilisé pour HTTP/2 ne pourrait pas être utilisé sans provoquer une 25 | situation de tête de bloc. 26 | 27 | - Les flux QUIC sont légèrement différents des flux HTTP/2. La section HTTP/3 28 | le détaillera un peu. 29 | -------------------------------------------------------------------------------- /en/h3-h2.md: -------------------------------------------------------------------------------- 1 | # HTTP/3 compared to HTTP/2 2 | 3 | HTTP/3 is designed for QUIC, which is a transport protocol that handles 4 | streams by itself. 5 | 6 | HTTP/2 is designed for TCP, and therefore handles streams in the HTTP layer. 7 | 8 | ## Similarities 9 | 10 | The two protocols offer clients virtually identical feature sets. 11 | 12 | - Both protocols offer streams 13 | 14 | - Both protocols offer server push support 15 | 16 | - Both protocols have header compression, and QPACK and HPACK are similar in 17 | design. 18 | 19 | - Both protocols offer multiplexing over a single connection using streams 20 | 21 | - Both protocols do prioritization on streams 22 | 23 | ## Differences 24 | 25 | The differences are in the details and primarily there thanks to HTTP/3's use 26 | of QUIC: 27 | 28 | - HTTP/3 has better and more likely to work early data support thanks to 29 | QUIC's 0-RTT handshakes, while TCP Fast Open and TLS usually sends less data 30 | and often faces problems. 31 | 32 | - HTTP/3 has much faster handshakes thanks to QUIC vs TCP + TLS. 33 | 34 | - HTTP/3 does not exist in an insecure or unencrypted version. HTTP/2 can be 35 | implemented and used without HTTPS - even if this is rare on the Internet. 36 | 37 | - HTTP/2 can be negotiated directly in a TLS handshake with the ALPN 38 | extension, while HTTP/3 is over QUIC so it needs an `Alt-Svc:` header 39 | response first to inform the client about this fact. 40 | 41 | -------------------------------------------------------------------------------- /en/feature-udp.md: -------------------------------------------------------------------------------- 1 | ## Transfer protocol over UDP 2 | 3 | QUIC is a transfer protocol implemented on top of UDP. If you watch your network 4 | traffic casually, you will see QUIC appear as UDP packets. 5 | 6 | Based on UDP it also then uses UDP port numbers to identify specific network 7 | services on a given IP address. 8 | 9 | All known QUIC implementations are currently in user-space, which allows for 10 | more rapid evolution than kernel-space implementations typically allow. 11 | 12 | ## Will it work? 13 | 14 | There are enterprises and other network setups that block UDP traffic on other 15 | ports than 53 (used for DNS). Others throttle such data in ways that makes 16 | QUIC perform worse than TCP based protocols. There is no end to what some 17 | operators may do. 18 | 19 | For the foreseeable future, all use of QUIC-based transports will probably 20 | have to be able to gracefully fall-back to another (TCP-based) alternative. 21 | Google engineers have previously mentioned measured failure rates in the low 22 | single-digit percentages. 23 | 24 | ## Will it improve? 25 | 26 | Chances are that if QUIC proves to be a valuable addition to the Internet 27 | world, people will want to use it and they will want it to function in their 28 | networks and then companies may start to reconsider their obstacles. During 29 | the years the development of QUIC has progressed, the success rate for 30 | establishing and using QUIC connections across the Internet has increased. 31 | -------------------------------------------------------------------------------- /ja/SUMMARY.md: -------------------------------------------------------------------------------- 1 | * [なぜ QUIC なのか](why-quic.md) 2 | * [HTTP/2、覚えていますか？](why-h2.md) 3 | * [TCP head-of-line ブロッキング](why-tcphol.md) 4 | * [TCP か UDP か](why-tcpudp.md) 5 | * [硬直化](why-ossification.md) 6 | * [セキュア](why-secure.md) 7 | * [Reduced latency](why-latency.md) 8 | * [これまでの歩み](proc.md) 9 | * [IETF](proc-ietf.md) 10 | * [HTTP/2 からの経験](proc-h2.md) 11 | * [現在の状況](proc-status.md) 12 | * [プロトコルの機能](the-protocol.md) 13 | * [UDP 上の転送プロトコル](feature-udp.md) 14 | * [高信頼性のデータ転送](feature-reliable.md) 15 | * [コネクションは複数のストリームを扱う](feature-streams.md) 16 | * [到着順序の保証](feature-inorder.md) 17 | * [素早いハンドシェイク](feature-handshakes.md) 18 | * [TLS 1.3](feature-tls.md) 19 | * [トランスポートとアプリケーションレベル](feature-trans-app.md) 20 | * [HTTP over QUIC](feature-http.md) 21 | * [Non-HTTP over QUIC](feature-nonhttp.md) 22 | * [QUIC の仕組み](quic.md) 23 | * [コネクション](quic-connections.md) 24 | * [接続で TLS を使う](quic-tls.md) 25 | * [ストリーム](quic-streams.md) 26 | * [0-RTT](quic-0rtt.md) 27 | * [Spin Bit](quic-spinbit.md) 28 | * [ユーザー空間](quic-userspace.md) 29 | * [API](quic-api.md) 30 | * [HTTP/3](h3.md) 31 | * [HTTPS:// の URL](h3-https.md) 32 | * [Alt-svc を使ったブートストラップ](h3-altsvc.md) 33 | * [QUIC ストリームと HTTP/3](h3-streams.md) 34 | * [プライオリティ制御](h3-prio.md) 35 | * [Server push](h3-push.md) 36 | * [HTTP/2 と比較した HTTP/3](h3-h2.md) 37 | * [よくある疑問点](criticism.md) 38 | * [The specifications (仕様)](specs.md) 39 | * [QUIC v2](quic-v2.md) 40 | -------------------------------------------------------------------------------- /ja/why-tcpudp.md: -------------------------------------------------------------------------------- 1 | ## TCP か UDP か 2 | 3 | TCP の枠組みで head-of-line ブロッキングを直せないのであれば、理論的には、新しいトランスポートプロトコルをネットワークスタックの中、UDP と TCP に隣接して作れるようになるべきです。もしくは 最悪 [SCTP](https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol) を使うべきかもしれません。SCTP は [RFC 4960](https://tools.ietf.org/html/rfc4960) の中で IETF によって標準化されたトランスポートプロトコルの一つで、必要とされるいくつかの機能を持っています。 4 | 5 | しかし、近年新規のトランスポートプロトコルを作る取り組みは、ほとんどすべて休止しています。何故なら、インターネット上に実際に展開することに困難が伴っていたからです。新規プロトコルの展開は、到達すべきユーザーとサーバーの間に展開されている TCP もしくは UDP のみ許可する、多数のファイアーウォール、NAT、ルーターなど、その他のミドルボックスによって阻まれてきました。他のトランスポートプロトコルを導入することは、N %のコネクションを失敗させることになります。何故なら UDP もしくは TCP ではないということは、何らかの形で不正、もしくは間違っているとボックスにみなされ、ブロックされるからです。多くの場合、 N %の失敗率は努力に対して高すぎるとみなされます。 6 | 7 | 加えて、通常ネットワークスタックのトランスポートプロトコルレイヤーの中を変更することは、OS のカーネルによって実装されているプロトコルを変更することを意味しています。OS のカーネルを更新して展開することは、多大な努力を必要とする遅いプロセスです。IETF によって標準化された多くの TCP の改善は、広くサポートされていないため、広範囲に渡って展開されたり使用されたりしていません。 8 | 9 | ## なぜ SCTP-over-UDP ではないのか 10 | SCTP はストリームを用いた信頼性のあるプロトコルで、WebRTC には UDP を使用する実装さえ存在します。 11 | 12 | これは QUIC に取って代わるものとして十分ではありませんでした。以下を含む幾つかの理由に原因があります。 13 | 14 | - SCTP がストリームの head-of-line ブロッキング問題を解決しないこと 15 | - SCTP では、ストリームの数をコネクションのセットアップ時に決めなければならないこと 16 | - SCTP が確かな TLS/security レイヤーを持たないこと 17 | - SCTP は 4-way ハンドシェイクを使用し、QUIC は 0-RTT を提供すること 18 | - QUIC は TCP 同様バイトストリームで、SCTP はメッセージベースであること 19 | - QUIC コネクションは IP アドレス間を移動することができ、SCTP はできないこと 20 | 21 | 更なる詳細と違いについては、[A Comparison between SCTP and QUIC](https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00) インターネットドラフトが参考になります。 22 | -------------------------------------------------------------------------------- /ja/criticism.md: -------------------------------------------------------------------------------- 1 | # よくある疑問点 2 | 3 | ## UDP は多くの企業や組織で動くものではない 4 | 5 | 多くの企業、運用者、組織は、昨今においてほとんどが攻撃に悪用されるという理由のため、ポート53 (DNS に使われる) 以外の UDP トラフィックをブロックするか、あるいは利用制限をかけています。 6 | 7 | 特に、いくつかの既存 UDP プロトコルや UDP プロトコルを用いた一般的なサーバー上の実装はアンプ攻撃に対して脆弱であり続けていて、攻撃者は大量のトラフィックを無関係な第三者に送りつけることができます。 8 | 9 | QUIC ではアンプ攻撃を軽減する方法が備わっています。サーバーから受け取る最初のパケットは最低でも1,200バイトを要求するとともに、クライアントからのレスポンスのパケットを受け取っていない場合では、応答としてサーバーは3つ以上のパケットを送ってはならない (MUST NOT)、とプロトコル上で明記されています。 10 | 11 | ## UDP はカーネル内で遅い 12 | 13 | 少なくとも2018年においては、 UDP がカーネル内で遅い点は正しいように思われます。 14 | 15 | 純粋に長年の間 UDP 転送のパフォーマンスは開発者の関心を集めてこなかったため、果たしてどの程度遅いのか、今後どのように発展していくのかは分かりません。 16 | 17 | ほとんどのクライアントにとって、この「遅さ」が気になることはないはずです。 18 | 19 | ## QUIC は CPU 使用量が高すぎる 20 | 21 | 先述の「UDP は遅い」と同様ですが、これも TCP や TLS の世界的な普及がより成熟したり、ハードウェア支援ができるまでに必要な時間をかけているため、CPU 使用量が高すぎる点に関してもあまり当てはまりません。 22 | 23 | もちろん、時間を経るごとに、こういった改善が見込めます。問題は利用者がどれだけ余剰な CPU 使用の増加を気にしなければならないかです。 24 | 25 | ## これは Google の規格でしょ？ 26 | 27 | いいえ、違います。 Google はインターネット規模で UDP を用いた QUIC 同様の規格が正しく動き、良いパフォーマンスであることを証明し、最初の仕様を IETF へ提案しました。 28 | 29 | それ以来、多数の企業や組織から参加している個人が、ベンダーニュートラル な IETF でプロトコルの標準化に取り組んでいます。 30 | 31 | もちろん Google の従業員は参加していますが、他にも Mozilla、Fastly、Cloudflare、Akamai、Microsoft、Facebook、Appleなど、インターネット上のトランスポートプロトコルの発展に興味を持つ多くの企業の従業員が参加しています。 32 | 33 | ## 改善にしては小さすぎる 34 | 35 | それは批判ではなく、1つの意見です。おそらくその通りで、HTTP/2 が展開されてからの改善としては非常に小さいものかもしれません。 36 | 37 | HTTP/3 はパケットロスの多いネットワーク上でより優れた性能を発揮し、より高速なハンドシェイクによって数字上でも体感でもレイテンシの改善が見込まれます。 38 | 39 | しかしそれがサーバーやサービスへ HTTP/3 サポートを導入するほどのメリットであると言えるでしょうか？ 40 | 41 | 時が経てば、そして将来のパフォーマンス測定結果が間違いなくそれを教えてくれるでしょう！ 42 | -------------------------------------------------------------------------------- /en/SUMMARY.md: -------------------------------------------------------------------------------- 1 | * [Why QUIC](why-quic.md) 2 | * [Remember HTTP/2](why-h2.md) 3 | * [TCP head of line blocking](why-tcphol.md) 4 | * [TCP or UDP](why-tcpudp.md) 5 | * [Ossification](why-ossification.md) 6 | * [Secure](why-secure.md) 7 | * [Reduced latency](why-latency.md) 8 | * [Process](proc.md) 9 | * [IETF](proc-ietf.md) 10 | * [Experience from HTTP/2](proc-h2.md) 11 | * [Status](proc-status.md) 12 | * [Protocol features](the-protocol.md) 13 | * [UDP](feature-udp.md) 14 | * [Reliable](feature-reliable.md) 15 | * [Streams](feature-streams.md) 16 | * [In Order](feature-inorder.md) 17 | * [Fast handshakes](feature-handshakes.md) 18 | * [TLS 1.3](feature-tls.md) 19 | * [Transport and application](feature-trans-app.md) 20 | * [HTTP over QUIC](feature-http.md) 21 | * [Non-HTTP over QUIC](feature-nonhttp.md) 22 | * [How QUIC works](quic.md) 23 | * [Connections](quic-connections.md) 24 | * [Connections use TLS](quic-tls.md) 25 | * [Streams](quic-streams.md) 26 | * [0-RTT](quic-0rtt.md) 27 | * [Spin Bit](quic-spinbit.md) 28 | * [User space](quic-userspace.md) 29 | * [API](quic-api.md) 30 | * [HTTP/3](h3.md) 31 | * [HTTPS:// URLs](h3-https.md) 32 | * [Bootstrap with Alt-svc](h3-altsvc.md) 33 | * [QUIC streams and HTTP/3](h3-streams.md) 34 | * [Prioritization](h3-prio.md) 35 | * [Server push](h3-push.md) 36 | * [Comparison with HTTP/2](h3-h2.md) 37 | * [Common criticism](criticism.md) 38 | * [The specifications](specs.md) 39 | * [QUIC v2](quic-v2.md) 40 | -------------------------------------------------------------------------------- /fr/why-latency.md: -------------------------------------------------------------------------------- 1 | # Données antérieures 2 | 3 | QUIC offre à la fois des handshakes 0-RTT et 1-RTT qui réduisent le temps 4 | nécessaire pour négocier et établir une nouvelle connexion. Comparez avec le 5 | handshake à 3 voies du TCP. 6 | 7 | En plus de ça, QUIC offre une prise en charge des "données antérieures" dès le 8 | départ, ce qui est fait pour autoriser plus de données et est utilisé plus 9 | facilement que TCP Fast Open. 10 | 11 | Avec le concept de flux, vous pouvez établir une autre connexion logique avec le 12 | même hôte sans avoir à d'abord attendre la fin de la connexion existante. 13 | 14 | ## TCP Fast Open est problématique 15 | 16 | TCP Fast Open a été publié en décembre 2014 en tant que la [RFC 17 | 7413](https://tools.ietf.org/html/rfc7413) et cette spécification explique comment 18 | les applications peuvent transmettre des données au serveur afin qu'elles soient 19 | déjà livrées dans le premier paquet TCP SYN. 20 | 21 | La prise en charge effective de cette fonctionnalité a pris du temps et pose encore 22 | de nombreux problèmes, même aujourd'hui en 2018. Les responsables de la mise en 23 | œuvre de la stack TCP ont rencontré des problèmes, tout comme les applications qui 24 | ont essayé de tirer parti de cette fonctionnalité, en sachant dans quelle version 25 | d'OS essayer pour l'activer mais également pour savoir comment revenir en arrière 26 | avec élégance et régler les problèmes qui surviennent. Plusieurs réseaux ont été 27 | identifiés pour interférer avec le trafic TFO et ont donc activement ruiné de 28 | telles handshakes TCP. 29 | -------------------------------------------------------------------------------- /ja/why-tcphol.md: -------------------------------------------------------------------------------- 1 | ## TCP head-of-line ブロッキング 2 | 3 | HTTP/2 は TCP を使って動作し、従来のバージョンの HTTP を使用するよりも少ない TCP コネクション数になります。 4 | 5 | TCP は信頼性の高い転送のためのプロトコルで、基本的には2つのマシンの間につながった仮想的な鎖のように考えることができます。 6 | 7 | 一方の端からネットワーク上に出されたデータは、結果的に、もう一方の端に 全く同じ順番で到達します (または、通信が途切れます)。 8 | 9 | ![a TCP chain between two computers](../images/tcp-chain.png) 10 | 11 | HTTP/2 を使うことで、典型的なブラウザは数十または数百の並列データ転送を単一の TCP コネクション上で行います。 12 | 13 | HTTP/2 を話す2つのエンドポイント間にあるネットワーク上で一つのパケットがドロップされると、それはすなわち、その損失したパケットが再送され、宛先に届けられるまでの間、TCP コネクション全体が停止することを意味します。 14 | 15 | TCP がこの「鎖」であるため、一つのつなぎ目が突然欠落すると、その欠落したもの以降すべてのつながりが待つ必要があります。 16 | 17 | 2つの別々のストリームを単一コネクションで送信するときに鎖を使って図解したイラスト。 18 | 19 | 赤色のストリームと緑色のストリーム: 20 | 21 | ![the chain showing links in different colors](../images/tcp-chain-streams.png) 22 | 23 | 24 | これが、TCP ベースの head-of-line ブロックになります！ 25 | 26 | パケットロス率が上がることで、HTTP/2 のパフォーマンスはより悪くなります。 27 | 28 | 2 %のパケットロス (これはかなりひどいです、念のため。) があるネットワーク環境では、 29 | 30 | 大抵の場合において HTTP/1 のほうがパフォーマンスが良くなることをテストが証明しています。 31 | 32 | これは、HTTP/1 では合わせて6つの TCP コネクションを使ってパケットを送信するため、パケットが損失した箇所があっても他のコネクションが止まることはないからです。 33 | 34 | この問題を解消するのは簡単ではありません。TCP を使っている限り。 35 | 36 | ## ブロックを解消するための独立したストリーム 37 | 38 | QUIC では、2つのエンドポイントの間に、接続を安全にし、データ配信を信頼できるものにするコネクションのセットアップが依然として存在します。 39 | 40 | ![a QUIC chain between two computers](../images/tcp-chain.png) 41 | 42 | このコネクション上で2つの異なるストリームをセットアップする際、それらは独立したものとして扱われるため、一つのストリームのあるつなぎ目が損失した場合、そのストリームの、特定のチェインのみが、停止し再送制御を行います。 43 | 44 | 黄色のストリームと青色のストリームがそれぞれ2つのエンドポイント間で通信を行うイラストがこちらです。 45 | 46 | ![two QUIC streams between two computers](../images/quic-chain-streams.png) 47 | -------------------------------------------------------------------------------- /fr/h3-h2.md: -------------------------------------------------------------------------------- 1 | # HTTP/3 comparé à HTTP/2 2 | 3 | HTTP/3 est conçu pour QUIC, qui est un protocole de transport qui gère les flux par 4 | lui-même. 5 | 6 | HTTP/2 est conçu pour TCP et gère donc les flux dans la couche HTTP. 7 | 8 | ## Similitudes 9 | 10 | Les deux protocoles offrent aux clients des ensembles de fonctionnalités 11 | pratiquement identiques. 12 | 13 | - Les deux protocoles offrent des flux 14 | 15 | - Les deux protocoles offrent un support push serveur 16 | 17 | - Les deux protocoles ont une compression d'en-tête, et QPACK et HPACK ont une 18 | conception similaire. 19 | 20 | - Les deux protocoles offrent le multiplexage sur une seule connexion utilisant des 21 | flux 22 | 23 | - Les deux protocoles établissent des priorités sur les flux 24 | 25 | ## Differences 26 | 27 | Les différences sont dans les détails et principalement là grâce à l'utilisation de 28 | QUIC par HTTP/3: 29 | 30 | - HTTP/3 a plus de chances de fonctionner plus tôt grâce aux handshakes 0-RTT 31 | de QUIC, alors que TCP Fast Open et TLS envoient généralement moins de données et 32 | rencontrent fréquemment des problèmes. 33 | 34 | - HTTP/3 a des handshakes beaucoup plus rapides grâce à QUIC vs TCP + TLS. 35 | 36 | - HTTP/3 n'existe pas dans une version non sécurisée ou non chiffrée. HTTP/2 peut 37 | être implémenté et utilisé sans HTTPS - même si c'est rare sur Internet. 38 | 39 | - HTTP/2 peut être négocié directement dans un handshake TLS avec l'extension ALPN, 40 | alors que HTTP/3 est sur QUIC donc nécessite une réponse d'en-tête `Alt-Svc:` 41 | pour informer le client de ce fait. 42 | -------------------------------------------------------------------------------- /en/h3-https.md: -------------------------------------------------------------------------------- 1 | # HTTPS:// URLs 2 | 3 | HTTP/3 will be performed using `HTTPS://` URLs. The world is full of these 4 | URLs and it has been deemed impractical and downright unreasonable to 5 | introduce another URL scheme for the new protocol. Much like HTTP/2 did not 6 | need a new scheme, neither will HTTP/3. 7 | 8 | The added complexity in the HTTP/3 situation is however that where HTTP/2 was 9 | a completely new way of transporting HTTP over the wire, it was still based on 10 | TLS and TCP like HTTP/1 was. The fact that HTTP/3 is done over QUIC changes 11 | things in a few important aspects. 12 | 13 | Legacy, clear-text, `HTTP://` URLs will be left as-is and as we proceed 14 | further into a future with more secure transfers they will probably become 15 | less and less frequently used. Requests to such URLs will simply not be 16 | upgraded to use HTTP/3. In reality they rarely upgrade to HTTP/2 either, but 17 | for other reasons. 18 | 19 | ## Initial connection 20 | 21 | The first connection to a fresh, not previously visited host for a 22 | HTTPS:// URL probably has to be done over TCP (possibly in addition to a 23 | parallel attempt to connect via QUIC). The host might be a legacy server without 24 | QUIC support or there might be a middle box in between setting up obstacles 25 | preventing a QUIC connection from succeeding. 26 | 27 | A modern client and server would presumably negotiate HTTP/2 in the first 28 | handshake. When the connection has been setup and the server responds to a 29 | client HTTP request, the server can tell the client about its support of and 30 | preference for HTTP/3. 31 | -------------------------------------------------------------------------------- /fr/SUMMARY.md: -------------------------------------------------------------------------------- 1 | * [Pourquoi QUIC](why-quic.md) 2 | * [Rappelez-vous de HTTP/2](why-h2.md) 3 | * [Blocage de tête de ligne TCP](why-tcphol.md) 4 | * [TCP ou UDP](why-tcpudp.md) 5 | * [Ossification](why-ossification.md) 6 | * [Sécurisé](why-secure.md) 7 | * [Latence réduite](why-latency.md) 8 | * [La procédure](proc.md) 9 | * [IETF](proc-ietf.md) 10 | * [Expérience depuis HTTP/2](proc-h2.md) 11 | * [Statut](proc-status.md) 12 | * [Caractéristiques du protocole](the-protocol.md) 13 | * [UDP](feature-udp.md) 14 | * [Fiable](feature-reliable.md) 15 | * [Flux](feature-streams.md) 16 | * [Dans l'ordre](feature-inorder.md) 17 | * [Handshakes rapides](feature-handshakes.md) 18 | * [TLS 1.3](feature-tls.md) 19 | * [Transport et application](feature-trans-app.md) 20 | * [HTTP sur QUIC](feature-http.md) 21 | * [Non-HTTP sur QUIC](feature-nonhttp.md) 22 | * [Comment QUIC fonctionne](quic.md) 23 | * [Connexions](quic-connections.md) 24 | * [Les connexions utilisent TLS](quic-tls.md) 25 | * [Flux](quic-streams.md) 26 | * [0-RTT](quic-0rtt.md) 27 | * [Spin Bit](quic-spinbit.md) 28 | * [Espace utilisateur](quic-userspace.md) 29 | * [API](quic-api.md) 30 | * [HTTP/3](h3.md) 31 | * [URLs HTTPS://](h3-https.md) 32 | * [Amorçage avec Alt-svc](h3-altsvc.md) 33 | * [Flux QUIC et HTTP/3](h3-streams.md) 34 | * [Priorisation](h3-prio.md) 35 | * [Push serveur](h3-push.md) 36 | * [Comparaison avec HTTP/2](h3-h2.md) 37 | * [Critique générale](criticism.md) 38 | * [Les spécifications](specs.md) 39 | * [QUIC v2](quic-v2.md) 40 | -------------------------------------------------------------------------------- /en/h3-altsvc.md: -------------------------------------------------------------------------------- 1 | # Alt-svc 2 | 3 | The alternate service (Alt-svc:) header and its corresponding `ALT-SVC` HTTP/2 4 | frame are not specifically created for QUIC or HTTP/3. They are part of an 5 | already designed and created mechanism for a server to tell a client: *"look, 6 | I run the same service on THIS HOST using THIS PROTOCOL on THIS PORT"*. See 7 | details in [RFC 7838](https://tools.ietf.org/html/rfc7838). 8 | 9 | A client that receives such an Alt-svc response is then advised to, if it 10 | supports and wants to, connect to that given other host in parallel in the 11 | background - using the specified protocol - and if it is successful switch its 12 | operations over to that instead of the initial connection. 13 | 14 | If the initial connection uses HTTP/2 or even HTTP/1, the server can respond 15 | and tell the client that it can connect back and try HTTP/3. It could be to 16 | the same host or to another one that knows how to serve that origin. The 17 | information given in such an Alt-svc response has an expiry timer, making 18 | clients able to direct subsequent connections and requests directly to the 19 | alternative host using the suggested alternative protocol, for a certain 20 | period of time. 21 | 22 | ## Example 23 | 24 | An HTTP server includes an `Alt-Svc:` header in its response: 25 | 26 | Alt-Svc: h3=":50781" 27 | 28 | This indicates that HTTP/3 is available on UDP port 50781 at the same host name 29 | that was used to get this response. 30 | 31 | A client can then attempt to setup a QUIC connection to that destination and 32 | if successful, continue communicating with the origin like that instead of the 33 | initial HTTP version. 34 | -------------------------------------------------------------------------------- /en/h3-push.md: -------------------------------------------------------------------------------- 1 | # HTTP/3 Server push 2 | 3 | HTTP/3 server push is similar to what is described in HTTP/2 ([RFC 4 | 7540](https://httpwg.org/specs/rfc7540.html)), but uses different mechanisms. 5 | 6 | A server push is effectively the response to a request that the client never 7 | sent! 8 | 9 | Server pushes are only allowed to happen if the client side has agreed to 10 | them. In HTTP/3 the client even sets a limit for how many pushes it accepts 11 | by informing the server what the max push stream ID is. Going over that limit 12 | will cause a connection error. 13 | 14 | If the server deems it likely that the client wants an extra resource that it 15 | hasn't asked for but ought to have anyway, it can send a `PUSH_PROMISE` frame 16 | (over the request stream) showing what the request looks like that the push is 17 | a response to, and then send that actual response over a new stream. 18 | 19 | Even when pushes have been said to be acceptable by the client before-hand, 20 | each individual pushed stream can still be canceled at any time if the client 21 | deems that suitable. It then sends a `CANCEL_PUSH` frame to the server. 22 | 23 | ## Problematic 24 | 25 | Ever since this feature was first discussed in the HTTP/2 development and 26 | later after the protocol shipped and has been deployed over the Internet, this 27 | feature has been discussed, disliked and pounded up in countless different 28 | ways in order to get it to become useful. 29 | 30 | Pushing is never "free", since while it saves a half round-trip it still uses 31 | bandwidth. It is often hard or impossible for the server-side to actually know 32 | with a high level of certainty if a resource should be pushed or not. 33 | -------------------------------------------------------------------------------- /en/why-h2.md: -------------------------------------------------------------------------------- 1 | ## Remember HTTP/2? 2 | 3 | The HTTP/2 specification [RFC 7540](https://httpwg.org/specs/rfc7540.html) was 4 | published in May 2015 and the protocol has since then been implemented and 5 | deployed widely across the Internet and the World Wide Web. 6 | 7 | In early 2018, almost 40% of the top-1000 web sites run HTTP/2, around 70% of 8 | all HTTPS requests Firefox issues get HTTP/2 responses back and all major 9 | browsers, servers and proxies support it. 10 | 11 | HTTP/2 addresses a whole slew of shortcomings in HTTP/1 and with the 12 | introduction of the second version of HTTP users can stop using a bunch of 13 | work-arounds. Some of which are pretty burdensome on web developers. 14 | 15 | One of the primary features of HTTP/2 is that it makes use of multiplexing, so 16 | that many logical streams are sent over the same physical TCP connection. This 17 | makes a lot of things better and faster. It makes congestion control work much 18 | better, it lets users use TCP much better and thus properly saturate the 19 | bandwidth, makes the TCP connections more long-lived - which is good so that 20 | they get up to full speed more frequently than before. Header compression 21 | makes it use less bandwidth. 22 | 23 | With HTTP/2, browsers typically use *one* TCP connection to each host instead 24 | of the previous *six*. In fact, connection coalescing and "desharding" 25 | techniques used with HTTP/2 may actually even reduce the number of connections 26 | much more than so. 27 | 28 | HTTP/2 fixed the HTTP head of line blocking problem, where clients had to wait 29 | for the first request in line to finish before the next one could go out. 30 | 31 | ![http2 man](../images/h2-man.jpg) 32 | -------------------------------------------------------------------------------- /fr/feature-udp.md: -------------------------------------------------------------------------------- 1 | ## Protocole de transfert sur UDP 2 | 3 | QUIC est un protocole de transfert implémenté au-dessus d'UDP. Si vous surveillez 4 | votre trafic réseau par hasard, vous verrez QUIC apparaître sous forme de paquets 5 | UDP. 6 | 7 | Basé sur UDP, il utilise également les numéros de port UDP pour identifier des 8 | serveurs spécifiques sur une machine donnée. 9 | 10 | Toutes les implémentations QUIC connues se trouvent actuellement dans l'espace 11 | utilisateur, ce qui permet une évolution plus rapide que ne permettent 12 | généralement pas les implémentations noyau. 13 | 14 | ## Est-ce que ça va fonctionner ? 15 | 16 | Certaines entreprises et autres configurations réseau bloquent le trafic UDP sur 17 | des ports autres que 53 (utilisé pour DNS). D'autres limitent ces données de 18 | manière à rendre QUIC moins performant que les protocoles basés sur TCP. Il n'y a 19 | pas de fin à ce que certains opérateurs peuvent faire. 20 | 21 | Dans un avenir prévisible, toute utilisation de transports basés sur QUIC devra 22 | probablement être en mesure de faire appel à une autre alternative (basée sur TCP). 23 | Les ingénieurs de Google ont précédemment mentionné les taux d'échec mesurés dans 24 | de faibles pourcentages à un chiffre. 25 | 26 | ## Cela va-t-il s'améliorer ? 27 | 28 | Il est fort probable que si QUIC s'avère être un atout précieux au monde d'Internet, 29 | les utilisateurs voudront l'utiliser et le feront fonctionner dans leurs réseaux, ce 30 | qui permettra aux entreprises de reconsidérer leurs obstacles. Au fil des années, le 31 | développement de QUIC a progressé, le taux de réussite de l’établissement et de 32 | l’utilisation de connexions QUIC sur Internet a augmenté. 33 | -------------------------------------------------------------------------------- /ja/quic-streams.md: -------------------------------------------------------------------------------- 1 | # ストリーム 2 | 3 | QUIC におけるストリームは軽量で順序付けられたバイトストリームの概念を提供します。 4 | 5 | QUIC には2種類の基本的なストリームが存在します: 6 | 7 | - イニシエータからピアへデータを1方向に転送する単方向ストリーム 8 | 9 | - お互いにデータを送ることができる双方向ストリーム 10 | 11 | どちらのエンドポイントも、両方のタイプのストリームを作成でき、交互に配置した複数ストリームのデータを並行で送信したり中止したりできます。 12 | 13 | QUIC のコネクションを経由してデータを送る際には、1つ以上のストリームが利用されます。 14 | 15 | ## フロー制御 16 | 17 | ストリームは各自独立にフロー制御が行われ、エンドポイントがメモリの割当量を制限したり、バックプレッシャーをかけたりできるようになっています。 18 | 19 | ストリーム作成も同様にフロー制御が行われ、それぞれのピアが一時的に許可される最大 Stream ID を宣言します。 20 | 21 | ## ストリームの識別名 22 | 23 | ストリームは 62bit の符号なし整数により識別され、この整数を Stream ID と呼びます。 24 | 25 | Stream ID の最下位 2bit はストリームの種類 (単方向もしくは双方向) とストリームのイニシエータの識別に利用されます。 26 | 27 | Stream ID の 最下位 bit (0x1) は ストリームのイニシエータを識別します。 28 | 29 | クライアントは偶数のストリームを開始し (このときの最下位 bit は 0 に設定されます)、サーバーは奇数のストリームを開始します (このときの最下位 bit は 1 に設定されます)。 30 | 31 | Stream ID の最下位 2bit (0x2) は 単方向ストリームと双方向ストリームの両者を区別します。 32 | 33 | 単方向ストリームでは常にこの bit は 1 に設定され、双方向ストリームではこの bit は 0 に設定されます。 34 | 35 | ## ストリームの並行性 36 | 37 | QUIC では任意の数のストリームを並行で操作することができます。エンドポイントは最大の Stream ID を制限することにより、並行して受信できる有効な入力ストリームの個数を制限できます。 38 | 39 | Stream ID の上限はエンドポイント特有で、設定を受け取ったピアにのみ適用されます。 40 | 41 | 42 | ## データの送受信 43 | 44 | エンドポイントはデータの送受信にストリームを利用します。それがつまるところストリームの究極の目的です。 45 | 46 | ストリームは順序付けられたバイトストリームの概念です。 47 | 48 | 別々のストリームは必ずしも元の順序で配信されるとは限りません。 49 | 50 | ## ストリームの優先順位付け 51 | 52 | ストリームに割り当てられたリソースに正しい優先順位付けがされているのならば、ストリームの多重化はアプリケーションのパフォーマンスに莫大な効果を与えます。 53 | 54 | HTTP/2 のような他の多重化されたプロトコルでの経験から言って、効果的な優先順位付けの計画はパフォーマンスに莫大なプラスの影響を持ちます。 55 | 56 | QUIC 自身は優先順位付けの情報を交換するフレームを持ちません。そのかわり、QUIC を利用するアプリケーションからの優先順位情報を信頼します。 57 | 58 | QUIC を利用するプロトコルはそのアプリケーションのセマンティクスに合った優先順位付けのスキームを定義することが出来ます。 59 | 60 | HTTP/3 に QUIC を利用する場合、HTTP レイヤーにおいては優先順位付けは不要です。 61 | -------------------------------------------------------------------------------- /ja/proc-status.md: -------------------------------------------------------------------------------- 1 | # 現在の状況 2 | 3 | QUIC ワーキンググループは2016年後半からプロトコルの策定のために活発に活動し、現在2019年7月までにリリースする予定で動いています。 4 | 5 | 2018年の11月現在では、いまだ HTTP/3 の大規模な相互運用テストは実施されていません。2つの実装が存在し、いずれについても、ブラウザや主要なサーバーソフトウェアにも実装が行われていません。 6 | 7 | QUIC ワーキンググループの wiki ページには15個ほどの [QUIC 実装リスト](https://github.com/curl/curl/wiki/QUIC-implementation) が掲載されていますが、いずれの実装も最新版の仕様との互換性はまだありません。 8 | 9 | QUIC の実装は簡単ではなく、プロトコルは毎日のように変更され続けています。 10 | 11 | ## サーバー 12 | 13 | Apache や nginx が QUIC をサポートしたという公式な発表はありません。 14 | 15 | ## クライアント 16 | 17 | IETF バージョンの QUIC や HTTP/3 をサポートしたブラウザをリリースした大規模ベンダーはまだありません。 18 | 19 | Google Chrome には Google 版の QUIC を何年も前から組み込まれています。しかし、IETF QUIC プロトコルとの互換性はなく、使われている HTTP の実装も HTTP/3 とは異なります。 20 | 21 | ## 実装の障害 22 | 23 | QUIC は TLS 1.3 を暗号化とセキュリティのために採用することにしました。これは車輪の再発明を避け、信頼できる既存のプロトコルを利用するためです。しかしながら、これと並行して、QUIC での TLS の利用を本当に効率化することにしました。QUIC では "TLS messages" のみを利用し "TLS records" は利用しないことにしました。 24 | 25 | これは無害な変更に聞こえますが、この決定は QUIC を実装している人たちにとってとても高いハードルとなりました。既存の TLS 1.3 をサポートしているライブラリにはこれらの機能にアクセスする API が不足しており、QUIC ではアクセスできないのです。一方で多くの QUIC の実装者は大きな組織に所属しており、それぞれがもっている TLS スタックを別々に使用しているため、全員にとって問題とはなっていません。 26 | 27 | 2018年11月現在、例えば広く使われているオープンソースの OpenSSL では、これらの必要な API は全くなく、また近々で追加するような要望も上がっていません。 28 | 29 | これにより QUIC スタックは OpenSSL 以外の TLS ライブラリを使う、パッチをあてた OpenSSL のビルドを使う、将来の OpenSSL に対しての更新を求める、といったいずれかの選択を取る必要があり、最終的にはデプロイの障害となります。 30 | 31 | ## カーネルと CPU 負荷 32 | 33 | Google と Facebook は QUIC を彼らの膨大なトラフィックに適用した場合、HTTP/2 over TLS に比べ約2倍の CPU が必要になると言っています。 34 | 35 | しかし、下記のような説明が含まれています。 36 | 37 | - 歴史的に多くの Linux の UDP スタックはこのような高速通信に利用されることを想定していなかったため、TCP スタックに比べて最適化がされていない 38 | 39 | - TCP と TLS の負荷を軽減するハードウェアは存在しているが、UDP のものはほとんどない。基本的に QUIC 向けのものは存在していない 40 | 41 | このような問題点がありますが、パフォーマンスと CPU の要求が将来的に改善されると信じています。 42 | -------------------------------------------------------------------------------- /en/h3-streams.md: -------------------------------------------------------------------------------- 1 | # QUIC streams and HTTP/3 2 | 3 | HTTP/3 is made for QUIC so it takes full advantage of QUIC's streams, where 4 | HTTP/2 had to design its entire stream and multiplexing concept of its own on 5 | top of TCP. 6 | 7 | HTTP requests done over HTTP/3 use a specific set of streams. 8 | 9 | ## HTTP/3 frames 10 | 11 | HTTP/3 means setting up QUIC streams and sending over a set of frames to the 12 | other end. There's but a small fixed number (actually nine on December 18th, 2018!) of known frames in 13 | HTTP/3. The most important ones are probably: 14 | 15 | - HEADERS, that sends compressed HTTP headers 16 | - DATA, sends binary data contents 17 | - GOAWAY, please shutdown this connection 18 | 19 | ## HTTP Request 20 | 21 | The client sends its HTTP request on a client-initiated *bidirectional* QUIC 22 | stream. 23 | 24 | A request consists of a single HEADERS frame and might optionally be followed 25 | by one or two other frames: a series of DATA frames and possibly a final 26 | HEADERS frame for trailers. 27 | 28 | After sending a request, a client closes the stream for sending. 29 | 30 | ## HTTP Response 31 | 32 | The server sends back its HTTP response on the bidirectional stream. A HEADERS 33 | frame, a series of DATA frames and possibly a trailing HEADERS frame. 34 | 35 | ## QPACK headers 36 | 37 | The HEADERS frames contain HTTP headers compressed using the QPACK algorithm. 38 | QPACK is similar in style to the HTTP/2 compression called HPACK ([RFC 39 | 7541](https://httpwg.org/specs/rfc7541.html)), but modified to work with 40 | streams delivered out of order. 41 | 42 | QPACK itself uses two additional unidirectional QUIC streams between the two 43 | end-points. They are used to carry dynamic table information in either 44 | direction. 45 | -------------------------------------------------------------------------------- /en/quic-connections.md: -------------------------------------------------------------------------------- 1 | # Connections 2 | 3 | A QUIC connection is a single conversation between two QUIC endpoints. QUIC's 4 | connection establishment combines version negotiation with the cryptographic 5 | and transport handshakes to reduce connection establishment latency. 6 | 7 | To actually send data over such a connection, one or more streams have to be 8 | created and used. 9 | 10 | ## Connection ID 11 | 12 | Each connection possesses a set of connection identifiers, or connection IDs, 13 | each of which can be used to identify the connection. Connection IDs are 14 | independently selected by endpoints; each endpoint selects the connection IDs 15 | that its peer uses. 16 | 17 | The primary function of these connection IDs is to ensure that changes in 18 | addressing at lower protocol layers (UDP, IP, and below) do not cause packets 19 | for a QUIC connection to be delivered to the wrong endpoint. 20 | 21 | By taking advantage of the connection ID, connections can thus migrate between 22 | IP addresses and network interfaces in ways TCP never could. For instance, 23 | migration allows an in-progress download to move from a cellular network connection 24 | to a faster wifi connection when the user moves their device into a location 25 | offering wifi. Similarly, the download can proceed over the cellular connection 26 | if wifi becomes unavailable. 27 | 28 | ## Port numbers 29 | 30 | QUIC is built atop UDP, so a 16 bit port number field is used to differentiate 31 | incoming connections. 32 | 33 | ## Version negotiation 34 | 35 | An QUIC connection request originating from a client will tell the server 36 | which QUIC protocol version it wants to speak, and the server will respond 37 | with a list of supported versions for the client to select from. 38 | -------------------------------------------------------------------------------- /fr/h3-altsvc.md: -------------------------------------------------------------------------------- 1 | # Alt-svc 2 | 3 | L'en-tête du service de remplacement (Alt-svc:) et sa trame `ALT-SVC` HTTP/2 4 | correspondante ne sont pas créés spécifiquement pour QUIC ou HTTP/3. Ils font partie 5 | d'un mécanisme déjà conçu et créé pour qu'un serveur indique à un client: "Regardez, 6 | je lance le même service sur CET HÔTE en utilisant CE PROTOCOLE sur CE PORT" *. Voir 7 | les détails dans la [RFC 7838](https://tools.ietf.org/html/rfc7838). 8 | 9 | Un client qui reçoit une telle réponse Alt-svc est ensuite invité, s’il le prend en 10 | charge et le souhaite, à se connecter en arrière-plan en parallèle à cet hôte 11 | donné - à l’aide du protocole spécifié - et s’il réussit à basculer ses opérations 12 | sur cela au lieu de la connexion initiale. 13 | 14 | Si la connexion initiale utilise HTTP/2 ou même HTTP/1, le serveur peut répondre et 15 | indiquer au client qu'il peut se reconnecter et essayer HTTP/3. Cela pourrait être 16 | vers même hôte ou à un autre qui sait comment servir cette origine. Les informations 17 | fournies dans une telle réponse Alt-svc ont un temporisateur d'expiration, 18 | permettant aux clients de diriger les connexions et demandes ultérieures 19 | directement vers l'hôte alternatif à l'aide du protocole alternatif suggéré, 20 | pendant une certaine période. 21 | 22 | ## Exemple 23 | 24 | Un serveur HTTP incluant une en-tête `Alt-Svc:` dans sa réponse: 25 | 26 | Alt-Svc: h3=":50781" 27 | 28 | Cela indique que HTTP/3 est disponible sur le port UDP 50781 avec le même nom d'hôte 29 | que celui utilisé pour obtenir cette réponse. 30 | 31 | Un client peut ensuite essayer de configurer une connexion QUIC avec cette 32 | destination et, en cas de succès, continuer à communiquer avec l’origine comme cela 33 | au lieu de la version HTTP initiale. 34 | -------------------------------------------------------------------------------- /fr/h3-https.md: -------------------------------------------------------------------------------- 1 | # URLs HTTPS:// 2 | 3 | HTTP/3 sera exécuté en utilisant des URLs `HTTPS://`. Le monde est rempli de ces 4 | URLs et il a été jugé peu pratique et tout à fait déraisonnable d'introduire un 5 | autre schéma d'URL pour le nouveau protocole. Tout comme HTTP/2 n'a pas besoin d'un 6 | nouveau schéma, HTTP/3 non plus. 7 | 8 | La complexité supplémentaire de la situation de HTTP/3 réside toutefois dans le fait 9 | que, lorsque HTTP/2 était un nouveau moyen de transporter HTTP sur le réseau, il 10 | était toujours basé sur TLS et TCP comme l'était HTTP/1. Le fait que HTTP/3 soit 11 | effectué sur QUIC change les choses en quelques aspects importants. 12 | 13 | Les anciennes, en texte clair, URLs `HTTP://`, seront laissées telles quelles et, 14 | au fur et à mesure que nous avançons dans le futur avec des transferts plus 15 | sécurisés, elles seront probablement de moins en moins utilisées. Les requêtes 16 | adressées à ces URLs ne seront tout simplement pas mises à niveau pour utiliser 17 | HTTP/3. En réalité, ils passent rarement à HTTP/2 non plus, mais pour d'autres 18 | raisons. 19 | 20 | ## Connexion initiale 21 | 22 | La première connexion à un hôte récent, non visité précédemment pour une URL 23 | HTTPS:// devra probablement être établie via TCP (éventuellement en plus d'une 24 | tentative parallèle de connexion via QUIC). L'hôte peut être un ancien serveur sans 25 | prise en charge de QUIC ou il peut y avoir une boîte intermédiaire entre les 26 | obstacles empêchant le succès d'une connexion QUIC. 27 | 28 | Un client et un serveur modernes négocieraient probablement HTTP/2 lors du premier 29 | handshake. Lorsque la connexion a été configurée et que le serveur répond à une 30 | requête HTTP du client, le serveur peut informer le client de sa prise en charge et 31 | de sa préférence pour HTTP/3. 32 | -------------------------------------------------------------------------------- /en/proc-ietf.md: -------------------------------------------------------------------------------- 1 | ## IETF 2 | 3 | The QUIC working group that was established to standardize the protocol within 4 | the IETF quickly decided that the QUIC protocol should be able to transfer 5 | other protocols than "just" HTTP. Google-QUIC only ever transported HTTP - 6 | in practice it transported what was effectively HTTP/2 frames, using the 7 | HTTP/2 frame syntax. 8 | 9 | It was also stated that IETF-QUIC should base its encryption and security on 10 | TLS 1.3 instead of the "custom" approach used by Google-QUIC. 11 | 12 | In order to satisfy the send-more-than-HTTP demand, the IETF QUIC protocol 13 | architecture was split in two separate layers: the transport QUIC and the 14 | "HTTP over QUIC" layer (the latter sometimes referred to as "hq"). 15 | 16 | This layer split, while it may sound innocuous, has caused the IETF-QUIC to 17 | differ quite a lot from the original Google-QUIC. 18 | 19 | The working group did however soon decide that in order to get the proper focus 20 | and ability to deliver QUIC version 1 on time, it would focus on delivering 21 | HTTP, leaving non-HTTP transports to later work. 22 | 23 | In March 2018 when we started working on this book, the plan was to ship the 24 | final specification for QUIC version 1 in November 2018; this was later 25 | postponed to July 2019. 26 | 27 | While the work on IETF-QUIC has progressed, the Google team has incorporated 28 | details from the IETF version and has started to slowly progress their version 29 | of the protocol towards what the IETF version might become. Google has continued 30 | using their version of QUIC in their browser and services. 31 | 32 | [Most new implementations under development](https://github.com/quicwg/base-drafts/wiki/Implementations) 33 | have decided to focus on the IETF version and are not compatible with the Google version. 34 | -------------------------------------------------------------------------------- /fr/h3-push.md: -------------------------------------------------------------------------------- 1 | # HTTP/3 push serveur 2 | 3 | Un serveur push HTTP/3 est similaire à ce qui est décrit dans HTTP/2 ([RFC 4 | 7540](https://httpwg.org/specs/rfc7540.html)), mais utilise des mécanismes 5 | différents. 6 | 7 | Un serveur push est en réalité la réponse à une requête que le client n'a jamais 8 | envoyée! 9 | 10 | Les push serveur ne sont autorisés que si le côté client les a acceptés. Dans 11 | HTTP/3, le client définit même une limite pour le nombre de push qu'il accepte en 12 | informant le serveur de l'ID de flux de push maximal. Dépasser cette limite 13 | entraînera une erreur de connexion. 14 | 15 | Si le serveur estime probable que le client souhaite une ressource supplémentaire 16 | qu'il n'a pas demandée mais qu'il devrait avoir de toute façon, il peut envoyer une 17 | trame `PUSH_PROMISE` (sur le flux de la requête) indiquant à quoi ressemble la 18 | requête dont la réponse est destinée, puis envoyer cette réponse réelle sur un 19 | nouveau flux. 20 | 21 | Même si les envois ont au préalable été déclarés acceptables par le client, chaque 22 | flux envoyé individuellement peut toujours être annulé à tout moment si le client 23 | le juge approprié. Il envoie ensuite une trame `CANCEL_PUSH` au serveur. 24 | 25 | ## Problématique 26 | 27 | Depuis que cette fonctionnalité a été abordée pour la première fois dans le 28 | développement de HTTP/2 et ensuite plus tard, après que le protocole ai été livré 29 | et déployé sur Internet, cette fonctionnalité a été discutée, détestée et 30 | perfectionnée de nombreuses différentes manières afin de la rendre utile. 31 | 32 | Un envoi n’est jamais "gratuit", car même s’il enregistre un demi aller-retour, il 33 | utilise toujours de la bande passante. Il est souvent difficile ou impossible pour 34 | le côté serveur de savoir avec un niveau élevé de certitude si une ressource doit 35 | être envoyée ou non. 36 | -------------------------------------------------------------------------------- /fr/h3-streams.md: -------------------------------------------------------------------------------- 1 | # Flux QUIC et HTTP/3 2 | 3 | HTTP/3 étant conçu pour QUIC, il tire pleinement parti des flux de QUIC, où HTTP/2 4 | devait concevoir l'ensemble de son concept de flux et de multiplexage au-dessus de 5 | TCP. 6 | 7 | Les requêtes HTTP effectuées via HTTP/3 utilisent un ensemble spécifique de flux. 8 | 9 | ## Trames HTTP/3 10 | 11 | HTTP/3 signifie la configuration de flux QUIC et l’envoi d’un ensemble de trames à 12 | l’autre extrémité. Il n'y a qu'un petit nombre fixe (huit!) de trames connues dans 13 | HTTP/3. Les plus importants sont probablement: 14 | 15 | - HEADERS, qui envoie des en-têtes HTTP compressés 16 | - DATA, envoie le contenu des données binaires 17 | - GOAWAY, veuillez arrêter cette connexion 18 | 19 | ## Requête HTTP 20 | 21 | Le client envoie sa requête HTTP sur un flux QUIC *bidirectionnel* initié par le 22 | client. 23 | 24 | Une requête consiste en une seule trame HEADERS et peut éventuellement être suivie 25 | d'une ou deux autres trames: une série de trames DATA et éventuellement d'une trame 26 | HEADERS finale pour terminer. 27 | 28 | Après avoir envoyé une requête, un client ferme le flux pour l’envoyer. 29 | 30 | ## Réponse HTTP 31 | 32 | Le serveur renvoie sa réponse HTTP sur le flux bidirectionnel. Une trame HEADERS, 33 | une série de trames DATA et éventuellement une dernière trame HEADERS. 34 | 35 | ## En-têtes QPACK 36 | 37 | Les trames HEADERS contiennent des en-têtes HTTP compressés à l'aide de 38 | l'algorithme QPACK, QPACK est styliquement similaire à celui de la compression 39 | HTTP/2 appelée HPACK ([RFC 7541](https://httpwg.org/specs/rfc7541.html)), mais 40 | modifiée pour fonctionner avec des flux livrés dans le désordre. 41 | 42 | QPACK lui-même utilise deux flux QUIC unidirectionnels supplémentaires entre les 43 | deux terminaisons. Ils sont utilisés pour transporter des informations de table 44 | dynamique dans les deux sens. 45 | -------------------------------------------------------------------------------- /en/README.md: -------------------------------------------------------------------------------- 1 | # HTTP/3 explained 2 | 3 | This book effort was started in March 2018. The plan is to document HTTP/3 and 4 | its underlying protocol: QUIC. Why, how they work, protocol details, the 5 | implementations and more. 6 | 7 | The book is entirely free and is meant to be a collaborative effort 8 | involving anyone and everyone who wants to help out. 9 | 10 | ## Prerequisites 11 | 12 | A reader of this book is presumed to have a basic understanding of TCP/IP 13 | networking, the fundamentals of HTTP and the web. For further insights and 14 | specifics about HTTP/2 we recommend first reading up the details in [http2 15 | explained](https://daniel.haxx.se/http2/). 16 | 17 | ## Author 18 | 19 | This book is created and the work is started by [Daniel 20 | Stenberg](https://daniel.haxx.se/). Daniel is the founder and lead developer 21 | of [curl](https://curl.haxx.se/), the world's most widely used HTTP client 22 | software. Daniel has worked with and on HTTP and internet protocols for over 23 | two decades and is the author of [http2 24 | explained](https://daniel.haxx.se/http2/). 25 | 26 | ## Home 27 | 28 | The home page for this book is found at 29 | [daniel.haxx.se/http3-explained](https://daniel.haxx.se/http3-explained). 30 | 31 | ## Help out 32 | 33 | If you find mistakes, omissions, errors or blatant lies in this document, 34 | please send us a refreshed version of the affected paragraph and we will make 35 | amended versions. We will give proper credits to everyone who helps out. I 36 | hope to make this document better over time. 37 | 38 | Preferably, you submit [errors](https://github.com/bagder/http3-explained/issues) 39 | or [pull requests](https://github.com/bagder/http3-explained/pulls) on the book's 40 | github page. 41 | 42 | ## License 43 | 44 | This document and all its contents are licensed under the [Creative Commons 45 | Attribution 4.0 license](https://creativecommons.org/licenses/by/4.0/). 46 | -------------------------------------------------------------------------------- /fr/why-h2.md: -------------------------------------------------------------------------------- 1 | ## Remember HTTP/2? 2 | 3 | La spécification HTTP/2 [RFC 7540](https://httpwg.org/specs/rfc7540.html) a été 4 | publiée en mai 2015 et le protocole a depuis été mis en œuvre et déployé largement 5 | sur Internet et sur le World Wide Web. 6 | 7 | Début 2018, près de 40% des 1 000 meilleurs sites Web utilisaient HTTP/2, environ 8 | 70% de toutes les demandes HTTPS de Firefox recevaient des réponses HTTP/2 et tous 9 | les principaux navigateurs, serveurs et proxies le prenaient en charge. 10 | 11 | HTTP/2 corrige toute une série de lacunes presentes dans HTTP/1 et avec 12 | l'introduction de la deuxième version de HTTP, les utilisateurs peuvent cesser 13 | d'utiliser toute une série de solutions de contournement. Certaines sont assez 14 | pénibles pour les développeurs Web. 15 | 16 | L'une des principales caractéristiques de HTTP/2 est qu'il utilise le multiplexage, 17 | de sorte que de nombreux flux logiques soient envoyés sur la même connexion TCP 18 | physique. Cela rend beaucoup de choses meilleures et plus rapides. Le contrôle de 19 | congestion fonctionne bien mieux, il permet aux utilisateurs d’utiliser bien mieux 20 | le protocole TCP et ainsi de saturer correctement la bande passante, de rendre les 21 | connexions TCP plus durables - ce qui est bien pour qu’ils atteignent la vitesse 22 | maximale plus souvent qu’avant. La compression d'en-tête lui fait utiliser moins de 23 | bande passante. 24 | 25 | Avec HTTP/2, les navigateurs utilisent généralement *une* connexion TCP avec chaque 26 | hôte au lieu des précédents *six*. En fait, les techniques de fusion et de 27 | "désarchivage" des connexions utilisées avec HTTP/2 peuvent même réduire beaucoup 28 | plus que ça le nombre de connexions. 29 | 30 | HTTP/2 a corrigé le problème de blocage de tête de ligne HTTP, dans lequel les 31 | clients devaient attendre la fin de la première requête en ligne avant que la 32 | suivante ne puisse être envoyée. 33 | 34 | ![http2 man](../images/h2-man.jpg) 35 | -------------------------------------------------------------------------------- /fr/proc-ietf.md: -------------------------------------------------------------------------------- 1 | ## IETF 2 | 3 | Le groupe de travail QUIC mis en place pour standardiser le protocole au sein de 4 | l'IETF a rapidement décidé que le protocole QUIC devait pouvoir transférer des 5 | protocoles autres que "simplement" HTTP. Google-QUIC ne transportait jamais que 6 | HTTP - en pratique, il transportait ce qui était en réalité des trames HTTP/2, en 7 | utilisant la syntaxe HTTP/2. 8 | 9 | Il a également été indiqué que l'IETF-QUIC devrait baser son cryptage et sa 10 | sécurité sur TLS 1.3 au lieu de l'approche "personnalisée" utilisée par Google-QUIC. 11 | 12 | Afin de satisfaire la demande d'envoi-plus-que-HTTP, l'architecture de protocole 13 | IETF QUIC a été scindée en deux couches distinctes: la couche de transport QUIC et 14 | la couche "HTTP sur QUIC" (cette dernière parfois appelée "hq"). 15 | 16 | Cette division de couche, bien que cela puisse paraître inoffensif, a entraîné une 17 | grande différence entre l'IETF-QUIC et l'original de Google-QUIC. 18 | 19 | Cependant, le groupe de travail a rapidement décidé que pour se concentrer 20 | correctement et délivrer la version 1 de QUIC à temps, il se concentrerait sur la 21 | livraison de HTTP, laissant les transports non-HTTP à un travail ultérieur. 22 | 23 | En mars 2018, lorsque nous avons commencé à travailler sur ce livre, le plan était 24 | d'expédier la spécification finale de la version 1 de QUIC en novembre 2018; cela a 25 | ensuite été reporté à juillet 2019. 26 | 27 | Alors que les travaux sur l’IETF-QUIC ont progressé, l’équipe de Google a incorporé 28 | les détails de la version de l’IETF et a commencé à faire progresser lentement sa 29 | version du protocole vers ce que pourrait devenir la version de l’IETF. Google a 30 | continué d'utiliser sa version de QUIC dans son navigateur et ses services. 31 | 32 | [La plupart des nouvelles implémentations en cours de 33 | développement](https://github.com/quicwg/base-drafts/wiki/Implementations) 34 | ont décidé de se concentrer sur la version de l'IETF et ne sont pas compatibles 35 | avec la version de Google. 36 | -------------------------------------------------------------------------------- /fr/README.md: -------------------------------------------------------------------------------- 1 | # HTTP/3 expliqué 2 | 3 | Ce livre a été lancé en mars 2018. Il est prévu de documenter HTTP/3 et son 4 | protocole sous-jacent: QUIC. Pourquoi, comment fonctionnent-ils, les détails du 5 | protocole, les implémentations et plus. 6 | 7 | Le livre est entièrement gratuit et se veut être un effort de collaboration 8 | impliquant tous ceux qui veulent aider. 9 | 10 | ## Prérequis 11 | 12 | Un lecteur de ce livre est censé avoir une compréhension de base du réseau TCP/IP, 13 | des principes fondamentaux de HTTP et du Web. Pour plus d'informations et de 14 | détails sur HTTP/2, nous vous recommandons tout d'abord de lire les détails dans 15 | [http2 expliqué](https://daniel.haxx.se/http2/). 16 | 17 | ## Auteur 18 | 19 | Ce livre est créé et le travail est démarré par [Daniel 20 | Stenberg](https://daniel.haxx.se/). Daniel est le fondateur et le développeur 21 | principal de [curl](https://curl.haxx.se/), le client HTTP le plus utilisé au 22 | monde. Daniel travaille avec et sur les protocoles HTTP et Internet depuis plus de 23 | deux décennies et est l'auteur de [http2 expliqué](https://daniel.haxx.se/http2/). 24 | 25 | ## Accueil 26 | 27 | La page d'accueil de ce livre se trouve à l'adresse 28 | [daniel.haxx.se/http3-explained](https://daniel.haxx.se/http3-explained). 29 | 30 | ## Contribuer 31 | 32 | Si vous trouvez des fautes, des omissions, des erreurs ou des mensonges flagrants 33 | dans ce document, veuillez nous envoyer une version mise à jour du paragraphe 34 | concerné et nous en ferons des versions corrigés. Nous allons donner des crédits 35 | appropriés à tous ceux qui aident. J'espère améliorer ce document avec le temps. 36 | 37 | De préférence, vous soumettez [des 38 | erreurs](https://github.com/bagder/http3-explained/issues) ou des [demandes de 39 | tirage](https://github.com/bagder/http3-explained/pulls) sur la page github du 40 | livre. 41 | 42 | ## Licence 43 | 44 | Ce document et tout son contenu sont sous licencés sous la [licence Creative Commons 45 | Attribution 4.0](https://creativecommons.org/licenses/by/4.0/). 46 | -------------------------------------------------------------------------------- /en/quic-v2.md: -------------------------------------------------------------------------------- 1 | # QUIC v2 2 | 3 | In order to get the most possibly focus on the core QUIC protocol and be able 4 | to ship it on time, several features that were originally planned to be part 5 | of the core protocol have been postponed and are now planned to instead get 6 | done in a subsequent QUIC version. QUIC version 2 or beyond. 7 | 8 | The author of this document does however have a rather faulty crystal ball so 9 | we can not tell for sure exactly what features will or will not appear in 10 | version 2. We can however mention some of the features and things that 11 | explicitly have been removed from the v1 work to be "worked on later" and that 12 | then possibly might appear in a version 2. 13 | 14 | ## Forward Error Correction 15 | 16 | Forward error correction (FEC) is a method of obtaining error control in data 17 | transmission in which the transmitter sends redundant data and the receiver 18 | recognizes only the portion of the data that contains no apparent errors. 19 | 20 | Google experimented with this in their original QUIC work but it was 21 | subsequently removed again since the experiments did not turn out well. This 22 | feature is subject for discussion for QUIC v2 but probably takes for someone 23 | to prove that it actually can be a useful addition without too much penalty. 24 | 25 | ## Multipath 26 | 27 | Multipath means that the transport can by itself use multiple network paths to 28 | maximize resource usage and increase redundancy. 29 | 30 | The SCTP proponents of the world like to mention that SCTP already features 31 | multipath and so does modern TCP. 32 | 33 | ## Unreliable data 34 | 35 | It has been discussed to offer "unreliable" streams as an option, that would 36 | then allow QUIC to also replace UDP-style applications. 37 | 38 | ## Non-HTTP adaptions 39 | 40 | DNS over QUIC was one of the early mentioned non-HTTP protocols that just 41 | might get some attention once QUIC v1 and HTTP/3 ship. But with a new 42 | transport like this having been brought on to the world I cannot imagine that 43 | it will stop there. 44 | -------------------------------------------------------------------------------- /fr/quic-connections.md: -------------------------------------------------------------------------------- 1 | # Connexions 2 | 3 | Une connexion QUIC est une conversation unique entre deux terminaisons QUIC. 4 | L’établissement de la connexion QUIC associe la négociation de la version à la 5 | négociation cryptographique et du handshake de transfert afin de réduire le temps 6 | d’attente de l’établissement de la connexion. 7 | 8 | Pour envoyer des données via une telle connexion, un ou plusieurs flux doivent être 9 | créés et utilisés. 10 | 11 | ## ID de connexion 12 | 13 | Chaque connexion possède un ensemble d'identifiants de connexion, ou d'IDs de 14 | connection, chacun d'entre eux pouvant être utilisé pour identifier la connexion. 15 | Les IDs de connexion sont sélectionnés indépendamment par les terminaisons; chaque 16 | terminaison sélectionne les identifiants de connexion que son pair utilise. 17 | 18 | La fonction principale de ces IDs de connexion est de garantir que les changements 19 | d’adressage au niveau des couches inférieures du protocole (UDP, IP et au-dessous) 20 | n’entraînent pas la transmission des paquets d’une connexion QUIC à la mauvaise 21 | terminaison. 22 | 23 | En tirant parti de l'ID de connexion, les connexions peuvent ainsi migrer entre les 24 | adresses IP et les interfaces réseau d'une manière que TCP n'aurais jamais pu. Par 25 | exemple, la migration permet à un téléchargement en cours de passer d'une connexion 26 | réseau cellulaire à une connexion wifi plus rapide lorsque l'utilisateur déplace 27 | son appareil dans un emplacement proposant le wifi. De même, le téléchargement peut 28 | s'effectuer par la connexion cellulaire si le wifi devient indisponible. 29 | 30 | ## Numéro de port 31 | 32 | QUIC est construit sur UDP, donc un champ de numéro de port de 16 bits est utilisé 33 | pour différencier les connexions entrantes. 34 | 35 | ## Négociation de version 36 | 37 | Une demande de connexion QUIC émanant d'un client indiquera au serveur la version 38 | du protocole QUIC qu'il souhaite utiliser, et le serveur répondra avec une liste 39 | des versions prises en charge que le client pourra sélectionner. 40 | -------------------------------------------------------------------------------- /ja/README.md: -------------------------------------------------------------------------------- 1 | # 詳解 HTTP/3 2 | 3 | この本の試みは2018年3月に始まりました。HTTP/3 と、その根幹のプロトコルである QUIC を文書化することがその目的です (なぜ、どのようにして動作するのか、プロトコルの詳細、その実装など)。 4 | 5 | この本は完全に無償で提供され、援助したいと考えるすべての人を巻き込んだ共同作品です。 6 | 7 | ## 前提条件 8 | 9 | この本の読者は、TCP/IP ネットワーキングの基礎や、HTTP、Web の基本を理解しているものとみなされます。 10 | HTTP/2 に関する詳細や特徴については、[http2 explained](https://daniel.haxx.se/http2/) を最初に読むことを推奨しています。 11 | 12 | ## 著者 13 | 14 | この本は [Daniel Stenberg](https://daniel.haxx.se/) によって作成されました。 15 | Daniel は、HTTP クライアントソフトウェアとして世界中で最も幅広く使われている [curl](https://curl.haxx.se/) の作者であり、リードデベロッパーです。 16 | Daniel は20年以上にわたり HTTP やインターネットのプロトコルに関して取り組んでおり、 [http2 explained](https://daniel.haxx.se/http2/) の著者でもあります。 17 | 18 | 訳者: 19 | 20 | - [inductor](https://github.com/inductor) 21 | - [ebiiim](https://github.com/ebiiim) 22 | - [kousukekikuchi1984](https://github.com/kousukekikuchi1984) 23 | - [MATTENN](https://github.com/MATTENN) 24 | - [beagle](https://github.com/beagleworks) 25 | - [MakTak](https://github.com/take114514) 26 | - [akihirok2k2](https://github.com/akihirok2k2) 27 | - [OldBigBuddha](https://github.com/OldBigBuddha) 28 | - [hidesuke](https://github.com/hidesuke) 29 | - [ichika](https://github.com/ichika5259) 30 | - [peacock](https://github.com/peacock0803sz) 31 | - [gim_kondo](https://github.com/gimKondo) 32 | - [hykw](https://github.com/hykw) 33 | - [misato8310](https://github.com/misato8310) 34 | - [aoi](https://github.com/blux2) 35 | - [morin_river](https://github.com/cahlchang) 36 | - [waku-tkd](https://github.com/waku-tkd) 37 | - [smaeda-ks](https://github.com/smaeda-ks) 38 | 39 | ## ホームページ 40 | 41 | この本のホームページは [daniel.haxx.se/http3-explained](https://daniel.haxx.se/http3-explained) にあります。 42 | 43 | ## ヘルプ！ 44 | 45 | 本文書に関する誤字脱字やあからさまな間違いを見つけた場合は、修正した状態の文書を送っていただければ、改訂版を作成します。 46 | 47 | 助けていただいたすべての方に、適切なクレジットを提供します！ 時間をかけてこの文書を良くしていければと思っています。 48 | 49 | よろしければ、[誤字の指摘](https://github.com/bagder/http3-explained/issues) または [プルリクエスト](https://github.com/bagder/http3-explained/pulls) を本の GitHub ページに送ってください。 50 | 51 | ## License 52 | 53 | この文書およびすべてのコンテンツは、[Creative Commons Attribution 4.0 license](https://creativecommons.org/licenses/by/4.0/) のライセンスにて使用許諾されています。 54 | -------------------------------------------------------------------------------- /HOWTO-TRANSLATE.md: -------------------------------------------------------------------------------- 1 | # How to translate this document 2 | 3 | Thanks for considering to translate or help out with the translation of this 4 | document. 5 | 6 | ## Format 7 | 8 | We only use markdown for text. 9 | 10 | The images used in the document are all used for all translations so use the 11 | same URL reference to get them into your translated version, use no local 12 | images unless there's a specific need for translation reasons. 13 | 14 | ## It will change 15 | 16 | This document is a living document and will keep getting updated and improved 17 | over time. Keep that in mind when working on the translation. 18 | 19 | ## Directories 20 | 21 | All translated contents live in sub-directories named after the specific 22 | language. "en" for English, "fr" for French etc. If you make a new 23 | translation, create a new directory and add your language to LANGS.md in the 24 | root dir. 25 | 26 | ## Keeping it up to date 27 | 28 | Once your translation has been merged into the repo, it may be current and up 29 | to date with the English master document at that moment in time. It may be 30 | useful to record which commit hash it is synced with, to allow easier lookups 31 | in the future if you want to see what has changed in the English version since 32 | the last sync and allow you to update those parts only. 33 | 34 | ## Push rights 35 | 36 | The main translator will be offered push rights to the repository and he/she 37 | can push updates to his/hers translation at any time or merge pull requests 38 | and more. 39 | 40 | ### Main translators 41 | - zh(中文) 42 | - [yi-bai](https://github.com/yi-bai) 43 | 44 | - ja(日本語) 45 | - [inductor](https://github.com/inductor) 46 | 47 | - fr(Français) 48 | - [quantumsheep](https://github.com/quantumsheep) 49 | 50 | ## Commit messages 51 | 52 | When committing changes, we use the following commit message format 53 | 54 | 55 | [section] [language] [short desc] (all in the first line) 56 | 57 | [multi-line free text if necessary, where you MUST give credits to the person 58 | who helped out with the change if anyone else did than the person authoring 59 | the commit] 60 | 61 | The empty line between the first and the third line is deliberate. 62 | -------------------------------------------------------------------------------- /en/why-tcpudp.md: -------------------------------------------------------------------------------- 1 | ## TCP or UDP 2 | 3 | If we can't fix head-of-line blocking within TCP, then in theory we should 4 | be able to make a new transport protocol next to UDP and TCP in the network 5 | stack. Or perhaps even use 6 | [SCTP](https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol) 7 | which is a transport protocol standardized by the IETF in [RFC 8 | 4960](https://tools.ietf.org/html/rfc4960) with several of the desired 9 | characteristics. 10 | 11 | However, in recent years efforts to create new transport protocols have almost 12 | entirely been halted because of the difficulties in deploying them on the Internet. 13 | Deployment of new protocols is hampered by many firewalls, NATs, routers and other 14 | middle-boxes that only allow TCP or UDP are deployed between users and the servers 15 | they need to reach. Introducing another transport protocol makes N% of the connections 16 | fail because they are being blocked by boxes that see it not being UDP or TCP and 17 | thus evil or wrong somehow. The N% failure rate is often deemed too high to be 18 | worth the effort. 19 | 20 | Additionally, changing things in the transport protocol layer of the network 21 | stack typically means protocols implemented by operating system kernels. 22 | Updating and deploying new operating system kernels is a slow process that 23 | requires significant effort. Many TCP improvements standardized by the IETF 24 | are not widely deployed or used because they are not broadly supported. 25 | 26 | ## Why not SCTP-over-UDP 27 | 28 | SCTP is a reliable transport protocol with streams, and for WebRTC there are 29 | even existing implementations using it over UDP. 30 | 31 | This was not deemed good enough as a QUIC alternative due to several reasons, 32 | including: 33 | 34 | - SCTP does not fix the head-of-line-blocking problem for streams 35 | - SCTP requires the number of streams to be decided at connection setup 36 | - SCTP does not have a solid TLS/security story 37 | - SCTP has a 4-way handshake, QUIC offers 0-RTT 38 | - QUIC is a bytestream like TCP, SCTP is message-based 39 | - QUIC connections can migrate between IP addresses but SCTP cannot 40 | 41 | For more details on the differences, see [A Comparison between SCTP and 42 | QUIC](https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00). 43 | -------------------------------------------------------------------------------- /fr/quic-v2.md: -------------------------------------------------------------------------------- 1 | # QUIC v2 2 | 3 | Afin de se concentrer au mieux sur le coeur du protocole QUIC et de pouvoir le 4 | livrer à temps, plusieurs fonctionnalités qui étaient prévues à l'origine pour 5 | faire partie du protocole principal ont été reportées et sont maintenant prévues 6 | pour être remplacées dans une prochaine version de QUIC. QUIC version 2 ou au-delà. 7 | 8 | Cependant, l’auteur de ce document a une boule de cristal plutôt défectueuse, nous 9 | ne pouvons donc pas savoir exactement quelles fonctionnalités apparaîtront ou ne 10 | figureront pas dans la version 2. Nous pouvons toutefois mentionner certaines des 11 | fonctionnalités et éléments explicitement supprimés du travail de la v1 pour être 12 | "travaillé plus tard" et pourraient alors éventuellement apparaître dans une 13 | version 2. 14 | 15 | ## Forward Error Correction 16 | 17 | La Correction d'Erreur Directe (en englais Forward Error Correction (FEC)) est une 18 | méthode d'obtention du contrôle d'erreur dans la transmission de données dans 19 | laquelle l'émetteur envoie des données redondantes et le récepteur ne reconnaît que 20 | la partie des données qui ne contient aucune erreur apparente. 21 | 22 | FEC a été expérimenté par Google dans leur travail original sur QUIC, mais 23 | il a été retiré à nouveau car les expériences ne se sont pas bien déroulées. 24 | Cette fonctionnalité est un sujet de discussion pour QUIC v2, mais il faut 25 | probablement que quelqu'un prouve qu’elle peut en fait être un ajout utile sans 26 | pénalité excessive. 27 | 28 | ## Multitrajet 29 | 30 | Multitrajet (en anglais multipath) signifie que le transport peut lui-même utiliser 31 | plusieurs chemins d'accès réseau pour optimiser l'utilisation des ressources et 32 | augmenter la redondance. 33 | 34 | Les partisans du SCTP dans le monde aiment mentionner que le SCTP est déjà 35 | multitrajet, tout comme le TCP moderne. 36 | 37 | ## Données non fiables 38 | 39 | Il a été envisagé de proposer comme option des flux "non fiables", qui permettraient alors à QUIC de remplacer également les applications de type UDP. 40 | 41 | ## Adaptations non-HTTP 42 | 43 | DNS sur QUIC est l’un des premiers protocoles non HTTP mentionnés qui pourrait attirer l’attention une fois que QUIC v1 et HTTP/3 seront disponibles. Mais avec un nouveau moyen de transport comme celui-ci ayant été apporté au monde, je ne peux pas imaginer que cela s’arrêtera là. 44 | -------------------------------------------------------------------------------- /en/why-tcphol.md: -------------------------------------------------------------------------------- 1 | ## TCP head of line blocking 2 | 3 | HTTP/2 is done over TCP and with much fewer TCP connections than when using 4 | earlier HTTP versions. TCP is a protocol for reliable transfers and you can 5 | basically think of it as an imaginary chain between two machines. What is 6 | being put out on the network in one end will end up in the other end, in the 7 | same order - eventually. (Or the connection breaks.) 8 | 9 | ![a TCP chain between two computers](../images/tcp-chain.png) 10 | 11 | With HTTP/2, typical browsers do tens or hundreds of parallel transfers over 12 | that single TCP connection. 13 | 14 | If a single packet is dropped, or lost in the network somewhere between two 15 | endpoints that speak HTTP/2, it means the entire TCP connection is brought to 16 | a halt while the lost packet needs to be re-transmitted and find its way to 17 | the destination. Since TCP is this "chain", it means that if one link is 18 | suddenly missing, everything that would come after the lost link needs to 19 | wait. 20 | 21 | An illustration using the chain metaphor when sending two streams over this 22 | connection. A red stream and a green stream: 23 | 24 | ![the chain showing links in different colors](../images/tcp-chain-streams.png) 25 | 26 | It becomes a TCP-based head of line block! 27 | 28 | As the packet loss rate increases, HTTP/2 performs less and less good. At 2% 29 | packet loss (which is a terrible network quality, mind you), tests have proven 30 | that HTTP/1 users are usually better off - because they typically have six TCP 31 | connections up to distribute the lost packet over so for each lost packet the 32 | other connections without loss can still continue. 33 | 34 | Fixing this issue is not easy, if at all possible, to do with TCP. 35 | 36 | ## Independent streams avoids the block 37 | 38 | With QUIC there is still a connection setup between the two end-points that 39 | makes the connection secure and the data delivery reliable. 40 | 41 | ![a QUIC chain between two computers](../images/tcp-chain.png) 42 | 43 | When setting up two different streams over this connection, they are treated 44 | independently so that if any link goes missing for one of the streams, only 45 | that stream, that particular chain, has to pause and wait for the missing link 46 | to get retransmitted. 47 | 48 | Illustrated here with one yellow and one blue stream sent between two 49 | end-points. 50 | 51 | ![two QUIC streams between two computers](../images/quic-chain-streams.png) 52 | -------------------------------------------------------------------------------- /en/why-ossification.md: -------------------------------------------------------------------------------- 1 | # Ossification 2 | 3 | The internet is a network of networks. There is equipment set up on the 4 | Internet in many different places along the way to make sure this network of 5 | networks works as it is supposed to. These devices, the boxes that are 6 | distributed out in the network, are what we sometimes refer to as middle-boxes. 7 | Boxes that sit somewhere between the two end-points that are the primary parties 8 | involved in a traditional network data transfer. 9 | 10 | These boxes serve many different specific purposes but I think we can say that 11 | universally they are put there because someone thinks they must be there to 12 | make things work. 13 | 14 | Middle-boxes route IP packets between networks, they block malicious traffic, 15 | they do NAT (Network Address Translation), they improve performance, some try 16 | to spy on the passing traffic and more. 17 | 18 | In order to perform their duties these boxes must know about networking and 19 | the protocols that are monitored or modified by them. They run software for 20 | this purpose. Software that is not always upgraded frequently. 21 | 22 | While they are glue components that keep the Internet together they are also 23 | often not keeping up with the latest technology. The middle of the network 24 | typically does not move as fast as the edges, as the clients and the servers of 25 | the world. 26 | 27 | All network protocols that these boxes might want to inspect and have ideas 28 | about what is okay and what is not then have this problem: these boxes were 29 | deployed a while ago when the protocols had a feature set of that 30 | time. Introducing new features or changes in behavior that were not known 31 | before, risks ending up considered bad or illegal by such boxes. Such traffic 32 | may well just be dropped or delayed to the degree that users really do not 33 | want to use those features. 34 | 35 | That is called "protocol ossification". 36 | 37 | Changes to TCP also suffer from ossification: some boxes between a client and 38 | the remote server will spot unknown new TCP options and block such connections 39 | since they do not know what the options are. If allowed to detect protocol 40 | details, systems learn how protocols typically behave and over time it becomes 41 | impossible to change them. 42 | 43 | The only truly effective way to "combat" ossification, is to encrypt as much 44 | as possible of the communication to prevent middle-boxes from seeing much of the 45 | protocol passing through. 46 | -------------------------------------------------------------------------------- /fr/why-tcphol.md: -------------------------------------------------------------------------------- 1 | ## Blocage de tête de ligne TCP 2 | 3 | HTTP/2 est réalisé sur TCP et avec beaucoup moins de connexions TCP que lors de 4 | l'utilisation de versions HTTP antérieures. TCP est un protocole pour des 5 | transferts fiables et vous pouvez le considérer comme une chaîne imaginaire entre 6 | deux machines. Ce qui est mis sur le réseau d'un côté finira par se retrouver à 7 | l'autre bout, dans le même ordre - à terme. (Ou la connexion est rompue.) 8 | 9 | ![une chaîne TCP entre deux ordinateurs](../images/tcp-chain.png) 10 | 11 | Avec HTTP/2, les navigateurs classiques effectuent des dizaines, voire des 12 | centaines de transferts parallèles sur cette seule connexion TCP. 13 | 14 | Si un seul paquet est abandonné ou perdu sur le réseau quelque part entre deux 15 | terminaisons qui parlent HTTP/2, cela signifie que toute la connexion TCP est 16 | interrompue et que le paquet perdu doit être retransmis et doit retrouver son 17 | chemin jusqu'à la destination. Puisque TCP est cette "chaîne", cela signifie que si 18 | un lien manque soudainement, tout ce qui viendrait après le lien perdu doit 19 | attendre. 20 | 21 | Illustration utilisant la métaphore de la chaîne lors de l'envoi de deux flux sur 22 | cette connexion. Un flux rouge et un flux vert: 23 | 24 | ![la chaîne montrant des liens de différentes 25 | couleurs](../images/tcp-chain-streams.png) 26 | 27 | Cela devient un bloc de début de ligne basé sur TCP! 28 | 29 | À mesure que le taux de perte de paquets augmente, HTTP/2 est de moins en moins 30 | performant. Avec 2% de perte de paquets (ce qui est une qualité de réseau 31 | épouvantable, remarquez-vous bien), des tests ont montré que les utilisateurs de 32 | HTTP/1 sont généralement mieux lotis - car ils disposent généralement de six 33 | connexions TCP pour répartir le paquet perdu donc pour chaque paquet perdu, les 34 | autres connexions sans perte peuvent toujours continuer. 35 | 36 | Résoudre ce problème n’est pas facile, et si tout de même possible, à faire avec 37 | TCP. 38 | 39 | ## Les flux indépendants évitent le blocage 40 | 41 | Avec QUIC, il existe toujours une connexion configurée entre les deux terminaisons 42 | qui sécurise la connexion et la livraison des données. 43 | 44 | ![une chaîne QUIC entre deux ordinateurs](../images/tcp-chain.png) 45 | 46 | Lors de la configuration de deux flux différents sur cette connexion, ils sont 47 | traités indépendamment. Ainsi, si un lien manque à l'un des flux, seul ce flux, 48 | cette chaîne particulière, doit s'interrompre et attend que le lien manquant soit 49 | retransmis. 50 | 51 | Illustré ici avec un flux jaune et un flux bleu envoyés entre deux terminaisons. 52 | 53 | ![deux flux QUIC entre deux ordinateurs](../images/quic-chain-streams.png) 54 | -------------------------------------------------------------------------------- /en/criticism.md: -------------------------------------------------------------------------------- 1 | # Criticism 2 | 3 | ## UDP will never work 4 | 5 | A lot of enterprises, operators and organizations block or rate-limit UDP 6 | traffic outside of port 53 (used for DNS) since it has in recent days mostly 7 | been abused for attacks. In particular, some of the existing UDP protocols and 8 | popular server implementations for them have been vulnerable for amplification 9 | attacks where one attacker can make a huge amount of outgoing traffic to 10 | target innocent victims. 11 | 12 | QUIC has built-in mitigation against amplification attacks by requiring that the 13 | initial packet must be at least 1200 bytes and by restriction in the protocol 14 | that says that a server MUST NOT send more than three times the size of the 15 | request in response without receiving a packet from the client in response. 16 | 17 | ## UDP is slow in kernels 18 | 19 | This seems to be the truth, at least today in 2018. We can of course not tell 20 | how this will develop and how much of this is simply the result of UDP 21 | transfer performance not having been in developers' focus for many years. 22 | 23 | For most clients, this "slowness" is probably never even noticeable. 24 | 25 | ## QUIC takes too much CPU 26 | 27 | Similar to the "UDP is slow" remark above, this is partly because the TCP and 28 | TLS usage of the world has had a longer time to mature, improve and get 29 | hardware assistance. 30 | 31 | There are reasons to expect this to improve over time. The question is how much 32 | this extra CPU usage will hurt deployers. 33 | 34 | ## This is just Google 35 | 36 | No it is not. Google brought the initial spec to the IETF after having proved, 37 | on a large Internet-wide scale, that deploying this style of protocol over UDP 38 | actually works and performs well. 39 | 40 | Since then, individuals from a large number of companies and organizations 41 | have worked in the vendor-neutral organization IETF to put together a standard 42 | transport protocol out of it. In that work, Google employees have of course 43 | been participating, but so have employees from a large number of other 44 | companies that are interested in furthering the state of transport protocols 45 | on the Internet, including Mozilla, Fastly, Cloudflare, Akamai, Microsoft, 46 | Facebook and Apple. 47 | 48 | ## This is too small of an improvement 49 | 50 | That is not really a critique but an opinion. Maybe it is, and maybe it is too 51 | little of an improvement so close in time since HTTP/2 was shipped. 52 | 53 | HTTP/3 is likely to perform much better in packet loss-ridden networks, it 54 | offers faster handshakes so it will improve latency both as perceived and 55 | actual. But is that enough of benefits to motivate people to deploy HTTP/3 56 | support on their servers and for their services? Time and future performance 57 | measurements will surely tell! 58 | -------------------------------------------------------------------------------- /fr/why-ossification.md: -------------------------------------------------------------------------------- 1 | # Ossification 2 | 3 | Internet est un réseau de réseaux. Il y a des équipements installés sur Internet 4 | dans de nombreux endroits pour assurer le fonctionnement de ce réseau de réseaux. 5 | Ces périphériques, les boîtiers distribués sur le réseau, sont ce que nous appelons 6 | parfois des boîtiers centraux. Les zones situées quelque part entre les points 7 | terminaisons sont l'une des deux parties principales impliquées dans un transfert 8 | de données réseau traditionnel. 9 | 10 | Ces boîtes servent à de nombreuses fins spécifiques, mais je pense que nous pouvons 11 | dire qu'universellement, elles sont placées là parce que quelqu'un pense qu'elles 12 | doivent être là pour que les choses fonctionnent. 13 | 14 | Les boîtiers centraux routent les paquets IP entre les réseaux, bloquent le trafic 15 | malveillant, effectuent la traduction d'adresses réseau (en anglais Network Address 16 | Translation (NAT)), améliorent les performances, tentent parfois d'espionner le 17 | trafic en passant, etc... 18 | 19 | Afin de s'acquitter de leurs tâches, ces boîtiers doivent connaître la mise en 20 | réseau et les protocoles qu'ils surveillent ou modifient. Ils exécutent des 21 | logiciels à cette fin. Logiciels qui ne sont pas toujours mis à jour fréquemment. 22 | 23 | Bien qu'ils soient des composants essentiels qui maintiennent Internet attaché, ils 24 | ne sont pas souvent en phase avec les dernières technologies. Le milieu du réseau 25 | ne se déplace généralement pas aussi vite que les bords, comme les clients et les 26 | serveurs du monde. 27 | 28 | Tous les protocoles de réseau que ces boîtes pourraient vouloir inspecter et qui 29 | ont des idées sur ce qui est ok et ce qui ne l'est pas alors ont ce problème: ces 30 | boîtes ont été déployées il y a quelque temps, alors que les protocoles avaient un 31 | ensemble de fonctionnalités de cette époque. L'introduction de nouvelles 32 | fonctionnalités ou de changements de comportement inconnus auparavant risquerait 33 | d'être considérée comme mauvaise ou illégale par de telles boîtes. Ce trafic peut 34 | tout simplement être supprimé ou retardé dans la mesure où les utilisateurs ne 35 | souhaitent vraiment pas utiliser ces fonctionnalités. 36 | 37 | C'est ce qu'on appelle "l'ossification du protocole". 38 | 39 | Les modifications apportées au protocole TCP souffrent également d’ossification: 40 | certaines boîtes entre un client et le serveur distant détectent de nouvelles 41 | options TCP inconnues et bloquent ces connexions car ils ne savent pas quelles sont 42 | les options. S'ils sont autorisés à détecter les détails de protocole, les systèmes 43 | apprennent le comportement typique des protocoles et, avec le temps, il devient 44 | impossible de les modifier. 45 | 46 | Le seul moyen véritablement efficace de "combattre" l'ossification consiste à 47 | chiffrer le plus possible la communication afin d'empêcher les boîtes moyennes de 48 | voir beaucoup du protocole la traversant. 49 | -------------------------------------------------------------------------------- /en/quic-streams.md: -------------------------------------------------------------------------------- 1 | # Streams 2 | 3 | Streams in QUIC provide a lightweight, ordered byte-stream abstraction. 4 | 5 | There are two basic types of stream in QUIC: 6 | 7 | - Unidirectional streams carry data in one direction: from the initiator of the stream to its peer. 8 | 9 | - Bidirectional streams allow for data to be sent in both directions. 10 | 11 | Either type of stream can be created by either endpoint, can concurrently send 12 | data interleaved with other streams, and can be canceled. 13 | 14 | To send data over a QUIC connection, one or more streams are used. 15 | 16 | ## Flow control 17 | 18 | Streams are individually flow controlled, allowing an endpoint to limit memory 19 | commitment and to apply back pressure. The creation of streams is also flow 20 | controlled, with each peer declaring the maximum stream ID it is willing to 21 | accept at a given time. 22 | 23 | ## Stream Identifiers 24 | 25 | Streams are identified by an unsigned 62-bit integer, referred to as the 26 | Stream ID. The least significant two bits of the Stream ID are used to 27 | identify the type of stream (unidirectional or bidirectional) and the 28 | initiator of the stream. 29 | 30 | The least significant bit (0x1) of the Stream ID identifies the initiator of 31 | the stream. Clients initiate even-numbered streams (those with the least 32 | significant bit set to 0); servers initiate odd-numbered streams (with the bit 33 | set to 1). 34 | 35 | The second least significant bit (0x2) of the Stream ID differentiates between 36 | unidirectional streams and bidirectional streams. Unidirectional streams 37 | always have this bit set to 1 and bidirectional streams have this bit set to 38 | 0. 39 | 40 | ## Stream concurrency 41 | 42 | QUIC allows for an arbitrary number of streams to operate concurrently. An 43 | endpoint limits the number of concurrently active incoming streams by limiting 44 | the maximum stream ID. 45 | 46 | The maximum stream ID is specific to each endpoint and applies only to the 47 | peer that receives the setting. 48 | 49 | ## Sending and Receiving Data 50 | 51 | Endpoints use streams to send and receive data. That is after all their 52 | ultimate purpose. Streams are an ordered byte-stream abstraction. Separate 53 | streams are however not necessarily delivered in the original order. 54 | 55 | ## Stream Prioritization 56 | 57 | Stream multiplexing has a significant effect on application performance if 58 | resources allocated to streams are correctly prioritized. Experience with 59 | other multiplexed protocols, such as HTTP/2, shows that effective 60 | prioritization strategies have a significant positive impact on performance. 61 | 62 | QUIC itself does not provide frames for exchanging prioritization information. 63 | Instead it relies on receiving priority information from the application that 64 | uses QUIC. Protocols that use QUIC are able to define any prioritization 65 | scheme that suits their application semantics. 66 | 67 | When HTTP/3 is used over QUIC, the prioritization is done in the HTTP layer. 68 | -------------------------------------------------------------------------------- /en/proc-status.md: -------------------------------------------------------------------------------- 1 | # Status 2 | 3 | The QUIC working group has worked fiercely since late 2016 on specifying the 4 | protocols and the plan is now to have it done by July 2019. 5 | 6 | As of November 2018, there still has not been any larger interoperability 7 | tests with HTTP/3 - only with the existing two implementations and none of 8 | them are done by a browser or a popular open server software. 9 | 10 | There are fifteen or so different [QUIC implementations 11 | listed](https://github.com/curl/curl/wiki/QUIC-implementation) in the QUIC 12 | working groups' wiki pages, but far from all of them can interoperate on the 13 | latest spec draft revisions. 14 | 15 | Implementing QUIC is not easy and the protocol has kept moving and changing 16 | even up to this date. 17 | 18 | ## Servers 19 | 20 | There have been no public statement in terms of support for QUIC from Apache 21 | or nginx. 22 | 23 | ## Clients 24 | 25 | None of the larger browser vendors have yet shipped any version, at any state, 26 | that can run the IETF version of QUIC or HTTP/3. 27 | 28 | Google Chrome has shipped with a working implementation of Google's own QUIC 29 | version since many years, but that does not interoperate with the IETF 30 | QUIC protocol and its HTTP implementation is different than HTTP/3. 31 | 32 | ## Implementation Obstacles 33 | 34 | QUIC decided to use TLS 1.3 as the foundation for the crypto and security 35 | layer to avoid inventing something new and instead lean on a trustworthy and 36 | existing protocol. However, while doing this, the working group also decided 37 | that to really streamline the use of TLS in QUIC, it should only use "TLS 38 | messages" and not "TLS records" for the protocol. 39 | 40 | This might sound like an innocuous change, but this has actually caused a 41 | significant hurdle for many QUIC stack implementors. Existing TLS libraries 42 | that support TLS 1.3 simply do not have APIs enough to expose this 43 | functionality and allow QUIC to access it. While several QUIC implementors 44 | come from larger organizations who work on their own TLS stack in parallel, 45 | this is not true for everyone. 46 | 47 | The dominant open source heavyweight OpenSSL for example, does not have any 48 | API for this and has not expressed any desire to provide any such anytime soon 49 | (as of November 2018). 50 | 51 | This will eventually also lead to deployment obstacles since QUIC stacks will 52 | need to either base themselves on other TLS libraries, use a separate patched 53 | OpenSSL build or require an update to a future OpenSSL version. 54 | 55 | ## Kernels and CPU load 56 | 57 | Both Google and Facebook have mentioned that their wide scale deployments of 58 | QUIC require roughly twice the amount of CPU than the same traffic load does 59 | when serving HTTP/2 over TLS. 60 | 61 | Some explanations for this include 62 | 63 | - the UDP parts in primarily Linux is not at all as optimized as the TCP stack 64 | is, since it has not traditionally been used for high speed transfers like 65 | this. 66 | 67 | - TCP and TLS offloading to hardware exist, but that is much rarer for UDP and 68 | basically non-existing for QUIC. 69 | 70 | There are reasons to believe that performance and CPU requirements will 71 | improve over time. 72 | -------------------------------------------------------------------------------- /fr/criticism.md: -------------------------------------------------------------------------------- 1 | # Critique 2 | 3 | ## UDP ne fonctionnera jamais 4 | 5 | Beaucoup d'entreprises, d'opérateurs et d'organisations bloquent ou limitent 6 | le débit du traffic UDP en dehors du port 53 (utilisé pour DNS) depuis qu'il a 7 | été depuis ces derniers jours principalement abusé pour des attaques. En 8 | particulier, certains des protocoles UDP existants et leur implémentations 9 | populaires pour serveur ont été vulnérables aux attaques par amplification 10 | dans lesquelles un attaquant peut générer une quantité considérable de trafic 11 | sortant afin de cibler des victimes innocentes. 12 | 13 | QUIC dispose d’une atténuation intégrée contre les attaques d’amplification en 14 | exigeant que le paquet initial soit au minimum de 1200 octets et par une 15 | restriction dans le protocole qui stipule qu’un serveur NE DOIT PAS envoyer 16 | plus de trois fois ça en réponse sans recevoir un paquet du client en réponse. 17 | 18 | ## UDP est lent dans les noyaux 19 | 20 | Cela semble être la vérité, du moins aujourd'hui en 2018. Nous ne pouvons 21 | bien sûr pas dire comment cela va évoluer et à quel point cela est simplement 22 | le résultat des performances de transfert UDP qui ne sont plus au cœur des 23 | préoccupations des développeurs depuis de nombreuses années. 24 | 25 | Pour la plupart des clients, cette "lenteur" n’est probablement même jamais 26 | perceptible. 27 | 28 | ## QUIC prend trop de processeur 29 | 30 | Semblable à remarque "UDP est lent" ci-dessus, c'est en partie du fait que 31 | l'utilisation du protocole TCP et TLS dans le monde a pris plus de temps pour se 32 | développer, s'améliorer et obtenir une assistance matérielle. 33 | 34 | Il y a des raisons de s'attendre à ce que cela s'améliore avec le temps. La 35 | question est de savoir de combien et combien cette utilisation supplémentaire du 36 | processeur va faire mal aux déployeurs. 37 | 38 | ## C'est juste Google 39 | 40 | Non ça ne l'est pas. Google a communiqué les spécifications initiales à l'IETF 41 | après avoir prouvé, à grande échelle à l'échelle de l'Internet, que le 42 | déploiement de ce style de protocole sur UDP fonctionne actuellement et 43 | correctement. 44 | 45 | Depuis lors, des membres d’un grand nombre d’entreprises et d’organisations ont 46 | travaillé au sein de l’organisation indépendante du fournisseur, l’IETF, pour 47 | élaborer un protocole de transport standard. Les employés de Google y ont bien 48 | sûr participé, tout comme les employés d’un grand nombre d’autres entreprises 49 | intéressées par l’état des protocoles de transport sur Internet, notamment 50 | Mozilla, Fastly, Cloudflare, Akamai, Microsoft, Facebook et Microsoft. Apple. 51 | 52 | ## C'est une trop petite amélioration 53 | 54 | Ce n'est pas vraiment une critique mais une opinion. Peut-être est-ce le cas, et 55 | c’est peut-être une amélioration trop minime, trop proche dans le temps depuis 56 | la publication de HTTP/2. 57 | 58 | That is not really a critique but an opinion. Maybe it is, and maybe it is too 59 | little of an improvement so close in time since HTTP/2 was shipped. 60 | 61 | HTTP/3 fonctionnera probablement beaucoup mieux dans les réseaux saturés de 62 | pertes de paquets, il offre des handshakes plus rapide, ce qui améliore la 63 | latence réelle et perçue. Mais est-ce assez d'avantages pour motiver les gens à 64 | déployer la prise en charge HTTP/3 sur leurs serveurs et pour leurs services? Le 65 | temps et les mesures de performance futures nous le diront sûrement! 66 | -------------------------------------------------------------------------------- /fr/quic-streams.md: -------------------------------------------------------------------------------- 1 | # Flux 2 | 3 | Les flux dans QUIC fournissent une abstraction légère, ordonnée et ordonnée. 4 | 5 | Il existe deux types de flux de base dans QUIC: 6 | 7 | - Les flux unidirectionnels transportent des données dans un sens: de 8 | l'initiateur du flux à son homologue. 9 | 10 | - Les flux bidirectionnels permettent l'envoi de données dans les deux sens. 11 | 12 | L'un ou l'autre type de flux peut être créé par l'un ou l'autre des points de 13 | terminaison, peut simultanément envoyer des données entrelacées à d'autres flux et 14 | peut être annulé. 15 | 16 | Pour envoyer des données via une connexion QUIC, un ou plusieurs flux sont utilisés. 17 | 18 | ## Contrôle de flux 19 | 20 | Streams are individually flow controlled, allowing an endpoint to limit memory 21 | commitment and to apply back pressure. The creation of streams is also flow 22 | controlled, with each peer declaring the maximum stream ID it is willing to 23 | accept at a given time. 24 | 25 | Les flux sont contrôlés individuellement, ce qui permet à un point de terminaison 26 | de limiter l’engagement de la mémoire et d’appliquer une contre-pression. La 27 | création de flux est également contrôlée en flux, chaque pair déclarant l’ID de 28 | flux maximum qu’il est prêt à accepter à un moment donné. 29 | 30 | ## Identificateurs de flux 31 | 32 | Les flux sont identifiés par un entier non signé de 62 bits, appelé ID de flux. Les 33 | deux bits les moins significatifs de l'ID de flux sont utilisés pour identifier le 34 | type de flux (unidirectionnel ou bidirectionnel) et l'initiateur du flux. 35 | 36 | Le bit le moins significatif (0x1) de l'ID de flux identifie l'initiateur du flux. 37 | Les clients initient des flux pairs (ceux dont le bit le moins significatif est 38 | défini sur 0); les serveurs lancent des flux impairs (avec le bit mis à 1). 39 | 40 | Le deuxième bit le moins significatif (0x2) de l'ID de flux différencie les flux 41 | unidirectionnels des flux bidirectionnels. Les flux unidirectionnels ont toujours 42 | ce bit défini sur 1 et les flux bidirectionnels ont ce bit défini sur 0. 43 | 44 | ## Flux simultané 45 | 46 | QUIC permet à un nombre arbitraire de flux de fonctionner simultanément. Une 47 | terminaison limite le nombre de flux entrants actifs simultanément en limitant l'ID 48 | de flux maximal. 49 | 50 | L'ID de flux maximal est spécifique à chaque terminaison et s'applique uniquement à 51 | l'homologue qui reçoit le paramètre. 52 | 53 | ## Envoi et réception de données 54 | 55 | Les terminaisons utilisent des flux pour envoyer et recevoir des données. C'est 56 | après tout leur but ultime. Les flux sont une abstraction ordonnée de flux 57 | d'octets. Les flux séparés ne sont toutefois pas nécessairement livrés dans l'ordre 58 | d'origine. 59 | 60 | ## Priorité des flux 61 | 62 | Le multiplexage de flux a un effet significatif sur les performances des 63 | applications si les ressources allouées aux flux sont correctement hiérarchisées. 64 | L'expérience acquise avec d'autres protocoles multiplexés, tels que HTTP/2, montre 65 | que des stratégies efficaces de hiérarchisation ont un impact positif significatif 66 | sur les performances. 67 | 68 | QUIC lui-même ne fournit pas de frames pour l'échange d'informations sur la 69 | priorisation. Au lieu de cela, il repose sur la réception d'informations de 70 | priorité de l'application qui utilise QUIC. Les protocoles qui utilisent QUIC 71 | peuvent définir n’importe quel schéma de priorisation adapté à la sémantique de 72 | leurs applications. 73 | 74 | Lorsque HTTP/3 est utilisé sur QUIC, la hiérarchisation est effectuée dans la 75 | couche HTTP. 76 | -------------------------------------------------------------------------------- /fr/proc-status.md: -------------------------------------------------------------------------------- 1 | # Statut 2 | 3 | Le groupe de travail de QUIC a travaillé d'arrache-pied depuis fin 2016 pour 4 | spécifier les protocoles et le plan est maintenant de le faire d'ici juillet 2019. 5 | 6 | En novembre 2018, il n'y avait toujours pas de tests d'interopérabilité plus grands 7 | avec HTTP/3 - uniquement avec les deux implémentations existantes et aucun d'entre 8 | eux n'est effectué par un navigateur ou un logiciel populaire de serveur ouvert. 9 | 10 | Il y a une quinzaine de [différentes implémentations de QUIC 11 | répertoriées](https://github.com/curl/curl/wiki/QUIC-implementation) dans les pages 12 | de wiki des groupes de travail de QUIC, mais toutes ne peuvent pas interagir sur 13 | les dernières revisions des spécifications. 14 | 15 | L'implémentation de QUIC n'est pas facile et le protocole a continué à évoluer, 16 | même à cette date. 17 | 18 | ## Les serveurs 19 | 20 | Il n'y a eu aucune déclaration publique en termes de soutien à QUIC d'Apache ou de 21 | nginx. 22 | 23 | ## Les clients 24 | 25 | Aucun des plus gros éditeurs de navigateurs n’a encore fourni de version, quel que 26 | soit son état, pouvant exécuter la version IETF de QUIC ou de HTTP/3. 27 | 28 | Google Chrome est livré avec une implémentation fonctionnelle de la version QUIC de 29 | Google depuis de nombreuses années, mais cela n'interagit pas avec le protocole 30 | QUIC officiel et son implémentation HTTP est différente de HTTP/3. 31 | 32 | ## Obstacles d'Implémentation 33 | 34 | QUIC a décidé d'utiliser TLS 1.3 comme base pour la couche de chiffrement et de 35 | sécurité pour éviter d'inventer quelque chose de nouveau et plutôt s'appuyer sur un 36 | protocole fiable et existant. Cependant, ce faisant, le groupe de travail a 37 | également décidé que, pour rationaliser réellement l'utilisation de TLS dans QUIC, 38 | il ne devrait utiliser que des "messages TLS" et non des "enregistrements TLS" pour 39 | le protocole. 40 | 41 | Cela peut sembler être un changement anodin, mais cela a en fait créé un obstacle 42 | considérable pour de nombreux développeurs de stack QUIC. Les bibliothèques TLS 43 | existantes qui prennent en charge TLS 1.3 n'ont tout simplement pas assez d'API 44 | pour exposer cette fonctionnalité et permettre à QUIC d'y accéder. Bien que 45 | plusieurs développeurs QUIC proviennent de grandes organisations qui travaillent 46 | sur leur propre stack TLS en parallèle, cela n’est pas vrai pour tout le monde. 47 | 48 | OpenSSL, le poids lourd open source dominant, par exemple, n’a pas d’API et n’a 49 | manifesté aucun désir de la fournir dans les meilleurs délais (à partir de novembre 50 | 2018). 51 | 52 | Cela entraînera éventuellement des obstacles de déploiement puisque les stacks QUIC 53 | devront se baser sur d'autres bibliothèques TLS, utiliser une version OpenSSL 54 | corrigée ou nécessiter une mise à jour d'une version future d'OpenSSL. 55 | 56 | ## Noyaux et charge du processeur 57 | 58 | Google et Facebook ont tous deux mentionné que leurs déploiements à grande échelle 59 | de QUIC requièrent environ deux fois plus de ressources processeur que la même 60 | charge de trafic lorsque HTTP/2 est utilisé via TLS. 61 | 62 | Quelques explications à cela incluent 63 | 64 | - Les composants UDP, principalement sous Linux, ne sont pas du tout aussi optimisés 65 | que la stack TCP, car elle n’a pas été utilisée traditionnellement pour des 66 | transferts à grande vitesse comme celui-ci. 67 | 68 | - Le déchargement TCP et TLS sur le matériel existe, mais cela est beaucoup plus 69 | rare pour UDP et pratiquement inexistant pour QUIC. 70 | 71 | Il y a des raisons de croire que les performances et les exigences en matière de 72 | processeur s'amélioreront avec le temps. 73 | -------------------------------------------------------------------------------- /fr/why-tcpudp.md: -------------------------------------------------------------------------------- 1 | ## TCP ou UDP 2 | 3 | Si nous ne pouvons pas résoudre le blocage de la tête de ligne dans TCP, nous 4 | devrions théoriquement pouvoir créer un nouveau protocole de transport à côté de 5 | UDP et TCP dans la stack réseau. Ou peut-être même utilisez-vous 6 | [SCTP](https://en.wikipedia.org/wiki/Stream_Control_Transmission_Protocol) qui est 7 | un protocole de transport normalisé par l'IETF dans la [RFC 8 | 4960](https://tools.ietf.org/html/rfc4960) avec plusieurs des caractéristiques 9 | souhaitées. 10 | 11 | Cependant, au cours des dernières années, les efforts pour créer de nouveaux 12 | protocoles de transport ont été presque complètement arrêtés en raison de la 13 | difficulté de les déployer sur Internet. Le déploiement de nouveaux protocoles est 14 | entravé par de nombreux pare-feu, NATs, routeurs et autres boîtes centrales qui 15 | autorisent uniquement le protocole TCP ou UDP sont déployés entre les utilisateurs 16 | et les serveurs qu’ils doivent atteindre. L'introduction d'un autre protocole de 17 | transport provoque l'échec de N% des connexions car elles sont bloquées par des 18 | boîtes ne la voyant pas comme étant UDP ou TCP et donc malfaisantes ou erronés 19 | d'une manière ou d'une autre. Le taux d'échec de N% est souvent jugé trop élevé 20 | pour en valoir la peine. 21 | 22 | Additionally, changing things in the transport protocol layer of the network 23 | stack typically means protocols implemented by operating system kernels. 24 | Updating and deploying new operating system kernels is a slow process that 25 | requires significant effort. Many TCP improvements standardized by the IETF 26 | are not widely deployed or used because they are not broadly supported. 27 | 28 | De plus, les modifications apportées à la couche de protocole de transport de la 29 | stack réseau impliquent généralement des protocoles implémentés par les noyaux de 30 | système d'exploitation. La mise à jour et le déploiement de nouveaux noyaux de 31 | système d'exploitation est un processus lent qui nécessite des efforts importants. 32 | De nombreuses améliorations TCP normalisées par l'IETF ne sont pas beaucoup 33 | déployées ou utilisées car elles ne sont pas énormément prises en charge. 34 | 35 | ## Pourquoi pas SCTP sur UDP 36 | 37 | SCTP is a reliable transport protocol with streams, and for WebRTC there are 38 | even existing implementations using it over UDP. 39 | 40 | This was not deemed good enough as a QUIC alternative due to several reasons, 41 | including: 42 | 43 | - SCTP does not fix the head-of-line-blocking problem for streams 44 | - SCTP requires the number of streams to be decided at connection setup 45 | - SCTP does not have a solid TLS/security story 46 | - SCTP has a 4-way handshake, QUIC offers 0-RTT 47 | - QUIC is a bytestream like TCP, SCTP is message-based 48 | - QUIC connections can migrate between IP addresses but SCTP cannot 49 | 50 | SCTP est un protocole de transport fiable avec des flux, et pour WebRTC, il existe 51 | même des implémentations existantes qui l'utilisent via UDP. 52 | 53 | Cela n’a pas été jugé suffisant comme alternative à QUIC pour plusieurs raisons, 54 | notamment: 55 | 56 | - SCTP ne résout pas le problème de blocage de tête de ligne pour les flux 57 | - SCTP exige que le nombre de flux soit déterminé lors de l'établissement de la 58 | connexion 59 | - SCTP n'a pas un solide concept TLS/de sécurité 60 | - SCTP a un handshake à 4 voies, QUIC offre 0-RTT 61 | - QUIC est un flux par octet comme TCP, SCTP est basé sur des messages 62 | - Les connexions QUIC peuvent migrer entre les adresses IP, mais SCTP ne peut pas 63 | 64 | Pour plus de détails sur les différences, voir [A Comparison between SCTP and 65 | QUIC](https://tools.ietf.org/html/draft-joseph-quic-comparison-quic-sctp-00). 66 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Attribution 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More_considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution 4.0 International Public License 58 | 59 | By exercising the Licensed Rights (defined below), You accept and agree 60 | to be bound by the terms and conditions of this Creative Commons 61 | Attribution 4.0 International Public License ("Public License"). To the 62 | extent this Public License may be interpreted as a contract, You are 63 | granted the Licensed Rights in consideration of Your acceptance of 64 | these terms and conditions, and the Licensor grants You such rights in 65 | consideration of benefits the Licensor receives from making the 66 | Licensed Material available under these terms and conditions. 67 | 68 | 69 | Section 1 -- Definitions. 70 | 71 | a. Adapted Material means material subject to Copyright and Similar 72 | Rights that is derived from or based upon the Licensed Material 73 | and in which the Licensed Material is translated, altered, 74 | arranged, transformed, or otherwise modified in a manner requiring 75 | permission under the Copyright and Similar Rights held by the 76 | Licensor. For purposes of this Public License, where the Licensed 77 | Material is a musical work, performance, or sound recording, 78 | Adapted Material is always produced where the Licensed Material is 79 | synched in timed relation with a moving image. 80 | 81 | b. Adapter's License means the license You apply to Your Copyright 82 | and Similar Rights in Your contributions to Adapted Material in 83 | accordance with the terms and conditions of this Public License. 84 | 85 | c. Copyright and Similar Rights means copyright and/or similar rights 86 | closely related to copyright including, without limitation, 87 | performance, broadcast, sound recording, and Sui Generis Database 88 | Rights, without regard to how the rights are labeled or 89 | categorized. For purposes of this Public License, the rights 90 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 91 | Rights. 92 | 93 | d. Effective Technological Measures means those measures that, in the 94 | absence of proper authority, may not be circumvented under laws 95 | fulfilling obligations under Article 11 of the WIPO Copyright 96 | Treaty adopted on December 20, 1996, and/or similar international 97 | agreements. 98 | 99 | e. Exceptions and Limitations means fair use, fair dealing, and/or 100 | any other exception or limitation to Copyright and Similar Rights 101 | that applies to Your use of the Licensed Material. 102 | 103 | f. Licensed Material means the artistic or literary work, database, 104 | or other material to which the Licensor applied this Public 105 | License. 106 | 107 | g. Licensed Rights means the rights granted to You subject to the 108 | terms and conditions of this Public License, which are limited to 109 | all Copyright and Similar Rights that apply to Your use of the 110 | Licensed Material and that the Licensor has authority to license. 111 | 112 | h. Licensor means the individual(s) or entity(ies) granting rights 113 | under this Public License. 114 | 115 | i. Share means to provide material to the public by any means or 116 | process that requires permission under the Licensed Rights, such 117 | as reproduction, public display, public performance, distribution, 118 | dissemination, communication, or importation, and to make material 119 | available to the public including in ways that members of the 120 | public may access the material from a place and at a time 121 | individually chosen by them. 122 | 123 | j. Sui Generis Database Rights means rights other than copyright 124 | resulting from Directive 96/9/EC of the European Parliament and of 125 | the Council of 11 March 1996 on the legal protection of databases, 126 | as amended and/or succeeded, as well as other essentially 127 | equivalent rights anywhere in the world. 128 | 129 | k. You means the individual or entity exercising the Licensed Rights 130 | under this Public License. Your has a corresponding meaning. 131 | 132 | 133 | Section 2 -- Scope. 134 | 135 | a. License grant. 136 | 137 | 1. Subject to the terms and conditions of this Public License, 138 | the Licensor hereby grants You a worldwide, royalty-free, 139 | non-sublicensable, non-exclusive, irrevocable license to 140 | exercise the Licensed Rights in the Licensed Material to: 141 | 142 | a. reproduce and Share the Licensed Material, in whole or 143 | in part; and 144 | 145 | b. produce, reproduce, and Share Adapted Material. 146 | 147 | 2. Exceptions and Limitations. For the avoidance of doubt, where 148 | Exceptions and Limitations apply to Your use, this Public 149 | License does not apply, and You do not need to comply with 150 | its terms and conditions. 151 | 152 | 3. Term. The term of this Public License is specified in Section 153 | 6(a). 154 | 155 | 4. Media and formats; technical modifications allowed. The 156 | Licensor authorizes You to exercise the Licensed Rights in 157 | all media and formats whether now known or hereafter created, 158 | and to make technical modifications necessary to do so. The 159 | Licensor waives and/or agrees not to assert any right or 160 | authority to forbid You from making technical modifications 161 | necessary to exercise the Licensed Rights, including 162 | technical modifications necessary to circumvent Effective 163 | Technological Measures. For purposes of this Public License, 164 | simply making modifications authorized by this Section 2(a) 165 | (4) never produces Adapted Material. 166 | 167 | 5. Downstream recipients. 168 | 169 | a. Offer from the Licensor -- Licensed Material. Every 170 | recipient of the Licensed Material automatically 171 | receives an offer from the Licensor to exercise the 172 | Licensed Rights under the terms and conditions of this 173 | Public License. 174 | 175 | b. No downstream restrictions. You may not offer or impose 176 | any additional or different terms or conditions on, or 177 | apply any Effective Technological Measures to, the 178 | Licensed Material if doing so restricts exercise of the 179 | Licensed Rights by any recipient of the Licensed 180 | Material. 181 | 182 | 6. No endorsement. Nothing in this Public License constitutes or 183 | may be construed as permission to assert or imply that You 184 | are, or that Your use of the Licensed Material is, connected 185 | with, or sponsored, endorsed, or granted official status by, 186 | the Licensor or others designated to receive attribution as 187 | provided in Section 3(a)(1)(A)(i). 188 | 189 | b. Other rights. 190 | 191 | 1. Moral rights, such as the right of integrity, are not 192 | licensed under this Public License, nor are publicity, 193 | privacy, and/or other similar personality rights; however, to 194 | the extent possible, the Licensor waives and/or agrees not to 195 | assert any such rights held by the Licensor to the limited 196 | extent necessary to allow You to exercise the Licensed 197 | Rights, but not otherwise. 198 | 199 | 2. Patent and trademark rights are not licensed under this 200 | Public License. 201 | 202 | 3. To the extent possible, the Licensor waives any right to 203 | collect royalties from You for the exercise of the Licensed 204 | Rights, whether directly or through a collecting society 205 | under any voluntary or waivable statutory or compulsory 206 | licensing scheme. In all other cases the Licensor expressly 207 | reserves any right to collect such royalties. 208 | 209 | 210 | Section 3 -- License Conditions. 211 | 212 | Your exercise of the Licensed Rights is expressly made subject to the 213 | following conditions. 214 | 215 | a. Attribution. 216 | 217 | 1. If You Share the Licensed Material (including in modified 218 | form), You must: 219 | 220 | a. retain the following if it is supplied by the Licensor 221 | with the Licensed Material: 222 | 223 | i. identification of the creator(s) of the Licensed 224 | Material and any others designated to receive 225 | attribution, in any reasonable manner requested by 226 | the Licensor (including by pseudonym if 227 | designated); 228 | 229 | ii. a copyright notice; 230 | 231 | iii. a notice that refers to this Public License; 232 | 233 | iv. a notice that refers to the disclaimer of 234 | warranties; 235 | 236 | v. a URI or hyperlink to the Licensed Material to the 237 | extent reasonably practicable; 238 | 239 | b. indicate if You modified the Licensed Material and 240 | retain an indication of any previous modifications; and 241 | 242 | c. indicate the Licensed Material is licensed under this 243 | Public License, and include the text of, or the URI or 244 | hyperlink to, this Public License. 245 | 246 | 2. You may satisfy the conditions in Section 3(a)(1) in any 247 | reasonable manner based on the medium, means, and context in 248 | which You Share the Licensed Material. For example, it may be 249 | reasonable to satisfy the conditions by providing a URI or 250 | hyperlink to a resource that includes the required 251 | information. 252 | 253 | 3. If requested by the Licensor, You must remove any of the 254 | information required by Section 3(a)(1)(A) to the extent 255 | reasonably practicable. 256 | 257 | 4. If You Share Adapted Material You produce, the Adapter's 258 | License You apply must not prevent recipients of the Adapted 259 | Material from complying with this Public License. 260 | 261 | 262 | Section 4 -- Sui Generis Database Rights. 263 | 264 | Where the Licensed Rights include Sui Generis Database Rights that 265 | apply to Your use of the Licensed Material: 266 | 267 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 268 | to extract, reuse, reproduce, and Share all or a substantial 269 | portion of the contents of the database; 270 | 271 | b. if You include all or a substantial portion of the database 272 | contents in a database in which You have Sui Generis Database 273 | Rights, then the database in which You have Sui Generis Database 274 | Rights (but not its individual contents) is Adapted Material; and 275 | 276 | c. You must comply with the conditions in Section 3(a) if You Share 277 | all or a substantial portion of the contents of the database. 278 | 279 | For the avoidance of doubt, this Section 4 supplements and does not 280 | replace Your obligations under this Public License where the Licensed 281 | Rights include other Copyright and Similar Rights. 282 | 283 | 284 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 285 | 286 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 287 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 288 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 289 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 290 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 291 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 292 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 293 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 294 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 295 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 296 | 297 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 298 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 299 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 300 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 301 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 302 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 303 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 304 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 305 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 306 | 307 | c. The disclaimer of warranties and limitation of liability provided 308 | above shall be interpreted in a manner that, to the extent 309 | possible, most closely approximates an absolute disclaimer and 310 | waiver of all liability. 311 | 312 | 313 | Section 6 -- Term and Termination. 314 | 315 | a. This Public License applies for the term of the Copyright and 316 | Similar Rights licensed here. However, if You fail to comply with 317 | this Public License, then Your rights under this Public License 318 | terminate automatically. 319 | 320 | b. Where Your right to use the Licensed Material has terminated under 321 | Section 6(a), it reinstates: 322 | 323 | 1. automatically as of the date the violation is cured, provided 324 | it is cured within 30 days of Your discovery of the 325 | violation; or 326 | 327 | 2. upon express reinstatement by the Licensor. 328 | 329 | For the avoidance of doubt, this Section 6(b) does not affect any 330 | right the Licensor may have to seek remedies for Your violations 331 | of this Public License. 332 | 333 | c. For the avoidance of doubt, the Licensor may also offer the 334 | Licensed Material under separate terms or conditions or stop 335 | distributing the Licensed Material at any time; however, doing so 336 | will not terminate this Public License. 337 | 338 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 339 | License. 340 | 341 | 342 | Section 7 -- Other Terms and Conditions. 343 | 344 | a. The Licensor shall not be bound by any additional or different 345 | terms or conditions communicated by You unless expressly agreed. 346 | 347 | b. Any arrangements, understandings, or agreements regarding the 348 | Licensed Material not stated herein are separate from and 349 | independent of the terms and conditions of this Public License. 350 | 351 | 352 | Section 8 -- Interpretation. 353 | 354 | a. For the avoidance of doubt, this Public License does not, and 355 | shall not be interpreted to, reduce, limit, restrict, or impose 356 | conditions on any use of the Licensed Material that could lawfully 357 | be made without permission under this Public License. 358 | 359 | b. To the extent possible, if any provision of this Public License is 360 | deemed unenforceable, it shall be automatically reformed to the 361 | minimum extent necessary to make it enforceable. If the provision 362 | cannot be reformed, it shall be severed from this Public License 363 | without affecting the enforceability of the remaining terms and 364 | conditions. 365 | 366 | c. No term or condition of this Public License will be waived and no 367 | failure to comply consented to unless expressly agreed to by the 368 | Licensor. 369 | 370 | d. Nothing in this Public License constitutes or may be interpreted 371 | as a limitation upon, or waiver of, any privileges and immunities 372 | that apply to the Licensor or You, including from the legal 373 | processes of any jurisdiction or authority. 374 | 375 | 376 | ======================================================================= 377 | 378 | Creative Commons is not a party to its public 379 | licenses. Notwithstanding, Creative Commons may elect to apply one of 380 | its public licenses to material it publishes and in those instances 381 | will be considered the “Licensor.” The text of the Creative Commons 382 | public licenses is dedicated to the public domain under the CC0 Public 383 | Domain Dedication. Except for the limited purpose of indicating that 384 | material is shared under a Creative Commons public license or as 385 | otherwise permitted by the Creative Commons policies published at 386 | creativecommons.org/policies, Creative Commons does not authorize the 387 | use of the trademark "Creative Commons" or any other trademark or logo 388 | of Creative Commons without its prior written consent including, 389 | without limitation, in connection with any unauthorized modifications 390 | to any of its public licenses or any other arrangements, 391 | understandings, or agreements concerning use of licensed material. For 392 | the avoidance of doubt, this paragraph does not form part of the 393 | public licenses. 394 | 395 | Creative Commons may be contacted at creativecommons.org. 396 | 397 | --------------------------------------------------------------------------------