【通信プロトコル】HTTP/3が正式に勧告、脱TCP時代の幕開けか [エリオット★]
■ このスレッドは過去ログ倉庫に格納されています
インターネット関連技術の標準化を手掛ける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が実施する。
https://cdn-xtech.nikkei.com/atcl/nxt/news/18/13024/ph1.png
HTTP/3はトランスポートのプロトコルにQUICを採用
HTTPでは基本的に1対のリクエストとレスポンスが独立して呼び出される。それらを個々に処理すると効率が下がる。そこでHTTP/3では、複数のリクエストとレスポンスをまとめた仮想的なパイプラインで処理することで、コネクション確立やエラー処理などのオーバーヘッドを低減させて高速化を図る。
従来のHTTP/2およびHTTP/1では、トランスポートのプロトコルにTCPを使っていた。しかしTCPは通信データ量のかなりの部分をプロトコルによる制御が占めている。このため遅延の影響を受けやすく、オーバーヘッドも大きい。
特に無駄が多いのが再接続時の処理だ。HTTPは暗号化処理の際にTLSを併用する。このため再接続時にはTCPで接続を確立した後に、さらにTLSによるネゴシエーションが必要だった。HTTP/3はQUICを採用することで、こうしたオーバーヘッドを排除している。
https://cdn-xtech.nikkei.com/atcl/nxt/news/18/13024/ph2.png
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/ >>196
これ見て運用でカバーとかプログラミング知らねーの？
仕様で細かいことまで決めてないからむかしのだし今のことなんてわかってないからだから実装レベルで必要なのを追加して
使い合うこっちとあっちは当然相手に合う実装が必要よ もしそれが運用でカバーするなんて実装も当然できるだろうがそんなのはめんどくさくて使ってられない
何のためにプログラミングするの？実装するときのTCP/IPスタックの話
https://www.saminiir.com/lets-code-tcp-ip-stack-1-ethernet-arp/
みたいな >>197
速度って何の速度だよ
光速度以上にはならんぞ >>195
AppleやマイクロソフトのHTTP Clientとかも？ 従来比で抑えられる通信量が10％もないとか聞いたので
仕組み的に移動で接続が切り替わりがちなスマホ向けの技術ぽいな Edgeも対応してる
Chromiumベースだから当然か >>201
どちらかと言うとサーバ側の負荷軽減の為の技術じゃないのかな
TCPのハンドシェイク時間がもったいないとか、C10K問題とかの話だろ >>11
先輩にJISで決められてるから伸ばすなガキって言われたんだよ 様々なビジネスニュースが自然と集まってくるスレ。
ここを見ておけば、経済情報はバッチリ！
◆スレ立て依頼スレ@ビジネスnews+[5/09-] 【依頼以外の目的に利用しないで下さい】 [エリオット★] [エリオット★]
https://egg.5ch.net/test/read.cgi/bizplus/1652072693/ >>203
TCPはコネクション維持するのにポートとか占有するから。 またMSが「対抗」して独自規格プロトコルを出して市場が混乱するのかな
ほんと迷惑 >>207
ゲイツの時の黒いMSからナデラの白いMSに変わったから、、、 なんつーか、適当にそれっぽいこと言って通ぶりたいパソコン大先生が
この板も多いなぁ・・・
標準技術がない時代の新技術の拡張仕様や、アプリケーションプラットフォーム
とかにおいてMSが独自技術を掲げることはあっても、RFCに対抗する
新プロコトルなんてMSが提示してバトったことなんてあったっけ？ｗ >>90
普及してるよ
俺の通ってる大学は8割位はIPv6の通信
自宅の回線やスマホがv6化されてるから
サーバ側がv6 readyなら当然 >>212
zeroconf関係はAppleとMicrosoftがちょっと
BonjourとUPnP >>215
ブラウザじゃなくSDKに入ってるHTTPクライアントの話
REST APIとかに使う >>60
日本が江戸～明治にかけて海外から医学や工業技術など急速に吸収出来た背景には
こういったカタカナを全て漢字に置き換えて表現したからやで、 惰性の力を甘く見てはいけない。IPv6はいつまでたっても普及しないし、JPEGも作られてから何十年も経つ規格で、
もっとましな代替技術・規格はいくらでも提案されているのに未だに現役。 >>224
オンラインの全世界対応対戦ゲームとかはどうなってんじゃろ
遅いと困るけど、誤アクションも困りそうだが >>227
というか10Gbpsの回線はIPv6のみだよね
v4はtunnelingでNAT >>225
googleもパケット見たらIPv6に移行してた >>229
googleレベルになると各大陸にIX持ってるからv6化のコスト削減は膨大 >>232
それを解消するための改良が目玉機能の一つ >>232
TCP上で動くHTTP2だとTCPの仕様上マルチ読み込みでロックする可能性が当初からあることがわかっていてその解決法がいろいろ提案されてるなかの一つがUDPにニューTCP的なのとTLSを載せてQUICとしてそのUDPのQUICのうえで動くのをHTTP3というんだって TCPの nagleアルゴリズムって余計なお世話だったんだが、quickではどうなん？ >>222
40年前にはJAPAN AS No1だったんだろ
何を世界に教えてやったんだよおまえ！と言われる立場だったよなあ
いつまでも教わるというかパクる心づもりでいるのかなあ
その言い草からすると自信あるんだなあパクリには
世界から見たら暗号でバクってるのかわからないもんなあ >>145
データグラムって書いてあるだけで信用できるわ
トーシロはまず使わない え？
HTTP/2 over QUICをHTTP/3にリネームしただけなん？ >>235
nagleをオフにして接続張れないようなザコが何言ってるんだ >>227
ほんとにな
知ったかぶりなアホだけがIPv6が普及してない連呼してて笑える IPv6は、大手はほぼサポートしてるけど、小さいところはほぼ相手にしてないんだけどな
ISPが寡占化してる日本しか見てないとわからんだろうけど v4のみの小さいところなんて
それがISPでもサーバサイドでも老衰を待つのみだ 馬鹿だなあ、弱小がわざわざIPv6なんてサポートしたらそれこそ即死だってのwww 1日2万アクセスぐらいのhttp2のwebサーバ作ったけど、
いかにhttp1.1がスレッドの消費が無駄なのかわかったわ
もちろん負荷になるならいずれCDN使う 昔からUDPで再送すれば速くなるってのは知られてて実装も色々あったが、グーグル様がサーバとクライアントの実装を抑えて圧倒的物量でデファクトにしたって認識なんだがあってる？ ■ このスレッドは過去ログ倉庫に格納されています
