Googleが「QUIC」で切り開くインターネットの未来

こんにちはこんばんは。はすです。まずはzennのリリースおめでとうございます🎉
これからお世話になります！というわけで初記事はQUICについて調べてみたのでそれをまとめてみようと思います。間違ってるところとかありましたらご指摘お願いいたします。

この記事でわかること

• QUICの大まかな歴史と種類
• QUICの仕組みとメリット

QUICの大まかな歴史と種類

2012　Googleが開発を開始
2015　標準化のためIETFにドラフト提出
2016　IETF、QUICワーキンググループ設置
・QUICはGoogleが開発した独自プロトコルでChromeや自社サービス提供のためのサーバに実装している
生まれた経緯として
・速度面でTCPよりもUDPのほうがいいからそっち使おう。
↓
・UDPだと信頼性の確保ができないからそういった処理を行う拡張機能的なものが必要
そこで生まれた拡張機能的存在が「QUIC」です。
詳しくはこちらを御覧ください。私よりも遥かによくまとまっています。

QUICの仕組みとメリット

QUICは、TCPの輻輳制御、ロスリカバリー、HTTP/2の機能の一部であるストリーム制御、フロー制御をUDPに対し提供します。

QUICの主なメリットは

• UDPとTLS1.3の利用でハンドシェイクの処理を可能な限り効率化できる
• コネクションID によりIPアドレスが変わっても通信が途切れない
• パケットロス発生時QUICは並行して他のパケット処理ができる

UDPとTLS1.3の利用でハンドシェイクの処理を可能な限り効率化できる

TCPではデータのやり取りを行うために「3wayハンドシェイク」というものを必要とします。
3wayハンドシェイクはTCPにおける通信の信頼性を実現するためのとても重要な機能です。
しかし、3wayハンドシェイクは通信効率を悪化させる原因になります。

なぜかというと「相手の応答が返るまで後続の機能を実行できない」事が挙げられます。

しかしUDPはこのハンドシェイクを必要とせずにデータのやり取りを開始できます。
そしてUDPのデメリットである信頼性の低さをQUICが補います。
QUICは暗号化通信を前提とするためTLSハンドシェイクが発生し、QUICはTLS1.3を使用します。TLS1.2と比較するとハンドシェイク時に発生するやりとりがTLS1.2よりも1往復少なく、ここも通信の効率化における重要な要素になります。

コネクションID によりIPアドレスが変わっても通信が途切れない

QUICではコネクションIDと呼ばれるもの導入することにより、データ通信(特にモバイルクライアントの再接続ロス)を効率化します。
例えばコネクションIDの利用により、モバイル端末上でダウロード進行中、モバイル回線→WiFiに切り替えてもセッション維持をしつつWiFiに切り替えることが可能になります。

パケットロス発生時QUICは並行して他のパケット処理ができる

まず、大まかにTCPとUDPのパケット通信での違いをまとめてみようと思います。

TCP	UDP
パケットが処理される順序が重要	パケットの受信順序に左右されない
TCPはパケットロスが起こると自動的に再送が始まります。そして再送が行われている間、後続のパケットを送信することはできません。
それに比べQUICを使うと、再送中でも並行して他のパケットの処理が可能になります。

感想

QUICについて調べるためにTCPとUDPも学びましたが小さな頃から使ってきていたインターネットがこんなにも面白い技術で成り立っていることがわかってとてもおもしろかったです。時代に合わせて素早い進化を遂げていることがインターネットの普及の大きな理由だと言うことを改めて実感できました。ではまた！