pixivのHTTP/2有効化の軌跡 - pixiv inside
@catatsuyです。普段はpixivの技術的な改善や広告周りを見ています。今回はHTTP/2の話を紹介します。 HTTPS化とHTTP/2について 以前紹介したようにpixivは2017/4/18にHTTPS化を完了していました。 pixivを常時HTTPS化するまでの道のり（前編） - pixiv inside pixivを常時HTTPS化するまでの道のり（後編） - pixiv inside 昨今ブラウザで使える新しい技術はHTTPSが必須要件とされることが多くなりました。その中の代表格がHTTP/2です。HTTP/2自体はHTTPSを要求していませんが、実際にはHTTPSでなければブラウザ側で有効にならないため必須です。 HTTP/2に対応するメリットは他の詳しい記事を参照して欲しいですが、ざっくり以下のメリットがあります。 HPACKという仕様でハフマン符号を使ったHTTPヘッ
HTTP/2 クロスオリジン サーバプッシュを可能にする提案仕様 - ASnoKaze blog
ちょっと不明瞭な部分が修正できてません。すみません。 20180824追記 Loading Signed Exchangesについて記事を書きました Loading Signed Exchangesの仕様 (WebPackaging) - ASnoKaze blog 20180213補足 「Origin-signed HTTP Responses」は「Signed HTTP Exchanges」に改称されました。 この仕様では、HTTP Exchange(リクエストとレスポンス)両方を署名対象にし、それらの署名値であるSignatureヘッダをレスポンスヘッダに追加して返します。署名値を計算するために一旦リクエストレスポンスをCBOR形式にシリアライズします。 ただHTTP Exchangeに署名をする仕様という点に注意が必要です 20180208追記 Bundled HTTP Excha
HTTP の新しいステータスコード 103 Early Hints | blog.jxck.io
Intro これは、 http2 Advent Calendar 2016 の 16 日目の記事である。 HTTP に新しいステータスコード 103 Early Hints が追加されようとしている。 HTTP/1.1 および HTTP2 双方と関わり、リソース配信の最適化に利用することができる。 いったい何のために必要なのか、どういうメリットが考えられるかを解説する。 HTTP2 Push の復習 まず HTTP2 の Push について復習する。 H2 Push は、簡単に言えば PUSH_PROMISE フレームを用いて、レスポンスよりも先に依存するリソースを返すための仕様である。 例えば /users のレスポンスは script.js と style.css をサブリソースとして含んでいるとする。 HTTP2 では SQL を発行して Users の一覧を取得している間に、先行し
New – AWS Application Load Balancer | Amazon Web Services
AWS News Blog New – AWS Application Load Balancer We launched Elastic Load Balancing (ELB) for AWS in the spring of 2009 (see New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatch to see just how far AWS has come since then). Elastic Load Balancing has become a key architectural component for many AWS-powered applications. In conjunction with Auto Scaling, Elasti
Gaurun Powered by HTTP/2 | メルカリエンジニアリング
SREチームの@cubicdaiyaです。つい先日メルカリでOSSとして開発・公開しているスマホアプリ向けのプッシュ通知用ゲートウェイサーバであるGaurunがGCM、APNsともにHTTP/2を利用したプッシュ通知に対応したので紹介します。 github.com ちなみにロゴも出来ました。 Gaurun〜A general push notification server in Go〜 繰り返しになりますが、GaurunはメルカリでOSSとして開発・公開しているスマホアプリ向けのプッシュ通知用ゲートウェイサーバです。GCMやAPNsへのプッシュ通知処理をHTTP + JSONベースの非同期処理APIでラップして大量のプッシュ通知を素早く送信することができるのが特徴です。 github.com メルカリのプッシュ通知のシステムもこのGaurunにより構築されています。クライアントとの通信に
AWSでのHTTP/2 or SPDY運用の課題とPROXY protocol - Hatena Developer Blog
東京でウェブオペレーションエンジニアをしている id:dekokun です。 本記事ではAWSでELBを使用してHTTP/2 or SPDYを運用する上で直面する問題としてのクライアントのIPアドレスが分からなくなる問題の紹介を行い、その後に解決策としてのPROXY protocolの紹介・PROXY protocolの設定方法について記載します。 この記事は先日公開しましたAWS EC2でのHTTP/2 or SPDY導入方法 - Hatena Developer Blog (以下、"前回の記事"と呼びます) の続編となります。 ELBのTCPモードにおける問題点 解決策としてのPROXY protocol PROXY protocolが必要となる技術的背景及びPROXY protocolの動作 ELB + nginx構成でのPROXY protocolの設定方法 ELBの設定 ngin
サイトの最適化 | tech - 氾濫原
HTTP2 化に伴なって、サイト全体の最適化を行ないました 依存の整理 もはや jQuery なしでも簡単に書けそうなスクリプト部分から jQuery 依存を抜きました。また、JSDeferred を Promise で置き換えました。 script 要素の async / defer script 要素については必要に応じて async や defer をつけるようにし、基本的に外部スクリプトでブロックする可能性を排除しました。 async は script 要素同士で独立している場合無条件につけられます (非シーケンシャル)。defer はページのDOMが構築されたあとに実行されるように遅延されます (シーケンシャル) defer は DOMContentLoaded 直前にまとめて呼ばれるようです。 外部ライブラリを自分でホスト 外部ライブラリをCDN経由でロードしている部分がありま
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のサポートを切る
HTTP/2 is now in General Availability
HTTP/2 is now in General AvailabilityWe’re pleased to announce that HTTP/2 is now in General Availability (GA). Our team has been working diligently to tightly integrate HTTP/2 support into our existing environment. We’ve taken measures to ensure that our design and testing of this component adheres to the HTTP/2 protocol standards and can be seamlessly deployed across our entire network. Enabling
HTTP2 を前提とした HTML+CSS コンポーネントのレンダリングパス最適化について | blog.jxck.io
Intro Chrome が予定している <link rel=stylesheet> の挙動の変更について、 Google Chrome チームの Jake が、興味深いブログを上げている。 The future of loading CSS この内容は、単に Chrome に対する変更だけではなく、 HTTP2 によって変化する最適化手法と、それを最も活かすための HTML, CSS の構成についてのヒントがある。 今回は、この内容を意訳+補足解説し、本サイトに適用していく。 HTTP/1.1 時代の CSS HTML 自体がコンポーネントを意識した作りになっている場合は、自然と CSS も class などを使いコンポーネント単位に作ることができるだろう。 しかし、 HTTP/1.1 では、リクエストの数を減らすために全ての CSS を 1 つ(もしくは少数個)に結合する最適化が主流だ
h2o試してみました、もしくはとりあえずサクッと既存のサイトをHTTP/2化する方法 - （ひ）メモ
先日、HTTP/2が正式な仕様として承認されると同時に、その実装であるH2Oのv1.0.0もリリースされました。 Kazuho's Weblog: H2O, the new HTTP server goes version 1.0.0 as HTTP/2 gets finalized HTTP/2の情報はちょいちょいウォッチはしていたのですが、今までHTTP/2なサーバーを動かしたことはなく、いい機会なので自分のサイトをH2Oを使ってHTTP/2対応してみました。 https://www.irori.org 大したことはやってないのですが、Apacheでサービスしており、認証やアクセス制限、ごにょごにょ黒魔術、CGI(!)やSSI(!!)なども動いているので、ApacheをH2Oにリプレースするのは無理でした。 そこで、H2Oをリバプーとして前段に置き、Apacheを後段に置く構成にしまし
HTTP2 のフロー制御 - Qiita
この記事は HTTP2 Advent Calendar の 1 日目の記事です。 初回は、執筆時点での最新ドラフトである HTTP2-draft16 のフロー制御(Flow Control) について解説します。 余談ですが, 現在の仕様では "HTTP2.0" ではなく "HTTP/2" もしくは "HTTP2" が正しい名称です. 更新 @kazu_yamamoto さんに指摘頂いた点を反映しました。 @kiri__n さんに指摘頂いた点を反映しました。 詳細については 更新履歴 をご覧下さい。 HTTP2 では、同じホストへの複数のリクエストを、同一の TCP コネクション上にストリームという単位で多重化することができるようになりました。 フロー制御とは、例えばひとつのストリームがリソースを占有してしまうことで、他のストリームがブロックしてしまうことを防ぐ、といった目的で行われます。
HTTP/2 入門
ストリームによる多重化 2つ目の特徴は「ストリーム」です。従来のHTTPでは、リクエストとレスポンスの組を1つずつしか同時に送受信できないことが、パフォーマンス上のボトルネックになっています。この問題を改善するべくHTTP/1.1では新たにパイプラインが導入されましたが、一部のレスポンスに時間がかかるような場面でレスポンスが詰まってしまう問題などがあり、広く使われてはいません。そこで、HTTP/2では1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ることでこの問題に取り組んでいます。 1つの接続上に作られた複数のストリーム上では、複数のフレームを同時並行で転送できます。例えば、あるストリーム上ではリクエストにあたるフレームが送信中でも、別のストリームではレスポンスにあたるフレームを受信するといったことが可能になります。これにより、全体的なパフォーマンスが向上します。 ヘッダー
HTTP2を試してみる | GREE Engineering
初めまして、インフラストラクチャ本部の後藤です。普段はChefを用いたサーバの自動構築環境の開発に従事しております。 今回は、近頃若者の間でも話題になっているHTTP2についてお話したいと思います。 2012年の末頃、HTTP1.1のセマンティクスを維持したままパフォーマンスを改善するという目的でHTTP2の仕様策定が開始されました。そんなHTTP2もワーキンググループ・ラストコールに向けて大詰めを迎えています。 現在最新版はdraft12となっており、すでに幾つかの実装が存在しています。HTTP2のwikiで確認できます。例えば、Google ChromeのCanaryビルドやFirefox Nightlyビルド では既にHTTP2が使用可能です。 またサービスとしては、twitter.com が対応しています。 HTTP2の特徴 HTTP2はGoogleの考案したSPDYと言うプロトコ
人間とウェブの未来 - 軽量な静的コンテンツ配信における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と使い方が似て
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
HTTP/2で 速くなるとき ならないとき
SHOP
インフラエンジニアのための次世代プロトコル入門 -
July TechFesta 2014