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とSPDY及びHTTP/1.1の実装におけるコンテンツサイズの変化による性能の遷移について
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 前回のエントリ「軽量な静的コンテンツ配信におけるHTTP/2とSPDYのWebサーバの性能を見てみよう」では、非常に小さな静的コンテンツに対してのレスポンス性能を比較しました。今回はより詳細な比較を見るために、リクエストするコンテンツサイズの変化によって、性能がどのように遷移するかを測定し、それを測定してグラフ化しました。（ローカルホストでベンチかけてるのは環境が十分にないからなので遺憾ながら家の単一VMで評価しています。） ベンチマーク結果 ベンチマーク測定は前回のエントリと同様の環境と設定で行っており、リクエストするコンテンツファイルのサイズを前回の21byteから20000byte（20kbyte）まで遷移させて、それぞれのコンテンツサ
Chromium Blog: Hello HTTP/2, Goodbye SPDY
HTTP is the fundamental networking protocol that powers the web. The majority of sites use version 1.1 of HTTP, which was defined in 1999 with RFC2616. A lot has changed on the web since then, and a new version of the protocol named HTTP/2 is well on the road to standardization. We plan to gradually roll out support for HTTP/2 in Chrome 40 in the upcoming weeks. HTTP/2’s primary changes from HTTP/
なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか？ 何が問題で、なぜ Google はそれらを作り変えるのか？ SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか？ 20% ルールで作ってみた Play プロジェクトでしかないのか？ こうした新しい動きには、かならず「それまで」と「今」を踏
Guy's Pod » Blog Archive » HTTP Pipelining – Not So Fast…(Nor Slow!)
HTTP Pipelining is an old optimization technique that’s been getting some renewed interest recently. I’ve written in the past about how pipelining is broadly used in Mobile, and recently Chrome & Firefox have been considering enabling it by default. I set out to try and assess the value of pipelining for page load times, and surprisingly found it have very little effect. This result surprised me,
Guy Podjarny「HTTP Pipeliningはwebを速くも遅くもしない」 - 以下斜め読んだ内容
Guy's Pod 2012.6.26のブログエントリ Guy's Pod » Blog Archive » HTTP Pipelining – Not So Fast…(Nor Slow!) http pipeliningサポートが普及した でも全然サイト高速化に貢献できてないこと なんで速くなってないのか調べた（サイトの作りが効果を相殺してる） グラフ入りで詳しく書いてるエントリ spdyのベンチマークの姉妹編のようなエントリで、http pipeliningとspdyが持てる力を発揮できてない理由は共通してる、など勉強になった 以下斜め読んだ内容 http pipelinig 昔から知られた最適化テクニック 最近モバイルでもブラウザでも広く使われつつある chrome/fxはデフォルト有効になった http pipeliningで速くなったと期待して軽くテストしてみた 全然速くなくて
Christopher Rogers、Namil Kim「lineもspdyサポート（その１）」 - 以下斜め読んだ内容
NAVER Engineers' Blog 2013.1.11のエントリ Adopting SPDY in Line – Part 1: An Overview « NAVER Engineers' Blog lineがspdyサポートしたよ、というシリーズものエントリ第１弾 場合によっては非sslでもspdy使ってるよ、とか、tlsのNPNは使わないことにしたとか、概要的内容 以下斜め読んだ内容 自分らはux向上頑張ってる。現在進行形 line＝コミュニケーションツールだとすると。。。 メッセージ送受信時間を短縮できれば、ux改善、と言える これまでの送受信はずっとhttp httpは普及してる技術 シンプルなrequest/responseモデル tcpコネクションの上で送受信するモデル httpの欠点 リアルタイム通信向けに設計されてないhttp メッセージングサービスにhttpが不
TechCrunch | Startup and Technology News
Yellow, an asset financier for solar energy and digital devices in Africa has raised $14 million series B funding in a round led by Convergence Partners with participation from the Energy Entrepreneur Fisker, the electric carmaker founded by the Danish auto designer Henrik Fisker, is gearing up to enter the Chinese market where competition is increasingly cut-throat, following in the footsteps of
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
Akamaiの設計者、SPDYの問題を提起
Webパフォーマンスの研究者であり、現在AkamaiのチーフプロダクトアーキテクトであるGuy Podjarny氏が「Not as SPDY as You Thought」と題して、SPDYの問題点を指摘している。SPDYは、Googleが開発した次世代通信プロトコル。HTTPの代替プロトコルとして設計されており、GoogleによればSPDYを利用することで、読み込み速度が最大50%も短縮できるとしている。 Podjarny氏は、SPDYを利用することで実際どれだけ高速になるのかを検証している。同氏は現実的なテストとして、アメリカのトップ500のサイト(Alexa調べ)に対してSPDY、プレーンHTTPS、HTTPのそれぞれの読み込み時間を計測したという。その結果、SPDYはHTTPSよりも4.5%だけ早く、HTTPよりも3.4%遅い結果となったと報告している。 試験結果からPodjarn
Node.js で Hello SPDY を作る - ぼちぼち日記
SPDY が流行っている SPDY が流行っています。当初 Chrome だけ使えていたのが FireFox のサポートするようになり、Google からの apache モジュールの提供や nginx のサポート予定などここ最近で SPDY に関する話題が急に増えています。Node.js では昨年既に node-spdy のモジュールが提供されていて、比較的早い段階から使えるようになっていました。(ただし node-0.7系が必要です。） これはおそらく Node は tls/zlib モジュールが使えるので比較的 SPDY の実装するのが楽だからじゃないかと個人的に見てまして、まぁ流行に乗って、今回まずは簡単・単純 Hello SPDY を独自に作ってみました。やっぱり新しいプロトコルを使ってみるのは新鮮ですね。 そもそも SPDY がどんな技術でどんなメリットがあるかなどは、それを書
こてさきAjax:node-spdy 試してみた - livedoor Blog（ブログ）
今日のブログのお題は、SPDY。Webサービスを「とにかく速くしよう！！」ということで、Google が提唱したプロトコルです。既にChromeでは、このSPDYが実装されており、サーチやGMailなど Google が提供する殆どのサービスで既に利用されています。 最近では、FireFoxへのインプリが始まったり、HTTP/2.0検討のベースとなるなど何かと話題のWeb最新技術です。 SPDYがWebを早くする仕組み SPDYは、現状のWebが抱える問題 ”HTTPは遅い!!" を解決するものです。HTTP が "遅い" 原因は色々ありますが、中でも最も大きいのは Request and Response の制限です。このため、SPDY では一本の HTTPS セッションの中で複数の HTTP セッションを多重化するといったことを行い高速化を実現しています。 Request & Resp
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch | Startup and Technology News
Status of HTTP pipelining in Chromium - Insouciant
【HTTP2.0最新動向】第1回：HTTP/2.0の策定、ついに始まる 
GitHub - google/closure-library: Google's common JavaScript library