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を利用するためのクライアント/サーバーについてやファイアウォール設定についても紹介されている。
もう実用されてるよね？ (スコア:1)
Wiresharkなんかでも対応してたと思うが。
Re:もう実用されてるよね？ (スコア:5, 参考になる)
Chromeとgoogle.comはすでに実際にQUICで通信している。
Re:もう実用されてるよね？ (スコア:3)
POSTDには、
と書いてあるけど、実際に調べてみたところ、特に何もしなくてもQUICを使っていた。
うへえ。
Re: (スコア:0)
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 はかなわんわな。
Re: (スコア:0)
なぜ「切り戻ししたらISPはかなわん」と判断したのかそのロジックを詳しく
開発自体は3年以上前からやってるだろ (スコア:0)
今さら新たに取り上げる理由がなんかあるの? GoogleがTLS 1.3あきらめたとか?
Re: (スコア:0)
たぶん、IPv6の普及に目途が付いたから次はこれ、っていうことじゃないか（大嘘）
この手のものはコスト負担どうするのか考えなければいつまで経っても普及しないのはもう実証済。
FWどーすんの? (スコア:0)
UDPなんて家庭用の簡易ルータでもデフォルトでリジェクトじゃない?
Re:FWどーすんの? (スコア:1)
full cone natでも自分がパケット投げた先からそのまままっすぐパケット帰ってくる分には通りますよ
UDPというもの全般をデフォルトで落としてる家庭用ルーターってのはむしろ聞かない
Re: (スコア:0)
full coneじゃねえや逆だ逆。symmetric natだ
Re: (スコア:0)
RTXシリーズのコンフィグが頭にある関係で、UDPは通す設定をしないと通らない物だと思ってたけど、家庭用ルーターだとその辺ザルなのか。（例えば、NTPで通信しようと思うとfilterにNTPを通す設定をしておかないと通信できないよね）
Re: (スコア:0)
RTXシリーズもYAMAHAの公式サイトのサンプルのせいで
送信側については下記の行が付いていること多いですけどね。
ip filter XXX pass * *
ip filter dynamic YYY * * udp
http://jp.yamaha.com/products/network/solution/internet/opticalfiber_c... [yamaha.com]
まぁ、デフォルトにしておいてくれればいいのに、
考えなしにこんなルール追加されていると、ちょっと気持ち悪いですよね。
Re: (スコア:0)
開けるのがデフォルトになるのを待つぐらい、じっくり腰据えて普及させていくつもりなんでは。
今のうちからQUIC使いたい人は設定変えて開けるでしょうし。
Re: (スコア:0)
ルーターのリゾルバを使わないDNSクエリを通さない家庭用ルーターって具体的にどこのメーカー？
Re: (スコア:0)
デフォルトリジェクトなら、Google DNS(8.8.8.8)に切り替えた人は続々通信不可能になって
大問題なはずだけど、そんな話は聞かないけどねぇ
Re:FWどーすんの? (スコア:1)
普通のDNSって、TCP53でも応答する気がするんだけど、Google DNS は違うの？
Re:FWどーすんの? (スコア:1)
googleの挙動以前の問題として、家庭用ルータのDNS forwarderはTCP非対応の製品が多いんだよね。
Re: (スコア:0)
TCP53ってDNSサーバー同士でゾーン転送する場合でなくて？
最近は一般のクライアントからの名前解決の問い合わせもUDPが使えない場合はTCPで送り直すとか発展してるのかしら？
Re:FWどーすんの? (スコア:1)
UDPにTCPで返事するってのはわからないけど、最初からTCPで問い合わせることはできる（rudeな振る舞いかもしれないが）と思うんだ。
Re:FWどーすんの? (スコア:1)
UDPだと512オクテットまでしか送れない決まりなので、それ以上になることが最初から想定されるなら別にTCPでリクエストしてもいいのよ？
＃DNSSECっていまだに普及してないんだなと感じるひととき
Re:FWどーすんの? (スコア:1)
最初は常にUDPで問い合わせる必要がある(RFC1123)。応答が一定のサイズを超えると
TCPにフォールバックされる仕様。一定のサイズはRFCの発行時期によって512～4096 Byte。
最初からTCPで問い合わせていいわけじゃない。
DNSSECも一緒
ところで、UDPの戻りのパケットもACL書かないと動かない機械なんて
今日日聞かないですよね
Re: (スコア:0)
qmailでの不具合を思い出したわ…
Re:FWどーすんの? (スコア:1)
> 最初は常にUDPで問い合わせる必要がある(RFC1123)。
RFC7766で、最初からTCPで問い合わせても桶になりました
https://tools.ietf.org/html/rfc7766 [ietf.org]
Re: (スコア:0)
えー初耳と思ったら、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
Re:FWどーすんの? (スコア:1)
さすがにUDP53は通すでしょ
その他不特定多数のポートは弾かれちゃうんじゃないかって疑問なんじゃないの？
セッション(?)IDみたいなのを見てサーバーからの応答パケットも通せるようになるとは思うけど
Re: (スコア:0)
たとえばでいいから、メーカー名と機種名を挙げてみてくれないか
個人的にはそんなのお目にかかったことない
Re: (スコア:0)
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
# やって挙動がおかしくなっても責任は持ちませんのであしからず
輻輳制御は？ (スコア:0)
利点ばかり述べてるけど、輻輳制御のような安全さへの配慮とかはないの？
それとも Google 利用者が多い先進国のネットならそんな心配しなくていいくらいに回線品質が高くなってるってことか？
Re: (スコア:0)
考えているみたいですよ
タレコミリンク先からリンクされている下記ページの
https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2... [google.com]
CONGESTION AVOIDANCEの部分
もっと先がありそう。 (スコア:0)
最終的にTCPの殆どの欠点を補ったプロトコルがUDPベースで実現されそうな感じだけど、そこまで行くならUDPベースにしなくてもIPの上にイチから構築した方が良くない？
で、そっちの新プロトコルを見据えてた上で、ルータ等が対応するまでの間暫定的にUDP上で実現って方が筋は良さそう。
Re: (スコア:0)
UDPってIPにポート番号ついたぐらいだと思うんだけど、
IP上に新プロトコルをつくることが、UDP上より良いと思われる点ってなに？
Re: (スコア:0)
そのポート番号とかチェックサムとかが無駄というか別レイヤでやるべきと考えている人はいる。
Re: (スコア:0)
話はやや脱線気味ですが、チェックサムが要らないという利用者向けに、UDP-Lite (RFC 3828 [ietf.org])がありますね。さすがにポートはTCP/UDP同様に存在しますが。
Re: (スコア:0)
アプリケーション毎に個別に実装する必要がなく、対応アプリケーションが普及する。
逆にそうでなければ、いつまでもアプリケーション固有の実装に留まって、いつまでも普及しない。
Re: (スコア:0)
つ SCTP
パケットベースで順序維持、マルチストリームマルチホーム対応
でも暗号化は入ってないんだなぁ
Re: (スコア:0)
そこでWebRTCを見習いましょう。WebRTCでは、暗号化にDTLSを使い、その上でSCTPをやり取りするようになっています。DTLSパケットは当然UDPに載せて運ぶので、SCTP over DTLS over UDP [google.co.jp]というわけです。
Re: (スコア:0)
で、その「IPの上にイチから構築した」新しいプロトコルとやらは
既存のクライアントネットワークサイドのNATやファイアウォールを簡単に超えられるのかね？
Re:もっと先がありそう。 (スコア:1)
ほんとにこれ。
IPv4 のアドレス枯渇は、新しいプロトコルの芽を摘んでると言えなくもないのかな。
# mishimaは本田透先生を熱烈に応援しています
Re: (スコア:0)
まぁNATに限らず、超高速スイッチとかハードでUDPまで見てますからね。。。
ロストテクノロジな未来、IPv4+HTTP(S)が「なぜかわからんがおまじない的につけとくヘッダ」
扱いになるかも(嘘
Re: (スコア:0)
NAT越えはIPv4のアドレス不足のせいだから「IP上のプロトコル」で解決するのは無理だし、
ファイアウォールを簡単に越えられてしまってはまずかろう。