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 ワーキング
Erlang & Elixir Fest 2019
「Erlang/OTP で WebRTC と QUIC」という内容で話をします。 発表者向け資料はこちらで準備中です。 以下は発表者向け資料を書くために適当に書き出した文章です。 自分は Erlang/OTP は長く使っていて、その使いみちの大半がクローズドソースなパッケージ製品の開発です。自分の会社を持ってからは、 Erlang/OTP で開発したパッケージ製品だけで会社が回る所まで来ています。 零細企業のクローズドソースのパッケージ製品の話ってあまり聞いたことがないので、では自社製品をどうやって開発してるのか、どんな感じで実装されているのかなどをお話しようと決めました。 自社製品である WebRTC SFU Sora という製品は P2P での利用を想定している WebRTC を無理やりサーバ経由にするという仕組みです。 この製品はフルスクラッチで実装しています。 WebRTC 関連の
WiresharkでのQUICの復号(decrypt) - ASnoKaze blog
2019/5/17追記 QUICの暗号化について説明を書きました asnokaze.hatenablog.com 2020/09/16「WiresharkがHTTP/3に対応した - ASnoKaze blog」 WiresharkはIETF版 QUICパケットのdecryptに対応しているので、やってみる。 Wiresharkの細かい対応状況については以下の通りです。 Tools · quicwg/base-drafts Wiki · GitHub 最新のソースコード内に書かれているTODOとしては、以下の通り。 * to-do list: * DONE key update via KEY_PHASE bit (untested) * TODO 0-RTT decryptionhttps://github.com/wireshark/wireshark/blob/master/epan
多くの人はまだHTTP/3を無理して学ぶ必要はない - Qiita
フューチャーアドベントカレンダー2018のピンチヒッターです。ワイキキの海を見下ろすホテルからこんばんわ。 QUICがリブランドされてHTTP/3になったというのはそれなりに大きな話題になりました。これを機に学ぼうという人も多いと思いますが、個人的には費用対効果を考えると、まだ早いのではないかと思います。HTTP/2のときともまた違ってそんな学んだことが役に立つ人も多くないのではないかな、と思います。 HTTP/2を学ぶべきだがHTTP/3を（あえて）学ぶ必要はないと思う理由 HTTP/1.1からHTTP/2はほとんどの部分が同じです。フレーム単位で送受信する方式になって、メールとかネットニュースと同じようなテキストベースのプロトコルから変わったりという「表現のシンタックス」上の変更が中心でしたが、その上で表現する、たとえばクッキーの意味だとか、フォームなどの情報をどのようにシリアライズし
QUICとHTTP/3時代のインターネット解説書はどうあるべきだろう - golden-luckyの日記
OSI参照モデルとTCP/IPモデル なぜいまでもOSI参照モデルによる説明が多いか QUICは、TCP/IPモデルのトランスポートとはいえるが、OSI参照モデルのレイヤ4とはいいにくい HTTP/QUICモデル QUICをどう解説するか OSI参照モデルとTCP/IPモデル かつてぼくたちは、7つのレイヤに分かれたOSI参照モデルという姿でコンピュータネットワークを学び、その7層のモデルにそって各種のプロトコルを理解しようとしていました。 だから、「SONET/SDH上のATM回線でIPパケットをやり取りする」という構想をきけば、「つまり、SONET/SDHがレイヤ1で、ATMがレイヤ2で、IPがレイヤ3なのだな」という枠組みを頭に描いていました。 と同時に、OSIのレイヤとはいったい……、というアンビバレントな想いにさいなまれることもよくありました。 「SONET/SDHがレイヤ1って
Introduction · HTTP/3 explained
This book effort was started in March 2018. The plan is to document HTTP/3 and its underlying protocol: QUIC. Why, how they work, protocol details, the implementations and more. The book is entirely free and is meant to be a collaborative effort involving anyone and everyone who wants to help out. A reader of this book is presumed to have a basic understanding of TCP/IP networking, the fundamental
総務省｜IETFにおける通信コネクション改善に関する国際標準化動向調査
現在、国際標準化団体IETF（Internet Engineering Task Force）では、Webアクセスの高速化を目的として、Web技術で利用される通信コネクション確立等の改善について議論されています。 このような背景から、IETFにおいて検討が進められている通信プロトコルQUIC（Quick UDP Internet Connections）に関連する技術動向及び国際標準化動向を調査し、その結果をとりまとめました※。 （※ 平成29年3月） IETFにおける通信コネクション改善に関する国際標準化動向調査報告書（概要） IETFにおける通信コネクション改善に関する国際標準化動向調査報告書（本文）
「HTTP/3」がHTTP-over-QUICの新名称に。IETFのQUICワーキンググループとHTTPワーキンググループで合意 － Publickey
現在IETFで仕様策定が進められている、UDPをベースに効率的で高速な通信を実現するためのプロトコル「QUIC」をトラスポート層に用いる新しいHTTPの名称が「HTTP/3」になることが決まりました。 HTTP/3のベースはGoogleが開発したQUIC。IETFで標準化へ もともとQUICは、Googleが高速なHTTPの通信を実現するためのプロトコルとして2013年に発表し、同社のChromeブラウザやクラウドサービスなどに実装してきました。 QUICは、従来のHTTPでトランスポート層に用いられているTCPの代わりに、UDPを用いています。 TCPはエラー訂正機能などを備え信頼性の高い通信が可能な一方、比較的オーバーヘッドの大きなプロトコルです。そこでTCPの代わりに通信の信頼性は保証されないもののオーバーヘッドの小さいUDPを用い、独自に一定の信頼性を保つ実装を組み込みつつHTTP
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
V on Twitter: "quiche - Git at Google https://t.co/ec1KVUstyj こっちか"
日本語 | HTTP/3 explained
README | HTTP/3 explained
Kazuho Okuさんのツイート: "再送制御には高い応答性（パケット受信後、数分の一RTTでのACK送信）が求められるが、HDD環境で動くユーザプロセス内でのトランスポート実装でそのような応答性を確保するのは困難（特にスワップインとか最悪）という話です… "