LINEの技術的負債を解消している話 ─ HTTP/2へのプロトコル変更やデータ同期の最適化での改善 - エンジニアHub｜Webエンジニアのキャリアを考える！
LINEの技術的負債を解消している話 ─ HTTP/2へのプロトコル変更やデータ同期の最適化での改善 サービス開始から10年近くがたったLINEでは、次の10年のため技術的な負債を解消・改善する取り組みをプロジェクトで行っています。 通信プロトコルをSPDYからHTTP/2に移行 抽象化レイヤーを設置してプロトコル移行のリスクを低減 Long PollingをPushへと切り替えて通信量を最適化 アプリの利用状況に応じて最適なデータ同期の方法を アーキテクチャの改善でアプリの信頼性や拡張性が向上 長い歴史を持つアプリには「技術的負債をどのように解消するか」という課題が常につきまといます。2011年にサービスを開始したコミュニケーションアプリ「LINE」においても同様で、多機能化や、開発・運用の長期化に伴い、いくつもの負債が発生していました。 この課題を解決するため、LINE株式会社では「『
Cache Digest と HTTP2 Server Push の現状 | blog.jxck.io
Intro httpbis のチェアである mnot から、 Cache Digest についての現状確認が ML に投稿された。 もしこのまま反応がなければ、 Cache Digest は終わり、対ブラウザキャッシュの Server Push は現実的ではなくなる。 Update mozilla standard position に RFP を上げたところ「実装はしないが仕様については non-harmful」となりそうだ。 PFP: Cache Digest Issue #131 mozilla/standards-positions HTTP2 Push HTTP2 の仕様策定時に盛り込まれた新機能として、 Server Push があった。 これは、例えば RPC 的な用途で双方向性のある通信を可能にした。 Web においては、リクエストが来る前にレスポンスを返しキャッシュに入れ
20170923 HTML5 conf
<style>@import url(https://fonts.googleapis.com/css?kit=o--8Et3j0xElSo4Jk-6CSAFGo-MchFAIGu5CKlWXM1EvvZIgZwBiTNIhJtKEYYg8ZXvGa5rAyCS67Tm-e9xc_ay9IoC_ULKAe7pSeX5NV_ekCqzDYunJTA8OBHRTQO5mW2pEF5ucPKpGylPjUTAWMZhS5hQqBy02TDC_oCDwvqpDqyy6jwxckwyuxNKgFUCo3oGfszxNJDzdBnnyZVl30Bi6sGhdVb3ySsP8a0BH8ME);</style>
HTTP/2が速いという幻想 - Webパフォーマンスについて
難しい話じゃないです。 皆さん、ご自分でChrome Developer Toolで簡単に確認できますから、やってみて下さい。 このブログでも、過去に統計分析をした結果は掲載したんですが、「盲信」はそうそう簡単には消えないようでして… takehora.hatenadiary.jp takehora.hatenadiary.jp 以下の図は、Chrome 63.0.3239.108での結果です。 CDNにFastlyでもAWS CloudFrontでも、どのCDNを使って実験して頂いても結構です。 CDNを使わずに、Webサーバ単体でも結構です。 同様の結果になります。 どちらもHTTPS通信です。 どちらも同じオリジン、同じファイル構成です。 HTTP/1.1は、Keep-Alive設定が入っています。 HTTP/1.1での配信 … Load Event 70ms HTTP/2での配信
リニューアルした日経電子版が高速すぎてヤバイ件｜こんぴゅ
日本経済新聞は国内を代表する経済誌だ。その電子版はwebでの継続課金を大成功させ、いまや50万以上の有料会員を擁するモンスターサイトだ。 その日経電子版が11月6日に全面リニューアルしたのだが、公開後、web業界がにわかにざわついた。表示速度が爆速だったのだ。日経公式もモバイルで2倍の表示速度を達成したと堂々と宣言していた。 webサービスは継続率こそ神KPIで、その継続率には速度が大きく影響する。 これはチェキらないとヤバイと感じ、友人のkitakさんとスピードの秘密を調査してみた。 Fastlyをコンテンツキャッシュに使う殆どのデータはFastlyを経由して取得されていた。Fastlyは最近注目を集めているCDN（世界中にエッジサーバーを配置し、高速にコンテンツを配信するサービス）で、非常に高機能でユニークなサービスだ。 一般に、CDNはいったん世界中にコンテンツをばらまくと、それを無
Fastly に入社しました
Summary in English: Joined Fastly, will continue my work on H2O there as an open-source developer. 2017年1月1日付で、Fastly 社へ転職したので報告いたします。 過去５年間、DeNA では R&D 的な立場から、様々な基盤的ソフトウェア（オープンソースになったものもありますし、クローズドなものもあります）の開発に携わってきました。 最近２年間は、同社のゲーム用サーバに端を発するオープンソースの HTTP/2 サーバ「H2O」の開発に従事してきましたが、その実装品質が高く評価され、世界有数のコンテンツ配信ネットワーク（CDN）である Fastly で採用された他、大規模なウェブサービス事業者で採用にむけた動きが進むなどの成果が出つつあります。 また、H2O における実装経験をもとに、H
TLS 1.3 開発日記 その3 バージョン - あどけない話
これは、http2 Advent Calendar 2016の7日目の記事です。 今回はTLSのバージョンについて書きます。TLSのバージョンは、Client Hello と Server Hello を交換することで決めます。 Client Hello TLS 1.3 の Client Hello は、TLS 1.2 と互換性を維持するために、構造が死守されています。 TLS 1.2 の Client Hello の定義はこう： struct { ProtocolVersion client_version; Random random; SessionID session_id; CipherSuite cipher_suites<2..2^16-2>; CompressionMethod compression_methods<1..2^8-1>; select (extension
Googleが新たに提唱するProgressive Web Appsの新たな開発パターン「PRPL」とは？
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
HTTP/2 Protocol for iOS Push Notification Server(APNS)
Apple has recently updated the protocol push notifications delivery service, called APNS. The newer version of this protocol is based upon HTTP/2 and JSON, which signals a huge improvement compared to the older binary protocol. News HTTP/2 based APNS Protocol New features and capabilities: A JSON based request response protocol APNS will send 200 Success Response on each notification - No more gue
2015 年をふりかえる - Block Rockin’ Codes
Intro 個人的には HTTP2 と ORTC/WebRTC と Service Worker 周りさわって、 JS と Go を書いてる一年だった。 Extensible Web - Progressive Web APP Extensible Web で始まった話が、様々な API の設計に適用された。 結果手に入った Service Worker を始めとする Low Level API を組み合わせて、もう一度モバイルと Web の関係を見直す Progressive Web App まで進み、 Web の形が見直された年だった。 Extensible Web の夜明けと開発者が得た可能性の話 - Block Rockin’ Codes HTTPS また、 HTTPS の重要性の認識が、啓蒙からデプロイまで降りたという印象。そして、待望だった Let's Encrypt がついに
h2load を使おう - あどけない話
これはhttp2 Advent Calendar 2015の25日目の記事です。 これまで web サーバのスループットを図るには weighttp が定番でしたが、これから h2load を使いましょう。 h2load は、nghttp2と一緒に配布されているベンチマークツールです。以下のような特徴があります。 ApacheBench を世襲したコマンドラインオプションを提供しています。 weighttp のように、計測側のマルチコア環境を活かすことができます。 weighttp で計測できるのは HTTP/1.1 のみでしたが、HTTP/1.1 over TLS、HTTP/2、HTTP/2 over TLS も計測できます。 対象プロトコルは以下のように切り替えます。 プロトコル 平文 TLS HTTP1.1 h2load --h1 http:// h2load --h1 https:
HTTP/2がつなぐSEOとフロントエンド開発の未来 - beijaflor
この投稿はhttp2 Advent Calendar 2015の24日目の記事として インフラ系の人がHTTP/2推進を頑張ってくれると、私のようなフロントエンドやSEOに関わる人間が幸せになるので、ぜひ、とにかく、なんとしてでも頑張っていただきたい！という応援のメッセージを送りたいという思いが形になったものです。 11月末。Googleの中の人でも飛び抜けて有名なジョン・ミュラー氏がGoogleのクローラーがHTTP/2に対応すると発表しました。 さらに、その中でランキング要因としても影響すると明言。SEO業界に衝撃が走りました。 Why Everyone Should Be Moving To HTTP/2 さらに、CDN大手のCloudflareがデフォルトでHTTP/2に対応するなど、時代の波は確実にHTTP/2に来ています。 Cloudflareが全ユーザにデフォルトでHTTP/
curl and HTTP/2 by default | daniel.haxx.se
Followers of this blog know that I’ve dabbled with HTTP/2 stuff for quite some time, and curl got its initial support for the new protocol version already in September 2013. curl shipped “proper” HTTP/2 support as it looks in the final specification both for the command line tool and the libcurl library before any browsers did in their release versions. (Firefox was the first browser to ship HTTP/
HTTP/2のNode.js実装node-http2を読む - Qiita
この記事は、http2 Advent Calendar 2015 の21日目の記事です。 はじめに HTTP/2のNode.jsでの実装node-http2を読んだので、ポイントだと思うところについて大まかに書きます。 node-http2ってどんな感じなの HTTP/2はどういう風に実装できるの Node.jsのStream APIの良い使用例ないかな みたいなことを知りたい人の手助けになればと思います。 扱うnode-http2のバージョンは3.2です。 Stream API node-http2ではNode.jsの主要なAPIであるStream APIがよく使われています。 全く知らない人のために概要だけまとめました。 HTTP/2の重要な概念としてStreamがありますがそれとStream APIは別のものです。 今回は単にStreamと書いた場合はHTTP/2としてのStream
HTTP/2 のコネクション再利用について確認してみる - ブログ・ア・ラ・クレーム
はじめに 本記事は http2 Advent Calendar 2015 の 12 日目の記事となります。 本記事では HTTP/2 における TCP コネクション再利用とその周辺仕様を確認してみようと思います。コネクション再利用の挙動を理解することは、実際の Web サイトにおける HTTP/2 のデプロイの助けになると思われます。 HTTP/1.1, HTTP/2 での TCP コネクション管理 よく訓練された方々には既知のことかとは思いますが、 HTTP/2 において HTTP/1.1 の頃にあった性能向上の為のハックであるドメインシャーディングは好ましくないテクニックになってしまいます。 HTTP/1.1 において今日のブラウザは 1 ドメインあたり概ね 6 TCP コネクションほど張って、並列にリクエストを送るような振る舞いをします。このため Web サイトなどで参照するドメイン
HTTP/2 のエラーハンドリングと Request Reliability Mechanism - Qiita
この記事で伝えたいこと HTTP/2 では、「stream」と「frame」と呼ばれる構造を導入することで、複数のリクエストを 1 つの TCP セッションで送受信できるようになりました。この構造の変化に伴い、HTTP/1.1 以前には存在しなかったエラーがあります。 そこで、この記事では HTTP/2 で新たに考慮すべきエラーを洗い出し、どう対処すべきなのかを整理します。 付録として、HTTP/2 のエラーを活用することで実現した「Request Reliability Mechanism」を説明します。 1. 変わらない部分：ステータスコード HTTP/1.1 で利用していた「404 Not Found」や「500 Internal Server Error」などのステータスコードは、HTTP/2 にそのまま引き継がれます。したがって、HTTP アプリケーションで発生するエラーは、HT
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - dunglas/vulcain: Fast and idiomatic client-driven REST APIs.
脆弱性発見者が注目する近年のWeb技術
ウェブを速くするためにDeNAがやっていること - HTTP/2と、さらにその先
GitHub - summerwind/h2a: Debugging reverse proxy for HTTP/2 developers