「HTTPの高速化に関わる仕組み」でHTTP/2までの高速化についてまとめてみたのですが、QUICについても書いておこうと思います。QUIC（Quick Udp Internet Connectionsのこと、クイックと読みます）はGoogleが開発したプロトコルでHTTP通信をUDP上で行うものです。UDPはTCPと違い通信の信頼性を保証しないためTCPが持つ機能の一部（再送制御など）をQUICが担います。また暗号化に関わる機能もQUICは持っています。
そもそもGoogleがTCPではなくUDP上でHTTP通信をやろうと思った理由の1つに、TCP/TLSの接続時のオーバーヘッドを抑えることで更なる高速化が期待できると考えたからだと思います。TCPの接続時のコネクション確立には3ウェイハンドシェイクで3回のやりとり、TLSでのネゴシエーションでは7回のやりとりが行われたあとにデータ送信が始まります。
これがQUICの場合だとクライアントとサーバー間を1往復するだけでデータ送信が開始できます。接続のやりとりが1往復のみなので「1-RTT」と呼ばれています（RTTはラウンドトリップタイム、往復時間という意味です）。
2回目以降のデータ送信については②で得たトークンを使い、いきなりデータをサーバーに送ります。接続時のやりとりがないため「0-RTT」と呼ばれています。
なお、③、④のデータは暗号化されています。
UDPを使うもう一つのメリットは、ヘッドオブラインブロッキング（※）がTCPに比べ緩和されることではないでしょうか。HTTP/2でも非同期通信ができますので前のリクエストを待たずに後続のリクエストを送ることができるわけですが、パケットをロストした場合においてはTCPは再送制御が働き、後続のリクエストに「待ち」が発生します。QUICはこの再送制御を独自で実装しているためTCPに比べ効率的な方法で（もしくは「待ち」が発生しない方法で）ヘッドオブラインブロッキングを取り除いているのではないかと思います。
（※）ヘッドオブラインブロッキング・・・前のリクエストが処理されるまで次のリクエストが待たされてしまう（ブロックされてしまう）ことをいいます。
他にもQUICの利点はあるのかもしれませんが、ここでは接続時のオーバヘッドとヘッドオブラインブロッキングについて書いてみました。なお、QUICは今後TLS1.3と同等の機能を持つ（TLS1.3の仕様を取り込み同様の機能を持つ）ことになるようです。
■2019年2月24日 「HTTP/3」について追記
2015年6月にGoogleがIETFにQUICのドラフトを提出し、2016年末にIETFの中でワーキンググループが設置され標準化の検討が始まりました。
上に書いていたことは、Googleが開発を行ったときにQUICをWeb利用のものとして考えていたものです。IETFの標準化の中ではWeb利用に限らないトランスポート層のプロトコルとしてQUICを位置づけています。IETFではQUICを利用するHTTPを「HTTP over QUIC」と呼んでいたのですが、2018年の11月に「HTTP/3」という名称で呼ぶことにかえました。
GoogleもIETFの標準化作業がまとまればそれを踏襲する意思を示しています。IETFでは2019年7月にQUICの標準化仕様の公開を予定しているようです。
■2022年7月14日 「HTTP/3」について追記
2022年6月にIETFはHTTP/3を正式に勧告しました。これにより今後は脱TCPの流れになっていくかもしれません。なお、2022年6月時点でHTTP/3に対応しているWEBサイトは全体の25%程度とのことです。
