QUIC の RFC ドラフトがリリースされた

QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2
https://tools.ietf.org/html/draft-tsvwg-quic-protocol-00

QUIC は Google が開発したネットワークトランスポートプロトコルで UDP 上で動作するプロトコルです。

詳細については Wikipedia を読んで貰ったり大津さんの記事を読んでください。

Googleが仕掛ける新プロトコルQUICとは何か
http://d.hatena.ne.jp/jovi0608/20130227/1361975933

とても詳しくまとまっているので、読めばわかるんですがもっと実装者側の視点に立って考えてみることにします。

最近は通信経路を暗号化するのが前提になってきています。ほとんどの場合で TLS over TCP を使っているのではないでしょうか。ただこれって効率はそんなにイイとは言えないんですよね。

TCP を貼った後に TLS で再度トンネルを作ってるわけですから。で、そのうえに HTTP/2 やら MQTT を通しているわけです。

QUIC はこの TCP + TLS を一緒くたにしたトランスポートプロトコルです。ただ独自に TCP 作り直すわけではなく、UDP 上で動くようにしました。

UDP 上でというのは別に珍しい話でではなく、WebRTC のデータチャネルも SCTP を UDP (DTLS) 上で動かしています。

QUIC は SCTP over DTLS over UDP と似ています。細かいことを上げれば違いはキリ無いのですが、 SCTP over DTLS over UDP と QUIC over UDP は何となく似ていると思って良いと思います。

実際世の中では HTTP/2 over TLS over TCP が巨人達が推し進めているためこっそりこっそりと広まっています。

QUIC は HTTP/2 over QUIC over UDP です。つまりアプリケーション側から見たら HTTP/2 なので、あまり意識する必要はありません。もちろん、クライアントがあればですが。

ただ libquic みたいに他の言語で気軽に使えるバインディングは一定時間経てば出てくると思います。というか Google はソースコード自体は公開しています。

https://code.google.com/p/chromium/codesearch#chromium/src/net/quic/

そう考えるとアプリケーションから見るとただの HTTP/2 なんですよね。

プロトコル自体はとても難解ですし、複雑です。でもまぁ TLS + TCP を 1 から実装すると考えればそんなもんだろうと思ってしまいます。さらに 1 コネクションで複数セッション、フロー制御など HTTP/2 のいいところもごっそり持って行かれています。

これ HTTP/2 いらないんじゃないか？とおもったら HTTP/2 に詳しい方からコメント貰いました。

開発者側の立場的にはツラいんですが、まぁメタルキングだと思って頑張って倒そうと思います（勉強になるし）。

利用者側は普通にクライアントやサーバライブラリ側で隠蔽されればただの「早くて安全な通信経路」でしかないのでいいことは多そうです。

とりあえず RFC ドラフトと暗号化部分から勉強していく予定です。