QUICの実装はTCP並みの効率を実現できるか？ Fastly奥氏らがベンチマークを紹介
現在標準化が進められている次世代HTTPの「HTTP/3」は、トランスポートプロトコルとして「QUIC」と呼ばれる新しいプロトコルを採用します。 現時点のHTTPはトランスポートプロトコルとして「TCP」が採用されています。その上で、可能な限り高速な通信が行えるようにさまざまな工夫や最適化が進められてきました。そしてもうこれ以上高速にしようとすると、TCPそのものを改善していくべきだろう、というところまできたのです。 それがHTTP/3で「QUIC」が採用される大きな理由といわれています。 TCPは内部で輻輳制御や再送などを自動的に行うことで通信が確実に行われることを保証してくれる便利なプロトコルですが、それゆえに、確実に通信が行われるまで待つ必要があるために通信環境によっては遅くなりがち、などの側面があります。 そこでQUICは、TCPのような通信の保証がない代わりにリアルタイム性の高い
キャッシュサーバの効率を改善するHTTP Variantsという提案仕様 - ASnoKaze blog
HTTP Variants IETFのHTTP WGやQUIC WGのチェアをしているmnot氏より、キャッシュの効率が改善する「Variants」というHTTPレスポンスヘッダを定義する「HTTP Variants」という提案仕様が出ています。 この機能は、Fastly VCLの機能の標準化のようです。 少々想定している背景がわかりづらいのですが、自分なりに簡単にまとめてみる。 背景 Webにおいて、サーバはクライアントからのリクエストヘッダを見てコンテンツを出し分けています。 例えば、Accept-Languageリクエストヘッダを見てコンテンツの言語を変更しています。キャッシュサーバももちろんこのAccept-Languageを見て、それぞれ毎にコンテンツをキャッシュする必要があります。 次の例を見てみましょう 1. ブラウザは下記のHTTPリクエストを送信する GET /foo H
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Fastlyのプログラマから見たCDN
