HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）
HTTP/3はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編） Webの世界では新しいHTTPの標準として「HTTP/3」の策定が進み、現在最終段階にあります。このHTTP/3はこれまでのHTTPをどのように改善し、高速化を実現していくのでしょうか。 2020年11月25日と26日にオンラインで開催されたFastly Japan主催のイベント「Yamagoya Traverse 2020」のセッション「Webを加速するHTTP/3」で、同社の奥一穂氏がHTTP/3の解説を行っています。 奥氏はHTTP/3に対応したHTTPサーバ「H2O」の開発を行うだけでなく、IETFでHTTP/3の標準策定にも関わるなど、日本においてもっともHTTP/3に詳しい人の一人であるといえます。 本記事では奥氏のセッションをダイジェストで
ChromeのHTTP/2サーバプッシュサポート廃止検討と、103 Early Hintsについて - ASnoKaze blog
ChromeがHTTP/2サーバプッシュの廃止を検討し始めている。またPreload + 103 Early Hintsの有効性について実験していく模様 背景 HTTP/2(RFC 7540) にはサーバプッシュという機能があります。これは、クライアントからのHTTPリクエストをまたずにサーバがHTTPレスポンスを先行して送ることが出来る機能です。 たとえば、index.htmlに画像1,2,3が含まれているようなページがあるとします。このindex.htmlへのリクエストを受け付けたサーバは、クライアントが画像1,2,3がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。（クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます） そうすることで、ページの表示を効率化出来ると考えられていました。 しかし、様々な議論の中
Chrome への HTTP/3 と IETF QUIC の導入について
.app 1 .dev 1 #11WeeksOfAndroid 13 #11WeeksOfAndroid Android TV 1 #Android11 3 #DevFest16 1 #DevFest17 1 #DevFest18 1 #DevFest19 1 #DevFest20 1 #DevFest21 1 #DevFest22 1 #DevFest23 1 #hack4jp 3 11 weeks of Android 2 A MESSAGE FROM OUR CEO 1 A/B Testing 1 A4A 4 Accelerator 6 Accessibility 1 accuracy 1 Actions on Google 16 Activation Atlas 1 address validation API 1 Addy Osmani 1 ADK 2 AdMob 32 Ads
Chrome is deploying HTTP/3 and IETF QUIC
$200K 1 10th birthday 4 abusive ads 1 abusive notifications 2 accessibility 3 ad blockers 1 ad blocking 2 advanced capabilities 1 android 2 anti abuse 1 anti-deception 1 background periodic sync 1 badging 1 benchmarks 1 beta 83 better ads standards 1 billing 1 birthday 4 blink 2 browser 2 browser interoperability 1 bundles 1 capabilities 6 capable web 1 cds 1 cds18 2 cds2018 1 chrome 35 chrome 81
QUIC vs TCP: Which is Better? | Fastly
Why FastlyProductsServicesSolutionsDevelopersPartnersResourcesPricing QUIC matches TCP's efficiency, says our research. | FastlyWe’ve shared a lot about how much we love QUIC (and why we’re building our own implementation called quicly). It promises latency reduction, improved throughput, resilience to client mobility, and increased privacy and security. Excitingly, the QUIC working group at the I
QUICむけにAES-GCM実装を最適化した話 (2/2)
前半で述べたように、OpenSSLのAEAD暗号器は、長いAEADブロックの処理を前提に作られています。平文の暗号化処理においては理論上の上限にあたる速度を叩き出す一方、事前処理と事後処理、および呼出オーバーヘッドについては、あまり最適化が図られているとは言えません。これは、AEAD暗号の主な使用用途が、これまでTLSという長いAEADブロックを使う（ことが一般的な）プロトコルであったことを反映していると言えるでしょう。 一方、QUICにおいては、UDPパケット毎に独立した、短いAEADブロックを暗号化する必要があり、したがって、次のような速度向上の機会があることが分かります。 AEAD処理をひとつの関数にまとめ、事前処理と事後処理を、パイプライン化されスティッチングされた暗号処理と並行に走らせることができれば、AEADブロックが短くても、理論値に近いスループットを発揮するような、AES-
QUICむけにAES-GCM実装を最適化した話 (1/2)
4月末に、会社のほうで「Can QUIC match TCP’s computational efficiency?」というブログエントリを書きました。我々が開発中のQUIC実装であるquiclyのチューニングを通して、QUICのCPU負荷はTLS over TCP並に低減可能であろうと推論した記事です。この記事を書く際には、Stay Homeという状況の中で、手元にあった安いハードウェアを使ったのですが、その後、10gbe NICを入手し、ハードウェアによるUDP GSOオフロード環境でのパフォーマンスを確認していくと、OpenSSLのAES-GCM実装がボトルネックになることがわかってきました。 TCP上で通信するTLSでは、一般に、データを16KB単位でAEADブロックに分割して、AES-GCMを用いてAEAD暗号化します注。一方、UDPを用いるQUICでは、パケット毎にAES-GC
Implementing HTTP/3 in Haskell - あどけない話
Mew.org is now speaking HTTP/3 (HTTP/2 over QUIC). If you gain access to the site using Firefox Nightly, the first connection would be HTTP/2 then the following connections should be HTTP/3 led by Alt-Svc:. Firefox Nightly This article explains insights which I found through the implementation activities of QUIC and HTTP/3 in Haskell. HTTP/2 server library I started implementing QUIC in January 20
「パケットの設計から見るQUIC」の訂正 - あどけない話
QUICは、一年半実装を続けている僕でも全容を把握できているとは言い難いほど大きなプロトコルですが、ある側面をさっと理解するには、n月刊ラムダノート Vol.2, No.1(2020)に西田さんが書かれた「パケットの設計から見るQUIC」がオススメです。ただ、QUICの専門家から見ると、若干不正確な部分がありますので、訂正すべき箇所をまとめておきます。(遅くなって、すみません。) 記事を公開することは西田さんにお知らせしていますが、ここに書いてある内容はあくまで僕の意見です。 最初のページ 「QUIC(Quick UDP Internet Connections)は、インターネットのアーキテクチャ 上で利用可能な、高い信頼性を提供する仕組みとして設計されたトランスポートプロ トコルです。」 IETF で標準化している QUIC は、「Quick UDP Internet Connectio
TCP/QUIC相互変換のポートフォワードツールを書いた - ASnoKaze blog
TCP/QUICのポートフォワードツールを書いた。 概要 IETFで標準化が進められているトランスポートプロトコルQUIC。 UDPを利用しており、エンドポイントのIPアドレスが変わってもコネクションが切れなかったり、より良い再送制御が行えたりと長所は多くある。しかし、QUICをサポートしているアプリケーションプロトコル、実装が現状多くはない。 QUICの恩恵に預かるために、TCPとQUICを相互変換するポートフォワードツール 「t2q2t」 を書いた。(実態としてはただのProxy) github.com ただし、ハンドシェイク回数が増えるのでコネクション確立時のオーバーヘッドは高い 利用例 ユースケースとしては例えば: クライアントとサーバそれぞれでt2q2tを実行する。 クライアント: TCPで0.0.0.0:2022でリッスンし、QUICで192.168.0.1:22に転送する サ
Googleが開発してるらしい QUIC as a VPN (QBone)について (2020年更新) - Qiita
(落ちの無い話です) [追記] IETF107 (2020/03/25)において、Googleでの利用例が共有されました。それについて、記事最後に追記しました。 公式な情報はまだないが、GoogleがQUICコネクションをVPNとして利用する「QUIC as a VPN (QBone)」なるものを作ってるのは窺い知ることができる。 2017年6月に、GoogleでQUICの開発に携わっているIan Swett氏より「QUIC Messages」という提案書が出ている。この提案書の、提案背景の章で「QUIC as a VPN (QBone)」は登場する。 Today, most production QUIC traffic is HTTP. However, developers are actively working on running WebRTC over QUIC (aka Q
HTTP のプライオリティが大きく変わろうとしている話（その他 IETF 105 雑感）
先週、モントリオールで開催された IETF 105 に参加してきました。 いろんなことがあったのですが、個人的に一番大きかったのは、HTTP/3 からプライオリティ（優先度制御）まわりの仕様を落とすことが決定したこと。 HTTP/3 は、トランスポートプロトコルである QUIC の上で動作する、次世代の HTTP プロトコルです。その設計は、QUIC ワーキングググループが、HTTP ワーキンググループから委託され、HTTP/2 の機能を移植する、という形式を取っています。 ところが、５月にロンドンで開催された QUIC ワーキンググループの中間会議で、一部参加者から HTTP/3 の優先度制御に対する不満が表明されたのです注1。それを受けて、QUIC ワーキンググループでは、HTTP/3 の優先度制御にあった HTTP/2 のそれとの差異を少なくする作業を進める一方、HTTP ワーキング
NGINX、次期版でQUIC、HTTP/3をサポートへ | OSDN Magazine
NGINX開発チームは5月21日、オープンソースのWebサーバーの最新開発版となる「NGINX 1.17.0」の開発開始を発表した。1.17は2020年4月に安定版が公開される安定版の開発ブランチとなる。 NGINXはオープンソースのWebサーバー/リバースプロキシサーバー。メールプロキシ、TCP/UDPプロキシサーバーなどの機能も持つ。オープンソース版は4億以上のWebサイトで利用されているという。NGINXは2019年3月に米F5 Networksにより買収されている。 NGINXは新機能の開発を行う開発ブランチであるMainline、安定版のStableの2つのバージョンを持ち、NGINX 1.17はMainlineの最新版となる。Stableは年1度のリリースサイクルを持ち、4月に公開された1.16.0が最新バージョンとなる。 帯域制限を設定するlimit_rateディレクティブで
HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog
この記事では、HTTP/3で導入されるHTTPヘッダ圧縮の仕組みである「QPACK 」について説明します。（執筆時 draft 07） 2020/06/01追記 まるっと解説記事を書き直しました asnokaze.hatenablog.com HTTP/2の場合 ハフマン符号 静的テーブル、動的テーブル HTTP/3とQPACKの導入背景 QPACKの概要 Encoder Instructions Decoder Instructions Header Block Instructions 相対インデックス Compressed Headers エラーハンドリング その他 QPACKという名称について HTTP/2の場合 簡単に、HTTP/2で導入されたヘッダ圧縮の仕組みである「RFC7541 HPACK」について補足します。飛ばしていただいても大丈夫です。 HTTP/2の元となったSPD
kubernetesでQUICのLoad Generatorを作った話 - Qiita
ギリシャからこんにちは！こんばんは！ NTTコミュニケーションズアドベントカレンダー 6日目です。 私は今、神々の王ゼウスが生まれた伝説の島、クレタ島にいます。 というのも、こちらで開催されているACM CoNEXT 2018という国際学会に参加しているからです。 QUICに関する最新成果を発表する Evolution, Performance, and Interoperability of QUIC (EPIQ) ワークショップ も併催されました。 ポスター発表もしてきたので、今日はそれに関連して、kubernetes(k8s)を使ったQUIC負荷テスト の構成方法について、お話します。 この記事でわかること QUICについての基礎知識 kubernetesを使った負荷テストの構築手順(kubeadm + kubenet) QUICとは QUICは、TCP＋TLSに代わるUDP上の新し
HTTP3Study に行ってきたメモ #http3study - console.lealog();
HTTP3Study (new) - connpass まったく詳しくない分野で脳内補完が効かないのと英語なのとで、まったく自信のないメモに仕上がりました。 間違ってたらむしろ教えてほしいです！ HTTP/3 (英語セッション) from Mark Nottingham はじめに ここは最初にWGのMtgをした部屋なので不思議な感じ 仕様の解説というより、経緯とか周辺について話すよ 仕様について議論してるけど、全ての実装・ユースケースを把握してるわけではない いままで HTTP/0.9 今でも使われてるかも `GET /`だけみたいにシンプル HTTP/1.0 いくつかヘッダがついたりした まだシンプルだったあの頃 1993年とかそのへんからユースケースが混んできた なのでみんな拡張をはじめた UAとかHostとか HTTP/1.1 Transfer-Encoding: chunk gzi
QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog
12月8日に現在標準化が進められているQUICの仕様のdraft-17が出ました。 以下の記事で書いたように、"HTTP over QUIC" のHTTP/3への名称が含まれています。 asnokaze.hatenablog.com その他にも幾つかの変更が含まれているのでざっと目を通す。 「Hypertext Transfer Protocol Version 3 (HTTP/3)」 「Using Transport Layer Security (TLS) to Secure QUIC」 「QUIC Loss Detection and Congestion Control」 「QUIC: A UDP-Based Multiplexed and Secure Transport」 この draft-17 は「9th Implementation Draft」であり、2019年1月に東京
QUICの話 (QUICプロトコルの簡単なまとめ) - ASnoKaze blog
[追記] QUIC, HTTP/3 関連記事 まるっと解説記事を書き直しました asnokaze.hatenablog.com その他もどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog QUICのコネクションマイグレーションについて - ASnoKaze blog QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog HTTP over QUICと、その名称について (HTTP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Redirecting...
HTTP and 5G (fixed1)
