【通信プロトコル】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/ >>97
自分がやり出したのを標準化に乗せたんだから当然だ
情報遅すぎる >>96
次世代じゃないな
元からあったのを使えるようにしたんだから
UDPはTCPと同じくIP使えるようになった時から使えてる
細かくいえばUDPのが先か >>96
さっぱりわからんってそもそもTCPわかってて言ってんの？ エックスサーバーもさくらインターネットも、レンタル用はHTTP/2だったが、
両社のホームページはHTTP/1.1だった >>15
わかるw
伸ばすのは最後がrのもんだけだよな そもそもいろんなfirewallすんなり通るのか？ >>105
伸ばすとか伸ばさないとかカンケーないんだ
JISが申請にはこれ使えって言ってるだけだ
世の中JISなんてのは関係ないからな
ところが申請だけじゃなくて全てそれでなければいけないとかいう老害の言葉を信じちゃったテクニカルしか興味ない技術者が思い込んでた >>102
記事をみると、こままで訂正／再送の仕組みがなかったUDPに
限定的にその仕組みを取り入れただけのように見える >>94
そんなのはTCP/IPの本の最初にあるUDPの解説でそれは1990年の本にも載ってる >>109
それがGoogleさまが作ったQUIC >>108
そもそも横棒はないのが正しいんじゃなくて「省いて」るんだよ
なぜか
紙の時代にはスペースが貴重だったから何度も繰り返し出てくるのが一文字でも少なければそれが利点だろ
なのに「ないのが正式」とかバカな話にすり替えられて何十年
日本の技術が進まないのがよくわかるだろ >>111
投げっぱなしで送信するデータの最大量をどう設定するんだろね
小さいと今までと変わりないし、
大きいとデータを得られないパケットがあったときページの表示に時間がかかってしまう >>90
その考えが日本がバカな理由の一つ
何十年も前からやってなけりゃ必要な時には使えない
使いたい時には全部利権が取られてる
インターネットそのものがそうだろ
しかも頭じゃなくてカラダで実際に使って使えるものが使われていくのがインターネット
だから複数乱立してても構わない
日本人は頭悪いと思われたくなくてはじめもしない >>115
あは
漢字でも横文字なのになあ
あはは >>116
自律走行車もその口で
これなんか官僚がITSとか中央集権システムやります大口だったから日本の自動車会社はどこも後づけ
今やITSないだろ？知ってる？
そういえばしれっとITSに自律走行車って書いてあったな IPv6は浸透していないというより、ネットワークの知らない部分で使われていて
IPアドレスの枯渇防止に寄与しているというのが正しいかと
多くの人が利用しているフレッツ網のNGNはIPv6で構成されているし
なお、フレッツ光ネクストとかで、IPv6 IPoEのバーチャルコネクトサービスを利用できる
環境にあるのに設定していない人もいるだろうから、環境は見直したほうがいいかもね >>113
つまりJISが横棒はここ省いてねとガイドしてたのはJIS規格の文書を見やすくするためだったんだよ
紙だったからだよ
それ以外に横棒の何が正式かとか制限はなくて商標登録とかくらいが正式かどうかのもん
ところが大学の先生がJISを憲法のように扱ったから会社の技術部門もJIS提出で作り直すの面倒出しとかいうのが積み重なってバカな金科玉条ができてた
日本てproduceなのに生産と産生とか使い分けないと文句言われてそれ覚えるだけで頭使い果たして本当に「生産的」な話に頭を使えないから寿司職人になるのに20年かかるかわけよ
いい加減年期長いのはバカにしてみろよ >>119
ちなみにうちは6だよ
あさひネットはユーザーレベル早かったな >>123
実際どうやってそれを解決しているの？教えてくれると嬉しい
なおお前が本当にその知識をしっているのか、他の人に知ってもらうことにも役立つ
一石二鳥 QUIC aims to be nearly equivalent to a TCP connection but with much-reduced latency. It does this primarily through two changes that rely on the understanding of the behaviour of HTTP traffic.[22]
The first change is to greatly reduce overhead during connection setup. As most HTTP connections will demand TLS, QUIC makes the exchange of setup keys and supported protocols part of the initial handshake process. When a client opens a connection, the response packet includes the data needed for future packets to use encryption. This eliminates the need to set up the TCP connection and then negotiate the security protocol via additional packets. Other protocols can be serviced in the same way, combining together multiple steps into a single request-response. This data can then be used both for following requests in the initial setup, as well as future requests that would otherwise be negotiated as separate connections.[22] The second change is to use UDP rather than TCP as its basis, which does not include loss recovery. Instead, each QUIC stream is separately flow controlled and lost data is retransmitted at the level of QUIC, not UDP. This means that if an error occurs in one stream, like the favicon example above, the protocol stack can continue servicing other streams independently. This can be very useful in improving performance on error-prone links, as in most cases considerable additional data may be received before TCP notices a packet is missing or broken, and all of this data is blocked or even flushed while the error is corrected. In QUIC, this data is free to be processed while the single multiplexed stream is repaired.[23] UDPで無駄な再送減らせるのは良いとして、途中の経路での支援は受けられなくなるよね
少なくとも今のところは >>107
機能追加とかではなく、高速化というメリットだから誰もが恩恵受ける万能的なものだよ
対応しないのはユーザー視点より自身の利益を見てるだけ >>129
大量のコネクション張るような使い方だとNATテーブル溢れちゃうかもね
安いルータだとNATテーブルの上限小さかったりするし
ただ、一つのコネクションで複数ストリームを流せるのでアプリケーション
の実装次第でそこまで問題にならないのでは >>130
通信遅延が少なくなると思ってくれればええよ そらUDPで確実に通信できるならUDPのほうがいいよね UDPで再送出来るようになるんか。
HTTP以外でも使えれば変革が起きそう。
ま、ユーザは何もわからんけどw 最終的にはリソースクラッシュ起因のトータルギッダムが起きてマスターコンベクターが右往左往するみたいなイメージだな UDPって懐かしいわ、PKG間の通信で使ってた
あの頃は楽しかったわ QUIC仕様がグダグダだったから前途多難で短命で終わるだろうと見ている
最先端のリアルタイム通信処理開発はすでにQUICを捨てて独自開発を進めている
その中で成功したものが次の規格の土台なる 脱TCP？は大ウソ だしWebだけだし
QUICのエラー時はTCPでQUICの再同期をとるように作られてるつまりQUICはTCPあることが前提のアプリレベルのデータグラム送受信プロトコル
Webでの多重コネクションがいちばん問題になってたその点を解決するためのもの
既存で動いてる機器のTCPの通信を100%保証して動かしたままでその上でいまTCPでやってることの新バージョンを作るためには今のTCPには触れないってこと
でUDP上に新TCPとTSLを新設したものをQUICと呼んでると
そもそも既存のTCP/TSLで動くHTTP/2だとTCPのせいで多重コネクション取り扱いがヘッドオブラインブロッキングでロックする可能性があるから
UDPの上でアプリモードのQUIC(含TSL)で動くHTTP/3にすることでこれを回避したと
UDPポートは443だけでカーネルモードじゃなくアプリモードで動く >>59
?
SDNの話？ルーティングは必須だろ。コントローラが何を意味してるか分からんが。 >>145
x UDPポートは443だけでカーネルモードじゃなくアプリモードで動く
o UDPポートは443だけ使う でQUICはカーネルモードじゃなくアプリモードで動く
あと
>>1の
QUIC（Quick UDP Internet Connections）
じゃなくて
IETFはQUIC quic だけだってよ
頭文字じゃないことにした (1)単一のプロトコルだけでは効率が悪いな、、、
↓
(2)いろんな用途に合わせてプロトコル仕様策定しよ
↓
(3)実装が大変になってきた、、、
↓
(4)HTTPでなんでもデータ通信できるようにしよ
↓
(5)単一のプロトコルだけでは効率が悪いな、、、
↓
(6)いろんな用途に合わせてプロトコル仕様策定しよ
どこの無限地獄だよ、、、 >>145
一貫してtslって書いてるから打ち間違いじゃなさそうだな >>7
電脳高等記述企画三とか書かれるよりましかな >>10
UDPってレベルじゃねーぞ？
UDPで通信担保する奴だとskeedって製品あったな。winny金子さんが顧問やってた企業。 これ既存のnwインフラそのまま使い続けられるんけ？ >>16
こっち側が対応しないと対向で通信出来ないんでは？ ■今までのHTTP通信
お前ら「おるかー？」
サーバー「おるでー！お前はまだおるかー？」
お前ら「おるぞー！」
お前ら「使い捨て暗号キー送るわ」
サーバー「こっちの使い捨て暗号キーも送るわ」
お前ら「（暗号文で）WEBページのデータくれ！」
サーバー「（暗号文で）ほらよ！」
→通信7回
■今までのHTTP通信（再接続時）
上と同じことを繰り返す
↓↓↓
■HTTP/3（通信4回）
お前ら「使い捨て暗号キー送るわ」
サーバー「こっちの使い捨て暗号キーも送るわ」
お前ら「（暗号文で）ホームページのデータくれ！」
サーバー「（暗号文で）ほらよ！あと番号札も送るわ」
→通信4回
■HTTP/3（再接続時）（通信2回）
お前ら「（暗号文で）WEBページのデータくれ！番号札はこいつだ！」
サーバー「（番号札で相手の使い捨て暗号キーを判断して、暗号文で）ほらよ！」
→通信2回
こんなイメージってこと？ ポリ公らから害悪でしかないおもちゃクソヘリを取り上げよう！
Defund the Police デモは民主主義が成立する最低条件な
▼いやがらせ5сｈに負けて、英半角小文字にして打ち込まないフサフサはハゲるってばよ
ＨΤтРＳ：／／ＤОＴ∪Р．ОＲＧ／∪РＬОＤΑ／ＤОＴ∪Р．ОＲＧ2823288.jpg >>158
一回の通信で7回やり取りはわかるけど
月平均にするとどんくらい？
それが問題やわ むかし資格試験の勉強したときに出てきたな
OSI参照モデルのトランスポート層のプロトコルがどうのこうのと
だから何って話で、オタだけで盛り上がってろって印象 HyperTextTranserProtocol Version Three
ってのも長すぎるし、まあ、頭文字取るよね >>163
普通に考えて、天文学的数字になるのは常識的に分かりそうだけど
httpリクエスト1回あたりに7回ってことだから
これで分からない人は、基礎知識が足りなすぎるから説明しても分からない
例えばGoogle Public DNSは10年前の段階で、既に1日平均700億回の
リクエストを受けている
https://www.rbbtoday.com/article/2012/02/15/86338.html
（DNSはISPのものを使うのが基本だし、当時はGoogle Public DNSも
マイナーだったけど、それでもコレ）
Cloudflareが受けたDDoSだと、1秒あたり1720万回のリクエストを
受けたこともある
https://blog.cloudflare.com/ja-jp/cloudflare-thwarts-17-2m-rps-ddos-attack-the-largest-ever-reported-ja-jp/ >>168
普及したプロトコルを変更するのは容易ではないから古臭いままなんだよなあ。
電子メールなんかもそうだけど。 >>7
アプセトネデブ！アプセトネデブ！アプセトネデブ！
人間が使うWebブラウザでは従来のHTTPでTCPで接続しておきながらほとんど連続転送しない
TCP自体も今のネット環境ではチェックサムエラーの再送なんてほとんど発生してないだろうし >>9
マイクロソフトとかは”ー”をつけるようになった
そういうガイドラインができてるんだよ >>56
>結局TCPを使う限りHead of Lineブロッキングが解消できないから
TCPと速度が同じなら、全ストリームが受け取れる速度の合計は同じなので、どれかのストリームが早く
受け取り完了できた分、他のストリームの受け取り完了が遅れる、つまるHOLブロッキングが起きるわけ
で、それを防ごうとしたら普通のTCPより不当に多くの帯域を食う、ただのインチキ技術だよ
google MAPで複数TCP使ったズルした時から、何も変わってない TCPは色々と無駄あるし時代に合わせてもっと軽量化したほうがいいこともあるよな
少なくとも月と地球の間だとTCPはまともに動かんと思うハンドシェイクがタイムアウトする HTTP/3はIETFのワーキンググループによる標準化プロセスが完了しRFC9114となっている
独自規格ではない>>179 >>180
なにいってんの
なんか思い込みしてんとちゃうTCPはざっくりとした規格で細かいことはすきにできたからこそこんな長期に使われてんだよ月と地球でもタイムアウトしないようにすればいいだけ
TCPができないのは転送レートの送信側の厳密な制御
だからスローから投げ始めてACK問題なければ多くしてって混雑でパケットロスするならすかさず下げるのが慣例的な使われ方
だいたいが慣例なんだよ慣例
生活の知恵レベル >>176
MSが騙されてるだけでAppleは無視してるぞw >>183
ん、やっぱ作り直したほうがいいと再認識したわ >>2
ガンダムの新作です→『機動武闘伝Gガンダム』
ｶﾞﾉﾀｧ･･･「ガ、ガンダムファイト！？」「監督が富野じゃない･･･だと･･･」 つまり今ある物を作り直す必要は無いし透過的な形で共存できる
何か問題あるの？ UDPになるのかよ
プロキシは対応できないやつかね UDPは個別の相手と接続手続きしなくて良いから手間が少なくて済む
その代わり再送とかの機能がなかったのをQUICで改善した感じかな nginxはHTTP/3に対応しているけどチューニングはこれからで速度的なメリットは生かせていないらしい サーバ側だけ対応してもクライアント側がQUIC使わないと実際には効果出ないと思う >>193
クライアント側は既に対応してるんじゃない？>>16 >>193
Googleが元締めならクライアント側処理も抜かりないかと >>183
なるほどね
柔軟な使い方できるわけね
運用でカバー的な >>196
これ見て運用でカバーとかプログラミング知らねーの？
仕様で細かいことまで決めてないからむかしのだし今のことなんてわかってないからだから実装レベルで必要なのを追加して
使い合うこっちとあっちは当然相手に合う実装が必要よ もしそれが運用でカバーするなんて実装も当然できるだろうがそんなのはめんどくさくて使ってられない
何のためにプログラミングするの？実装するときのTCP/IPスタックの話
https://www.saminiir.com/lets-code-tcp-ip-stack-1-ethernet-arp/
みたいな >>197
速度って何の速度だよ
光速度以上にはならんぞ >>195
AppleやマイクロソフトのHTTP Clientとかも？ ■ このスレッドは過去ログ倉庫に格納されています
