【通信プロトコル】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はお友だちだからな
最初から >>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とかも？ 従来比で抑えられる通信量が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で再送すれば速くなるってのは知られてて実装も色々あったが、グーグル様がサーバとクライアントの実装を抑えて圧倒的物量でデファクトにしたって認識なんだがあってる？ ■ このスレッドは過去ログ倉庫に格納されています
