【通信プロトコル】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/ IETFは(RFC)Request for commentsで てかさ、その新しいプロトコルに対応するのがhttpdてか、Webサーバだとして、実際にパケットがどう動くのか見てみないとわからんから
まぁテスト環境作るか… Webサーバーじゃねーからちゃんと、Webサーバと書け >>9
え、「HTTP/3」とか言っているから、HTTP関連かと思ってた
nginxとかapacheとかが対応するようになるのかと思た パケロス環境だと大変なことになりそう
その場合はTCPに切り替わるんかな >>9
伸ばすようになってもうだいぶ経つけど
そんなことよりついでに増えたデーターにイライラする >>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にアクセスすれば試せるぞ >>17
神戸でそれで追っかけられたが、おまえ神戸か >>17
これなんだろうと思ったらいばらぎ（なぜか変換できない）県の方言か パイプライニング昔からあるのに整備しないで私企業に都合いいプロトコルが取って代わるってのはなんだかなぁ QUICはなんか制約あってやってない
なんだっけな？
忘れた
UDPにしたら当然速くなる >>16
おぉ…そうだったのか…ちゃんと読んでなかった…詳細トンクス
パケット覗いてみたら…てか俺の頭でわかるかどうかだけどｗ 見てみようかなｗ
なんかここ数年、早すぎるよ…WebRTCでなんとかだったのに、あの時もGoogleがUDPベースで新しいプロトコル作っているて情報みたけど
３・４年さぼったら、その時でも辛かったのに、もうあれだよ、はるか先だよ スレタイ読んでも全く分からん
簡潔に誰か説明してくれないか 単なるUDPの上にレイヤか被せただけやんｗ
厳密にはセッション層だろｗ
トランスポート層の一個上やん >>1
大切なのは旧ハードでも現ハードでも利用できるかどうかだ
Windows11みたいにTPM2.0以下は対応しないと足切りされたら叶わないからな >>26
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
これがヒキニートか 「お客様バカですか」逆ギレも 急増する“PCサポート詐欺”…業者を直撃 手口の実態
news.yahoo.co.jp/articles/4fb8aaa341ff1faa44b3ec4a6e9bcc8b305b0fac 通信プロトコルの革新か、今でもWindows95や98でも
セキュリティキーはともかくLANを使えインターネットにも接続できる
でも通信プロトコルが変わるんじゃ使えなくなるな これってMVNOの昼の時間帯のping悪化に少しは効果ありますか？ >>31
UDPパケットやから接続でいるけどブラウザが対応してないんで通信できない
正確にはね
98なんてルート証明書が期限ぎれ
最新ブラウザインストール不能 >>28
QUIC通さないルーターとかはあるかもな
ファイアウォールの設定とか面倒そうではある >>36
ねーよバカ
ルール書かなきゃ素通り
全然理解してないのバレバレ >>36
ベースUDPみたいだし、そんなことないか >>34
なるほど、サンクス
鯖に接続する時のFTPとか
メールソフトはどうなんだろうね >>40
最新のFirefoxやChromeが動くならお前等エンドユーザーが気にすることは何もない
1行で済むこと Win95のTCP-IPプロトコル設定ってよくわからずに複数回やったけど、あんなのスマホ世代には絶対無理だろ たんにUDPの上に乗っかってるだけじゃないのかコレ
あと経路はHTTP/3に対応していなくても問題なく使えるのか？ >>45
キャッシュサーバ、プロキシなんかは意識する必要ないって認識なの？ これ今までLVSのDR構成でやってたような大規模なロードバランシングってどうするの？
QUICのIPマイグレーションが発生した時のhttpd側のログとかwebアプリから見たremote IPてどうなるの？ >>47
実装による
フリーで対応しているのは無いかもな これがうまく普及したらApacheがNginX対して優位ができるかな？ >>48
機能が対応してないなら最悪買い直し
まぁファームのアップで対応するんじゃね？ 結局どういう事？
素麺6束を1束ずつ別々の鍋で調理するより
でかい鍋1つで6束全部茹でた方が効率良いって話？ >>53
トラック6台で送るより電車1編成で送ろうぜ ふむふむ なるほど なるほど わからん
UDPは垂れ流しやろ？ リトライをオーバーヘッド最少でやるという事？ >>51
結局TCPを使う限りHead of Lineブロッキングが解消できないから
つか解消しようとするとそれSCTPじゃんて話になって
エンドのルーターが対応してないって結論になるのでUDPに乗せることにした 考えたやつはここにいる連中よりはるかに頭いいだろうし俺らに仕組みがようわからんでも大丈夫やろ とりあえずTCPと違って経路上の機器から明確なコネクションの終わりがわからないので
CGNとかやってるルーターはポートがあふれて死ぬ気がする ネットワークの試験勉強しとるけど
これからの通信は、ルータの概念が消えて
コントローラという一つの上位層がすべて制御する通信になるって書いてる >>7
うぅ〜ん、確かに（）内は英語だ
（）内にカタカナか日本語訳を書けば良いのかな？ フロー制御するならTCP と性能で大きな差になるとは思えないが、実際違うもんなのかね。
シーケンスを細かく記事にしてくれているサイトあればみてみたい。 >>7
日本独自の漢字ひらがなで使えるシステム作ってくれ でもこれポゼッションコールからのフェーディングロケーションシステムつかってるからランアバウト的なやつだろ？ いうてあと20年はTCPメインやろ
IPv4も未だに残ってるし インターネットのトラフィックはいまや動画サイトが大半を占める
動画サイトのトラフィックを減らす規格が必要 >>7
まあ気持ちはわかる
25年位前に開発してた機器をネットワーク対応にすることになって詳しそうな人に聞きに行ったら３文字略語だらけで最初はちんぷんかんぷんだったわ
まあその人ちゃんと最後まで教えてくれたから感謝してる UDPだとパケットロスしたら再送することになるから逆に通信量が増える予感しかしないが大丈夫か？
暗号通信にUDP使ってパケットロスしたらネゴシエーションからやり直しだぜ >>79
もしかしてTCPはロストしてもパケット再送しないで済む魔法の技術だとでも思ってるのか？ 日本の最大の弱みは
人脈（人間関係）至上主義！
政界でも企業内でも
人間関係だけの人脈コジキ営業職
が幅を効かして有能な人材を押しのける
企業内では
人間関係だけの人脈コジキ営業職
が威張り腐って、貴重な技術職は不遇になる
だから優秀な技術職が
中韓に引き抜かれて技術パクリされる
「やーどーもどーも」だけで仕事を恵んでもらう
人間関係だけの人脈コジキ営業マンが出世して
優秀な技術職が薄給で冷遇されてれば
日本の科学技術力が衰退するのは当然だ
そして行き着く先の最悪ケースは
みずほ銀行のシステムトラブルだ
本来なら社長にすべき優秀な技術職を
プライドさえ捨てれば馬鹿でも出来る
人脈コジキ営業職に異動させたりしている
まったく狂気の沙汰である
これで国際競争に勝とうなんて
本気で思っているのなら
世界でもマレにみるアホ企業だ！
ルータのフィルタ処理ができんからしばらく閉めたままだな QUICは既存ネットワーク機器でも使えるのか？
なら普及するかも！？ とりあえずTCPは〜UDPは〜って言ってるやつは通信階層の概念が分かってない >>67
ヘッダが簡略するのと3way handshakeがなくなるは影響は大きそう パケットの内容とか読むのが難しくならないこれ？
セキュリティとかトラフィックコントロールとか、大丈夫なんかな >>57
遥かに頭のいいやつが考えたはずのipv6とか未だに普及してないし、頭のいいやつを盲信するのは危険だよ >>67
複数ストリームを流してるときにパケットロスが発生しても影響を受けるのは
ロスしたストリームのみってのは大きいかもね
(TCPだとコネクション全体で再送が行われるので全部のストリームに影響する) 超簡単にいうと、
データ送信側は投げっぱなしで受信側が受信できてないと判断したら、その部分だけデータ再送信
こんな感じか テルネットでつないで動作確認とかできなくなるな…隔世の感 さっぱりわからんが 次世代の通信プロトコルで通信が早くなるということだけ分かった
今より良くなるならいいんじゃね >>16
ほんとだ、GOOGLEにアクセスしたらHTTP/3だった！ 単語はなんとなく知ってるけど、畑違いだからぼんやりとしかワカラン
横文字ばかり並んでるけど
キップ買うよりSUICAが早いよねって事かな
手続きで、線自体が早くなったわけでは無い・・・はず もともとUDP/TCPはお友だちだからな
最初から ■ このスレッドは過去ログ倉庫に格納されています
