インターネット関連技術の標準化を手掛けるIETFは6日、通信プロトコル「HTTP/3（HyperText Transport Protocol/3）」を「RFC 9114」として勧告した。HTTP/3はHTTPでは7年ぶりのメジャーアップデートとなる。HTTP/3では、HTTPのトランスポート層を従来のTCPからQUICに置き換えるという大きな変更が行われ、コネクション確立やエラー処理などのオーバーヘッドを低減させて高速化を図ったことにより、効率的でレイテンシの小さな通信を行えるようになったとしている（Publickey、日経クロステック）。
それがQUICだとプロトコルの流れがTLSトンネルの中で、且つポート番号も多くのアプリケーションが443つかっているから、基本全量検査になるので負荷爆上げですな、って話。 これは「xxx over HTTPS」の流れの時から既に、443番ポートはペイロード完全監視監視対象下にしていることが多いとは思うけど、 今までポート番号を443以外を使っていたところもQUICに合流されると、負荷爆上げで上位モデル買わなきゃいけなくなるからお財布に優しくない。
ついに地獄が始まる(ファイアウォール/エンドポイントセキュリティ) (スコア:1)
HTTP/3が普及すると必然的にQUICが普及することになるので、何でもUDP/443に乗せて通信するという地獄のような状態が始まる。
「今までも既にTCP/443でそうだった」といえばそれまでなんだが、
QUIC使ったアプリケーションの実装面ではUDP/443上にTLSで作ったトンネルでいろんなアプリケーションプロトコルを流すものが多いので、
ファイアウォールやエンドポイントセキュリティではポート番号等である程度判別がついていたものを、
UDP/443できたデータグラムの中身をTLSオフロードした上で、完全にペイロード解析しないといけない。
という状況に陥るので、今まで以上にセキュリティに対するコストが高くなるのが問題。
会社のセキュリティ担当は今までは単純にQUIC自体を許可しない方向で動いていたと思うけど、これが徐々にできなくなる可能性を秘めているから頭抱えていると思う。
Re:ついに地獄が始まる(ファイアウォール/エンドポイントセキュリティ) (スコア:3, 興味深い)
会社のセキュリティ担当は今までは単純にQUIC自体を許可しない方向で動いていたと思うけど、これが徐々にできなくなる可能性を秘めているから頭抱えていると思う。
HTTPですら3まで上がる長年の間、会社のインターネット出入り口で検問してセキュリティを保つという方法を変えなかったのが敗因なんだと思う。どの口が知識やソフトウェアの更新が大切と言ってきたのか。
Re:ついに地獄が始まる(ファイアウォール/エンドポイントセキュリティ) (スコア:1)
エンドポイント側（端末側）で統制かける方法が今風で、
ネットワークペリメータにゲートウェイおいてHTTPSの中身見るなんて時代遅れすぎると思うけど。
Re: (スコア:0)
流行りで言うならゼロトラスト且つ多層防御なので、できるならどっちもやるのが今風よ。
Re: (スコア:0)
ゼロトラストなんて営業用語でしかなく、現実のセキュリティレベルは常にコストとのトレードオフで決まる。
Re: (スコア:0)
ゼロトラストには種類ある皆を疑い慎重に行動するものと皆を疑うがなぁなぁで済ませるものだ。
Re: (スコア:0)
そもそも通信覗いて暗号化を台無しにするなよ。
それは本当に必要なことなのか？
Re: (スコア:0)
それなら何でもかんでも一つのポートで通信するなって話でして。
たいていのネットワークで開放されているポートで通信が行われ、
ファイアーウォールのセキュリティを台無しにされたのが先。
ビジネス向けネットワークアプリケーションで簡単に導入できることを売りにしていると
謳い文句が「ファイアーウォールの設定を変更する必要はありません」だったりする。
Re: (スコア:0)
検閲なんて放棄してしまえば解決。
実際必要ないよね。
セキュリティ面で必要な対応はクライアントサイドでやればよし。
Re: (スコア:0)
ポート番号はもう今更なのでプロトコルが刷新されているのが問題でHTTP/3のオフロードやペイロード解析に対応してないソフトがちょくちょくあるので頭抱えてる
Re: (スコア:0)
今広く使われているファイアウォールとかパケットシェイパーとかの機材が TCP/80,443 は比較的優先して保護するのに、UDP は落としまくる仕様(設定)だったりする。
そのせいで、ポートが開いていても混雑時間帯だと QUIC/UDP なプロトコルだとパケットがロストしまくって、うまく通信できないとか発生してる。
安物の機器は QUIC とかそもそもプロトコル対応してないので、買い換えないとどうにもならない地獄。
Re: ついに地獄が始まる(ファイアウォール/エンドポイントセキュリティ) (スコア:0)
そろそろ日本の大企業のセキュリティ担当者は「自分が仕事してる気分になる」ために他人の仕事の邪魔した挙句にセキュリティも台無しにする愚行を改める時だ。
OSベンダはそういうバカのせいで自社製品が不安定になることを嫌って「邪魔する実装」をやらざるを得ないんだし。
Re: (スコア:0)
セキュリティが目的ならポートだけで信じちゃうのはまずいんじゃないの？
どのポートを使ってようがペイロード見なきゃ安全かなんてわからんでしょ。
Re: (スコア:0)
最近のちょっとしたよさげなファイアウォールだと、ポート番号で判別する場合はそのポート番号で動作するとアプリケーション制御で規定したプロトコルの流れに合ってなければすぐ落とせるのよ。
だからポート番号を活用することでリソース削減ができる。
それがQUICだとプロトコルの流れがTLSトンネルの中で、且つポート番号も多くのアプリケーションが443つかっているから、基本全量検査になるので負荷爆上げですな、って話。
これは「xxx over HTTPS」の流れの時から既に、443番ポートはペイロード完全監視監視対象下にしていることが多いとは思うけど、
今までポート番号を443以外を使っていたところもQUICに合流されると、負荷爆上げで上位モデル買わなきゃいけなくなるからお財布に優しくない。
Re: (スコア:0)
監視やれめればいいじゃん。
とてもお財布にも優しい。
Re: (スコア:0)
アプライアンスメーカー「商機やで！」
Re: (スコア:0)
正気か？
Re: (スコア:0)
UDP/443は許可しないつもり。そう、どう考えても隠れ蓑にされるに決まってる(偏見アリ)。
TCP/443にフォールバックされるはず。そういう実装を選ぶ。
Re: (スコア:0)
現状、UDP/443を塞ぐのが最適
将来は、これに対応したファイアウォール等が安価になると予想されるので、
そうなってから許可すればいい
Re: (スコア:0)
QUIC使ったアプリケーションの実装面ではUDP/443上にTLSで作ったトンネルでいろんなアプリケーションプロトコルを流すものが多いので、
参考までに知りたいんだけど具体的には何がある？自分はまだSMB Over QUICしか知らないので。
ほかにもHTTPに関するRFCが多数公開 (スコア:1)
ここ数日で公開されたHTTP関係のRFC。番号順ではないのは、公開順に並べたつもりだから。
（全部a hrefでリンクにしたら投稿フィルタに引っかかったので、主要なもの以外はリンクを外した。すまん）
従来のHTTP/1.1はRFC 9110～9112に更新。9110と9111はHTTP/1.1、HTTP/2、HTTP/3で共通するコア部分の仕様ということで、名称から1.1のバージョンが外れた。
HTTP/1.1がとうとうInternet Standardになったのはめでたい。
そろそろHBT`Pにするべき (スコア:0)
基本がテキストベースってのはRS232Cの時代の名残りでしょ。
基本をバイナリベースにしてhyper binary transport protocolにした方が処理を簡素化できてオーバーヘッドも大幅に減るだろうに。
Re: (スコア:0)
どうせテキスト部分なんて大した量じゃないよ。
最近じゃjsonデータで何でも送っちゃう時代だし、コンテンツ自体は昔からdeflateとかgzip圧縮が可能でしょ。
あと、hyper text ってそういう意味じゃないから…。ハイパーリンクで繋がってるテキストって意味だから…。
最後に、RS232Cの時代全然関係無いと思う。
Re: (スコア:0)
HTTP は Internet 時代もだいぶたってからできたプロトコルなので RS232C とか全く関係ないぞ。
TCP/IP は最初から8bitフルストリーム通信。もともとが HTML を通信するためのプロトコルだから HTTP って呼ばれてるだけだよ。
Re: (スコア:0)
もちょっと勉強してから出直して欲しい。
Re: (スコア:0)
何から何まで間違ってるけど、ネタじゃなさそうなのが怖い。
たぶん、自分の中の限られた知識をつぎはぎにしてなんとか自分なりにつじつまを合わせたらこうなったんだろうなぁ……。
Re: (スコア:0)
通信制御コードの開始・終端はSTX・ETXでは…？
それと、ASCIIかんけーねーし
Re: (スコア:0)
バイナリベースになると、今では覇権をとっているクソ^h^h リトルエンディアンのCPUがオーバーヘッドとバグの温床になる
歴史が繰り返されそうだけど・・・
Re: (スコア:0)
と、ビッグエンディアンなTCP/IPを使って申しております。
Re: (スコア:0)
HTTP/2 からバイナリなんですけど…
Re: (スコア:0)
龍宮城帰りなんだよ
Re: (スコア:0)
WBXML使おうよ。
Re: (スコア:0)
いい質問ですねぇ！ 実は今回掲題のRFC 9114 HTTP/3と同時に、RFC 9204: QPACK: Field Compression for HTTP/3 [rfc-editor.org]というHTTP3のフィールド圧縮を定めたRFCが標準化されています。HTTP/2でも使われていたヘッダフィールド圧縮HPACKの改良版という位置付けですね。
なるほど... (スコア:0)
Web3の時代ってのはこれのことか
よくあるかんちがい (スコア:0)
いよいよWeb3.0の時代
まぁ別にいいんだけど (スコア:0)
HTTP/2 でどれだけ実際の通信が改善されたかも不明瞭なんだけど
新しいプロトコルの導入で実施の通信で何か本当に改善されたのか。
導入推進者は統括してどうぞ。
Re: (スコア:0)
Re: (スコア:0)
「実際の通信」という日本語が難しすぎたかな?
たとえばHTTP/2はとんだ羊頭狗肉だという話があったわけだが
https://takehora.hatenadiary.jp/entry/2017/12/27/011121 [hatenadiary.jp]
Re: (スコア:0)
なら不明瞭では無いし
これからの事はわからないでしょう総括は実後にするものだし
親コメは文句言いたいだけ
Re: (スコア:0)
googleみたいに日々膨大な通信があるところにしてみればネゴシエーションを一発でできるようなるだけで経費削減になるだろ。知らんけど。
動画サイトの帯域対策は？ (スコア:0)
現状、インターネットでいちばん帯域を消費してるのは、いわゆる動画サイト、
動画サイトの帯域を節約できる規格じゃないと、帯域削減効果が少ない
たとえば、youtubeやtwitch、netflix、amazonprime、とかの実視聴状態で帯域やパケット数をどれだけ削減できるかの
シミュレーションをやって公表してほしい
Re:動画サイトの帯域対策は？ (スコア:3, 参考になる)
答え：帯域制限でドロップしたりストールして取り溢してきたフレームが拾えるようになる程度で、土管を消費する帯域そのものは減らない。
QUICによる効果に言及した論文は、フレーム落ち改善とか、”QoE品質が～”みたいなものとなっている。
https://arxiv.org/pdf/1809.10270.pdf [arxiv.org]
https://blog.apnic.net/2021/12/08/efficient-multipath-transport-with-q... [apnic.net]
そもそも、バックボーン…つまりCDNの中では既にQUIC化が進んでいて、
2017～2018年にかけてQUIC化で、GoogleのCDNのスループットが3割ほど改善している：
https://cloud.google.com/blog/products/gcp/introducing-quic-support-ht... [google.com]
自社内だからオールQUICへの切り替えが出来る訳で、大半の帯域消費は改善済みとも言える。
そうして、CDNから先のキャリアとエンドユーザー間の雑多な通信が残された訳だ。
このQUIC化によるバックボーンの改善で、末端キャリアに何がもたらされたかというと、
2017年から2018年にかけて、動画配信の帯域が大幅に拡大し、大手キャリアがNetflixと提携したりと苦労しつつ、
最終的には、以下記事にあるように常時速度制限する事態になったのだ。
https://gigazine.net/news/20190821-wireless-carrier-throttling-video-p... [gigazine.net]
＃参考までにアメリカの帯域消費状況：
https://www.businessinsider.com/which-services-use-the-most-bandwidth-2015-12 [businessinsider.com]
＃蛇足までに、ブラウザのQUICを有効にすると、Google検索結果のページ読み込み時間は8%ほど改善するとのこと。
Re: (スコア:0)
広告動画の削減なんて業界の誰もやるわけないと思う
Re: (スコア:0)
そんなことないでしょ。動画の帯域を改善できるなら、すなわちもっとたくさん広告を送り付けられるようになるということ。動機は十分あると思う。
Re: (スコア:0)
動画の帯域削減は、新しいコーデックの開発を別途やってるじゃない。
AV1使えよ。
internet2ってのがあったと思うのですが (スコア:0)
あれはなんだったんでしょうか？
Re: (スコア:0)
あれはなんだったんでしょうか？
そこはひどいインターネッツだったのでしょう
そろそろ (スコア:0)
RFC9999と10000が見えてきたな
Re: (スコア:0)
RFC10000発行すると何か障害が起きるかな？
Re: (スコア:0)
RFC 10000はぜひRFC10k問題に関するRFC(4/1発行)にしてほしい