実践nginx〜メルカリの場合〜Handling a tremendous amount of images with Fastly / Yamagoya Traverse 2020
なぜ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よりHTTPSの方が速い？それSPDYですから！ - 西尾泰和のはてなダイアリー
HTTP vs HTTPS Test — Does encryption make websites slower or faster?というサイトでHTTPとHTTPSの速度の比較ができて、しかもHTTPSの方が速い、なぜ？という話をFacebookで見て、僕もChromeで試してみたら確かに速い。なぜ？ SPDYですよね。参考文献：Web表示の高速化を実現するSPDYとHTTP/2.0の標準化 | 最新の技術・取り組み | IIJ SPDYが使われているかどうかを確認できるSPDY indicator - Chrome Web Storeをインストールして試してみたら「SPDY3.1が使われています」という表示が出た。 chrome://net-internals/#spdy を見ると以下のようになっていた。Force SPDY Alwaysをtrueにするか、SPDY Enabled
我々はどのようにして安全なHTTPS通信を提供すれば良いか - Qiita
HTTPS通信は複数のプロトコル、手法が組み合わされて実現されている。そのため、暗号化手法それぞれのリスク、ブラウザの対応等様々な用件があり、全てを理解するにはちょっと時間とリソースが足りない。結局のところ、我々はどのようにして安全なHTTPS通信を提供できるのか。色々調べていたところ、MozillaがMozilla Web siteに使用する、HTTPSの推奨設定を公開している。 Security/Server Side TLS - MozillaWiki このドキュメントはMozillaのサーバ運用チームが、Mozillaのサイトをより安全にするために公開しているもので、他のサイトにそのまま適用できるかは十分に注意する必要がある。例えばガラケー向けサイトとか。そのまま使えないとしても、HTTPS通信の設定をどうすれば良いか、理解の一助になるはずだ。 この記事は上記MozillaWiki
SPDYとLinuxの間でGoogleマップがハマった落とし穴 - ぼちぼち日記
tl;dr 書いていたら思わず長文の大作になってしまいましたので、プロトコルオタ以外の方は文章の多さに退屈されるかと思います。GoogleマップサービスでSPDYの問題が発覚し、GoogleがLinuxカーネルに修正を加えて対応したというお話です。将来 Linux + nginx + SPDY を使いリバースプロキシでサービス運用を検討されている方は参考になるかもしれません。 1. はじめに、 プロトコルに執着する年寄りエンジニアの老害が叫ばれて久しい。 年甲斐もなく自分好みのパケットを追っかけるおやじエンジニアの姿を見て眉をひそめる若者も多いと聞く。 そんな批判に目もくれず、今日も一つ、プロトコルオタのネタをブログで公開したいと思いますw 今回はちょうど１年ほど前に書いたブログ記事 「GmailがハマったSPDYの落とし穴」の続編です。といっても今度の舞台は、Googleマップ。ネタ元も
SPDY対応するために考えてること - ASnoKaze blog
概要 若者の間でも、SPDYに対応するためのノウハウが共有されていないことは有名である。 そこで、中規模サイトでSSL化、SPDY対応という観点で個人的に考えていることを書き出してみる。 HTTP2は暗号化の議論や、アップグレード、ヘッダ圧縮など細部が違うため別途考慮する必要があるが、今回の話も概ね適応できるだろう。 今回主に考える構成としては、以下の様に前段にリバースプロキシを置く構成である。 幾つかSPDY対応しているソフトウェアがあるが、現状NGINXが無難だと考えているので、NGINX前提で話を進める。 （SPDY対応のロードバランサ製品の導入も出来るだろうが、今回は考慮しない） SSL化とSPDY対応 SDPYではSSL化が必須である。これは、SSLハンドシェイク時にHTTPSとSPDYのどちらで通信を行うかネゴシエーションしているためである（TLS上でのプロトコルネゴシエーショ
SSL/SPDYを攻撃するCRIMEはBEASTの正統な後継者だ
はじめに 以前のエントリでSSLに対する新しい攻撃手法「BEAST」を紹介しましたが、今回はBEASTをさらに発展させた「CRIME」という攻撃について簡単に紹介したいと思います。一次情報源としてこちらのスライド（英語）が閲覧できますので、時間がある方はぜひ目を通してみてください。 CRIMEの意味 CRIMEは "Compression Ratio Info-Leak Made Easy" あるいは "Compression Ratio Info-Leak Mass Exploitation" の頭文字で、SSLやSPDY（あるいはHTTPボディ部のgzip圧縮）で使われる圧縮アルゴリズムに注目した攻撃手法です。あまり知られていませんがSSLには圧縮機能が存在しており、サーバ側・クライアント側双方が圧縮機能をONにしている場合に、データが圧縮されます。 BEASTとの関係 CRIMEはB
HTML5時代のWeb開発者が知らないとガチヤバな3つの未来予測と6つの脆弱性対策
8月21～23日にパシフィコ横浜で開催された「CEDEC 2013」では、Webの世界に関するセッションも数多く行われた。本記事ではその中から、サイボウズ・ラボの竹迫良範氏による「HTML5のこれまでとこれから、最新技術の未来予測」と、セキュリティコミュニティでは大変著名なネットエージェント、長谷川陽介氏による「HTML5時代におけるセキュリティを意識した開発」の2つのセッションの様子をお送りしよう。 竹迫氏が「HTML」の周りの最新技術と、3つの未来予測を語る 未来予測その1：通信は暗号化が標準に――「スタバでドヤリング」から考える最新技術 竹迫氏はまず、スターバックスでスタイリッシュなMacBook Airをこれ見よがしに使う、「ドヤリング」という技術（？）について写真を出すところから講演を始めた。 実は、この「ドヤリング」、公衆無線LANを利用すると盗聴のリスクがあることが指摘されて
SPDYはどのような状況でも速度向上が見込めるような万能な技術ではない | ykzts.blog
ここ最近、俄かにSPDYが流行の兆しを見せているように見える。言及されぬ技術は使われず、そして使われぬ技術は存在しない物であるのと同義であると私は考えるので悪い事ではないのだが、本来SPDYを使う上で注意すべきである点を無視して言及しているように見えるので一度深く熟考する必要があるのではないだろうか。 SPDYは複数の要求を一つの接続に纏め上げられる通信規格であり、通常のHTTPによる通信に於いて存在していた大きな速度遅延の要因をなくす事は、確かに出来ている。だがSPDYは規格の仕様上、TLSを上層に配す、HTTPSである事を求められている。HTTPSは暗号化と複合化の処理だけではなく、証明書の確認も行われる事になる為に、HTTPよりも速度は低下する事になってしまっている。数十程度の接続しかなされないようなウェブページであれば、SPDYを使う事によって得られる速度向上よりも、HTTPSを使
Webはインターネットになった - naoyaのはてなダイアリー
先週金曜日にエンジニアサポートCROSS2013に行ってきた。目当ては @Jxck_ さんホストによる次世代Webセッション。セッション自体は前後半に分かれていて 前半はプロトコル編。SPDY (wikipedia) や HTTP/2.0 の動向やその課題点など 後半はアーキテクチャ編。プロトコルが変わった上で、その上で動くソフトウェアのアーキテクチャが云々 という内容でした。前半がより技術寄り、後半はテーマ的にもより広範の話題を扱うという感じでどちらも面白かった。 CROSS 2013レポート(2) - mad-pの日記 こちらに細かいログがあります。 話の前提になる SPDY や HTTP/2.0 周りの昨今については 【HTTP 2.0の最新動向】 第1回：HTTP/2.0の策定、ついに始まる - INTERNET Watch Watch 【HTTP 2.0の最新動向】 第2回：HT
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以外で世界的にメジャーな大規模の
CROSS 2013レポート(2) - mad-pの日記
CROSS 2013レポートパート2です。次世代Webセッションのメモ。 CROSS 2013 間違いや発言意図と違う表現だ、などということがあると思います。ご指摘いただければ幸いです。 次世代Webセッション前半〜プロトコル編 http://www.cross-party.com/programs/?p=138 http://www.ustream.tv/recorded/28598269 司会 Jackさん(@Jxck_) 以下J 大津さん(@jovi0608) SPDY関連 以下jovi 小松さん(@komasshu) Websockets 以下koma 清水さん(@kazubu) HTTP/2.0 以下kazubu HTTP2 2012/11最初のドラフト。絶賛議論中 どんなところが問題? kazubu: 前回のIETFの続きのトピック。crimeアタックに関して圧縮回り見直しとか
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が不
次世代規格 HTTP2.0 のファーストドラフト公開 - Block Rockin’ Codes
intro 少し経って、去る11月28日に、HTTP プロトコルの次期規格となる HTTP2.0 のドラフト、 draft-ietf-httpbis-http2-00 が、IETF の httpbis ワーキンググループで公開されました。 このドラフトは Google から提案された仕様である SPDY が採用されています。 HTTP1.1 からのアップデート HTTP1.1 の RFC が提出されたのは 1999 年で、 13 年経った今年 2012年8月 に、 HTTP の仕様を議論する httpbis というワーキンググループが、 HTTP1.1 のアップデート版になる仕様、 HTTP2.0 の策定を開始しました。 これは、 HTTP1.1 の仕様策定がある程度落ち着いてきたこと、次期仕様を考える良い時期であること、 そしてなによりも、 Web の使われ方が大きく変わり、 求められて
Mike Belshe「HTTP Speed+Mobilityレビュー」 - 以下斜め読んだ内容
belshe.com 2012.3.29のエントリ Comments on Microsoft’s SPDY Proposal « Mike's Lookout MSがIETFへ出したHTTP Speed+Mobilityへ、SPDYの仕様の作者の一人による項目別の寸評 MS案とSPDYの違い等がピンポイントで分かって有益 以下斜め読んだ内容 MS案ではコア部分はSPDYそのまま SPDYから取り込まれてるもの 多重化 リクエストの優先順位コントロール 圧縮 フレームのシンタックスもSPDYそのまま SYN_STREAM SYN_RESET SYN_REPLY HEADERS SPDYはwebsocketより古い歴史 「HTTP Speed+Mobility」では、シンタックスをwebsocketに似たものへ修正してる プロトコル面でSPDYと違いを生み出す変更ではない この修正でSPDY
SPDYメモ - 以下斜め読んだ内容
ニュースサイト記事、ホワイトペーパー等々斜め読んだだけではイマイチ掴めないSPDY 要するにこういうこと？、な話を箇条書き 出典等は後から追加 以下羅列 HTTPを50%高速化？ よく出るキャッチコピー SPDYは、SSL接続前提 厳密には、SSL強制じゃない SPDYのスペックにはSSL限定、となってない 作者的には「当然SSLでしょ」らしい Comments on Microsoft’s SPDY Proposal « Mike's Lookout SSL接続を高速化。の方が誤解が少ない気が。。 SPDYの実装：サーバー、ライブラリ experimentalなものもリリースされたもの、言語別、色々出てる SPDY公式サイトにリストあり SPDY - The Chromium Projects SPDYの実装：ブラウザ chrome、firefox、kindle fireに入ってるブラウ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【HTTP2.0最新動向】第2回：HTTP/1.1からのアップグレードメカニズム 11月に開催されたIETF85のhttpbisワーキング・グループから
【HTTP2.0最新動向】第1回：HTTP/2.0の策定、ついに始まる 
https://jp.techcrunch.com/2012/08/07/20120806http-20-spdy-and-friendly/