AWS EC2でのHTTP/2 or SPDY導入方法 - Hatena Developer Blog
東京でウェブオペレーションエンジニアをしている id:dekokun です。 ここ数年、HTTP/2 or SPDYが話題ですよね。nginxが1.9.5からSPDY対応を切ってHTTP/2の設定ができるようになったり、はてなでも以下ブログにも記載されているように、SPDY or HTTP/2も積極的に導入していっています。 developer.hatenastaff.com 先日、AWSの環境にてSPDYを導入したのですが、導入していくまでにはやはり若干の苦労がありました。そこで、SPDY or HTTP/2をどのように導入していったか及びそこで起きた問題点の解決策等をまとめようと思います。 なお、この記事では"HTTP/2 or SPDY"と書いていますが、SPDYはHTTP/2にその座を譲ろうとしている立場となっています。具体的には、今年の5月にChromeがSPDYのサポートを切る
SPDYで複数のTCPコネクションをひとつにまとめるとはどういうことか - ゆううきブログ
SPDYが流行っていて，複数のTCPコネクションを1つにまとめて高速化を図るらしいということは知っていた． しかし，単にTCPのコネクション数を抑えるだけならHTTP 1.1のKeep Aliveやpipeliningを使えばよいし，既存技術のどこが問題でSPDYはどう解決しているのかを調べてみた． SPDYの人でもWeb標準の人でもなんでもないので，間違いが多分含まれています． 並列TCPコネクション 並列にTCPコネクションを張る状況として，Webの世界においては以下の2つを思いつく． ブラウザがあるページをロードして，そのページに複数の画像ファイルが含まれており，それらを同時に取得するために並列にTCPコネクションを張り，HTTPリクエストを投げる． JSで非同期に複数のHTTPリクエストを投げる．1個のリクエストを投げるときに1個のTCPコネクションを張る． 並列TCPコネクション
Kazuho's Weblog: HTTP/2 is much faster than SPDY thanks to dependency-based prioritization
HTTP/2 is much faster than SPDY thanks to dependency-based prioritization Background HTTP/2 provides two methods to prioritize streams (e.g. files being served). One method is called weight-based prioritization. In weight-based prioritization, every stream is given a weight, and the value is used by the server to proportionally distribute the bandwidth between the streams. The other method is depe
Google、「SPDY」終了と「HTTP/2」サポートを発表
Googleが、HTTPをサポートする独自プロトコル「SPDY」のChromeでのサポートを2016年までに終了する。SPDYの多くの機能を統合した「HTTP/2」の策定が近いためとしている。 米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をベース
「WebSocket, WebRTC, Socket API, … 最新Webプロトコルの傾向と対策」HTML5 Conference 2013 セッションレポート
「WebSocket, WebRTC, Socket API, … 最新Webプロトコルの傾向と対策」HTML5 Conference 2013 セッションレポート 吉田 啓二 2013年11月30日（土）に開催された「HTML5 Conference 2013」の、エヌ・ティ・ティ・コミュニケーションズ株式会社・小松健作さんによるセッション「WebSocket, WebRTC, Socket API,…最新Webプロトコルの傾向と対策」の内容をご紹介します。 最新のWebプロトコルが続々と誕生 1990年から10年間ほどは、HTTPというたった一つのプロトコルが、Web通信用のプロトコルとして使われていました。その後、HTML5という言葉が出てきてから、WebSocketやSPDY、HTTP/2.0、WebRTC、Raw Socket API、SCTP over UDP、QUICといった
「第43回 HTML5とか勉強会 ～HTML5に関わるプロトコルたち」活動報告 | gihyo.jp
2013年12月16日、今年最後のHTML5とか勉強会は、ソフトバンク株式会社さんに会場をお借りして開催しました！ 毎年12月の勉強会ではソフトバンクさんのカフェテリアを使用させていただいているのですが、それも4度目となりました。厚く御礼を申し上げます。 さて、今年最後のテーマは「HTML5に関わるプロトコルたち」と題して、先月行われた「HTML5 Conference 2013」セッションの再演を2本と、LTを4本お話いただきました。 本稿ではその内容についてレポートします。 最新Webプロトコルの傾向と対策 最初のセッションでは、NTTコミュニケーションズの小松健作さんにWebの最新の通信プロトコルについて、SPDYとWebRTCに焦点を当ててお話いただきました。 WebSocket、SPDY、HTTP2.0、WebRTCなど、多くのWebに関わる通信プロトコルが近年続々と現れてきまし
SPDY対応アプリケーションをC言語で実装する方法
人間とウェブの未来（旧） 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 昨日、SPDYのCライブラリであるspdylayがめでたく1.0.0としてリリースされたので早速使ってみました。まずはmacOSX10.8.3で試してみました。ビルド方法はメモに書いていますので参考にして下さい。 今回はSPDYで通信できるクライアントをCで書く際に、どのような実装の流れになるかを紹介したいと思います。本エントリで実装流れを把握したら、spdylay/spdylay.hを読む事をおすすめします。 SPDYのCライブラリspdylayの概要 spdylayのAPIはコールバックベースで実装されています。ただ、今回はコールバックされる関数の詳細な実装まで説明すると、全体的な流れが見えにくくなるので、コールバック関数の実装の仕方は省
なぜ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
HTTP vs HTTPS Test
HTTP vs HTTPS Test Encrypted Websites Protect Our Privacy and are Significantly Faster Compare load times of the unsecure HTTP and encrypted HTTPS versions of this page. Each test loads 360 unique, non-cached images (0.62 MB total). For fastest results, run each test 2-3 times in a private/incognito browsing session.
HTTP/2.0を捨て、より完璧なプロトコルを - W3C WGでVarnish開発者が提案
W3C HTTPワーキンググループのメーリングリストに「Please admit defeat (was: Our Schedule)」というメールが投函された。メールを投函したのは高速キャッシュサーバVarnishの開発者でありFreeBSDのカーネル開発者でもあるPoul-Henning Kamp氏。不完全な状態のHTTP/2.0を公開することはさまざまなリソースの無駄であること、HTTPのコンセプトをよりシンプルにして暗号処理やプライバシなどの問題を解決した、しっかりしたプロトコルを策定してから公開すべきだと提案している。 HTTP/2.0はGoogleの開発したSPDYと呼ばれるプロトコルをベースとした次世代のHTTPプロトコル。現在策定が進められている段階にあり、順調にいけば2015年には正式なプロトコルとして策定される見通し。しかし現在策定が進められているHTTP/2.0はいく
人間とウェブの未来 - 軽量な静的コンテンツ配信における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マップ。ネタ元も
Nginx Inc. Launches NGINX Plus - nginx.com
F5 Sites DevCentral Connect & learn in our hosted community F5 Labs The latest threat intel and research to help protect your apps MyF5 Your key to everything F5, including support, registration keys, and subscriptions Partner Central Research and support for partners LearnF5 Guidance, insights, and how to use F5 products Contact F5 Contact F5 Sales Talk to an F5 sales representative Contact F5 Su
HTTP 2.0のインパクト
Q: FWは今後どんどん暗号されてURLフィルタリングやマルウェアフィルタリングとか出来なくなってくるのか？ A: 出来なくなってくると思う。すでにHyperGiantを中心にhttpsによる暗号通信が普及しており、現状でも出来ない事が多いし、今後も広がっていくと思う。 Q: SSLのセットアップ時に書いてある証明書のCNぐらいしかIdentityファイルしかなくなってしまうと思うがそれに対応しているデバイスはありますか？ Q: CGNの必要セッション数が減るとおっしゃっていたが、タブブラウザはタブが開いているときはセッションを保持しようとするのでその辺を考慮すると実際セッション数は削減することは出来るのか？ A: その点については考慮していかないといけない。タブブラウザのおける全体のセッション数は使い方・作り方に左右される。 Q: AkamaiはSPDY対応はユーザーが対応であればデフォ
今更ながらSPDYとWebSocketのServer Pushについて調べてみた - There's an echo in my head
ログの見れないSkypeやっぱ不便だよね→Hubotとかあるし自分でチャット作ったら面白そう→そういやLINEってSPDYなんだっけ→WebSocketってSPDYに乗るんじゃなかったっけ。 というわけでSPDYとWebSocketのServer Pushについてざっくりと調べてみた。 SPDY と WebSocket の基礎と SPDY の Pushとか、WEB+DB PRESS Vol.75のSPDYの特集の第1章を読んだ感じ、 SPDYでは、後々リクエストが来るとわかっているリソースをサーバから送りつけてキャッシュさせておく それによってリクエストの生成と通信のコストを削減できる レスポンスを並列で返せるようになったのでさらに時間を短縮できる WebSocketでは、純粋に相互にメッセージのやりとりをする やり取りするモノが最初に決まるので毎回送受信するヘッダを削減できる まさに相互
[その2] HTTP/2の留意点とトレードオフ - ワザノバ | wazanova
https://insouciant.org/tech/http-slash-2-considerations-and-tradeoffs/1 comment | 0 points1) Network Performance 2) Scalability & DoS HTTPに関する次の課題は、スケーラビリティとDoS攻撃対策。httpbisワーキンググループの活発な参加者の多くは中継器か大きなサービス（例えば、Akamai / Twitter / Google / HAProxy / Varnish / Squid / Apache Traffic Serverなど。）の会社に所属しているので、それらのイシューにはかなりセンシティブで、HTTP/2は、スケーラビリティに関わるいくつかの検討事項がある。 Header compression: ものすごく賛否両論ある。 Multiplexi
[その1] HTTP/2の留意点とトレードオフ - ワザノバ | wazanova
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はラウンドトリップのコストが高く、ページ読込みのパフォーマンスを悪化
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
メッセージング基盤の進化 Erlang、SPDYからそれを支える組織の話 LINE Platform Development Chronicle #linedevday
HTTPを強化する
SPDY対WebSockets?
