【通信プロトコル】HTTP/3が正式に勧告、脱TCP時代の幕開けか [エリオット★]

1 ：へっぽこ立て子＠エリオット ★：2022/06/08(水) 14:39:22.59 ID:CAP_USER.net

　インターネット関連技術の標準化を手掛ける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/

100 ：名刺は切らしておりまして：2022/06/08(水) 21:50:04 ID:2rozZg0z.net

もともとUDP/TCPはお友だちだからな
最初から

101 ：名刺は切らしておりまして：2022/06/08(水) 21:51:06 ID:2rozZg0z.net

>>97
自分がやり出したのを標準化に乗せたんだから当然だ
情報遅すぎる

102 ：名刺は切らしておりまして：2022/06/08(水) 23:03:04.32 ID:LmxJ0AYGt

ルータのnatテーブルが心配

103 ：名刺は切らしておりまして：2022/06/08(水) 21:53:12 ID:2rozZg0z.net

>>96
次世代じゃないな
元からあったのを使えるようにしたんだから
UDPはTCPと同じくIP使えるようになった時から使えてる
細かくいえばUDPのが先か

104 ：名刺は切らしておりまして：2022/06/08(水) 21:54:01 ID:2rozZg0z.net

>>96
さっぱりわからんってそもそもTCPわかってて言ってんの？

105 ：名刺は切らしておりまして：2022/06/08(水) 21:54:01 ID:7JmtlY8y.net

エックスサーバーもさくらインターネットも、レンタル用はHTTP/2だったが、
両社のホームページはHTTP/1.1だった

106 ：名刺は切らしておりまして：2022/06/08(水) 21:54:38 ID:BCIpdW7D.net

>>15
わかるw
伸ばすのは最後がrのもんだけだよな

107 ：名刺は切らしておりまして：2022/06/08(水) 21:54:42 ID:ins3BqVW.net

そもそもいろんなfirewallすんなり通るのか？

108 ：名刺は切らしておりまして：2022/06/08(水) 21:54:52 ID:2rozZg0z.net

>>105
別にメリットなけりゃそれでいいだろ

109 ：名刺は切らしておりまして：2022/06/08(水) 21:57:33 ID:2rozZg0z.net

>>106
伸ばすとか伸ばさないとかカンケーないんだ
JISが申請にはこれ使えって言ってるだけだ
世の中JISなんてのは関係ないからな
ところが申請だけじゃなくて全てそれでなければいけないとかいう老害の言葉を信じちゃったテクニカルしか興味ない技術者が思い込んでた

110 ：名刺は切らしておりまして：2022/06/08(水) 21:58:59 ID:o+cY57fV.net

>>103
記事をみると、こままで訂正／再送の仕組みがなかったUDPに
限定的にその仕組みを取り入れただけのように見える

111 ：名刺は切らしておりまして：2022/06/08(水) 21:59:45 ID:2rozZg0z.net

>>94
そんなのはTCP/IPの本の最初にあるUDPの解説でそれは1990年の本にも載ってる

112 ：名刺は切らしておりまして：2022/06/08(水) 22:00:16 ID:2rozZg0z.net

>>110
それがGoogleさまが作ったQUIC

113 ：名刺は切らしておりまして：2022/06/08(水) 22:02:20 ID:eUzMpHbx.net

>>98
各駅から隔駅くらい

114 ：名刺は切らしておりまして：2022/06/08(水) 22:04:00 ID:2rozZg0z.net

>>109
そもそも横棒はないのが正しいんじゃなくて「省いて」るんだよ
なぜか
紙の時代にはスペースが貴重だったから何度も繰り返し出てくるのが一文字でも少なければそれが利点だろ

なのに「ないのが正式」とかバカな話にすり替えられて何十年

日本の技術が進まないのがよくわかるだろ

115 ：名刺は切らしておりまして：2022/06/08(水) 22:06:25 ID:o+cY57fV.net

>>112
投げっぱなしで送信するデータの最大量をどう設定するんだろね
小さいと今までと変わりないし、
大きいとデータを得られないパケットがあったときページの表示に時間がかかってしまう

116 ：名刺は切らしておりまして：2022/06/08(水) 22:07:55 ID:zx8rANQl.net

>>7
超文転送通信手順3号

117 ：名刺は切らしておりまして：2022/06/08(水) 22:09:05 ID:2rozZg0z.net

