HTTP のプライオリティが大きく変わろうとしている話（その他 IETF 105 雑感）
先週、モントリオールで開催された IETF 105 に参加してきました。 いろんなことがあったのですが、個人的に一番大きかったのは、HTTP/3 からプライオリティ（優先度制御）まわりの仕様を落とすことが決定したこと。 HTTP/3 は、トランスポートプロトコルである QUIC の上で動作する、次世代の HTTP プロトコルです。その設計は、QUIC ワーキングググループが、HTTP ワーキンググループから委託され、HTTP/2 の機能を移植する、という形式を取っています。 ところが、５月にロンドンで開催された QUIC ワーキンググループの中間会議で、一部参加者から HTTP/3 の優先度制御に対する不満が表明されたのです注1。それを受けて、QUIC ワーキンググループでは、HTTP/3 の優先度制御にあった HTTP/2 のそれとの差異を少なくする作業を進める一方、HTTP ワーキング
QUICハンドシェイクの再設計、もしくはTLSレイヤの終焉
先週スウェーデンのKistaで開催された第５回QUIC Interimで、ハンドシェイクプロトコルの再設計案の採用が決まりました。 提案者として、その背景にある考え方を整理したいと思います。 ▪️提案内容 詳しくはDesign Docを見てもらえばいいとして、ざっくりいうと、TLSスタックをふたつに分割し パケットはQUICがレイアウトしたバイト列をTLSスタックが提供するAPIを使って暗号化注1して生成 ハンドシェイクメッセージについては、平文のメッセージをTLSスタックとQUICスタックとの間で交換し、QUICスタック側で上記手法によるパケット化暗号化を行う というものです。 これにより、たとえばサーバがハンドシェイク時に送出するパケットの構造は以下のようにかわります。 図1. 従来方式 図2. 新方式 赤は難読化（つまり正当なパケットと攻撃との区別がつかない）、黄は未認証の暗号化（通
CI 用 Docker イメージ作成におけるベストプラクティス
H2O の CI では長らく、秘伝のタレ的な .travis.yml を使い続けてきたのですが、なにぶん依存関係が多いもので、だいぶメンテナンスが辛い感じになってきていました。また、CI テストで発生したエラーの調査の度に、時間のかかる CI を回さなければならないことが、開発者のストレスとなっていました。 そこで一念発起して、Docker イメージを使った CI に切り替えることにしました（実行環境としては引き続き Travis を使います）。 その際に、要件として以下のようなことを考えました。 CI以外に、コミット前のテストにも使えるようなイメージにすること コマンド一発でビルドとテストが動作すること 無駄な処理をしないこと その結果、以下のような実装になりました。 テストに必要なソフトウェア群をインストールしたイメージを Docker Hub にアップロードしておく テストには、1.
なぜ今、新しいHTTPサーバが必要なのか - H2O について勉強会で話したこと
先月末の話になりますが、SAPジャパンさんを会場に開催されたデータ転送ミドルウェア勉強会で、私が中心になって開発しているHTTPサーバ「H2O」について話す機会をいただき、登壇してきました。 以下は当日使用したスライドです。なぜ今H2Oを開発しているのか、その背景にある現状認識と将来の方針について、日本語で説明してあるので、興味ある方はご覧ください。 発表の機会をくださった@repeatedlyさんと@frsyukiさん、会場を提供してくださったSAPジャパンさん、ありがとうございました。 H2Oの開発は順調に進んでおり、HTTP/2サーバプッシュへの対応も完了し、まもなく次のバージョンがリリースできるかと思います。今後ともよろしくお願いいたします。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
