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

Googleが提唱するHTTPSを置き換える「QUICプロトコル」とは 40

ストーリー by hylom
まだまだ普及の道は見えず 部門より

Googleが「QUIC(Quick UDP Internet Connections)」と呼ばれるUDPベースの新たなインターネットプロトコルを開発しているそうだ(POSTD)。

QUICはHTTPSを置き換えるものとして開発されており、UDPベースで暗号化された通信を行うという。TCPでは接続を確立するまでの処理のオーバーヘッドがあることが知られているが、UDPはそれがないためにより高速に利用でき、レイテンシを削減できるのが特徴。また、UDPではパケットロスに対処するための機構はないが、QUICでは独自のエラー訂正機能を備えており、欠落したパケットの内容をほかのパケットから復元できる仕組みを備えている。さらに、接続を独自の「Connection UUID」という識別子で管理することで、通信中にクライアントのIPアドレスが変わるようなケースでも再接続を行わずに通信を継続できるという。

POSTDの記事ではQUICを利用するためのクライアント/サーバーについてやファイアウォール設定についても紹介されている。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by Anonymous Coward on 2016年08月31日 6時52分 (#3072798)
    QUIC使って通信する機器も出てるよね?
    Wiresharkなんかでも対応してたと思うが。
    • by Anonymous Coward on 2016年08月31日 6時55分 (#3072799)

      Chromeとgoogle.comはすでに実際にQUICで通信している。

      親コメント
      • POSTDには、

        Chromeブラウザは、2014年からQUICを(試験的に)サポートしています。QUICを試してみたい方は、Chromeでこのプロトコルを有効にすることができます。

        と書いてあるけど、実際に調べてみたところ、特に何もしなくてもQUICを使っていた。
        うへえ。

        親コメント
        • by Anonymous Coward

          Google の怖いところは、あんだけの通信ボリュームを扱っているのにホイホイと使うプロトコルとかを変えてしまうところ。

          昔も tcp:80 → tcp:443 に突然変えたりしてきたけど、QUIC もすでに突然バグあったとか言い出してプロトコルを止めたことがある。
          https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/wc9PtfSQDDk [google.com]

          普及したころに QUIC(udp) → HTTPs/SPDY(tcp) に突然切り戻されたりしたら ISP はかなわんわな。

          • by Anonymous Coward

            なぜ「切り戻ししたらISPはかなわん」と判断したのかそのロジックを詳しく

  • by Anonymous Coward on 2016年08月31日 6時09分 (#3072795)

    今さら新たに取り上げる理由がなんかあるの? GoogleがTLS 1.3あきらめたとか?

    • by Anonymous Coward

      たぶん、IPv6の普及に目途が付いたから次はこれ、っていうことじゃないか(大嘘)

      この手のものはコスト負担どうするのか考えなければいつまで経っても普及しないのはもう実証済。

  • by Anonymous Coward on 2016年08月31日 7時10分 (#3072805)

    UDPなんて家庭用の簡易ルータでもデフォルトでリジェクトじゃない?

    • by Anonymous Coward on 2016年08月31日 8時51分 (#3072839)

      full cone natでも自分がパケット投げた先からそのまままっすぐパケット帰ってくる分には通りますよ
      UDPというもの全般をデフォルトで落としてる家庭用ルーターってのはむしろ聞かない

      親コメント
      • by Anonymous Coward

        full coneじゃねえや逆だ逆。symmetric natだ

      • by Anonymous Coward

        RTXシリーズのコンフィグが頭にある関係で、UDPは通す設定をしないと通らない物だと思ってたけど、家庭用ルーターだとその辺ザルなのか。(例えば、NTPで通信しようと思うとfilterにNTPを通す設定をしておかないと通信できないよね)

        • by Anonymous Coward

          RTXシリーズもYAMAHAの公式サイトのサンプルのせいで
          送信側については下記の行が付いていること多いですけどね。

          ip filter XXX pass * *
          ip filter dynamic YYY * * udp

          http://jp.yamaha.com/products/network/solution/internet/opticalfiber_c... [yamaha.com]

          まぁ、デフォルトにしておいてくれればいいのに、
          考えなしにこんなルール追加されていると、ちょっと気持ち悪いですよね。

    • 開けるのがデフォルトになるのを待つぐらい、じっくり腰据えて普及させていくつもりなんでは。
      今のうちからQUIC使いたい人は設定変えて開けるでしょうし。

    • by Anonymous Coward

      ルーターのリゾルバを使わないDNSクエリを通さない家庭用ルーターって具体的にどこのメーカー?

    • by Anonymous Coward

      デフォルトリジェクトなら、Google DNS(8.8.8.8)に切り替えた人は続々通信不可能になって
      大問題なはずだけど、そんな話は聞かないけどねぇ

      • by nim (10479) on 2016年08月31日 8時30分 (#3072832)

        普通のDNSって、TCP53でも応答する気がするんだけど、Google DNS は違うの?

        親コメント
        • by Anonymous Coward on 2016年08月31日 10時00分 (#3072877)

          googleの挙動以前の問題として、家庭用ルータのDNS forwarderはTCP非対応の製品が多いんだよね。

          親コメント
        • by Anonymous Coward

          TCP53ってDNSサーバー同士でゾーン転送する場合でなくて?
          最近は一般のクライアントからの名前解決の問い合わせもUDPが使えない場合はTCPで送り直すとか発展してるのかしら?

          • by nim (10479) on 2016年08月31日 9時07分 (#3072850)

            UDPにTCPで返事するってのはわからないけど、最初からTCPで問い合わせることはできる(rudeな振る舞いかもしれないが)と思うんだ。

            親コメント
            • by Anonymous Coward on 2016年08月31日 9時25分 (#3072856)

              UDPだと512オクテットまでしか送れない決まりなので、それ以上になることが最初から想定されるなら別にTCPでリクエストしてもいいのよ?

              #DNSSECっていまだに普及してないんだなと感じるひととき

              親コメント
              • by Anonymous Coward on 2016年08月31日 10時23分 (#3072893)

                最初は常にUDPで問い合わせる必要がある(RFC1123)。応答が一定のサイズを超えると
                TCPにフォールバックされる仕様。一定のサイズはRFCの発行時期によって512~4096 Byte。
                最初からTCPで問い合わせていいわけじゃない。
                DNSSECも一緒

                ところで、UDPの戻りのパケットもACL書かないと動かない機械なんて
                今日日聞かないですよね

                親コメント
              • by Anonymous Coward

                qmailでの不具合を思い出したわ…

              • by Anonymous Coward on 2016年08月31日 22時24分 (#3073372)

                > 最初は常にUDPで問い合わせる必要がある(RFC1123)。

                RFC7766で、最初からTCPで問い合わせても桶になりました
                https://tools.ietf.org/html/rfc7766 [ietf.org]

                親コメント
              • by Anonymous Coward

                えー初耳と思ったら、RFC7766って今年の3月か・・・
                いや、正直まだ見てなかったです。

                ちなみに該当の項目ってどこらへんでしょうかね
                下記の部分で良い?

                https://tools.ietf.org/html/rfc7766#section-6.1.1 [ietf.org]
                5. Transport Protocol Selection

                a DNS resolver or server that is sending a non-zone-transfer query MUST send a UDP query first.

                This requirement is hereby relaxed. Stub resolvers and recursive resolvers MAY elect to send either TCP or UDP queries depending on local operational reasons. TCP MAY be used before sending an

      • by Anonymous Coward on 2016年08月31日 8時45分 (#3072834)

        さすがにUDP53は通すでしょ
        その他不特定多数のポートは弾かれちゃうんじゃないかって疑問なんじゃないの?

        セッション(?)IDみたいなのを見てサーバーからの応答パケットも通せるようになるとは思うけど

        親コメント
    • by Anonymous Coward

      たとえばでいいから、メーカー名と機種名を挙げてみてくれないか
      個人的にはそんなのお目にかかったことない

    • by Anonymous Coward

      iptablesですら、UDPをステートフルとして扱っているのに
      今更UDPの戻りパケットを意識しなきゃいけないのって・・・
      製品としてありますか?

      例えばCentOS6のiptablesにデフォルトで記載されている
      下記の行はUDPに対しても有効

      -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

      これをTCPだけに変更したらNTPやDNSの戻りを書かなければならなくなるため
      大変面倒なことになる。

      -A INPUT -m state --state ESTABLISHED,RELATED -m tcp -p tcp -j ACCEPT

      # やって挙動がおかしくなっても責任は持ちませんのであしからず

  • by Anonymous Coward on 2016年08月31日 10時58分 (#3072915)

    利点ばかり述べてるけど、輻輳制御のような安全さへの配慮とかはないの?
    それとも Google 利用者が多い先進国のネットならそんな心配しなくていいくらいに回線品質が高くなってるってことか?

  • by Anonymous Coward on 2016年08月31日 12時01分 (#3072939)

    最終的にTCPの殆どの欠点を補ったプロトコルがUDPベースで実現されそうな感じだけど、そこまで行くならUDPベースにしなくてもIPの上にイチから構築した方が良くない?
    で、そっちの新プロトコルを見据えてた上で、ルータ等が対応するまでの間暫定的にUDP上で実現って方が筋は良さそう。

    • by Anonymous Coward

      UDPってIPにポート番号ついたぐらいだと思うんだけど、
      IP上に新プロトコルをつくることが、UDP上より良いと思われる点ってなに?

      • by Anonymous Coward

        そのポート番号とかチェックサムとかが無駄というか別レイヤでやるべきと考えている人はいる。

        • by Anonymous Coward

          話はやや脱線気味ですが、チェックサムが要らないという利用者向けに、UDP-Lite (RFC 3828 [ietf.org])がありますね。さすがにポートはTCP/UDP同様に存在しますが。

      • by Anonymous Coward

        アプリケーション毎に個別に実装する必要がなく、対応アプリケーションが普及する。
        逆にそうでなければ、いつまでもアプリケーション固有の実装に留まって、いつまでも普及しない。

    • by Anonymous Coward

      つ SCTP
      パケットベースで順序維持、マルチストリームマルチホーム対応
      でも暗号化は入ってないんだなぁ

      • by Anonymous Coward

        そこでWebRTCを見習いましょう。WebRTCでは、暗号化にDTLSを使い、その上でSCTPをやり取りするようになっています。DTLSパケットは当然UDPに載せて運ぶので、SCTP over DTLS over UDP [google.co.jp]というわけです。

    • by Anonymous Coward

      で、その「IPの上にイチから構築した」新しいプロトコルとやらは
      既存のクライアントネットワークサイドのNATやファイアウォールを簡単に超えられるのかね?

      • ほんとにこれ。

        IPv4 のアドレス枯渇は、新しいプロトコルの芽を摘んでると言えなくもないのかな。

        --
        # mishimaは本田透先生を熱烈に応援しています
        親コメント
        • by Anonymous Coward

          まぁNATに限らず、超高速スイッチとかハードでUDPまで見てますからね。。。

          ロストテクノロジな未来、IPv4+HTTP(S)が「なぜかわからんがおまじない的につけとくヘッダ」
          扱いになるかも(嘘

      • by Anonymous Coward

        NAT越えはIPv4のアドレス不足のせいだから「IP上のプロトコル」で解決するのは無理だし、
        ファイアウォールを簡単に越えられてしまってはまずかろう。

typodupeerror

※ただしPHPを除く -- あるAdmin

読み込み中...