Intro 2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。 RFC 9110: HTTP Semantics RFC 9111: HTTP Caching RFC 9112: HTTP/1.1 RFC 9113: HTTP/2 RFC 9114: HTTP/3 RFC 9163: Expect-CT Extension for HTTP RFC 9204: QPACK: Field Compression for HTTP/3 RFC 9205: Building Protocols with HTTP RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field
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に詳しい人の一人であるといえます。 本記事では奥氏のセッションをダイジェストで
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 不定期連載を始めます IIJ-II 技術研究所 技術開発室の山本です。私はプログラミング言語HaskellでHTTP/2とTLS 1.3を実装した後、もっぱらQUICを実装することに時間を費やしてきました。 ご存知の方もいらっしゃると思いますが、今年の5月にQUICの仕様がRFC9000として公開されました。このRFCは実によく書かれているので、読みこなせばQUICの全容が掴めるでしょう。 しかし仕様は膨大ですし、実際に実装してみて初めて腑に落ちることもあります。そこでこの機会に、実際にQUICを実装した経験者目線で、QUICの解説をしていきたいと思います。なんとなくTCP/IPを分かっている方が、ある程度QUICの理解ができることを
ジェフ・ヒューストンのブログより。 QUICトランスポート・プロトコル(RFC 9000)は、オリジナルのTCPトランスポート・プロトコルを改良したものに過ぎないという一般的な見解があります[1][2]。私は、この意見に同意し難く、私にとってQUICは、通信のプライバシー、セッション制御の完全性、柔軟性の面で、アプリケーションが利用できるトランスポート機能における重要な変化を象徴しています。QUICは、より多くの形式のアプリケーションの動作に本質的に役立つ、異なる通信モデルを体現しています。そうです。TCPよりも高速です。私の意見では、公衆インターネットは、いずれQUICがTCPに取って代わると思っています。ですから、私にとってQUICは、TCPに少し手を加えただけのものではありません。ここでは、TCPとQUICの両方について説明し、QUICがトランスポート・テーブルに加えた変更について見
HTTP/3入門 第1章進化するHTTPの歩み ～ HTTP/1.1とHTTP/2をおさらいし、HTTP/3の基本を知る この特集記事は2021年6月24日に発売されたWEB+DB PRESS Vol.123に掲載された特集1「HTTP/3入門」を再掲したものです。 先日2022年6月にHTTP/3を含むHTTP関連の仕様が正式なRFCとなりました。ここではRFCの正式リリースに伴い、いち早く変更点を抑え、囲みボックスを用いた加筆解説でわかりやすくお伝えしております。 特集のはじめに HTTP（Hypertext Transfer Protocol）の最新版であるHTTP/3が登場しました。HTTP/3では、より安全で速い通信が行えます。本特集では、今までのHTTPにあった課題と、HTTP/3で課題をどのように解決し、改善が行われたかを解説します。 本章では、HTTPそのものと各バージ
今回は改めてHTTP/3とはどのようなもので、QUICとは何か、HTTP/2時代からの改善点と我々はHTTP/3の波に乗るべきなのかチェックしていきたいと思います。時がたち次世代Web通信プロトコル「HTTP/3」の標準化プロセスが完了し、2022年6月に「RFC 9114」となりました。既に基盤となる「QUICプロトコル」の標準化プロセスも完了し、RFC9000としてRFCとなりました。もうHTTP/3は無視出来ないところまできています。 HTTP/3の誕生と歴史HTTP/3とは、HTTP/1.1 HTTP/2に続く新しいバージョンの約束事です。HTTP/1.1からHTTP/2は様々な点で劇的な進化を遂げましたが、HTTP/3はHTTP/2の根本的な課題をTCP・TLSの融合という形で解決し問題点を補うよう進化してきました。 1991年：HTTP/0.9（HTTPの始まりGETメソッドし
HTTP/3｜Webエンジニアが知るべき新常識 ─ QUICやコネクションマイグレーションなどを学ぶ 新しい通信プロトコルとして普及が進んでいるHTTP/3については、エンジニアHubでも過去に概論的な記事を掲載しています。今回はアプリケーション開発者が自社サービスでHTTP/3を採用することを想定して、仕様上の留意点や、どのように使い始めるか、そしてサイトを制作する際に注意しておきたいポイントまでを藤吾郎（gfx）さんに解説していただきました。 本記事ではHTTP/3およびその通信プロトコルであるQUICを、アプリケーション開発者として活用する立場で入門します。HTTP/3は、HTTP/1.1とHTTP/2に続く新しいメジャーバージョンのHTTPプロトコルです。HTTP/3はHTTP/1.1およびHTTP/2を置き換えるポテンシャルを持っています。将来的にほとんどのインターネットトラフィ
本章では、HTTP/3がTCPに代わって下位層で用いるQUICについて解説します。 QUICはトランスポートプロトコル QUICはトランスポートプロトコルです。QUICの説明に入る前に、トランスポートプロトコルついておさらいします。 TCP/IPの4階層モデル プロトコルは階層で役割を分担しています。TCP/IPの4階層モデルでは、アプリケーション層、トランスポート層、インターネット層、ネットワークインタフェース層に分かれます（図1）。 図1 TCP/IPの4階層モデル アプリケーション層に分類されるアプリケーションプロトコルは、クライアントやサーバで動作するアプリケーションの動作に関するデータやメッセージの通信ルールを規定します。たとえばSMTP（Simple Mail Transfer Protocol）は、メールを送信する通信ルールを規定しています。HTTPはこの層に属します。
Why FastlyProductsServicesSolutionsDevelopersPartnersResourcesPricing QUIC is now RFC 9000QUIC is a new latency-reducing, reliable, and secure internet transport protocol that is slated to replace TCP, the most commonly used transport today. We’ve talked before about how we love QUIC and are deeply invested in making it a success because it aligns with our mission to build a faster, more resilient
HTTP/3の基盤となる「QUICプロトコル」の標準化プロセスが完了、IETFの「RFC 9000」として 現在標準化が進められている新たなHTTPである「HTTP/3」のトランスポート層プロトコルとなる予定の新しい通信プロトコル「QUIC」が、インターネットで用いられる通信プロトコルなどの標準化を行う団体のIETF（Internete Engineering Task Force）により「RFC 9000」として策定を完了、新たなインターネット標準になったことが明らかになりました。 QUIC is now RFC 9000 | Fastly QUIC is RFC 9000 | daniel.haxx.se QUICはもともとHTTPをより高速化するためにGoogleが開発し、その後IETFで標準化が進められてきました。 QUICはまずは次世代のHTTPであるHTTP/3のトランスポート
フロントエンドカンファレンス沖縄 2023 の登壇資料です
ハイクラス求人TOPIT記事一覧HTTP/3とQUICはなぜ必要になり、どのように標準化されてきたのか？ 現代のプロトコル設計とインターネットの課題 HTTP/3とQUICはなぜ必要になり、どのように標準化されてきたのか？ 現代のプロトコル設計とインターネットの課題 IETFで標準化が進められているWebの新しい通信プロトコルQUICとHTTP/3について、現在のインターネットが抱える課題やプロトコル設計での議論を中心に、ASnoKaze blogの後藤ゆき（@flano_yuki）さんに執筆いただきました。 2021年、Webに新しい通信プロトコルが登場しました。RFC 9000として標準化されたQUICと、その上で動作するHTTP/3です。HTTP/3はまだドラフト版ですが出版準備段階となっており、すでに実際のWeb通信でも広く使われています この2つのプロトコルは、現在のWebやイン
IETFに『Secure shell over HTTP/3 connections』という提案仕様が提出されています。 これは、HTTP/3コネクション上でSSHを実行するプロトコルを定義しています。なお、"SSH3"という名称を仕様中で使用していますが、あくまで提案段階ですので今後変わる可能性もあります。 SSH3ではHTTP/3を使うことにより以下の特徴を持ちます QUICのメリットが享受できる（例えばIPアドレスが変わってもコネクションを維持できる） HTTPの認証方式をサポートする（Basic認証、OAuth 2.0、Signature HTTP Authentication Scheme） SSH通信の秘匿 (第三者からするとただのHTTP通信にみえる) エンドポイントの秘匿 (Signature HTTP Authentication Schemeを使うことで、そこでサービス
https://www.slideshare.net/yuyarin/quicnat 最近QUICとNATについての話をJANOGで紹介するぐらいQUICという新しいプロトコルに既存のネットワークインフラがどう適応していくかを考えています。 id:asnokaze さんの記事で紹介されているように、QUICやHTTP3/3で送信元UDPポートとして利用を避けるべきポートの議論が行われています。これはUDPのリフレクション攻撃のへの対応としてインフラストラクチャ側で特定のUDPポートのトラフィックをブロックしているケースがあるからです。実際に私もこのブロックの設定を行ったことがあります。 これはUDPというプロトコルの特性に起因する問題であり、QUIC, HTTP/3に限らずUDPを使うプロトコルに広くある問題です。 asnokaze.hatenablog.com QUICクライアント側で送
大きな流れは、あらかじめ立っているHTTP/1.1のlocalhost:80をリバースプロキシを使ってlocalhost:8443でHTTP/3を受け付けられるようにすること。以下の図の通り必要に応じてHTTP/2やHTTP/1.1にフォールバックさせる。
IETFのQUICワーキンググループで標準化作業が進められてきたQUICとHTTP/3が、6月のQUICワーキンググループにおけるラストコールを経て、IETFのステアリンググループであるIESGのラストコールとして10月21日に受諾されました。 ラストコールとしてIESGが受諾したドキュメントは、QUICとHTTP/3の標準化に関わる以下の6つのドキュメントです。 QUIC: A UDP-Based Multiplexed and Secure Transport QUIC Loss Detection and Congestion Control Using TLS to Secure QUIC Version-Independent Properties of QUIC Hypertext Transfer Protocol Version 3 (HTTP/3) QPACK: Head
IETFのQUICワーキンググループはHTTP/3の標準化プロセスを完了し、「RFC 9114」として発表しました。 HTTP/3 has been published as an RFC. https://t.co/jdsUHy9FKD — IETF QUIC WG (@quicwg) June 6, 2022 HTTPはWorld Wide Webを開発したティム・バーナーズ＝リーによって1990年に最初のバージョンが作られました。 その後、1996年にHTTP/1.0がIETFによってRFC化され、1999年にHTTP/1.1へアップデート。2015年2月には初めてのメジャーバージョンアップとなるHTTP/2がRFCとなりました。HTTP/3は7年ぶりのメジャーアップデートと言えます。 HTTP/3では高速な通信を実現するために、HTTPのトランスポート層を従来のTCPからQUICに
インターネット関連技術の標準化を手掛けるIETF（Internet Engineering Task Force）は2022年6月6日（米国時間）、通信プロトコル「HTTP/3（HyperText Transport Protocol/3）」を「RFC 9114」として勧告した。HTTP/3はインターネット通信の多くを占めるWebにおける通信プロトコルの最新版である。 最大の特徴は、トランスポートのプロトコルに「QUIC（Quick UDP Internet Connections）」を採用した点。QUICは2021年にIETFで「RFC 9000」として勧告された。その名前が示すように、TCP（Transmission Control Protocol）ではなく、UDP（User Datagram Protocol）に基づくプロトコルだ。TCPが備えていた再送制御の仕組みや、TLS（Tr
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はどうやってWebを加速するか？ TCP、TLS、HTTP/2の問題とHTTP/3での解決策～Fastly奥氏が解説（前編）」の続きです） サーバプッシュの
はじめに HTTPのバージョンと仕様について、個々最近の動きについて整理しておこうかと思います。 HTTPには幾つかのバージョンが有り、現在HTTP/1.1とHTTP/2が広く利用されており、HTTP/3も徐々に使われだしています。 バージョンが異なっていても、クライアントからHTTPリクエストを送り、サーバがHTTPレスポンスを返すのは変わりません。HTTPメッセージをどのようなフォーマットで送るかはバージョンによって異なりますが、HTTPメッセージが持つ意味は変わりません。 意味(セマンティクス)とは、GETリクエストやPOSTリクエスト、ステータスコード、ヘッダがどういった意味を持つかということです。 バージョンと、セマンティクスの歴史的遷移は下記のとおりです。 HTTP/1.1とセマンティクス HTTPは最初0.9から始まり、HTTP/1.0、HTTP/1.1と進んできました。 H
2021年について、プロトコル周りの動向を振り返っていきたいと思います。 今年は、個人的には次の2点がホットトピックと挙げられると思います。 QUICやHTTP/3を活用した応用系プロトコルの作業が進む プライバシー系の取り組みが活発化 それでは、個別に補足していきます。（IETFの動向がメインです。なお、個人的にキャッチアップできてないトピックもあります...） HTTP関連 まずは、HTTPです。HTTP/3の標準化が注目を浴びていますが、HTTP/1.1やHTTP/2なども改定作業が行われております。あわせて、HTTPセマンティクスは各バージョンから独立し、各バージョンから参照される形となりました。それぞれRFC出版の最終段階となっています。 書いた記事はここらへん HTTPのバージョンについて、現在のまとめ HTTPセマンティクス仕様の改訂版 まとめ HTTP/2の改定版仕様の変更
ChromeがHTTP/2サーバプッシュの廃止を検討し始めている。またPreload + 103 Early Hintsの有効性について実験していく模様 背景 HTTP/2(RFC 7540) にはサーバプッシュという機能があります。これは、クライアントからのHTTPリクエストをまたずにサーバがHTTPレスポンスを先行して送ることが出来る機能です。 たとえば、index.htmlに画像1,2,3が含まれているようなページがあるとします。このindex.htmlへのリクエストを受け付けたサーバは、クライアントが画像1,2,3がを要求してくることを予測しサーバプッシュでこれらのリソースを送りつけることが来でます。（クライアント側から、そのリソースが不要であればサーバプッシュをキャンセルすることもできます） そうすることで、ページの表示を効率化出来ると考えられていました。 しかし、様々な議論の中
By Sedrubal HTTP/3は2022年に標準化されたHTTPの仕様で、開発当初は「HTTP over QUIC(QUICを使用したHTTP)」と呼ばれていました。HTTP/3を使用することで通信パフォーマンスが向上するとされていますが、特定の条件においては旧バージョンのHTTP/2の方がパフォーマンスが高まるという論文が発表されました。 QUIC is not Quick Enough over Fast Internet | Proceedings of the ACM Web Conference 2024 https://dl.acm.org/doi/10.1145/3589334.3645323 QUIC is not Quick Enough over Fast Internet - YouTube 2024年時点ではHTTPには大きく3つのバージョンが存在しています。
Want to learn more about unlimited IOPS w/ Metal for Postgres and Vitess? Talk to Solutions By Matt Robenolt | January 4, 2023 Over here at PlanetScale, we offer you a MySQL database. As a part of this offering, it is critical that we offer you a MySQL protocol-compatible interface to access. This enables using mysql-client as well as any MySQL-compatible driver for your favorite language. But wha
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
奥一穂 / Fastly ■ セッション概要 インターネット通信の基盤技術であるTCPが誕生してから40年、TLSが誕生してから20年が過ぎた今、TCPとTLSに変わる新しいトランスポート層プロトコル「QUIC」の標準化が佳境を迎えています。同時に、QUICを利用するHTTPプロトコル「HTTP/3」の標準化も進んでおり、2020年末から21年にかけては、これら新プロトコルへの移行が進むものと予測されています。QUICとHTTP/3でユーザ体験は改善するのか。セキュリティ、運用やモニタリング手法は変化するのか。本セッションでは、標準化と実装の双方に関わってきた発表者が、TCP, TLS, HTTP/2 といった既存プロトコルの抱えている問題と、それらをQUICとHTTP/3がどのように解決するか。また、今後どのような変化が想定されるかについて、解説します。 ■ 公式サイト #lined
HTTP/3をするにはhttpsをする必要があるため証明書を作る。だがそれを信頼させてもHTTP/3ではなくHTTP/1.1にフォールバックした。（HTTP/2にならないのは使ったライブラリの使い方の関係だと思う。）
Mozillaのブログ「Mozilla Hacks」に4月16日付けで投稿された記事「QUIC and HTTP/3 Support now in Firefox Nightly and Beta」によると、5月末までにFirefoxでHTTP/3が利用可能になることが明らかにされました。 FirefoxでのHTTP/3対応について、次のように説明されています。 Support for QUIC and HTTP/3 is now enabled by default in Firefox Nightly and Firefox Beta. We are planning to start rollout on the release in Firefox Stable Release 88. HTTP/3 will be available by default by the end o
Intro 本サイトを HTTP3 対応し、Alt-Svc ヘッダおよび DNS HTTPS Resource Record によってそれをアドバタイズする構成を適用した。 色々ハマったので作業のログを記す。 HTTP3 on h2o Fastly の数々の発表からも h2o が HTTP3 に対応していることは自明だが、その設定方法がドキュメントに記載されておらず、なかなか設定方法がわからずにいた。先日、たまたま当該 issue の中で、設定ファイルサンプルの中にコメントアウトされたフラグがあることを教えてもらい、これをたよりに HTTP3 化を進めることができた。 したがって、ここから記す内容はドキュメントやリリースノートの内容ではないため、将来的に全然違う方法になるかもしれない点には注意が必要だ。なお、最近はリリース自体がないため master をビルドしてデプロイしている。 h2o
2022年にインターネット技術の標準を策定する団体のIETFがHTTPの新しいバージョンとして「HTTP/3」を標準化して以降、HTTP/3の利用はウェブの世界で急速に普及していきました。HTTP/3にどのような利点があり、なぜ急速に普及したのかについてウェブに関するエキスパートエンジニアのロビン・マークスさんがAPNICのブログに投稿しています。 Why HTTP/3 is eating the world | APNIC Blog https://blog.apnic.net/2023/09/25/why-http-3-is-eating-the-world/ GoogleやMetaなどの大企業がHTTP/3を採用しているため、GIGAZINEやAPNICのブログ記事の読み込みも含めて多くの通信でHTTP/3が利用されています。通信に利用されているHTTPのバージョンごとの推移を調査し
RG-Arch輪考資料: Implementation and Performance Evaluation of the QUIC Protocol in Linux Kernel
ついさっき、ついにHTTP/3対応のブランチが本家のnginxにmergeされました。 このまま何事もなければ次のMainline versionである1.25.0がリリースされたタイミングで使えるようになるはずです。 検索するとnginxでHTTP/3を使う方法を解説しているサイトがいくつかヒットしますが、実はmergeするちょっと前くらいから非互換な変更をいくつも入れていたので、そのままだと動かないはずです。なので簡単に使い方を解説しておきます。 なお分かっていると思いますが、こちらの記事は記事執筆時点（2023/05/20）の内容です。 OpenSSLの代わりを選ぶ HTTP/3を使うには自分でbuildする必要があります。いずれpackageが配布されるだろうと思っている人がいるかもしれませんが、nginxのHTTP/3対応はBoringSSLのAPIで対応されています。OpenS
図1: QUICの無効化は待ってくださいQUICを無効化？！“Googleが遅く感じるので、QUICを無効化する” そのようなTIPSが散見されます。数年前から見ていましたが、QUICがトレンドになったのと同時に、再び目立ち始めたと感じています。IPv6が普及し始めた時期もそうでしたが、新しいプロトコルの出現時には、決まって現れる文言です。 問題に直面する利用者にとっては切実であり、無効化は間違った解決手段とは言いません。しかしエンジニアならば無効化する前に、原因を探求しなければなりません。 HTTP3/QUIC と HTTP2/TCP どちらが優先？QUICの無効化とは、TCPだけを利用する選択と言えます。はじめにQUIC, TCPの両者が使えるとき、どのように使い分けるのか見ていきます。 ある、HTTPSスキームのURL https://www.example.com/ があったとき、
HTTP3 でpub-subとMQTT-over-QUICの比較をIoTの観点から行った論文の備忘録です。 IoTという文脈で、ネットワークエミュレータに遅延と帯域を設定して、性能（最初のデータが到達するまでの時間、通信終了までの時間やスループット）、ネットワークへのオーバーヘッド（バイト量とパケット数）、リソースの使用状況（CPU使用率、RAM使用量）、の3つを比較しています。 性能面では、H3 pub-subのほうが優れた結果が得られていますが、ネットワークのオーバーヘッドやリソースの使用状況はHTTP3 pub-subのほうが MQTT-over-QUICよりも多くのリソースを使用する結果となったようです。 これらの結果から、IoTという文脈を考えた場合、トレードオフが存在しているということを示唆しています。 元論文は下で読めます。 arxiv.org 実装について H3 pub-s
Haskellコミュニティでは、ネットワーク関連を担当。 4児の父であり、家庭では子供たちと、ジョギング、サッカー、スキー、釣り、クワガタ採集をして過ごす。 「フロー制御」の回で説明したように、輻輳制御とは途中のネットワークが溢れないようにするための仕組みです。QUICは、正確なRTT計測や、前回説明した簡潔なロス検知の機能を提供しています。このため輻輳制御としては、パケット欠落や遅延といったシグナルを使うアルゴリズムが利用可能です。RFC9002では、デフォルトの輻輳制御アルゴリズムとしてNewRenoを採用しています。 1990年に現れたRenoは、1995年に出されたアイディアに基づいて改良されNewRenoとなりました。2008年に提案されたCUBICや、2016年に現れたBBRに比べると、NewRenoは古い輻輳制御アルゴリズムです。QUICのデフォルトの輻輳制御に古いNewRe
2022年7月追記: この記事は古くなっています。現在の最新仕様では、拡張CONNECTメソッドを使うことになってます asnokaze.hatenablog.com 確立したHTTP/3コネクションをVPNのように使う、MASQUEという仕組みがIETFで議論されています。 以前書いた記事では、UDPパケットをProxyさせるCONNECT-UDPという提案仕様を紹介しました。 asnokaze.hatenablog.com その後、同様に確立されたHTTP/3コネクション上で、IPパケットをトンネリング可能にする「The CONNECT-IP HTTP Method」という仕様が提案されています。 CONNECT-UDPと同様に経路上の第三者にはただのHTTP/3通信を行っているようにしか見えないため、検閲やブロッキングに対して耐性があると思われます。 それでは簡単に見ていきましょう。
WebSocketに変わる、Webの新しい双方向通信仕様 WebTransportの標準化・実装が進められています。 このWebTransportではHTTP/3の特徴を活かし、パケットの順番が入れ替わったり、パケットロスがあったとしても受け取った順番に処理を行うことが出来ます。DATAGRAM拡張を使えば、パケットロスしたデータも再送不要にできます。 前回紹介した通り、WebTransportは「WebTransportover QUIC」や「WebTransportover HTTP/3」がありましたが、HTTP/3を使う方向で議論が進んでいます。 asnokaze.hatenablog.com Chromeの開発者メーリングリストでは、この「WebTransport over HTTP/3」実装が進められている事が書かれています。 groups.google.com そこで、今回はプ
WWDC21で、「Accelerate networking with HTTP/3 and QUIC」という発表がありました。 developer.apple.com iOS15、MacOS Monterey からHTTP/3とQUICが利用可能になるらしく、HTTPの進化、HTTP/3の使い方、QUICの使い方の紹介が取り上げられていました。 気になったスライドをピックアップしてまとめてみました。 Evolution of HTTP HTTPの進化 ここでは、HTTP/1.1、HTTP/2、HTTP/3の進化を典型的なWebページの表示(index.html, logo.png, style.css)のダウンロードにかかる時間の改善によって表しています。HTTP/1.1→HTTP/2ではストリームの多重化によって、logo.png, style.cssをリクエストするタイミングが早くな
どうも、インフラの後藤です。夏休みの自由研究として、HTTP/3について遊んでみたのでよろしくおねがいします。 はじめに HTTP/3はRFC目前となっており、すでに多くのブラウザがサポートし、ミドルウェアも実装が進められています。また、GCPではCloud CDN やHTTPS Load Balancingですでに利用することが出来ます。 HTTP/3は、トランスポートプロトコルにUDPで動作するQUICを利用しています。このQUICは様々な効率化の仕組みが盛り込まれていて、結果としてHTTPプロトコルの高速化が実現されています。 一方で、少ない環境ではあるものの、QUICが利用できないネットワークがあることも知られています。実際に使用する場合に問題になることはなく、多くの場合はHTTP/2にフォールバックされアクセスが行われます。ですが、国内での実情は調査の余地があると思われます。 今
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く