インターネット関連技術の標準化を手掛ける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（Transport Layer Security）による暗号化処理をQUICが実施する。
HTTP/3はトランスポートのプロトコルにQUICを採用
HTTPでは基本的に1対のリクエストとレスポンスが独立して呼び出される。それらを個々に処理すると効率が下がる。そこでHTTP/3では、複数のリクエストとレスポンスをまとめた仮想的なパイプラインで処理することで、コネクション確立やエラー処理などのオーバーヘッドを低減させて高速化を図る。
従来のHTTP/2およびHTTP/1では、トランスポートのプロトコルにTCPを使っていた。しかしTCPは通信データ量のかなりの部分をプロトコルによる制御が占めている。このため遅延の影響を受けやすく、オーバーヘッドも大きい。
特に無駄が多いのが再接続時の処理だ。HTTPは暗号化処理の際にTLSを併用する。このため再接続時にはTCPで接続を確立した後に、さらにTLSによるネゴシエーションが必要だった。HTTP/3はQUICを採用することで、こうしたオーバーヘッドを排除している。
TCPとTLSによるオーバーヘッドをなくす
HTTP/3はもともと米Google（グーグル）が開発していた。対応するWebサーバーが増え、Google以外にも多くの事業者がHTTP/3への対応を進めている。米Q-Successの調査によると、2022年6月時点で約25％のWebサイトが既にHTTP/3に対応しているという。
2022.06.08
日経クロステック（xTECH）
https://xtech.nikkei.com/atcl/nxt/news/18/13024/
カッコつけて横文字ばっか使うなバーカ
え……
これをどうしろというねん
日本が江戸～明治にかけて海外から医学や工業技術など急速に吸収出来た背景には
こういったカタカナを全て漢字に置き換えて表現したからやで、
まぁテスト環境作るか…
>>8
https://eng-blog.iij.ad.jp/archives/10039#%e7%89%b9%e5%be%b4
＞もしみなさんが、最新のFirefoxやChromeをお使いでしたら、すでにQUICを利用しています。
＞今回は https://www.google.com にアクセスして、確かめてみましょう。最初に通信するとき、
＞ブラウザは HTTP/2を利用しますが、HTTPの Alt-Svc ヘッダを介して
＞HTTP/3 が利用可能だと通知されます。そのため、2回目からの通信にはHTTP/3を使うようになります。
実質Googleが開発してるから、Googleにアクセスすれば試せるぞ
おぉ…そうだったのか…ちゃんと読んでなかった…詳細トンクス
パケット覗いてみたら…てか俺の頭でわかるかどうかだけどｗ 見てみようかなｗ
なんかここ数年、早すぎるよ…WebRTCでなんとかだったのに、あの時もGoogleがUDPベースで新しいプロトコル作っているて情報みたけど
３・４年さぼったら、その時でも辛かったのに、もうあれだよ、はるか先だよ
ほんとだ、GOOGLEにアクセスしたらHTTP/3だった！
自分がやり出したのを標準化に乗せたんだから当然だ
情報遅すぎる
え、「HTTP/3」とか言っているから、HTTP関連かと思ってた
nginxとかapacheとかが対応するようになるのかと思た
なんだっけな？
忘れた
UDPにしたら当然速くなる
簡潔に誰か説明してくれないか
ブラウザの表示が速くなるよ
セキュリティキーはともかくLANを使えインターネットにも接続できる
でも通信プロトコルが変わるんじゃ使えなくなるな
>>31
UDPパケットやから接続でいるけどブラウザが対応してないんで通信できない
正確にはね
98なんてルート証明書が期限ぎれ
最新ブラウザインストール不能
あと経路はHTTP/3に対応していなくても問題なく使えるのか？
その理解力の無さはちょっと惨過ぎる
QUICのIPマイグレーションが発生した時のhttpd側のログとかwebアプリから見たremote IPてどうなるの？
機能が対応してないなら最悪買い直し
まぁファームのアップで対応するんじゃね？
結局TCPを使う限りHead of Lineブロッキングが解消できないから
つか解消しようとするとそれSCTPじゃんて話になって
エンドのルーターが対応してないって結論になるのでUDPに乗せることにした
>>56
>結局TCPを使う限りHead of Lineブロッキングが解消できないから
TCPと速度が同じなら、全ストリームが受け取れる速度の合計は同じなので、どれかのストリームが早く
受け取り完了できた分、他のストリームの受け取り完了が遅れる、つまるHOLブロッキングが起きるわけ
で、それを防ごうとしたら普通のTCPより不当に多くの帯域を食う、ただのインチキ技術だよ
google MAPで複数TCP使ったズルした時から、何も変わってない
フロー制御するならTCP と性能で大きな差になるとは思えないが、実際違うもんなのかね。
シーケンスを細かく記事にしてくれているサイトあればみてみたい。
HTTP/2 over QUICをHTTP/3にリネームしただけなん？
IPv6は、大手はほぼサポートしてるけど、小さいところはほぼ相手にしてないんだけどな
ISPが寡占化してる日本しか見てないとわからんだろうけど
管理人からひと言
はて、どうなるやら
この記事へのコメントはありません。