/ Pixabay / www_slon_pics / PD
QUICが登場した理由
Googleは 2013年にQUICの作業を開始しました 。 ChromeおよびChromiumブラウザでテストされました。 その後、YouTubeを含む会社のサイトをサポートする技術が始まりました。 数年後、ITの巨人はプロトコルテストが成功し、IETFに提示されることを発表しました。
インターネット評議会は、2016年3月にQUICの作業を開始しました。 IETFの代表者が指摘したように、将来、QUICはTCPを置き換える必要があります。TCPは最新のネットワーク（主にモバイル）でその能力を使い果たしたためです。
TCPプロトコルでは、接続はサーバーとクライアントのIPアドレスとポートによって決定されます。 何らかの理由でこれらのパラメーターのいずれかが変更された場合、接続を再作成する必要があります。 したがって、モバイルネットワークでの通信の安定性の問題。 ユーザーは異なるセルタワー間を移動し、IPアドレスを絶えず変更します。
QUICの目標は、ワイヤレスネットワーク（Wi-Fiを含む）間の切り替えプロセスをよりスムーズにすることです。 さらに、Googleが実施したテストでは、YouTubeで動画を視聴する際の拒否回数が30％削減されています。
プロトコルの機能
QUICはUDPプロトコルに基づいており、受信者がデータを受信する準備ができているかどうかを確認せずにデータを交換できます。 「トリプルハンドシェイク」の原理を使用する TCPとは異なり、QUICハンドシェイクは、すでに使い慣れているサーバーでは1つのステップで、クライアントが以前に操作したことのないサーバーでは2つのステップで行われます。 安全な通信チャネルを開き、暗号キーを交換するには、第2段階が必要です。 その結果、QUICの接続と伝送遅延はTCPよりも低くなります。 モバイルデバイスを使用して長距離（たとえば、ある大陸から別の大陸へ）でデータを送信する場合、TLSを使用したTCPとQUICパケットとの接続を確立する速度の差は300ミリ秒に達する可能性があります。
QUICには、サーバーとクライアントのIPアドレスとポートに関連付けられた一連のパラメーターがなくなりました。 代わりに、プロトコルは接続識別子UUIDで機能します。 これにより、接続を再作成することなく、毎回Wi-Fiとモバイルネットワークを切り替えることができます（UUIDが保存されます）。 このメカニズムは、ワイヤレスネットワーク間の切り替え時にセッションを節約するMoshユーティリティに似ています。 それに関する情報は、 公式プロジェクトリポジトリで見つけることができます 。
QUICには 、データの整合性制御方法である直接エラー修正、または前方エラー修正（FEC）が追加されています。 QUICを介して送信される各パケットには、ネイバー情報があります。 したがって、パッケージが失われた場合、パッケージの内容を復元できます。
技術に対する批判
これまでのところ、この技術にはいくつかの欠点があります。 たとえば、DDoS攻撃に対する脆弱性 。 情報セキュリティの専門家によると、DDoS攻撃を組織するための一般的なキットにはUDPサポートが組み込まれているため、大きな脅威になります。 このため、QUICを実装するときは、ハンドシェイクメカニズムが正しく機能することを確認することが重要です。可能な限りハードウェアの近くで最適化して実装する必要があります。 それ以外の場合、カーネルが以前に処理できたこれらの攻撃は、サードパーティソリューション（nginxなど）によって処理される必要があります。
/ウィキメディア/ Sagor Kumar sr / CC
2番目の欠点は、プロトコルがNAT、エニーキャスト、またはECMPテクノロジーを使用するネットワークと互換性がないことです。 TCP接続で動作し、QUICトラフィックを認識および規制することはできません。 この非互換性により、使用範囲が制限されます。
さらに、QUICテストの結果は、この技術の作成者が約束したとおり、モバイルデバイスではプロトコルがうまく機能しないことを示しました。 実験によれば、ネットワーク帯域幅と転送されるデータの量が増えると、TCPとQUICのページ読み込み時間が等しくなります。 これは、QUICがカーネル空間ではなくユーザー空間で機能するためです。
QUICのもう1つの欠点は、トラブルシューティングが難しいことです。 このプロトコルは、データだけでなく、送信されるパケットのヘッダーも暗号化します。 これにより、システム管理者がネットワークパフォーマンスを評価し、問題を迅速にトラブルシューティングすることが難しくなります。
見込み
既存の脆弱性により、QUICを介して設計されたシステムを保護することは困難です。 プロトコルの欠陥をなくすために、開発者は実際の状態での作業に関するデータが必要です。 このため、IETFにはテストにIT企業が関与しています。このプロトコルはすでに大規模な組織でサポートされています。 QUICにより、 CDNサービスが機能し始めました-CloudflareおよびVerizon Digital Media Services（VDMS）。 Cloudflareでは、QUIC接続機能はベータ版です。 VDMSチームは2016年からプロトコルの実装に取り組んでおり、現在ではサービスのすべてのクライアントがQUICを使用できます。 QUICプロトコルのバージョンは、Apple、Pandora、Facebookでもテストされています。 企業の完全なリストはGitHubで入手できます 。
QUICは実験的な技術ですが、このプロトコルをサポートするサイトの数は増え続けていますが、これはW3Techs研究機関のデータによって示されています 。 IETFがQUICの最終バージョンをいつ提供するかはまだ明確ではありませんが、標準の採用によりプロトコルがより頻繁に使用されると専門家は見積もっています。
PS VAS Expertsの企業ブログでは、他に何を書いていますか：