1. Qiita
  2. 投稿
  3. http2

http2/quic meetup メモ

  • 7
    いいね
  • 0
    コメント
この記事は最終更新日から1年以上が経過しています。

meetup行ってきたのでメモ。
殴り書きなので、自分で理解しきれていないところもある。

前田さんのTwitterからかなり引用させてもらってます。
https://twitter.com/mad_p

QUIC (Jana Iyengar)

UDPでHTTP2と同じことを実現する。
HTTP/2のプロトコル部分を置き換え、セマンティスクスはそのまま。
常時暗号化、0-RTT/1-RTT、コネクションの輻輳制御、セッションのフローコントロール、CPU最適化などがある。
http://src.chromium.org/viewvc/chrome?revision=162259&view=revision

http2 (Mark Nottingham)

https://http2.github.io

apacheもnginxも対応しつつある。
Service Workerでプライオリティーヒントをリクエストごとにサーバーに送ることができるかもしれない。

プライオリティについてはsummerwindさんのこのスランドが素晴らしい。
http://sssslide.com/speakerdeck.com/summerwind/2-prioritization

HTTP2へのOriginフレームの追加
http://d.hatena.ne.jp/ASnoKaze/20151029/1446136493

接続をオリジンにまたがって同じconnectionに相乗りすることを考えている。サーバーからこのconnectionでこのoriginを送りたくないという表現もできるように。

HTTP/2の後継としては多くの拡張が考えられている。

HTTPヘッダのJSON表現
https://tools.ietf.org/html/draft-reschke-http-jfv-00
https://github.com/HTTPWorkshop/workshop/blob/gh-pages/presentations/reschke-headers/index.html

encrypted content-encodingヘッダの追加。

Blind caching
中身を見ないでもキャッシュを共有する方法。

webpush (Martin Thomson)

https://datatracker.ietf.org/wg/webpush/documents/

webpushはサイトを閲覧していない時に送る4K程度のメッセージ。
通常はemailやchatの通知に使われる。「更新があります」「パケットが届きました」など。

GCM, APNS, WNS…、これらの標準化がAPI(W3C)、プロトコル(IETF)で検討されている。

100人以上の人が同時に同じことをしようとしても、単にバッテリーを使うだけ。3つのアプリで2時間分のバッテリーを食うことになってしまう。2分間だけネットに接続してまたスリープみたいなことをやりたい。

overview: app内のブラウザがsubscriptionをapplication serverに送る。app serverはpush messageをpush serviceに送る。service workersがウインドウなしに処理

UAからPush serviceにHTTP/2のGETを送る。これは何も返事を期待しないが、これによってpush serverがPUSH PROMISEフレームを送れるようになる。このstreamはロングポーリングの空リクエストと同様の働きをする。

CSoWLDqVEAAzRrI.jpg-large.jpg
PUTはPOSTの間違い。

Let's Encrypt (Richard Barnes)

無料でSSL証明書を使用できる仕組み。
https://letsencrypt.org

無料。自動。透明、オープン、協力的

ACME(アクメ) Automated Certificate Management Environment
自動で証明書を更新する仕組み。

domain validationはチャレンジを送り、DNSにそのチャレンジに対応したレコードを入れることで行う。正しいドメインオーナーだけがDNSを変更できることを利用。

Acmeではauthorizationの申請から、チャレンジの取得、検証まで全部を仕様化。このループには人が介在しない。標準化によってツール化することができる

TLS1.3 (EKR)

圧縮(サイドチャネル攻撃(CRIMEとか)に耐えるものが必要。HTTP/2でHPACKを作ったのも同じ理由)。
TLS 1.3 1-RTTハンドシェーク。これが初めて話す相手との基本的なフローになる。最初のメッセージでDH shareをいくつかの(固定の?)群上で送る。サーバーからはサーバー設定とサーバーkey shareを返す。
サーバーがpassiveになることで攻撃に強くなる。
初のサーバーからの通信でいきなりアプリケーションデータを送ってしまえる。これは最初のパケットに相乗りしてすぐに届く。HTTP/2のSETTINGSフレームやPUSH PROMISEをここで送ってしまえる。
WGはいつでもclient authを要求できる仕様を検討中。
https://tools.ietf.org/html/draft-ietf-tls-tls13-10

cache aware server push (kazuho oku)

h2o v1.5
http://blog.kazuhooku.com/2015/09/h2o-version-150-released.html?m=1

ブラウザがリソースを保持しているかどうかをクッキーで判断する。
それによってHTTP2のサーバープッシュを積極的に使えるようになるという話。
mnotが興味を示していたので、これは本格的に採用されそう。

サーバープッシュが難しいことについては、rebuild.fmのエピソード99参照。
http://rebuild.fm/99/

雑感

QUICのサンプル実装をやってみたい。
時間を見つけてService Workerとhttp2のウェブプッシュを試してみたい。
h2oのクッキーも。

隣にMark Nottinghamが座っていて少し緊張した。