TLSとSPDYの間でGoogle Chromeがハマった脆弱性(CVE-2014-3166の解説) - ぼちぼち日記
1. はじめに、 Googleがハマったシリーズ第3弾。今度は Chrome の脆弱性がテーマです。 先日(8月12日頃）突然Google ChromeでSPDYの機能が一旦停止されました。CloudFareの人が気づいてspdy-devへのMLの問い合わせし、すぐGoogleのaglさんからの返事で計画的で一時的なものであることがわかりました。 twitterやfacebookもSPDYが全て使えなくなり非常に驚いたのですが、直後に Chrome の Stable/Beta/Dev チャンネルがアップデートされ、ほどなくして問題なくSPDYが使えるようになりました。 この理由は公式には明らかにされていませんが、Chromeのリリースアナウンスにヒントがありました。そこには、 High CVE-2014-3166: Information disclosure in SPDY. Credi
HTTP/2 リンク集 - ASnoKaze blog
定期的に更新します 公式 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
SPDY対応するために考えてること - ASnoKaze blog
概要 若者の間でも、SPDYに対応するためのノウハウが共有されていないことは有名である。 そこで、中規模サイトでSSL化、SPDY対応という観点で個人的に考えていることを書き出してみる。 HTTP2は暗号化の議論や、アップグレード、ヘッダ圧縮など細部が違うため別途考慮する必要があるが、今回の話も概ね適応できるだろう。 今回主に考える構成としては、以下の様に前段にリバースプロキシを置く構成である。 幾つかSPDY対応しているソフトウェアがあるが、現状NGINXが無難だと考えているので、NGINX前提で話を進める。 （SPDY対応のロードバランサ製品の導入も出来るだろうが、今回は考慮しない） SSL化とSPDY対応 SDPYではSSL化が必須である。これは、SSLハンドシェイク時にHTTPSとSPDYのどちらで通信を行うかネゴシエーションしているためである（TLS上でのプロトコルネゴシエーショ
Firefox NightlyでHTTP/2を試す方法 - ぼちぼち日記
(注） 2014/3/27の Nightly より draft-10 (h2-10)対応になりました。 ちょっと前からですが、Firefox の Nightly ビルドで HTTP/2 が試験的に使えるようになりました。 Bug 950768 - Land http/2 draft08 pref'd off in mozilla-central これまでは tryサーバでビルドしたものを置いてもらいダウンロードしていたんですが、開発担当の Patrick McManus さん曰く、もう面倒になったんで入れちゃったらしいです。 そこでテスト用にHTTP/2を利用したい方向けに、私が普段HTTP/2のテストをする手順通り Firefox Nightly を使って HTTP/2 の動作確認する方法を記載しておきます。 注意事項： Nightly ビルドの動作は不安定な場合もあります。テスト以外に
SPDYとLinuxの間でGoogleマップがハマった落とし穴 - ぼちぼち日記
tl;dr 書いていたら思わず長文の大作になってしまいましたので、プロトコルオタ以外の方は文章の多さに退屈されるかと思います。GoogleマップサービスでSPDYの問題が発覚し、GoogleがLinuxカーネルに修正を加えて対応したというお話です。将来 Linux + nginx + SPDY を使いリバースプロキシでサービス運用を検討されている方は参考になるかもしれません。 1. はじめに、 プロトコルに執着する年寄りエンジニアの老害が叫ばれて久しい。 年甲斐もなく自分好みのパケットを追っかけるおやじエンジニアの姿を見て眉をひそめる若者も多いと聞く。 そんな批判に目もくれず、今日も一つ、プロトコルオタのネタをブログで公開したいと思いますw 今回はちょうど１年ほど前に書いたブログ記事 「GmailがハマったSPDYの落とし穴」の続編です。といっても今度の舞台は、Googleマップ。ネタ元も
SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013
SPDYやQUIC登場の背景。Webの進化がプロトコルを変えつつある。HTML5 Conference 2013 Webをより速くしようと、HTTPよりも優れたプロトコルとして提案されたSPDY（スピーディ）。しかしそのSPDYによって、下位レイヤであるTCPの制限が顕著に見えるようになってしまい、そのことでTCP以外のプロトコルとしてQUICをGoogleが提案しています。 Webの進化は、インターネットのプロトコルにまで影響を与えようとしている、という非常に興味深い話が、HTML5のコミュニティ「html5j」主催のイベント「HTML Conference 2013」で行われた小松健作氏のセッション「最新Webプロトコル、傾向と対策」で行われました。 その内容をダイジェストで紹介しましょう。 最新Webプロトコル、傾向と対策 小松です。所属はNTTコミュニケーションズでHTML5の研究
HTTP/2.0のALPN利用に伴うSSL負荷分散装置の不具合にご注意下さい - ぼちぼち日記
1. はじめに、 ただ今IETF-88@バンクーバーの開催が真っただ中です。スノーデン事件の余波もあり、インターネット技術（特にセキュリティ関連）の議論は熱くなっています。 ちょうど今朝未明（バンクバーでは11/5朝）に HTTP/2.0の標準化を進める httpbis ワーキンググループとセキュリティエリアの合同セッションが開催されました。合同セッションでは、ヘッダ圧縮技術(HPACK)のセキュリティや、HTTP接続(HTTPSではない）で通信の暗号化を行ったらどうか、といった興味深い議論が行われました。このうち将来HTTP/2.0の展開に重要な ALPN(Application Layer Protocol Negotiation) は、このミーティングで最終的な仕様を確定させる段階での議論でした。議論の中で、ALPNの導入によってブラウザから既存の実サービスへの接続に(少なからず)影
新たな技術仕様・要素とは？HTTP/2.0相互接続試験参加レポート（技術解説編）
新たな技術仕様・要素とは？HTTP/2.0相互接続試験参加レポート（技術解説編） 大津 繁樹（株式会社インターネットイニシアティブ） 前回のHTTP/2.0接続試験参加（標準化作業編）に続き、今回お届けするのは技術解説編。既存のSPDYでは使われていないようなHTTP/2.0で新しく議論された技術仕様、相互接続試験のポイントとなった技術要素などを中心にレポートします。 HTTP/2.0相互接続試験で重要な技術要素の概要 SPDYを技術ベースにして検討されているHTTP/2.0仕様は、現在60ページ弱の分量です。従来のHTTP/1.1と異なりバイナリー通信を基本とするため、その多くはフレームフォーマットの説明に割かれています。HTTP/2.0で新しく導入されたヘッダ圧縮の仕様(HPACK)は、現在HTTP/2.0の仕様と分離されていますが、将来的には統合することも検討されています。 HTTP
次世代プロトコルはどう作られる？HTTP/2.0相互接続試験参加レポート（標準化作業編）
次世代プロトコルはどう作られる？HTTP/2.0相互接続試験参加レポート（標準化作業編） 大津 繁樹（株式会社インターネットイニシアティブ） 先日私はドイツで行われた第1回目のHTTP/2.0接続試験に参加してきました。今回、この接続試験を通じて次世代プロトコルがどのように作られていくのか、HTTP/2.0の仕様策定作業の最前線の様子を少しご紹介したいと思います。 はじめに 先日公開された小松健作さんの記事「変わるWebプロトコルの常識（SPDY, HTTP2.0編）」で解説されている通り、Webを支えるプロトコルHTTPをバージョン1.1から2.0に大幅に改訂する作業が、現在急ピッチで進められています。10数年ぶりに改訂されるHTTPの仕様は、現状のインターネット環境に適応できるよう、これまで以上にWeb表示の高速化・効率化が実現できることを目的としています。 HTTP/2.0標準化作業
Web表示の高速化を実現するSPDYとHTTP/2.0の標準化 | IIJの技術 | インターネットイニシアティブ（IIJ）
（※）このページで紹介している事項は記事初出時点の情報に基づいたものです。本ページはアーカイブとして掲載しています。 ツイート 2013年8月6日 はじめに SPDY(スピーディと読みます)は、GoogleがWebの表示を高速化するために開発した、新しいプロトコルです。新しいと言っても、今後普及が見込まれるような新技術ではなく、既に実用化され多くの方が日常的に利用しています。 現在ChromeやFirefox、Operaのブラウザを使われている方は、Googleのサービスやtwitterにアクセスしていると、実は全く気付かないうちに、このプロトコルを利用しています。 SPDYは2010年6月にリリースされたChromeのバージョン6安定版からデフォルトで有効になっており、Chrome利用者はこの新技術を3年以上も利用していることになります。 一般のユーザはSPDYを使っているかどうか、どう
なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか？ 何が問題で、なぜ Google はそれらを作り変えるのか？ SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか？ 20% ルールで作ってみた Play プロジェクトでしかないのか？ こうした新しい動きには、かならず「それまで」と「今」を踏
SPDY Protocol - Draft 3 日本語訳
この文書は「SPDY Protocol - Draft 3」の日本語訳です。 原文の最新版 は、この日本語訳が参照した版から更新されている可能性があります。 この日本語訳は参考情報であり、正式な文書ではないことに注意してください。また、翻訳において生じた誤りが含まれる可能性があるため、必ず原文もあわせて参照することを推奨します。 公開日: 2013-02-11 更新日: 2013-08-21 翻訳者: Moto Ishizawa <[email protected]> 翻訳協力: Shigeki Ohtsu 1. 概要 HTTP 実装のボトルネックの1つに、並列処理のために複数コネクションを必要とすることがあります。これは、接続確立のために追加で発生するラウンドトリップや、スロースタートによる遅延、そして1つのサーバーに対して複数の接続をおこなうことを避けるためのクライアントによるコネクシ
GmailがハマったSPDYの落とし穴 - ぼちぼち日記
1. SPDYブーム到来 おかげさまで、ここ数日 SPDY が私の周りで非常にブームになってきています。 前回案内したSPDY＆WS勉強会は既に200名以上の申し込みがあり、今ではSPDYネタでブログを書くと非常に注目されるうれしい状況です。時代はまさに、 SPDYはハイプサイクルを順調に駆け上がっている 状況だと思います。 図１：2012年のハイプサイクル： 図はガートナー社のプレスリリース http://www.gartner.co.jp/press/html/pr20120906-01.html から引用 SPDYが、まだ黎明期に入ったばかりなのか、それとも既にピーク期に入ったのか、それは歴史が証明してくれるでしょう。 ということで勉強会までSPDY熱が冷めないよう、私もいろんなSPDYネタを出していきたいと思います。 2. GmailがハマったSPDYの落とし穴とは 先日、 Goo
SPDYと「やったー、net-http-spdyできたよー」の話 - I am Cruby!
SPDYを知るSPDYという実験的なプロトコルがありまして、 SPDY - The Chromium Projects HTTP2.0はSPDYをベースに作られるかも、みたいな話も風の噂で聞いたりするのでじゃあどんなもんかなあと仕様を読んで見ました。 SPDY Protocol - Draft 2 - The Chromium Projects SPDY Protocol - Draft 3 - The Chromium Projects SPDYv2とSPDYv3というのがあって、基本的にはSPDYv3の方を読んどけばいいのかなあとは思います。 ただSPDYv2もすでにいろんなところで使われていますので、仕様書の「7.Incompatibilities with SPDY draft #2」の部分もチェックしておきましょう。 HTTP Layering over SPDYSPDYというの
Guy Podjarny「SPDYはみんな思ってるものと違う」 - 以下斜め読んだ内容
Guy's POD 2012.6.12のエントリ Guy's Pod » Blog Archive » Not as SPDY as You Thought AkamaiでChief Product Architectという肩書きを持つエンジニアによるspdy検証エントリ spdyを実戦投入してもたちまち速くなるわけじゃないことを検証してる トラフィック数ランキング上位500サイトで検証 なんでgoogleが宣伝してる通りに速くならないのかも分析してる コメント欄も盛り上がってる Steve SoudersやSPDYテストしてるgoogleの人（Matt Welsh）とか Guyがspdy rantじゃないことがよくわかる 「spdyいいよね」「高速化tipsの賞味期限」「spdyはここ変えたら凄くなる」等々議論してて楽しい Guyのポイントはまとめると spdyに手を出す前にサイト高速化
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP/2 入門
HTTPを強化する
spdylay-ja
【HTTP2.0最新動向】SPDYからHTTP/2.0へ～HTTPbis WG Interim Meetingレポート 
Chrome バージョン 42 以上で NPAPI プラグインが動作しない