タグ

SPDYに関するsomemoのブックマーク (6)

  • HTTP/2 入門

    ストリームによる多重化 2つ目の特徴は「ストリーム」です。従来のHTTPでは、リクエストとレスポンスの組を1つずつしか同時に送受信できないことが、パフォーマンス上のボトルネックになっています。この問題を改善するべくHTTP/1.1では新たにパイプラインが導入されましたが、一部のレスポンスに時間がかかるような場面でレスポンスが詰まってしまう問題などがあり、広く使われてはいません。そこで、HTTP/2では1つの接続上にストリームと呼ばれる仮想的な双方向シーケンスを作ることでこの問題に取り組んでいます。 1つの接続上に作られた複数のストリーム上では、複数のフレームを同時並行で転送できます。例えば、あるストリーム上ではリクエストにあたるフレームが送信中でも、別のストリームではレスポンスにあたるフレームを受信するといったことが可能になります。これにより、全体的なパフォーマンスが向上します。 ヘッダー

    HTTP/2 入門
  • HTTP2CAT

    -v, --verbose Print debug information such as reception/transmission of frames and name/value pairs. -n, --null-out Discard download data. -s, --stat Print statistics. --no-tls Disable SSL/TLS. --no-connection-flow-control Disables connection level flow control. --no-stream-flow-control Disables stream level flow control. --upgrade Perform HTTP Upgrade for HTTP/2.0. This option is ignored if --no

  • なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes

    Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか? 何が問題で、なぜ Google はそれらを作り変えるのか? SPDY や QUIC は Google の独自プロトコルだけど、それは当にただの独自プロトコルで終わらせていいのか? 20% ルールで作ってみた Play プロジェクトでしかないのか? こうした新しい動きには、かならず「それまで」と「今」を踏

    なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
  • mod_spdyから学ぶSPDYとストリーム並列処理の実装

    人間とウェブの未来(旧) 「ウェブの歴史は人類の歴史の繰り返し」という観点から色々勉強しています。2014年までの人間とウェブの未来の旧ブログです。 HTTP関連の研究をしているので、そろそろ古い技術を詰めるばかりではなく(これはこれでとても大事な事なのですが)、新しい技術についても調べておきたいところです。 ということで、僕のSPDYに関する現状の理解を、mod_spdyに関する情報を元にまとめておきたいと思います。 SPDY概要 SPDYの概要を表す図としては、下記が良く用いられます。 TLS上にのせたSPDYストリーム上でHTTPやWebSocketを扱うプロトコルで、特徴としては、以下の4つがあげられます。 ストリームの並列化 フレームレイヤーやヘッダーの圧縮 リクエストの優先処理 サーバからのリソースプッシュ HTTP/2.0についても、SPDYを元に仕様が検討されています。では

    mod_spdyから学ぶSPDYとストリーム並列処理の実装
  • Module ngx_http_spdy_module

    Module ngx_http_spdy_module This module was superseded by the ngx_http_v2_module module in 1.9.5.

  • SPDYで複数のTCPコネクションをひとつにまとめるとはどういうことか - ゆううきブログ

    SPDYが流行っていて,複数のTCPコネクションを1つにまとめて高速化を図るらしいということは知っていた. しかし,単にTCPのコネクション数を抑えるだけならHTTP 1.1のKeep Aliveやpipeliningを使えばよいし,既存技術のどこが問題でSPDYはどう解決しているのかを調べてみた. SPDYの人でもWeb標準の人でもなんでもないので,間違いが多分含まれています. 並列TCPコネクション 並列にTCPコネクションを張る状況として,Webの世界においては以下の2つを思いつく. ブラウザがあるページをロードして,そのページに複数の画像ファイルが含まれており,それらを同時に取得するために並列にTCPコネクションを張り,HTTPリクエストを投げる. JSで非同期に複数のHTTPリクエストを投げる.1個のリクエストを投げるときに1個のTCPコネクションを張る. 並列TCPコネクション

    SPDYで複数のTCPコネクションをひとつにまとめるとはどういうことか - ゆううきブログ
  • 1