アカウント名:
パスワード:
HTTP-over-QUIC（HTTP/3）って、UDPなの！？？https://www.orangeitems.com/entry/2018/11/14/003000 [orangeitems.com]
セッションレスのUDPだとDoSアタックが容易になるのでは、という話らしいけど。
今時作られてるプロトコルなので、素人考えで思いつくような弱点ぐらいは徹底的に詰められてるから大丈夫。
TCPの性能に納得がいかないからって、必要な機能だけを残して、要らない機能を消す、ってのは出来ない。それをやるとTCPじゃなくなる。だから、TCPより速く通信できるアプリを作ろうとすると、UDPの上に載せることになる。ところが、アプリを作ってると、結局、セッション管理やら、パケットの到着確認やら再送やらの機能が必要になってアプリ内に実装していく羽目に陥る。
その車輪を毎回再発明するのもアレなので、必要最小限だけ詰め込んだ、Reliable UDPというプロトコルが密かにあったらしいけど、弱点だらけでセキュリティが現代の基準で使い物にならない。その辺も踏まえて同用途のために新たにGoogleが開発したのがQUIC、という解説は詳解 Reliable UDP [speakerdeck.com]が参考になる。
QUICを使ったアプリは、古の教科書に従えば、トランスポート層は信頼出来ないUDP通信に基づいて動くアプリであって、アプリ層で通信制御を全部やってる、という分類になる。教科書がどんどん古文書になってってるな。
Keepaliveのためにパケ死しそうなプロトコルだな。
高速な通信をしたければ、ブラウザは接続先ホストを記憶している必要がある。嫌味だな。
QUIC自体が弱点を詰めてたとしても、当面の間「セッションレスのUDPだとDoSアタックが容易になる」ことには変わりない。
今普及している一般的な業務用のルータ（L4まで制御）からすると、QUICなんてのはUDPで膨大なパケット垂れ流しているようにしか見えない。故に、QoS制御もできないし、DoSのような異常な通信と正常な通信を区別しての制御も極めて難しい。
業務用のルータがQUICに適した制御ができるようになるなんてのは10年は先になるだろうね。
そもそもQUICは暗号化前提だから中身判別できない。そのくせ内部でアプリケーションを区別するための情報があって、外からは暗号化された同じ宛先アドレス、宛先ポートのパケットだけど、なかでは音声もその他も全部流れてるってことになる。
QUICが流行ってしまったら、QoS自体不可能では。
機器の更新でついて来れないとこは消えてくださいってことなのかな。
別に標準化でお墨付きを与えなくても、どっかがUDP垂れ流しで自社のサービス高速化とかを勝手にやり出す可能性は常にあったわけだし。Gで始まる会社とか。
他の大手も追随して、謎のUDPだらけになっちゃって個別に対応しないとダメになるよりは、標準化して、何に対応すれば取り合えずば大丈夫、とした方がマシ、とかかな。
(CISCO 的な)L2 ACL は wire speed 出ること多いから、とりあえずそこで tcp なら established なルールで弾けていた有象無象がudp だと全開け素通しせざるを得ないって理解したんだけど、そういうことでいい？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
こんな記事が (スコア:0)
HTTP-over-QUIC（HTTP/3）って、UDPなの！？？
https://www.orangeitems.com/entry/2018/11/14/003000 [orangeitems.com]
セッションレスのUDPだとDoSアタックが容易になるのでは、という話らしいけど。
Re:こんな記事が (スコア:4, 興味深い)
今時作られてるプロトコルなので、素人考えで思いつくような弱点ぐらいは徹底的に詰められてるから大丈夫。
TCPの性能に納得がいかないからって、必要な機能だけを残して、要らない機能を消す、ってのは出来ない。それをやるとTCPじゃなくなる。
だから、TCPより速く通信できるアプリを作ろうとすると、UDPの上に載せることになる。
ところが、アプリを作ってると、結局、セッション管理やら、パケットの到着確認やら再送やらの機能が必要になってアプリ内に実装していく羽目に陥る。
その車輪を毎回再発明するのもアレなので、必要最小限だけ詰め込んだ、Reliable UDPというプロトコルが密かにあったらしいけど、
弱点だらけでセキュリティが現代の基準で使い物にならない。その辺も踏まえて同用途のために新たにGoogleが開発したのがQUIC、
という解説は詳解 Reliable UDP [speakerdeck.com]が参考になる。
QUICを使ったアプリは、古の教科書に従えば、トランスポート層は信頼出来ないUDP通信に基づいて動くアプリであって、
アプリ層で通信制御を全部やってる、という分類になる。教科書がどんどん古文書になってってるな。
Re: (スコア:0)
Keepaliveのためにパケ死しそうなプロトコルだな。
ブラウザに接続先ホストを記憶させるプロトコル。 (スコア:0)
高速な通信をしたければ、ブラウザは接続先ホストを記憶している必要がある。嫌味だな。
業務用機器の寿命分かって言ってるの？ (スコア:0)
今時作られてるプロトコルなので、素人考えで思いつくような弱点ぐらいは徹底的に詰められてるから大丈夫。
QUIC自体が弱点を詰めてたとしても、当面の間「セッションレスのUDPだとDoSアタックが容易になる」ことには変わりない。
今普及している一般的な業務用のルータ（L4まで制御）からすると、QUICなんてのはUDPで膨大なパケット垂れ流しているようにしか見えない。
故に、QoS制御もできないし、DoSのような異常な通信と正常な通信を区別しての制御も極めて難しい。
業務用のルータがQUICに適した制御ができるようになるなんてのは10年は先になるだろうね。
Re:業務用機器の寿命分かって言ってるの？ (スコア:2, 興味深い)
そもそもQUICは暗号化前提だから中身判別できない。
そのくせ内部でアプリケーションを区別するための情報があって、
外からは暗号化された同じ宛先アドレス、宛先ポートのパケットだけど、
なかでは音声もその他も全部流れてるってことになる。
QUICが流行ってしまったら、QoS自体不可能では。
Re: (スコア:0)
機器の更新でついて来れないとこは消えてくださいってことなのかな。
別に標準化でお墨付きを与えなくても、どっかがUDP垂れ流しで自社のサービス高速化とかを勝手にやり出す可能性は常にあったわけだし。Gで始まる会社とか。
他の大手も追随して、謎のUDPだらけになっちゃって個別に対応しないとダメになるよりは、標準化して、何に対応すれば取り合えずば大丈夫、とした方がマシ、とかかな。
Re: (スコア:0)
(CISCO 的な)L2 ACL は wire speed 出ること多いから、
とりあえずそこで tcp なら established なルールで弾けていた有象無象が
udp だと全開け素通しせざるを得ないって理解したんだけど、そういうことでいい？