HTTP-over-QUICと呼ばれていたプロトコルの名称がHTTP/3に 19
ストーリー by hylom
まだ素人にはオススメできませんが 部門より
まだ素人にはオススメできませんが 部門より
今まで「HTTP-over-QUIC」と呼ばれていたプロトコルが、「HTTP/3」に改称されるようだ。インターネット関連技術の標準化を行なっているInternet Engineering Task Force（IETF）ですでに議論が行われており、正式な承認が出たという（MozillaのエンジニアDaniel Stenberg氏のブログ、ZDNet Japan、マイナビニュース、Publickey）。
QUICはGoogleが開発しているネットワークプロトコルで、低レイテンシ、ネットワーク帯域の効率的な利用、暗号化サポートなどが特徴とされている（過去記事）。HTTP-over-QUICはQUICプロトコル上でHTTPを使ってWebブラウザとWebサーバー間の通信を行うもの。すでにChromeブラウザにはQUICが実装されており、Googleのサービスなどで使われている。
Microsoftの資料はいずこかなあ？ (スコア:0)
EdgeとIIS、.NET FrameworkのHTTP/3(HTTP-over-QUIC)とTLS1.3のサポート計画はどこかに資料がありましたでしょうか？
QUIC (スコア:1)
Windows 10 ver.1809にwinquic.dll / winquic.sysってファイルが含まれているだろう？
これがQUIC対応のライブラリとドライバらしい。まだPreview扱いらしいがな。
TLS 1.3 (スコア:0)
TLS 1.3には、いずれ対応するとは言っているが、いつ対応するかは知らん。
https://blogs.windows.com/msedgedev/2016/06/15/building-a-faster-and-m... [windows.com]
関係無いけど、MS の匂いを感じる (スコア:0)
デファクトスタンダードを取れ
それで全てが獲れる
こんな記事が (スコア: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 だと全開け素通しせざるを得ないって理解したんだけど、そういうことでいい？
Re:こんな記事が (スコア:1)
追記の記事で、HTTP/3の使いみちが肯定されている
https://www.orangeitems.com/entry/2018/11/14/200044 [orangeitems.com]
CDNはDDoS対策がしやすいらしい。
(エッジサーバーが分散しているからDDoS攻撃しずらいのは直感的にわかるけど、この引用はちょっと弱そう)
https://www.cdnetworks.co.jp/solution/ddos.html [cdnetworks.co.jp]
オリジンのサーバーはUDPを開けないで、CDNのエッジサーバーだけにHTTP/3を対応させる。CDNはDDoS対策がしやすいらしいので、コンテンツ配信などのキャッシュされた大容量のデータ通信を安全に高速化できる。
Re: (スコア:0)
443/UDPだから、443/UDPをふさいでいると使えない。
Re: (スコア:0)
そしてUDPでセッション/コネクション風の仕組みが実装されるんですよ。
#マジでありそうでイヤだ
Re:こんな記事が (スコア:1)
ありそうではなくて、そうなる以外に考えられないのですが。
なんでUDP上でやるかと言えば、既存のインターネットで新しいTCP後継プロトコルを流すにはそれ以外に上手くいきそうな方法がないってだけ。
IPの上に直接新しいプロトコルを乗せたら対応できるネットワーク機器がほとんど無い状態からのスタートになる。
Re: (スコア:0)
ほんとそうですよね。実際、本来IP上に載るプロトコルにも関わらず、UDP上でやりとりする規定も設けられたプロトコル、いくつもあります。IPsec ESP、SCTP (RFC 6951)、DCCP (RFC 6773)、RVSP (RFC 2205 APPENDIX C.)。
Re:こんな記事が (スコア:2)
SCTPは対応する奴も出てきてると思ってたが伸びてないんかなぁ
Re: (スコア:0)
TCP/IPなんて言われているようにIPとTCP/UDPはOSI参照モデルのように綺麗に分離されているわけではないからかな。
そんなことするなら事実上IPやめることになるんだろうね。
でも独自ネットワーク作ろうとする国家があったりするから以外とやれないわけではないのかも。