>>90
その考えが日本がバカな理由の一つ
何十年も前からやってなけりゃ必要な時には使えない
使いたい時には全部利権が取られてる

インターネットそのものがそうだろ
しかも頭じゃなくてカラダで実際に使って使えるものが使われていくのがインターネット
だから複数乱立してても構わない
日本人は頭悪いと思われたくなくてはじめもしない

118 ：名刺は切らしておりまして：2022/06/08(水) 22:10:21 ID:2rozZg0z.net

>>116
あは
漢字でも横文字なのになあ
あはは

119 ：名刺は切らしておりまして：2022/06/08(水) 22:12:46 ID:2rozZg0z.net

>>117
自律走行車もその口で
これなんか官僚がITSとか中央集権システムやります大口だったから日本の自動車会社はどこも後づけ
今やITSないだろ？知ってる？
そういえばしれっとITSに自律走行車って書いてあったな

120 ：名刺は切らしておりまして：2022/06/08(水) 22:15:48 ID:o+cY57fV.net

IPv6は浸透していないというより、ネットワークの知らない部分で使われていて
IPアドレスの枯渇防止に寄与しているというのが正しいかと
多くの人が利用しているフレッツ網のNGNはIPv6で構成されているし

なお、フレッツ光ネクストとかで、IPv6 IPoEのバーチャルコネクトサービスを利用できる
環境にあるのに設定していない人もいるだろうから、環境は見直したほうがいいかもね

121 ：名刺は切らしておりまして：2022/06/08(水) 22:19:21 ID:nxRuUx7y.net

>>107
当然新たに対応しないとダメ

122 ：名刺は切らしておりまして：2022/06/08(水) 22:19:29 ID:2rozZg0z.net

>>114
つまりJISが横棒はここ省いてねとガイドしてたのはJIS規格の文書を見やすくするためだったんだよ
紙だったからだよ

それ以外に横棒の何が正式かとか制限はなくて商標登録とかくらいが正式かどうかのもん

ところが大学の先生がJISを憲法のように扱ったから会社の技術部門もJIS提出で作り直すの面倒出しとかいうのが積み重なってバカな金科玉条ができてた

日本てproduceなのに生産と産生とか使い分けないと文句言われてそれ覚えるだけで頭使い果たして本当に「生産的」な話に頭を使えないから寿司職人になるのに20年かかるかわけよ

いい加減年期長いのはバカにしてみろよ

123 ：名刺は切らしておりまして：2022/06/08(水) 22:20:23 ID:2rozZg0z.net

>>120
ちなみにうちは6だよ
あさひネットはユーザーレベル早かったな

124 ：名刺は切らしておりまして：2022/06/08(水) 22:21:24 ID:2rozZg0z.net

>>115
なぜQUIC調べないの？

125 ：名刺は切らしておりまして：2022/06/08(水) 22:23:40 ID:o+cY57fV.net

>>124
実際どうやってそれを解決しているの？教えてくれると嬉しい
なおお前が本当にその知識をしっているのか、他の人に知ってもらうことにも役立つ

一石二鳥

126 ：名刺は切らしておりまして：2022/06/08(水) 22:38:14 ID:2rozZg0z.net

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]

127 ：名刺は切らしておりまして：2022/06/08(水) 22:38:48 ID:2rozZg0z.net

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]

128 ：名刺は切らしておりまして：2022/06/08(水) 22:41:57 ID:s2lW6iew.net

コマンドをアスキーで送るとか正気の沙汰じゃないね

129 ：名刺は切らしておりまして：2022/06/08(水) 22:56:08 ID:idArNWf7.net

UDPで無駄な再送減らせるのは良いとして、途中の経路での支援は受けられなくなるよね
少なくとも今のところは

130 ：名刺は切らしておりまして：2022/06/08(水) 23:00:16 ID:P7fZeVou.net

>>38
NATが心配

131 ：名刺は切らしておりまして：2022/06/08(水) 23:08:59 ID:6v66TjDh.net

