パスワードを忘れた? アカウント作成
13768011 story
インターネット

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のサービスなどで使われている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2018年11月14日 17時08分 (#3515387)

    EdgeとIIS、.NET FrameworkのHTTP/3(HTTP-over-QUIC)とTLS1.3のサポート計画はどこかに資料がありましたでしょうか?

  • by Anonymous Coward on 2018年11月14日 18時39分 (#3515434)

    HTTP-over-QUIC(HTTP/3)って、UDPなの!??
    https://www.orangeitems.com/entry/2018/11/14/003000 [orangeitems.com]

    セッションレスのUDPだとDoSアタックが容易になるのでは、という話らしいけど。

    • by Anonymous Coward on 2018年11月14日 23時19分 (#3515565)

      今時作られてるプロトコルなので、素人考えで思いつくような弱点ぐらいは徹底的に詰められてるから大丈夫。

      TCPの性能に納得がいかないからって、必要な機能だけを残して、要らない機能を消す、ってのは出来ない。それをやるとTCPじゃなくなる。
      だから、TCPより速く通信できるアプリを作ろうとすると、UDPの上に載せることになる。
      ところが、アプリを作ってると、結局、セッション管理やら、パケットの到着確認やら再送やらの機能が必要になってアプリ内に実装していく羽目に陥る。

      その車輪を毎回再発明するのもアレなので、必要最小限だけ詰め込んだ、Reliable UDPというプロトコルが密かにあったらしいけど、
      弱点だらけでセキュリティが現代の基準で使い物にならない。その辺も踏まえて同用途のために新たにGoogleが開発したのがQUIC、
      という解説は詳解 Reliable UDP [speakerdeck.com]が参考になる。

      QUICを使ったアプリは、古の教科書に従えば、トランスポート層は信頼出来ないUDP通信に基づいて動くアプリであって、
      アプリ層で通信制御を全部やってる、という分類になる。教科書がどんどん古文書になってってるな。

      親コメント
      • by Anonymous Coward

        Keepaliveのためにパケ死しそうなプロトコルだな。

      • 高速な通信をしたければ、ブラウザは接続先ホストを記憶している必要がある。嫌味だな。

      • 今時作られてるプロトコルなので、素人考えで思いつくような弱点ぐらいは徹底的に詰められてるから大丈夫。

        QUIC自体が弱点を詰めてたとしても、当面の間「セッションレスのUDPだとDoSアタックが容易になる」ことには変わりない。

        今普及している一般的な業務用のルータ(L4まで制御)からすると、QUICなんてのはUDPで膨大なパケット垂れ流しているようにしか見えない。
        故に、QoS制御もできないし、DoSのような異常な通信と正常な通信を区別しての制御も極めて難しい。

        業務用のルータがQUICに適した制御ができるようになるなんてのは10年は先になるだろうね。

        • by Anonymous Coward on 2018年11月15日 7時40分 (#3515639)

          そもそもQUICは暗号化前提だから中身判別できない。
          そのくせ内部でアプリケーションを区別するための情報があって、
          外からは暗号化された同じ宛先アドレス、宛先ポートのパケットだけど、
          なかでは音声もその他も全部流れてるってことになる。

          QUICが流行ってしまったら、QoS自体不可能では。

          親コメント
        • by Anonymous Coward

          機器の更新でついて来れないとこは消えてくださいってことなのかな。

          別に標準化でお墨付きを与えなくても、どっかがUDP垂れ流しで自社のサービス高速化とかを勝手にやり出す可能性は常にあったわけだし。Gで始まる会社とか。

          他の大手も追随して、謎のUDPだらけになっちゃって個別に対応しないとダメになるよりは、標準化して、何に対応すれば取り合えずば大丈夫、とした方がマシ、とかかな。

        • by Anonymous Coward

          (CISCO 的な)L2 ACL は wire speed 出ること多いから、
          とりあえずそこで tcp なら established なルールで弾けていた有象無象が
          udp だと全開け素通しせざるを得ないって理解したんだけど、そういうことでいい?

    • by mofuppo (47988) on 2018年11月15日 14時41分 (#3515863)

      追記の記事で、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対策がしやすいらしいので、コンテンツ配信などのキャッシュされた大容量のデータ通信を安全に高速化できる。

      親コメント
    • by Anonymous Coward

      443/UDPだから、443/UDPをふさいでいると使えない。

    • by Anonymous Coward

      そしてUDPでセッション/コネクション風の仕組みが実装されるんですよ。
      #マジでありそうでイヤだ

      • by Anonymous Coward on 2018年11月14日 20時35分 (#3515494)

        ありそうではなくて、そうなる以外に考えられないのですが。
        なんでUDP上でやるかと言えば、既存のインターネットで新しいTCP後継プロトコルを流すにはそれ以外に上手くいきそうな方法がないってだけ。
        IPの上に直接新しいプロトコルを乗せたら対応できるネットワーク機器がほとんど無い状態からのスタートになる。

        親コメント
        • by Anonymous Coward

          ほんとそうですよね。実際、本来IP上に載るプロトコルにも関わらず、UDP上でやりとりする規定も設けられたプロトコル、いくつもあります。IPsec ESP、SCTP (RFC 6951)、DCCP (RFC 6773)、RVSP (RFC 2205 APPENDIX C.)。

        • by Anonymous Coward

          TCP/IPなんて言われているようにIPとTCP/UDPはOSI参照モデルのように綺麗に分離されているわけではないからかな。
          そんなことするなら事実上IPやめることになるんだろうね。
          でも独自ネットワーク作ろうとする国家があったりするから以外とやれないわけではないのかも。

typodupeerror

未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー

読み込み中...