定期的に更新します 公式 IETF WGページ：draft一覧、憲章など HTTP/2リポジトリ 仕様群：編集中の仕様群 実装リスト 運用ガイド FAQ(日本語訳) WGリポジトリ ミーティング議事録 関連仕様：alt-svcとhttp2-encryption ML httpbis http-devops webpush 関連I-D draft-kerwin-http2-encoded-data draft-ietf-tls-applayerprotoneg draft-thomson-webpush-http2-00 日本語解説記事 仕様翻訳 http2.info HTTP 2.0の最新動向：HTTP/2.0の仕様策定開始当初の解説記事 変わるWebプロトコルの常識（SPDY, HTTP2.0編） SPDY & HTTP2.0 & QUIC HTTP/2における明示的プロキシ(Expli
先日Jxckさんがセッションオーナーを務めた次世代Webセッション@CROSS2014に参加してきました。 セッションではSPDYやHTTP/2(その当時はまだHTTP/2.0だったかな)について主にリソース転送をどうよくするかについて話がされ、QUICなど”Post-TCP”な話も出て非常に興味深く楽しみました。 そこで「僕が考える次世代Web」というお題でブログを書けとJxck先輩から宿題をいただいて、何の話を書こうかなとずーっと思っていたのですが、最近のIETFの議論で個人的にはとても大切だと考えるトピックがあったので紹介＋僕の思いを書きたいと思います。 [訂正] 私がドラフトを読み違えていたのが問題なのですが、このExplicit Proxyの仕組みはhttp schemeの場合だけ適用され、httpsでは適用されません。そのため、httpsについては引き続き安全だと言えます。 し
HTTPbis Working Group Y. Hirano Internet-Draft Google, Inc. Intended status: Standards Track February 14, 2014 Expires: August 18, 2014 WebSocket over HTTP/2.0 draft-hirano-httpbis-websocket-over-http2-00 Abstract The WebSocket protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that co
準備 virtualboxとvagrantがインストールされてない場合は、公式サイトからダウンロードします。 https://www.virtualbox.org/wiki/Downloads http://www.vagrantup.com/downloads.html VMの起動 GitHubから落としてきます $ git clone https://github.com/flano-yuki/nghttp2-vagrantfile $ cd ./nghttp2-vagrantfile プラグインをインストールして、vmを起動します $ vagrant plugin install vagrant-omnibus $ vagrant upboxのダウンロードに数分、Chefのダウンロードに数分、各種インストールとビルドに20分程度かかります... nghttp2 vagrant ssh
Hi, I’m Mark Nottingham. I write about the Web, protocol design, HTTP, Internet governance, and more. This is a personal blog, it does not represent anyone else. Find out more. Comments? Let's talk on Mastodon. @mnot@techpolicy.social other HTTP posts Yet More New HTTP Specs Wednesday, 8 June 2022 A New Definition of HTTP Monday, 6 June 2022 How Multiplexing Changes Your HTTP APIs Sunday, 13 Octob
The HTTPbis working group of the IETF had an interim meeting in Zurich January 22nd to 24th. I participated from remote and I listened in on the discussions over webex and followed the jabber room while the meetings were going on, addressing HTTP2 protocol issues one by one ironing out quirks and progressing forward. I won’t bore you with details why I wasn’t present in Zurich. Here’s a couple of
https://insouciant.org/tech/http-slash-2-considerations-and-tradeoffs/1 comment | 0 pointsChromiumの開発チームのWilliam Changが、HTTP/2の要検討事項とそのトレードオフについてまとめています。HTTP/2.0とSPDYの概要については、Akamaiのこの10分のビデオを参照ください。 1) Network Performance HTTP/1.xは、ネットワークの利用が非効率。HTTP Pipelining（それはそれで固有の問題がある。）を除いて、HTTP/1.xは、接続あたり一つのトランザクションしかできないことが、HOL (Head of line) blockingの原因となる。HOL blockingはラウンドトリップのコストが高く、ページ読込みのパフォーマンスを悪化
現在のウェブページは、動画や音声などリッチコンテンツ化が進み、さまざまなユーザー体験を実現するため、多くのネットワークリソースを消費する傾向にある。 こうした背景からHTTP2.0は、動画配信や高度化するウェブサービス、そしてHTML5に対応する新しいプロトコルとして、技術の標準化を策定する組織のIETF（インターネット技術タスクフォース）によって標準化の作業が進められている。 これまでのデフォルト規格であったHTTP1.1では、コネクション数などがリクエストに対する応答速度に直接影響を与え、レスポンスまでに時間がかかる。多くのユーザーを抱えるISPや通信事業者にとっては、一人のユーザーのウェブアクセスが大量のポートやコネクションを消費することになり、ネットワークリソース管理の問題が生じていた。 対してHTTP2.0では、これらの新しいタイプのリクエストを効率よくこなせるように、リクエスト
12月15日、VOYAGE GROUP様の会議室で http2.0 ミニハッカソン #2が行われました。 恐れ多くも参加してきましたが、端っこのほうでひっそりしていました。 議論は最新仕様についての知識共有と、実装方法の話がメインだったかと思います。 よくプロトコル実装中にありがちな感じのホワイトボード。 HPACK draft 05 前回のミニハッカソンと同様、議論の中心はヘッダ圧縮の仕組みであるHPACKでした。 HTTP2.0を実装する上で最初の砦になるのがHPACKです。ヘッダを構成・解釈出来なければHTTPの通信はままなりません。 HPACK draft 05では、3つの手法を用いてヘッダの転送量を減らしています ハフマン符号を用いて文字列を表現する static tableとheader tableを用いてヘッダを表現する 一度送ったヘッダとの差分のみ転送する ヘッダを構成・解
December 3, 2013 Volume 11, issue 10 PDF Making the Web Faster with HTTP 2.0 HTTP continues to evolve Ilya Grigorik HTTP (Hypertext Transfer Protocol) is one of the most widely used application protocols on the Internet. Since its publication, RFC 2616 (HTTP 1.1) has served as a foundation for the unprecedented growth of the Internet: billions of devices of all shapes and sizes, from desktop compu
http2_easy_hd_encoder.rst HTTP/2.0 ヘッダー圧縮エンコーダーを簡単に書くには ? 現在策定が進んでいる HTTP/2.0 では独自のヘッダー圧縮方法を使用している. 最新版は, http://http2.github.io/http2-spec/compression.html で公開されている. この文章を書いている時点での最新版は, http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-04 である. 以下では, draft-XX は, HTTP/2.0 ドラフト XX を指し, HPACK-XX は, ヘッダー圧縮ドラフト XX を指すこととする. このヘッダー圧縮に対しては複雑すぎるという批判がある. 確かに, zlib をそのまま使えた SPDY に対して実装すべき部分は
1. はじめに、 ただ今IETF-88@バンクーバーの開催が真っただ中です。スノーデン事件の余波もあり、インターネット技術（特にセキュリティ関連）の議論は熱くなっています。 ちょうど今朝未明（バンクバーでは11/5朝）に HTTP/2.0の標準化を進める httpbis ワーキンググループとセキュリティエリアの合同セッションが開催されました。合同セッションでは、ヘッダ圧縮技術(HPACK)のセキュリティや、HTTP接続(HTTPSではない）で通信の暗号化を行ったらどうか、といった興味深い議論が行われました。このうち将来HTTP/2.0の展開に重要な ALPN(Application Layer Protocol Negotiation) は、このミーティングで最終的な仕様を確定させる段階での議論でした。議論の中で、ALPNの導入によってブラウザから既存の実サービスへの接続に(少なからず)影
intro この内容は、 HPACK draft-03 を元に書かれています。 http://tools.ietf.org/html/draft-ietf-httpbis-header-compression-03 将来のドラフトでは変わる可能性があるためバージョンにはご注意下さい。 (以下の内容は、自分がアルゴリズムから読み解いたものなので、間違ってたら教えて下さい。) HPACK HPACK のフレーム表現の中に、以下のような表記が出てくる。 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 | Index (7+) | +---+---------------------------+この Index(7+) は、ここに数値が 7 bit もしくは、それに続く数 byte を用いて、 表現されていることを示している。 この表現
Things we have learned and common mistakes - todo The spec notes that stream ids must be increasing, but this can be easy to accidentally violate. If after frame generation, you insert the frame into a priority queue, then it's possible for a higher priority frame to move ahead. Therefore, stream ids must be generated/committed later in processing in order to ensure correct stream id ordering. Imp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く