@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ヘッ
日本経済新聞は国内を代表する経済誌だ。その電子版はwebでの継続課金を大成功させ、いまや50万以上の有料会員を擁するモンスターサイトだ。 その日経電子版が11月6日に全面リニューアルしたのだが、公開後、web業界がにわかにざわついた。表示速度が爆速だったのだ。日経公式もモバイルで2倍の表示速度を達成したと堂々と宣言していた。 webサービスは継続率こそ神KPIで、その継続率には速度が大きく影響する。 これはチェキらないとヤバイと感じ、友人のkitakさんとスピードの秘密を調査してみた。 Fastlyをコンテンツキャッシュに使う殆どのデータはFastlyを経由して取得されていた。Fastlyは最近注目を集めているCDN（世界中にエッジサーバーを配置し、高速にコンテンツを配信するサービス）で、非常に高機能でユニークなサービスだ。 一般に、CDNはいったん世界中にコンテンツをばらまくと、それを無
Googleが新たに提唱するProgressive Web Appsの新たな開発パターン「PRPL」とは？ 小松 健作（NTTコミュニケーションズ） 「Google I/O 2016」では、これからのWebアプリ開発パターンとして提唱しているPWApps(Progressive Web Apps）について多くのプレゼンテーションがなされました。 PWAppsとは、最新のWeb技術を有効に活用し、漸進的（Progressive）に高度なユーザー体験を提供しようとする概念です。このPWAppsの概念を具体化する一つの手法として、「PRPL」（パープル）と名付けられた開発・提供パターンが提案されました。本稿ではこのPRPLを解説するとともに、その有効性や課題点を考察します。 本稿は、Google I/O 2016の二つのセッションに関する、解説記事です。 Polymer and Progress
東京でウェブオペレーションエンジニアをしている 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のサポートを切る
2. Copyright (C) 2016 DeNA Co.,Ltd. All Rights Reserved. 自己紹介 名前: 奥 一穂 ウェブ関連の基盤技術プログラマ ⁃ 主な業績（公開のもの） • Palmscape / Xiino (Palm OS向けウェブブラウザ) • Webブラウザプラグインを用いたサービス ⁃ Japanize, Mylingual, Pathtraq, ... • Q4M (MySQL用メッセージキュープラグイン) • Starlet (Perl用Webアプリケーションサーバ) • JSX (最適化コンパイラつきJavaScript方言) ⁃ M.I.T. TR100/2002, IPA未踏スーパークリエータ (2004), 日本/北東アジアOSS貢献者賞 (2015) 2HTTPとサーバ技術の最新動向
Webサーバのベンチマークをとるのが趣味になりつつあるmatsumotoryです。 Webサーバのベンチマークについては、abからはじまりwrk等を使っていたのですが、最近ではほぼh2loadを使っています。 h2loadはnghttp2というHTTP/2ライブラリのアプリケーションに含まれているツールですが、 HTTP/2（SPDYも）とHTTP/1.xに両対応している ベンチマーク側の同時スレッド数を増やせる TLS及びSNIもサポートしている 最小、最大、平均、標準偏差あたりもちゃんとでる ので、色々プロトコルを変えつつ同じベンチマークツールで、値の目安を出すにはとても重宝しています。 Nghttp2: HTTP/2 C Library - nghttp2.org 実行結果のサンプルは例えば以下、 $ h2load -c 100 -n 10000 https://localhost:
InfoQは先日，ThoughtWorksのMarko Vuksanovic氏とSam Gibson氏から，同社の月刊誌であるThought Works P2で公開された，TLS/HTTPSとHTTP/2に関する両氏の最近の調査について話を聞くことができた。両氏はユビキタスコンピューティング，TLS/HTTPSの働き，証明書信頼(certificate trust)，HTTP2のセキュリティへの影響といった，セキュリティに重点を置いた話題に関して，広範な専門知識を提供してくれた。 InfoQ: 今年は問題がいくつも公表されたことから，インターネットセキュリティが大きな話題になりました。今日の問題として，セキュリティがどの程度重要だとお考えですか？同じような問題が，今後も発生すると考えられている理由についても教えてください。 Vuksanovic/Gibson: セキュリティの問題は昨今に始
1. Copyright (C) 2015 DeNA Co.,Ltd. All Rights Reserved. HTTP/2時代のウェブサイト設計 DeNA Co., Ltd. Kazuho Oku 1
弊社インフラチームが使っているmuninをh2oのHTTP/2で高速化して、諸々の制御はmrubyでコントロールした。チームから「はやーい！」「スクロールで勝てない！」「こんな早い表示最近みたことなかったですよ！」と喜びの声が多数届いております。— MATSUMOTO, Ryosuke (@matsumotory) 2015, 7月 30 h2oをリバースプロキシで使えば、http://でのアクセスはHTTP/1.xでコンテンツを返しつつ、https://からのアクセスについてはHTTP/2＋TLSに対応したブラウザであればHTTP/2、対応していなければHTTP/1.xでコンテンツを返す事ができます。 また、h2oがmrubyによる機能拡張をサポートし、かつ、先日アクセス元IPアドレスをmruby内で参照することができるようになったので、IPアドレスを用いたアクセス制御もh2o+mrub
はじめに 私は自ら「串職人」と名乗るほどウェブの(つまりHTTPの）Proxyサーバが好きで、もう10年以上もプロキシサーバを作り続けています。このブログの主題であるクラウド型WAF、Scutumもそのひとつです。そもそもプロトコルとしてのHTTPが好きです。ウェブの裏側に、とてもシンプルな、テキストベースのHTTPプロトコルが活躍しているということが私の串職人としての出発点です。 HTTP/2が出た 先日、ついにHTTP/2が出ました。 数年前から、「SPDY」などのキーワードに代表される次世代のHTTPが模索されていることは何となく知っていましたが、どうもGoogleのような非常に大きいトラフィックを処理している組織が主導しているもので、一般の開発者やウェブの利用者にとってそれほど魅力的なものではなさそうだな、という印象を抱いていました。 サーバ側を作っているのもGoogle、ブラウザ
CreditThis article is translated with permission of Matt Wilcox. You can find original article at HTTP2 for front-end web developers.本記事はMatt Wilcox氏の了承を得て翻訳された記事です。 原文はHTTP2 for front-end web developersにて掲載されています。HTTP2は我々開発者のWebサイト作成の常識を変えるだろう。HTTP1におけるベストプラクティスはHTTP2の世界では害になってしまう。 HTTP1は今日におけるWebの大半において遅く非効率であるHTTP1.xは私達が最も慣れ親しんでいるHTTPのバージョンだ。HTTP1.xは、ワールドワイドウェブがどのようになるか予想できなかったときに設計された古いプロトコル
HTTPの次バージョンとなるHTTP/2の仕様を検討しているIETFのHTTPbisワーキンググループは、7月30日付けのHTTP/2のドラフト文書をもってワーキンググループのラストコールしたことを明らかにしました。 Working Group Last Call: draft-ietf-httpbis-http2-14 and draft-ietf-httpbis-header-compression-09 from Mark Nottingham on 2014-08-01 ([email protected] from July to September 2014) 同ワーキンググループは6月からラストコールへの動きを進めていましたが、7月30日に公開した14番目のドラフト文書で、課題としてリストアップされていた内容にすべて対応。これをもってラストコールとすると、8月1日付けのメーリ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
