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
HTTP2のヘッダ圧縮 Huffman Encode の原理とメリット・デメリット - Qiita
この記事は HTTP2 Advent Calendar 2014 の 16 日目の投稿です。 HTTP2 では、通信の遅延を小さくするために、ヘッダのサイズを小さくする機構を備えています。 その仕様は HPACK と呼ばれ、下記の組み合わせで構成されます。 Literal ASCII Encoding 非圧縮のエンコーディングと言える。 Huffman 今回の主人公。 出現頻度が高い文字ほど、小さいデータサイズで表現。 Index 「Static Table に事前定義されている値」または「既にインデックス化した値」を番号で指定する。 圧縮に大きく寄与する。 今回は、Huffman Encoding の原理とメリット／デメリットを解説します。 gzip じゃダメなんですか？ HTTP/1.1 では、Body を gzip エンコードすることでサイズを圧縮することが出来ます。ヘッダも同じよう
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
