Open sourcing our NGINX HTTP/2 + SPDY code
Open sourcing our NGINX HTTP/2 + SPDY code Loading... In December, we released HTTP/2 support for all customers and on April 28 we released HTTP/2 Server Push support as well. The release of HTTP/2 by CloudFlare had a huge impact on the number of sites supporting and using the protocol. Today, 50% of sites that use HTTP/2 are served via CloudFlare. CC BY 2.0 image by JD Hancock When we released HT
HTTP/2 is here! Goodbye SPDY? Not quite yet
HTTP/2 is here! Goodbye SPDY? Not quite yet12/03/2015 Why choose, if you can have both? Today CloudFlare is introducing HTTP/2 support for all customers using SSL/TLS connections, while still supporting SPDY. There is no need to make a decision between SPDY or HTTP/2. Both are automatically there for you and your customers. Enabling HTTP/2 If you are a customer on the Free or Pro plan, there is no
なぜHTTPSはHTTPより速いのか
先週、httpvshttps.com というウェブサイトが公開されました。このウェブサイトでは、HTTP と HTTPS を用いてアクセスした場合のウェブページのダウンロード完了までにかかる時間の比較ができるのですが、多くの環境で HTTPS の方が HTTP よりも高速なことに驚きの声が上がっていました。 HTTP が TCP 上で平文を送受信するのに対し、HTTPS は TCP 上で TLS (SSL) という暗号化技術を用いて通信を行います。ならば、TLS のオーバーヘッドのぶん HTTPS のほうが遅いはずだ、という予測に反する結果になったのですから、驚くのも無理はありません。 実は、この結果にはからくりがありました。 Google Chrome、Mozilla Firefox、最近のSafari注1は、Google が開発した通信プロトコル「SPDY」に対応しており、HTTPS
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
normalize.io - an ES6 module, Web Component, and SPDY/HTTP2 Push frontend development worfklow
normalize.io βetaimport the future, build the present, normalize the past. A streamlined ES6 Module, HTML Import, and SPDY/HTTP2 frontend development solution. Show Me an Example!The frontend development workflow has fundamentally changed with the advent of ES6 modules, HTML imports, and SPDY/HTTP2 push. Normalize provides a streamlined frontend solution by normalizing inconsistencies with browser
世界制覇をもくろむLINE――ベールを脱いだプラットフォームの全体像とは
世界制覇をもくろむLINE――ベールを脱いだプラットフォームの全体像とは：LINE Developer Conferenceまとめリポート（前編）（3/3 ページ） LINEにおけるネットワーク周りの高速化への取り組み LINEビジネスコネクトなどの利用が本格化していくと、サービスや通信の負荷は増大していく。LINEでは、サービスの高速化に向けてどのような取り組みを進めているのだろうか。 SPDYの最適化 LINEのクライアントとサーバー間は、HTTPを拡張して高速化を図ったプロトコルである「SPDY」をベースに通信を行っている。なぜSPDYの仕様をそのまま使っていないかというと、LINEサーバーの場合は、通信の相手はLINEアプリしかなく、UserAgentは1種類に限定される。UserAgentが未知の状態でサーバーがリクエストを受け付ける場合、どのプロトコルで相手と通信するかを最初に
HTTP/2, SPDY 対応の負荷テストツール h2load - Qiita
HTTP/2, SPDY に対応する負荷テストツール h2load を紹介します. HTTP/1 用の負荷テストツールは ab や weighttp が有名ですが, これらは HTTP/2 や SPDY には対応していません. HTTP/2, SPDY を負荷テストする場合は h2load を使うことができます. h2load は nghttp2 リポジトリに入っています. SPDY プロトコルをサポートするには, spdylay をリンクする必要があります. そのため最初に spdylay をインストールしてから nghttp2 をインストールします. インストール方法はそれぞれの README を見てください. この記事の執筆時点では HTTP/2 はまだ策定途中です. h2load は nghttp2 がサポートする HTTP/2 ドラフトバージョンのみに対応し, 執筆時点のバージョ
人間とウェブの未来 - 軽量な静的コンテンツ配信におけるHTTP/2とSPDYのWebサーバの性能を見てみよう
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。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と使い方が似て
SPDYとLinuxの間でGoogleマップがハマった落とし穴 - ぼちぼち日記
tl;dr 書いていたら思わず長文の大作になってしまいましたので、プロトコルオタ以外の方は文章の多さに退屈されるかと思います。GoogleマップサービスでSPDYの問題が発覚し、GoogleがLinuxカーネルに修正を加えて対応したというお話です。将来 Linux + nginx + SPDY を使いリバースプロキシでサービス運用を検討されている方は参考になるかもしれません。 1. はじめに、 プロトコルに執着する年寄りエンジニアの老害が叫ばれて久しい。 年甲斐もなく自分好みのパケットを追っかけるおやじエンジニアの姿を見て眉をひそめる若者も多いと聞く。 そんな批判に目もくれず、今日も一つ、プロトコルオタのネタをブログで公開したいと思いますw 今回はちょうど１年ほど前に書いたブログ記事 「GmailがハマったSPDYの落とし穴」の続編です。といっても今度の舞台は、Googleマップ。ネタ元も
なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか？ 何が問題で、なぜ Google はそれらを作り変えるのか？ SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか？ 20% ルールで作ってみた Play プロジェクトでしかないのか？ こうした新しい動きには、かならず「それまで」と「今」を踏
0-RTT接続、これがQUICの力。QUIC対SPDY3の再接続対決(動画有) - ぼちぼち日記
1. QUICサーバを試す 先日紹介したGoogleの新プロトコル QUIC ですが、Chomium ソース中にテスト用の QUICサーバが用意されています(net/tools/quic以下)。 今のところこの QUIC サーバは、Linux上でしかビルドできません。また、コンテンツの方はあらかじめ wget で取得した静的なもの（バルサフレーム形式と呼ばれている）しか使えませんが、現在これを使っていろいろQUICの特性を評価しているところです。 Googleからのアナウンスにあるよう、QUICの大きな特徴の一つとして、 TCP Fast Open と TLS Snapstart を組み合わせたような(だいたい 0-RTTの）素早い接続 が挙げられます。 UDP上でQUIC独自にセッション管理をしているので再接続時には全くハンドシェイク無しで接続を開始できる技です。モバイル環境の様に頻繁に
WebSocketのリバースプロクシやSPDYサポートが加わった「nginx 1.4」登場 | OSDN Magazine
オープンソースのWebサーバー「nginx」開発チームは4月24日、最新の安定版となる「nginx 1.4.0」を公開した。1年ぶりの新たな安定版リリースとなり、SPDYプロトコルのサポート、WebSocketリバースプロキシなどの機能が加わっている。 nginxはロシアの開発者Igor Sysoev氏が開発したWebサーバーソフトウェア。軽量かつ高速なのが特徴で、リバースプロキシやIMAP/POP3プロキシ、キャッシュ、負荷分散、コンテンツの圧縮といった機能も持つ。ライセンスは二条項BSDライセンスで、BSD系OSだけでなくLinuxやMac OS X、Solaris、Windowsなどさまざまなプラットフォームで動作する。調査会社Netcraftの調査によると2013年4月のシェアは15％で、Apache HTTP Server（55％）、Microsoft IIS（20％）についで3
twitterが spdy/3.1 の試験を始めてます - ぼちぼち日記
はじめに、 先日 @tatsuhiro_t さんのつぶやきで見つけたのですが、twitter が spdy/3.1 の試験をしているようです。 ChromiumのコミットログからGoogleがspdy/3.1を実装したのは気づいていましたが、www.google.comを調べても spdy/3 までしか提供されていないので内部で試験中なんだろうなと思ってました。 Googleではなく twitter がインターネット向けに spdy/3.1 のフィールド試験を最初に始めたというのは驚きです。 さっそく twitter からの NPNリストを確認しましたが、その時は自前の環境では twitter から spdy/3 しか確認できませんでした。最近はほぼ毎回 spdy/3.1 が来ているようなので大規模な試験が始まったんではないかと思います。 そして、ちょうど先週末 Chromium で Fl
HTTP 2.0最新動向インタビュー - IETF httpbis wg チェア Mark Nottingham氏:Geekなぺーじ
TOP > ブログ > HTTP 2.0最新動向インタビュー - IETF httpbis wg チェア Mark Nottingham氏 昨年後半、IETFのhttpbisワーキンググループでHTTP 2.0標準化に向けた動きが開始されました。 そのhttpbisワーキンググループのチェアであるMark Nottingham氏(Akamai)に対するインタビューの機会を頂けました。 Mark Nottingham氏は、HTTP 2.0標準化の舵取りをしている方です。 非常に興味深い最新状況を伺えたので、可能な限り生に近い情報をお届けします(日本語に翻訳する前の英語版はこちら)。 お楽しみ頂ければ幸いです。 Q: HTTP 2.0標準化開始の経緯を教えて下さい HTTP 1.1とHTTP 1.0には、よく知られた制限があります。 特に顕著なのが、ひとつのコネクションでリクエストを出してレス
FacebookがSPDYを始めました！ - ぼちぼち日記
1. SPDYが熱いです！ ちょうど先週末CROSS2013の 次世代Webセッション(プロトコル編) にパネラーとして参加させていただきました。 次世代Webの鍵となるWebSocket・SPDY・HTTP/2.0について熱い話ができとても満足しています。会場は満員で皆さんがとても興味を持って聞いていただいているのも十分感じることができました。 参加していただいた方、本当にありがとうございました。 2. LINEがSPDYを使っている セッションでは、つい最近 LINE が SPDY を使っているという発表( http://tech.naver.jp/blog/?p=2381 )について紹介し、その有用性についていくつかコメントをしました。 SPDYは、 Google が2011年より2年近くほとんどのGoogleサービスで実運用していますが、Google以外で世界的にメジャーな大規模の
SPDY と WebSocket の基礎と SPDY の Push - Block Rockin’ Codes
最近 SPDY対WebSockets? などという記事が出てきたりして、 SPDY と WebSocket が色々ごちゃごちゃになって語られているのかもなぁ、と思います。 SPDY では Akamai の中の人の Guy's Pod » Blog Archive » Not as SPDY as You Thought や、それに対するフォロー記事 Followup to “Not as SPDY as You Thought” « Mike's Lookout なんかも、 ちょっと注目されたりしました。 これらの記事には WebSocket や SPDY の性質やモチベーションを正しく理解するために、 知っておくと良い知識へのキーワードが散りばめられていると思ったので、 そこら辺について、つらつら書いてみようかと思います。 SPDY は「遅い」のか？ Guy's Pod » Blog A
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://research.google.com/pubs/archive/43447.pdf
https://www.ietf.org/proceedings/92/slides/slides-92-saag-5.pdf
The realtime web: HTTP/1.1 to WebSocket, SPDY & beyond
SPDYの話
