QUICについて調べた

Transcript

1. QUIC A UDP-Based Multiplexed and Secure Transport protocol
2. QUIC is 何？ • トランスポート層の通信プロトコル • Googleが開発 • TCPの「トリップタイム」問題を解決したもの • UDP上に位置し、TLS1.3を内蔵
3. QUICが使用される通信 • HTTP/3 ◦ HTTP/2の次 ◦ Googleの通信ではよく使われている ◦ Apacheはまだ非対応。Nginxは2020年10月にプレスリリースが出ている
4. QUIC HTTP/3になるとなにがいいのか • HTTP/2に比べて通信が速くなる（理論上） ◦ UDP上に位置するため3wayハンドシェイク（SYNやACKの通信のやつ）が無い ◦ ヘッドオブラインブロッキングが解決されている ▪ TCPの通信では鎖のようになっていいて、 1つのつなぎ目が欠落（パケットロス）するとそれ以 降のすべての繋がりが待つ必要 ▪ 実際、パケットロスがある環境では HTTP/1のほうがパフォーマンスがいいらしい • WebTransport APIが使える ◦ WebsocketとWebRTCを合わせてQUICプロトコルを使用した API ◦ 高速 ◦ 最近Chrome(97)に追加された
5. QUICの通信をみる • Wiresharkで確認したい • QUICはTLSが含まれているため通信データの内容は見れなさそう • とりあえずダメ元で試してみる
6. QUICの通信をみる • サーバをGoで書く ◦ https://github.com/lucas-clemente/quic-go を使用する • ありがたいことにexampleがあったので使わせてもらう ◦ https://github.com/lucas-clemente/quic-go/tree/master/example/echo • Client-Serverごとにファイルを分け、それぞれMacOS、Ubuntuで通信を行う ◦ MacOS: Monterey ▪ 192.168.3.7 ◦ Ubuntu: 20.04 ▪ 192.168.3.253
7. QUICの通信をみる • PC間で通信できるようにアドレスを書き換える ◦ （clientのIPアドレスは192.168.3.253にする） サーバのIPアドレス
8. QUICの通信をみる • server側のキャプチャ
9. QUICの通信をみる • client側のキャプチャ
10. QUICの通信をみる client server Initial • QUICのハンドシェイクはTLS1.3のハンドシェイクの流れと一緒 ◦ （ただしUDPを使う） • Initialパケット ◦ ClientHelloが入ったCRYPTOフレームをInitialパケットに格納し てサーバに送る ◦ TCPのSYNのイメージ
11. QUICの通信をみる client server Initial Initailパケットのペイロードは、 イニシャル用の鍵で暗号化 されます。イニ シャル用の鍵は、サーバのコネクション IDから生成します。この最初の サーバのコネクション IDは、クライアントが乱数的に生成します。 中継装置から見ると、サーバのコネクション IDがInitialヘッダ中にあるの で、そこからイニシャル用の鍵を生成でき、さらにペイロードを復号できま す。このため、Initialパケットには「一手間かけないと覗けない」程度の安 全性しかありません 。 引用元: https://eng-blog.iij.ad.jp/archives/10582
12. QUICの通信をみる client server Initial Retry 一番最初のハンドシェイクなので クライアントが生成した接続先コネ クションIDを使いたくないときや、通信元アドレスが本物かどうかを 確認したいときは、サーバは Retry Packet をクライアントに送り返 します。 引用元: https://tex2e.github.io/blog/protocol/quic-retry-packet
13. QUICの通信をみる client server Initial Retry Initial Protected Payload • Initialを送ってprotected payloadが返る • protected payloadはserver hello
14. QUICの通信をみる client server Initial Retry Initial Protected Payload Initailパケットを受け取ったサーバは、ヘッダ中のコネクション IDからイニ シャル用の鍵を生成し、ペイロードを復号します。 ClientHelloが取り出せ るので、ServerHelloを作成し、イニシャル用の鍵で暗号化して、 Initialパ ケットを送り返します 。ややこしいのですが、このとき必要であれば、サー バは自分自身のコネクション IDを作り直します。 引用元: https://eng-blog.iij.ad.jp/archives/10582
15. QUICの通信をみる client server Initial Retry Initial Protected Payload Handshake またサーバは、ClientHelloの中にあるクライアントの DH公開鍵と、生成し たサーバのDH秘密鍵からハンドシェイク鍵を生成します。そして、 EncryptedExtensionsなどをハンドシェイク鍵で暗号化し、 Handshake パケットのペイロードに格納して送信 します。 引用元: https://eng-blog.iij.ad.jp/archives/10582
16. QUICの通信をみる client server Initial Retry Initial Protected Payload Handshake Protected
17. QUICの通信をみる client server Handshake Protected Payload Protected Payload Protected Payload • あとは多分データ送信 • TLS暗号化されているので生データは見れなかった
18. QUICまとめ • TCPよりハンドシェイクは少なかった • デフォルトでTLS暗号化されているのは安心できそう • もっと詳しく知りたい人向け ◦ IIJ Engineers Blog ▪ https://eng-blog.iij.ad.jp/archives/author/kazu/page/2 ◦ QUIC: A UDP-Based Multiplexed and Secure Transport (RFC9000) ▪ https://datatracker.ietf.org/doc/rfc9000/ ◦ Chrome への HTTP/3 と IETF QUIC の導入について ▪ https://developers-jp.googleblog.com/2020/10/chrome-http3-ietf-quic.html
19. 使ったソースコード cateiru/quic-example https://github.com/cateiru/quic-example
20. 参考文献 • https://www.nginx.co.jp/blog/introducing-technology-preview-nginx-support-for -quic-http-3/ • https://xtech.nikkei.com/atcl/learning/lecture/19/00038/00004/ • https://http3-explained.haxx.se/ja/proc/proc-status • https://directcloud.jp/contents/webhttp-3quic/ • https://wa3.i-3-i.info/word15428.html • https://http3-explained.haxx.se/ja/why-quic/why-tcphol • https://eng-blog.iij.ad.jp/archives/10582 • https://tex2e.github.io/blog/protocol/quic-retry-packet