Presentation material for TokyoRubyKaigi11. Describes techniques used by H2O, including: techniques to optimize TCP for responsiveness, server-push and cache digests.
![Developing the fastest HTTP/2 server](https://cdn-ak-scissors.b.st-hatena.com/image/square/ec2f71fee53da2e20c2da85aa6a9effdd0429ac4/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fhttp2-tokyorubykaigi-20160528-160528053255-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
ストリームによる多重化 2つ目の特徴は「ストリーム」です。従来のHTTPでは、リクエストとレスポンスの組を1つずつしか同時に送受信できないことが、パフォーマンス上のボトルネックになっています。この問題を改善するべくHTTP/1.1では新たにパイプラインが導入されましたが、一部のレスポンスに時間がかかるような場面でレスポンスが詰まってしまう問題などがあり、広く使われてはいません。そこで、HTTP/2では1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ることでこの問題に取り組んでいます。 1つの接続上に作られた複数のストリーム上では、複数のフレームを同時並行で転送できます。例えば、あるストリーム上ではリクエストにあたるフレームが送信中でも、別のストリームではレスポンスにあたるフレームを受信するといったことが可能になります。これにより、全体的なパフォーマンスが向上します。 ヘッダー
現在まで使われていたHTTPプロトコルはヴァージョンが1.1である。 インターネットが流行りだした当初では、インターネット回線も遅く、画像などを多量に取りれるような現在のWebページとは重くて表示が大変であったこともあり、そんなWebページは作らなかったから特に問題は無かった。 しかしながら、時が経ち、インターネットの速度向上により、Web2.0だとか言われるような、多量のCSS,Javascript,画像と、1つのページを表示するに対して、多量の通信が必要な状況となるわけで、実際には、1ページあたりに対して、4〜6コネクションが張られるわけで、サーバー側としても、大変だ。 コンテンツはキャッシュが利くから大丈Vとか思っている人もいるかもしれないけど、多いものでは1ページあたりの画像が100枚ぐらい存在するなどと言うサイトもあるわけで、これらのすべてがキャッシュ化されていたとしても、HTT
今まで http だったこのサイトを http2 対応しました。 静的ファイルもそうですが、このサイトで動いている kibana が体感で速くなった気がします(計測すればよかった)。 SSL 証明書は最近流行りの Let’s Encrypt ではなくて、温かみのある StartSSL で取得しました。パスワードではなく、証明書でのログインがいいですね。 どちらも無料で取得できます。前者はコマンドラインから取得できるが構成管理難しめ、後者はサイト上から手作業で取得が必要だが構成管理は容易、というおおざっぱな違いがあります。 今回学んだことは 「出来るだけ https 対応してから http2 対応すべし」 でした。雑に http2 にしたら 403 Forbidden や、Chrome で ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY が発生しハマりました。
Our works RFC7540 HTTP/2 (Japanese translation) RFC7541 HPACK (Japanese translation) HTTP/2 Frequently Asked Questions (Japanese translation) HPACK Test Case HTTP/2 Frame Test Case Our implementations nghttp2(Dockerfile) iij-http2 haskell-http2 H2O go-http2 sasazka h2spec Meetup HTTP/2 Study #7 (2015/5/21) HTTP/2 Party & Lightning Talks (2015/4/14) HTTP/2 Study #6 (2014/11/25) HTTP/2 Conference (2
私はWeb関連の基盤技術を20年くらいやっています。 最近の仕事としてはディー・エヌ・エーで「H2O」というWebサーバを開発していて、2016年2月に1.7.0をリリースしました。HTTP/2対応のWebサーバとしてはおそらく世界最速で洗練された実装だろうという評価をいただいています。 本日はサーバ技術をそもそもどういう評価軸でわれわれが見ているのか、HTTP/2の特長。そしてサーバプッシュとはなにか、HTTPS化はどれだけサーバ負荷が上がるのかについてのわれわれの見解。Webサーバ内でのスクリプト実行がどう変わってきているのか、といった話をしていきます。 サーバ技術の評価軸 サーバ技術の評価軸をどう考えているかですが、大きく分けて4つの項目で考えています。 サーバ負荷 転送データ量 応答性 設定・運用コスト まず「サーバ負荷」です。小規模なWebサイトではサーバ負荷はそれほど問題にはな
CEDEC2021 ダウンロード時間を大幅減!~大量のアセットをさばく高速な実装と運用事例の共有~ SEGADevTech
第3会FRESH勉強会で発表予定のスライド。HTTPについて詳しくない人のために HTTPの概要から先日RFC化されたHTTP/2の新機能、使いどころを解説します。
update 色々と twitter で議論が起こったのでまとめて貼っておきます。 togetter.com みなさんありがとうございました。 intro HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。 そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。 前提 今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。 また、本エントリ内では独自に以下の表記を採用します。 HTTP/1.1 = HTTP/1.1 (平文) HTTP/2 = HTTP/2 (平文) HTTPS/1.1 = HTTP/1.1 over
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く