カオステストでHTTP/2の問題を見つけ出す | POSTD
(注：2017/04/20、いただいたフィードバックを元に翻訳を修正いたしました。修正内容については、 こちら を参照ください。) 要約 HTTP/2 にはHTTP/1.xに比べて多数の改良点がありますが、 カオステスト を行ったところ、HTTP/2のパフォーマンスがHTTP/1より劣る状況があることが分かりました。 ネットワーク上にパケット損失がある場合、TCP層での輻輳制御によって、少数のTCPコネクションの中に多重化されているHTTP/2ストリームがスロットリングされます。さらに、TCPリトライのロジックにより、リトライが行われている間、1つのTCPコネクションに影響しているパケット損失が、いくつかのHTTP/2ストリームに同時に強い影響を与えます。言い換えれば、ヘッドオブラインブロッキングが事実上、ネットワーク階層の レイヤ7 から レイヤ4 へ移動したということです。 背景とサー
レイテンシに負けないプロトコルとして登場したHTTP/2～奥一穂氏による「HTTPとサーバ技術の最新動向」（前編）。Developers Summit 2016
私はWeb関連の基盤技術を20年くらいやっています。 最近の仕事としてはディー・エヌ・エーで「H2O」というWebサーバを開発していて、2016年2月に1.7.0をリリースしました。HTTP/2対応のWebサーバとしてはおそらく世界最速で洗練された実装だろうという評価をいただいています。 本日はサーバ技術をそもそもどういう評価軸でわれわれが見ているのか、HTTP/2の特長。そしてサーバプッシュとはなにか、HTTPS化はどれだけサーバ負荷が上がるのかについてのわれわれの見解。Webサーバ内でのスクリプト実行がどう変わってきているのか、といった話をしていきます。 サーバ技術の評価軸 サーバ技術の評価軸をどう考えているかですが、大きく分けて4つの項目で考えています。 サーバ負荷 転送データ量 応答性 設定・運用コスト まず「サーバ負荷」です。小規模なWebサイトではサーバ負荷はそれほど問題にはな
21世紀のエンジニアのためのHTTP/2入門 | κeenのHappy Hacκing Blog
第3会FRESH勉強会で発表予定のスライド。HTTPについて詳しくない人のために HTTPの概要から先日RFC化されたHTTP/2の新機能、使いどころを解説します。
HTTP2 時代のサーバサイドアーキテクチャ考察 - Block Rockin’ Codes
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
HTTP/2の現状とこれから
The document discusses graph databases and their properties. Graph databases are structured to store graph-based data by using nodes and edges to represent entities and their relationships. They are well-suited for applications with complex relationships between entities that can be modeled as graphs, such as social networks. Key graph database technologies mentioned include Neo4j, OrientDB, and T
HTTP/2から見えるTLS事情 - あどけない話
これは HTTP/2 アドベントカレンダー19日目の記事です。 この記事はたくさんの資料を読んだ上で書きましたが、間違いとか勘違いとかがあるかもしれません。もしあれば、指摘していただけると幸いです。 実質的に必須となったTLS HTTP/2は、HTTP/1.1と同じく、暗号化なし/ありのポートとして、80と443を使います。そのため、通信開始時にHTTP/1.1とHTTP/2をネゴシエーションするための仕組みが、HTTP/2で定められています。 このように仕様としては暗号化なしのHTTP/2が定義されていますが、Firefox や Chrome が TLS を要求するために、実質的は暗号化ありが必須となっています。これは、米国の監視プログラムPRISMに代表される広域監視(pervasive surveillance)に対抗するために、IETFがさまざまな通信にプライバシの強化を要求する方
QUICの技術要素分解
この投稿はHTTP2 Advent Calendar 2014の18日目の記事です。 前日は HTTP2におけるProxyに関する議論 でした。 (あらすじ・前略) もっこすにはHTTPがわからぬ。もっこすは、ただのゲーマーである。ヴァナディールで市場価格操作に命を懸け、艦娘と遊んで暮らしてきた。けれどもトランスポート層のプロトコルについては、人一倍に敏感であった。 HTTP2とは直接関係ないので、念のため概要を説明してから進みます。HTTP2勉強会 #hｔtp2studyシリーズに参加されている方だと、もうご存知の方が多そうな気はしますが、とりあえず。 QUICとは、Googleが開発しChromiumに実装中のトランスポート層、すなわちTCPと同じ層のプロトコルです。Internet上で運用される独自実装トランスポートの常として、UDPで包んだ中に独自実装が入っています。 QUICの主
IETF89 で #http2study の話をしてきました。 - Block Rockin’ Codes
Intro 2014/3/2 ~ 3/7 にイギリスのロンドンで実施された IETF89 に参加し、HTTP2 について議論している httpbis というワーキンググループで、日本での HTTP2.0 に関する Local Activity (コミュニティ活動とその成果)について発表してきました。 IETF IETF は、ネットに関わる「Wire より上、Application より下」のレイヤの標準仕様などを決める標準化団体です。 IETF には、さらに目的に特化した WG(Working Group) に分かれており、最近自分が取り組んでいる HTTP2 はこの IETF の中の httpbis という WG で議論されています。 今回色々な方の助けもあり、幸運が重なって、初めて IETF に参加することができました。 とりあえず旅行記的に書いてみます。 -2日目(出発) 日本での土
Webを支えるプロトコル - ASnoKaze blog
若者のプロトコル離れが叫ばれて久しいが、最近プロトコルは非常にホットな分野である。 目まぐるしく進化するWebに合わせ、プロトコルの世界も着実に進化している。 今までブラウザでは出来なかった事が出来るようになり、Webサービスをより安全に使えるようになった。 そしてWebのパフォーマンスを大きく改善するためにHTTP2.0も議論されている。 Webを支えるプロトコルとして、大きく分けて３つに分けられるかと思う（私の勝手なイメージ、正確な図ではありません） Webアプリケーション ブラウザが今まで出来なかったことを出来るようにしたり、Webアプリケーションの認証・認可などの機能を提供するプロトコルなど。JSやサーバサイドプログラミングで利用したりする。 WebSocket (http://tools.ietf.org/html/rfc6455) ブラウザとWebサーバの間でソケット通信を行う
なぜ QUIC や SPDY が生まれたのか ? - Block Rockin’ Codes
Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか？ 何が問題で、なぜ Google はそれらを作り変えるのか？ SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか？ 20% ルールで作ってみた Play プロジェクトでしかないのか？ こうした新しい動きには、かならず「それまで」と「今」を踏
Googleが仕掛ける新プロトコルQUICとは何か - ぼちぼち日記
まずは免責事項。 1.Disclaimer 本ブログの記載内容は、筆者が独自に QUIC に関する Chromium のソースを分析し、検証した結果です。 QUICに関するGoogle からの公式な技術資料は現状公開されていません。 今後、QUICの技術仕様の公表で本ブログの記述内容が不十分だったり、誤っている可能性があります。ご理解の上お読みください。 (注： 2013年6月27日に Google は正式に QUIC 仕様を公開しました。「Experimenting with QUIC 」 本ブログの内容は大筋では間違っていませんが、当時の解析漏れやその後の開発等により、細かいところで異なっていたり、説明が大きく不足している部分もあります。お読みになる際はご注意ください。) 2. はじめに、 Googleがまたまた新しいプロトコルの実装を始めました。Web表示の高速化を目指した SPDY
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
