先週、モントリオールで開催された IETF 105 に参加してきました。 いろんなことがあったのですが、個人的に一番大きかったのは、HTTP/3 からプライオリティ（優先度制御）まわりの仕様を落とすことが決定したこと。 HTTP/3 は、トランスポートプロトコルである QUIC の上で動作する、次世代の HTTP プロトコルです。その設計は、QUIC ワーキングググループが、HTTP ワーキンググループから委託され、HTTP/2 の機能を移植する、という形式を取っています。 ところが、５月にロンドンで開催された QUIC ワーキンググループの中間会議で、一部参加者から HTTP/3 の優先度制御に対する不満が表明されたのです注1。それを受けて、QUIC ワーキンググループでは、HTTP/3 の優先度制御にあった HTTP/2 のそれとの差異を少なくする作業を進める一方、HTTP ワーキング
12. HTTP/2フレーム Length : ペイロードのオクテット数 Type : フレームの種類、データフレームやヘッダーフレームなどを指す Flags : ストリームの終了やらのフラグ Stream Identifier : 31bitのストリームのID R : 未定義 Frame Payload : タイプによって決められたデータ形式のデータの領域 13. フレームタイプ Type Name Summary Binary DATA ストリームに関連する任意の可変長オクテット列。 0x0 HEADERS 名前-値のペアを転送する。ストリームの開始に仕様される。 0x1 PRIORITY 送信者からストリームの優先度を指定する。 0x2 RST_STREAM ストリームの即時終了を表す 0x3 SETTINGS エンドポイントの通信方式に影響を与える設定など。 0x4 PUSH_PR
第3会FRESH勉強会で発表予定のスライド。HTTPについて詳しくない人のために HTTPの概要から先日RFC化されたHTTP/2の新機能、使いどころを解説します。
update 色々と twitter で議論が起こったのでまとめて貼っておきます。 togetter.com みなさんありがとうございました。 intro HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。 そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。 前提 今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。 また、本エントリ内では独自に以下の表記を採用します。 HTTP/1.1 = HTTP/1.1 (平文) HTTP/2 = HTTP/2 (平文) HTTPS/1.1 = HTTP/1.1 over
“Generic Event Delivery Using HTTP Push” なる RFC を知った。 JavaScript の Push API をネットワークレベルでどう実現するか決めるものらしい。 Push API, システムが提供する GCM なんかのラッパーだと思い込んでいた。 Chrome の現状はそのようだけど、標準的にはスタック全体を定義しようとしている模様。 仕様を書いているのは Mozilla の人。えらい。 Web Push は HTTP/2 の上に定義されており、PUSH_PROMISE で UA にメッセージを送る。 TCP で現実的なプッシュを作れるとは思っていなかったので驚いた。 ざっと調べてみたところ GCM も TCP ベースらしい。 接続を保つべく適当な間隔で heartbeat していると、世間の資料にはある。 SMS など cell networ
先日、HTTP/2が正式な仕様として承認されると同時に、その実装であるH2Oのv1.0.0もリリースされました。 Kazuho's Weblog: H2O, the new HTTP server goes version 1.0.0 as HTTP/2 gets finalized HTTP/2の情報はちょいちょいウォッチはしていたのですが、今までHTTP/2なサーバーを動かしたことはなく、いい機会なので自分のサイトをH2Oを使ってHTTP/2対応してみました。 https://www.irori.org 大したことはやってないのですが、Apacheでサービスしており、認証やアクセス制限、ごにょごにょ黒魔術、CGI(!)やSSI(!!)なども動いているので、ApacheをH2Oにリプレースするのは無理でした。 そこで、H2Oをリバプーとして前段に置き、Apacheを後段に置く構成にしまし
米Googleは2月9日（現地時間）、2009年に発表したアプリケーションレイヤープロトコル「SPDY」のサポートを2016年初頭までに終了する計画を発表した。 SPDYは、ネットワーキングプロトコル「HTTP（Hypertext Transfer Protocol）」をサポートし、Webページ表示を高速化する目的で構築されたプロトコル。立ち上げ当時、ほとんどのWebサイトはHTTPのバージョン1.1（HTTP/1.1）を採用していたが、HTTP/2の標準化が近いため、Webブラウザ「Chrome 40」の次のアップデートから段階的にHTTP/2をサポートするという。 HTTP/2はSPDYをベースとしており、SPDYの複数ストリームのマルチプレックス機能、ヘッダ圧縮機能、リクエストの優先度指定機能などがHTTP/2に統合されている。 インターネット技術の標準化を策定するIETF（Inte
先月末の話になりますが、SAPジャパンさんを会場に開催されたデータ転送ミドルウェア勉強会で、私が中心になって開発しているHTTPサーバ「H2O」について話す機会をいただき、登壇してきました。 以下は当日使用したスライドです。なぜ今H2Oを開発しているのか、その背景にある現状認識と将来の方針について、日本語で説明してあるので、興味ある方はご覧ください。 発表の機会をくださった@repeatedlyさんと@frsyukiさん、会場を提供してくださったSAPジャパンさん、ありがとうございました。 H2Oの開発は順調に進んでおり、HTTP/2サーバプッシュへの対応も完了し、まもなく次のバージョンがリリースできるかと思います。今後ともよろしくお願いいたします。
先週、httpvshttps.com というウェブサイトが公開されました。このウェブサイトでは、HTTP と HTTPS を用いてアクセスした場合のウェブページのダウンロード完了までにかかる時間の比較ができるのですが、多くの環境で HTTPS の方が HTTP よりも高速なことに驚きの声が上がっていました。 HTTP が TCP 上で平文を送受信するのに対し、HTTPS は TCP 上で TLS (SSL) という暗号化技術を用いて通信を行います。ならば、TLS のオーバーヘッドのぶん HTTPS のほうが遅いはずだ、という予測に反する結果になったのですから、驚くのも無理はありません。 実は、この結果にはからくりがありました。 Google Chrome、Mozilla Firefox、最近のSafari注1は、Google が開発した通信プロトコル「SPDY」に対応しており、HTTPS
HTTP2 のフロー制御 この記事は HTTP2 Advent Calendar の 1 日目の記事です。 初回は、執筆時点での最新ドラフトである HTTP2-draft16 のフロー制御(Flow Control) について解説します。 余談ですが, 現在の仕様では "HTTP2.0" ではなく "HTTP/2" もしくは "HTTP2" が正しい名称です. 更新 @kazu_yamamoto さんに指摘頂いた点を反映しました。 @kiri__n さんに指摘頂いた点を反映しました。 詳細については 更新履歴 をご覧下さい。 フロー制御 HTTP2 では、同じホストへの複数のリクエストを、同一の TCP コネクション上にストリームという単位で多重化することができるようになりました。 フロー制御とは、例えばひとつのストリームがリソースを占有してしまうことで、他のストリームがブロックしてしまう
Nov 11, 2014 すでに1週間経ってしまいましたが、11月3日は HTTP/2 カンファレンスに参加していました。来日中の Ilya による基調講演から始まり、各 HTTP/2 の実装者による技術的なセッションやトークセッションまであって、非常に濃い内容で楽しめました。個人的には間違いなく今年のベストカンファレンスだったと思います。 そんな豪華なセッションの合間に、自分も HTTP/2 クライアントを60分で実装するという内容で発表とライブコーディングをしてきました。発表資料は以下の通りで、ライブコーディングで実装したクライアントのコード Gist で公開しています。 発表前は HTTP/2 の仕様の解説にかける時間と、ライブコーディングにかける時間をどれぐらいにするかのバランスで悩んでいたのですが、結局 HTTP/2 の基本的な仕様は一通り仕組みを理解できる程度に説明するようにし
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 既存のHTTPやWebサーバの技術を見ているものとして、新しい技術も調査しておかないといけないなということで、今日はHTTP/2とSPDYでおしゃべり可能なWebサーバの性能を見てみたいと思います。 HTTP/2の実装としては、tatsuhiro-tさんのC言語実装ライブラリであるnghttp2に注目しており、今日はそのライブラリを使って実装されているWebサーバnghttpdを動かし、SPDY/3.1で動作しているnginxとの性能比較をしました。HTTP/2やSPDY/3.1はもちろんクライアント側も既存のベンチマークツールではおしゃべりできないので、nghttp2で実装されているh2loadを使用しました。weighttpと使い方が似て
宣伝 2015/11 追記 ソフトウェアデザイン 11月号に HTTP/2の特集記事を書かせていただきました。より詳しく書きましたので、本記事より参考になるかと思います。 http://www.amazon.co.jp/dp/B01494YKUI HTTP2は2014年4月のWG Last Callに向けて、仕様策定が進められている。 現在も、ロンドンで行われているIETFのミーティングでは熱い議論が行われているところであろう。 (local activityとして日本での活動なども紹介されているようです) HTTP2の仕様を決めているHTTPbisワーキンググループのchairであるMark Nottingham氏が、自身のブログにて「Nine Things to Expect from HTTP/2」という記事が投稿されている。 ここでは、HTTP2が何をもたらすか以下の観点で説明して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く