(´・ω・`)何この誰もわかんないニュース

132 ：名刺は切らしておりまして：2022/06/08(水) 23:18:48 ID:PGSJBWBr.net

>>108
機能追加とかではなく、高速化というメリットだから誰もが恩恵受ける万能的なものだよ
対応しないのはユーザー視点より自身の利益を見てるだけ

133 ：名刺は切らしておりまして：2022/06/08(水) 23:36:25 ID:X0Dj6QUp.net

>>130
大量のコネクション張るような使い方だとNATテーブル溢れちゃうかもね
安いルータだとNATテーブルの上限小さかったりするし
ただ、一つのコネクションで複数ストリームを流せるのでアプリケーション
の実装次第でそこまで問題にならないのでは

134 ：名刺は切らしておりまして：2022/06/08(水) 23:41:05 ID:Kjm/CGBS.net

HVDCも早よ

135 ：名刺は切らしておりまして：2022/06/09(木) 01:02:37 ID:a7vc0g0U.net

田代砲の威力減弱するってこと？

136 ：名刺は切らしておりまして：2022/06/09(木) 01:13:34 ID:viC79xh/.net

>>7
うるせえ、全部英語でええわ

137 ：名刺は切らしておりまして：2022/06/09(木) 01:14:13 ID:viC79xh/.net

>>131
通信遅延が少なくなると思ってくれればええよ

138 ：名刺は切らしておりまして：2022/06/09(木) 03:54:44 ID:LoLKYy1h.net

そらUDPで確実に通信できるならUDPのほうがいいよね

139 ：名刺は切らしておりまして：2022/06/09(木) 05:25:53 ID:CU8CAwdP.net

>>7
全部漢字に訳す中国人か？

140 ：名刺は切らしておりまして：2022/06/09(木) 06:42:36 ID:SvOVy2Et.net

>>118
あは
それ横書きな
あはは

141 ：名刺は切らしておりまして：2022/06/09(木) 07:39:18 ID:AcwI1A/n.net

UDPで再送出来るようになるんか。
HTTP以外でも使えれば変革が起きそう。
ま、ユーザは何もわからんけどw

142 ：名刺は切らしておりまして：2022/06/09(木) 07:42:23 ID:Z9aK7ola.net

最終的にはリソースクラッシュ起因のトータルギッダムが起きてマスターコンベクターが右往左往するみたいなイメージだな

143 ：名刺は切らしておりまして：2022/06/09(木) 08:00:20 ID:+Bl5Z0iA.net

UDPって懐かしいわ、PKG間の通信で使ってた
あの頃は楽しかったわ

144 ：名刺は切らしておりまして：2022/06/09(木) 08:07:18 ID:OXL6L1SJ.net

>>68
コードの部分は英語or日本語？

145 ：名刺は切らしておりまして：2022/06/09(木) 08:22:19 ID:q92ie1Gn.net

QUIC仕様がグダグダだったから前途多難で短命で終わるだろうと見ている
最先端のリアルタイム通信処理開発はすでにQUICを捨てて独自開発を進めている
その中で成功したものが次の規格の土台なる

146 ：名刺は切らしておりまして：2022/06/09(木) 08:31:34 ID:Fz7KBqfS.net

脱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だけでカーネルモードじゃなくアプリモードで動く

147 ：名刺は切らしておりまして：2022/06/09(木) 08:43:20 ID:IEd2akTH.net

>>59
?
SDNの話？ルーティングは必須だろ。コントローラが何を意味してるか分からんが。

148 ：名刺は切らしておりまして：2022/06/09(木) 09:05:10 ID:Z801UMtw.net

>>146
x UDPポートは443だけでカーネルモードじゃなくアプリモードで動く
o UDPポートは443だけ使う でQUICはカーネルモードじゃなくアプリモードで動く

あと
>>1の
QUIC（Quick UDP Internet Connections）
じゃなくて
IETFはQUIC quic だけだってよ
頭文字じゃないことにした

149 ：名刺は切らしておりまして：2022/06/09(木) 09:50:19 ID:t1zYMAuN.net

(1)単一のプロトコルだけでは効率が悪いな、、、
↓
(2)いろんな用途に合わせてプロトコル仕様策定しよ
↓
(3)実装が大変になってきた、、、
↓
(4)HTTPでなんでもデータ通信できるようにしよ
↓
(5)単一のプロトコルだけでは効率が悪いな、、、
↓
(6)いろんな用途に合わせてプロトコル仕様策定しよ

どこの無限地獄だよ、、、

150 ：名刺は切らしておりまして：2022/06/09(木) 10:48:04 ID:tMojvnep.net

英語文化圏は頭文字羅列ばっか

151 ：名刺は切らしておりまして：2022/06/09(木) 11:57:15 ID:t2kAHOO+.net

>>146
一貫してtslって書いてるから打ち間違いじゃなさそうだな

152 ：名刺は切らしておりまして：2022/06/09(木) 12:00:30 ID:0m3RIDyO.net

情室は大騒ぎ

153 ：名刺は切らしておりまして：2022/06/09(木) 12:01:50 ID:yk1SV98F.net

>>7
電脳高等記述企画三とか書かれるよりましかな

154 ：名刺は切らしておりまして：2022/06/09(木) 12:21:21 ID:IEd2akTH.net

>>10
UDPってレベルじゃねーぞ？

UDPで通信担保する奴だとskeedって製品あったな。winny金子さんが顧問やってた企業。

155 ：名刺は切らしておりまして：2022/06/09(木) 12:46:54 ID:xbcrFd8v.net

これ既存のnwインフラそのまま使い続けられるんけ？

156 ：名刺は切らしておりまして：2022/06/09(木) 12:53:31 ID:sKLxsTz2.net

>>16
こっち側が対応しないと対向で通信出来ないんでは？

157 ：名刺は切らしておりまして：2022/06/09(木) 12:57:18 ID:sKLxsTz2.net

>>35
どのくらい？
体感できるくらい？

158 ：名刺は切らしておりまして：2022/06/09(木) 13:03:18 ID:5mWADUOz.net

>>68
( ﾟ∀ﾟ)つ ぴゅう太

159 ：名刺は切らしておりまして：2022/06/09(木) 14:32:21 ID:KpixR4n6.net

■今までのHTTP通信
お前ら「おるかー？」
サーバー「おるでー！お前はまだおるかー？」
お前ら「おるぞー！」
お前ら「使い捨て暗号キー送るわ」
サーバー「こっちの使い捨て暗号キーも送るわ」
お前ら「（暗号文で）WEBページのデータくれ！」
サーバー「（暗号文で）ほらよ！」

→通信7回

■今までのHTTP通信（再接続時）
上と同じことを繰り返す

　↓↓↓

■HTTP/3（通信4回）
お前ら「使い捨て暗号キー送るわ」
サーバー「こっちの使い捨て暗号キーも送るわ」
お前ら「（暗号文で）ホームページのデータくれ！」
サーバー「（暗号文で）ほらよ！あと番号札も送るわ」

→通信4回

■HTTP/3（再接続時）（通信2回）
お前ら「（暗号文で）WEBページのデータくれ！番号札はこいつだ！」
サーバー「（番号札で相手の使い捨て暗号キーを判断して、暗号文で）ほらよ！」

→通信2回


こんなイメージってこと？

160 ：名刺は切らしておりまして：2022/06/09(木) 14:36:53 ID:ybjUFjGc.net

>>159
再送処理も解説よろ

161 ：名刺は切らしておりまして：2022/06/09(木) 15:12:17 ID:LmP/i1pg.net

ポリ公らから害悪でしかないおもちゃクソヘリを取り上げよう！
Defund the Police デモは民主主義が成立する最低条件な

▼いやがらせ5сｈに負けて、英半角小文字にして打ち込まないフサフサはハゲるってばよ
ＨΤтРＳ：／／ＤОＴ∪Р．ОＲＧ／∪РＬОＤΑ／ＤОＴ∪Р．ОＲＧ2823288.jpg

162 ：名刺は切らしておりまして：2022/06/09(木) 15:34:22 ID:ApXEnp7u.net

HTTP/2で既にQUIC使えたんじゃ？

163 ：名刺は切らしておりまして：2022/06/09(木) 16:25:50 ID:3Jyj8pgk.net

これなんかいいことあるんか

164 ：名刺は切らしておりまして：2022/06/09(木) 16:38:41 ID:z4mbD78T.net

>>159
一回の通信で7回やり取りはわかるけど
月平均にするとどんくらい？
それが問題やわ

165 ：名刺は切らしておりまして：2022/06/09(木) 16:43:27 ID:bbfZNLA+.net

>>7
H
T
T
P
/
3

166 ：名刺は切らしておりまして：2022/06/09(木) 16:48:02 ID:JFc00UBI.net

むかし資格試験の勉強したときに出てきたな
OSI参照モデルのトランスポート層のプロトコルがどうのこうのと
だから何って話で、オタだけで盛り上がってろって印象

167 ：名刺は切らしておりまして：2022/06/09(木) 17:00:36 ID:55BW1mL5.net

HyperTextTranserProtocol Version Three
ってのも長すぎるし、まあ、頭文字取るよね

168 ：名刺は切らしておりまして：2022/06/09(木) 17:12:30 ID:GR6wTjiT.net

>>5
これ。 勧告！？

169 ：名刺は切らしておりまして：2022/06/09(木) 17:16:27 ID:z+z/+W1O.net

えー、プロトコルにまだ改善の余地があったのか

170 ：名刺は切らしておりまして：2022/06/09(木) 18:06:59 ID:KpixR4n6.net

>>164
普通に考えて、天文学的数字になるのは常識的に分かりそうだけど
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/

171 ：名刺は切らしておりまして：2022/06/09(木) 18:22:39 ID:FZg333eU.net

>>169
普及したプロトコルを変更するのは容易ではないから古臭いままなんだよなあ。
電子メールなんかもそうだけど。

172 ：名刺は切らしておりまして：2022/06/09(木) 18:49:32 ID:SvOVy2Et.net

>>165
だからそれは縦書きだっつーの

173 ：名刺は切らしておりまして：2022/06/09(木) 19:23:51 ID:SvOVy2Et.net

>>169
いまでも色々改善提案されてる
HTTP/3が最新じゃない
https://i.imgur.com/uTOOwsd.jpg
https://www.rfc-editor.org/

174 ：名刺は切らしておりまして：2022/06/09(木) 20:47:40 ID:YAMqW3gn.net

輻輳制御どうすんだ？

175 ：名刺は切らしておりまして：2022/06/09(木) 21:12:07 ID:UwwqbgLn.net

>>7
アプセトネデブ！アプセトネデブ！アプセトネデブ！

176 ：名刺は切らしておりまして：2022/06/09(木) 21:52:20 ID:O9uAbT0Z.net

　
人間が使うWebブラウザでは従来のHTTPでTCPで接続しておきながらほとんど連続転送しない
TCP自体も今のネット環境ではチェックサムエラーの再送なんてほとんど発生してないだろうし

177 ：名刺は切らしておりまして：2022/06/09(木) 22:32:33 ID:WDx0dPQ3.net

>>9
マイクロソフトとかは”ー”をつけるようになった
そういうガイドラインができてるんだよ

178 ：名刺は切らしておりまして：2022/06/09(木) 22:59:43 ID:VFgs53gp.net

>>56
>結局TCPを使う限りHead of Lineブロッキングが解消できないから

TCPと速度が同じなら、全ストリームが受け取れる速度の合計は同じなので、どれかのストリームが早く
受け取り完了できた分、他のストリームの受け取り完了が遅れる、つまるHOLブロッキングが起きるわけ
で、それを防ごうとしたら普通のTCPより不当に多くの帯域を食う、ただのインチキ技術だよ

google MAPで複数TCP使ったズルした時から、何も変わってない

179 ：名刺は切らしておりまして：2022/06/09(木) 23:33:12 ID:Tyi+MxmF.net

日本語喋れ馬鹿

180 ：名刺は切らしておりまして：2022/06/09(木) 23:42:57 ID:bMDkQ5j6.net

ActiveXとか独自規格はもうたくさん

181 ：名刺は切らしておりまして：2022/06/10(金) 00:31:32 ID:K8cXsKDR.net

TCPは色々と無駄あるし時代に合わせてもっと軽量化したほうがいいこともあるよな
少なくとも月と地球の間だとTCPはまともに動かんと思うハンドシェイクがタイムアウトする

182 ：名刺は切らしておりまして：2022/06/10(金) 00:38:00 ID:K8cXsKDR.net

HTTP/3はIETFのワーキンググループによる標準化プロセスが完了しRFC9114となっている
独自規格ではない>>180

183 ：名刺は切らしておりまして：2022/06/10(金) 01:02:26 ID:uqjZ/X79.net

googleの独自規格を標準化するだろう

184 ：名刺は切らしておりまして：2022/06/10(金) 01:05:25 ID:E51bBTEb.net

>>181
なにいってんの
なんか思い込みしてんとちゃうTCPはざっくりとした規格で細かいことはすきにできたからこそこんな長期に使われてんだよ月と地球でもタイムアウトしないようにすればいいだけ
TCPができないのは転送レートの送信側の厳密な制御
だからスローから投げ始めてACK問題なければ多くしてって混雑でパケットロスするならすかさず下げるのが慣例的な使われ方
だいたいが慣例なんだよ慣例
生活の知恵レベル

185 ：名刺は切らしておりまして：2022/06/10(金) 01:23:15 ID:kqggIYEw.net

>>177
MSが騙されてるだけでAppleは無視してるぞw

186 ：名刺は切らしておりまして：2022/06/10(金) 01:33:24 ID:K8cXsKDR.net

>>184
ん、やっぱ作り直したほうがいいと再認識したわ

187 ：名刺は切らしておりまして：2022/06/10(金) 01:52:01 ID:yjvmvl+T.net

>>2
ガンダムの新作です→『機動武闘伝Gガンダム』
ｶﾞﾉﾀｧ･･･「ガ、ガンダムファイト！？」「監督が富野じゃない･･･だと･･･」

188 ：名刺は切らしておりまして：2022/06/10(金) 02:26:17 ID:K8cXsKDR.net

既存のHTTPサーバーをHTTP/3化する手法を使ってPiping ServerをHTTP/3対応する

https://scrapbox.io/nwtgck/%E6%97%A2%E5%AD%98%E3%81%AEHTTP%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E3%82%92HTTP%2F3%E5%8C%96%E3%81%99%E3%82%8B%E6%89%8B%E6%B3%95%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6Piping_Server%E3%82%92HTTP%2F3%E5%AF%BE%E5%BF%9C%E3%81%99%E3%82%8B

189 ：名刺は切らしておりまして：2022/06/10(金) 02:30:56 ID:K8cXsKDR.net

つまり今ある物を作り直す必要は無いし透過的な形で共存できる
何か問題あるの？

190 ：名刺は切らしておりまして：2022/06/10(金) 04:27:44 ID:4LPQUpSV.net

>>7
馬鹿は失せろ

191 ：名刺は切らしておりまして：2022/06/10(金) 06:16:07 ID:yVzOots8.net

UDPになるのかよ
プロキシは対応できないやつかね

192 ：名刺は切らしておりまして：2022/06/10(金) 09:07:38 ID:gXMt4pAg.net

UDPは個別の相手と接続手続きしなくて良いから手間が少なくて済む
その代わり再送とかの機能がなかったのをQUICで改善した感じかな

193 ：名刺は切らしておりまして：2022/06/10(金) 09:21:27 ID:BgTn2IlU.net

nginxはHTTP/3に対応しているけどチューニングはこれからで速度的なメリットは生かせていないらしい

194 ：名刺は切らしておりまして：2022/06/10(金) 09:23:17 ID:gXMt4pAg.net

サーバ側だけ対応してもクライアント側がQUIC使わないと実際には効果出ないと思う

195 ：名刺は切らしておりまして：2022/06/10(金) 09:49:43 ID:LrxDWx0k.net

>>194
クライアント側は既に対応してるんじゃない？>>16

196 ：名刺は切らしておりまして：2022/06/10(金) 09:57:39 ID:qvr/5FTa.net

>>194
Googleが元締めならクライアント側処理も抜かりないかと

197 ：名刺は切らしておりまして：2022/06/10(金) 10:38:50 ID:LSZhgoBp.net

>>184
なるほどね
柔軟な使い方できるわけね
運用でカバー的な

198 ：名刺は切らしておりまして：2022/06/10(金) 11:02:44 ID:OHZk5aNM.net

速度あげれば解決

199 ：名刺は切らしておりまして：2022/06/10(金) 11:20:36 ID:bSsKTbLA.net

>>197
これ見て運用でカバーとかプログラミング知らねーの？
仕様で細かいことまで決めてないからむかしのだし今のことなんてわかってないからだから実装レベルで必要なのを追加して

使い合うこっちとあっちは当然相手に合う実装が必要よ もしそれが運用でカバーするなんて実装も当然できるだろうがそんなのはめんどくさくて使ってられない
何のためにプログラミングするの？実装するときのTCP/IPスタックの話
https://www.saminiir.com/lets-code-tcp-ip-stack-1-ethernet-arp/
みたいな

200 ：名刺は切らしておりまして：2022/06/10(金) 11:27:56 ID:7Iqkitfp.net

>>198
速度って何の速度だよ
光速度以上にはならんぞ