Internet Engineering Council（IETF）の代表者は、トランスポートレベルでのデータ転送用のQUICプロトコルが大規模なテストの準備ができていると発表しました。 しかし、多くの欠点があるため、RFCとしてまだ表すことができません。 詳細は今日の資料にあります。
/ Pixabay / www_slon_pics / PDQUICが登場した理由
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 / CC2番目の欠点は、プロトコルが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の企業ブログでは、他に何を書いていますか：