QUICとは
- QUICとは、Googleが高速化を目指し、UDPソケット上に用意したプロトコルです。
- なぜ、Googleはこのquicを作り出したのかというと、それは多分HTTP/2がTCPソケットの上に実装されたものであるからだと考えられます。
- どうしても、TCPは接続初期に何度か往復した通信をする必要があり、エラーや順序の整列をきちんとするために受信通知を返す必要があります。つまり高機能ではあるが、パフォーマンスへの影響が少なからず起こるということです。
では、UDPはどうか?
UDPは、TCPで行われている再送処理や輻輳制御などを取り払い通信回数を減らすことでパフォーマンスへの影響を減らしたプロトコルです。
では、QUICはどうなのか？
QUICでは、TCPが行っているようなパケットロス時の再送処理や、輻輳時の制御などを自前で実装しています。
また、TLSの機能を保持しており、シーケンス番号などのデータも隠蔽しています。
じゃあ、HTTPSでのTCPと変わらないのでは？
HTTPSでは、TCPのハンドシェイク後にTLSのハンドシェイクを行う必要があり、何度も通信を往復しパケットを送信する必要がありました。
しかし、QUICでは、この2つの確認を融合しておりより少ない通信、(初回で1往復でネゴシエーション)できます。
引用: https://datatracker.ietf.org/meeting/98/materials/slides-98-edu-sessf-quic-tutorial/
実はこの、QUICのIETF版として議論されているHTTP over QUICをHTTP/3という名前にすることが決定されています。
QUICトランスポートプロトコル
QUICトランスポートプロトコルは、QUICのIETF版として定義されたもので、TCPとTLSレイヤが置き換わるようなもので、
UDPを基にして再送処理、輻輳制御, 暗号化などを実装したものです。
引用: https://blog.honai.me/post/how-http-works-5-quic-http3
つまり、どう違うの？
- TCPでは、1つのコネクション内のパケットが全て整列されて転送されることを保証する。
- QUICでは、セッションは張るがその中に複数の通信のストリームを張り、ストリームの内部では順序を保証するものの、ストリーム間での保証はしない。
quic-go
goでquicを試してみたい場合は、quic-goがおすすめです。
僕も試してみようと思ったのですが、体力が尽きたので、実際に試されている面白記事を載せて終わらせたいと思います。
参考: https://tech.aptpod.co.jp/entry/2021/01/28/100000