互联网工程理事会（IETF）的代表宣布，用于传输级别数据传输的QUIC协议已准备好进行大规模测试。 但是由于许多缺点，它尚不能表示为RFC。 详细信息在今天的材料中。
/ PNG / www_slon_pics / PD为什么QUIC出现
Google于2013年
开始研究QUIC。 已在Chrome和Chromium浏览器中
进行了测试 。 后来，技术
开始支持该公司
的网站，包括YouTube。 几年之后，这家IT巨头
宣布协议测试成功，并将提交给IETF。
互联网理事会于2016年3月开始研究QUIC。 正如IETF的代表所
指出的 ，由于QUICK已经耗尽了其在现代网络（主要是移动网络）中的功能，因此将来QUIC将不得不取代TCP。
在TCP协议中，连接由服务器和客户端的IP地址和端口确定。 如果由于某些原因这些参数之一发生更改，则必须重新创建连接。 因此，移动网络中通信稳定性的困难。 用户在不同的基站之间移动并不断更改IP地址。
QUIC的目标是使无线网络（包括Wi-Fi）之间的切换过程更加顺畅。 此外，由Google进行的测试表明，在YouTube上观看视频时，再缓冲次数减少了30％。
协议功能
QUIC的工作基于UDP协议，该协议允许您交换数据而无需检查收件人是否准备好接收数据。 与QUIC在TCP中
使用 “三重握手”原理的TCP不同，握手是在与已经熟悉的服务器进行一步的过程中进行的，而在与客户端以前未使用过的服务器进行的过程中进行的是两步。 第二阶段需要打开安全的通信通道并交换加密密钥。 结果，QUIC
的连接和传输
延迟比TCP低。 使用移动设备在长距离（例如，从一个大陆到另一个大陆）上传输数据时，在带TLS的TCP和QUIC数据包之间建立连接的速度差异可能达到300毫秒。
QUIC不再具有与服务器和客户端的IP地址和端口关联的一组参数。 而是，协议使用连接标识符UUID。 这样，您每次都可以在Wi-Fi和移动网络之间切换，而无需重新创建连接（保存UUID）。 该机制类似于
Mosh实用程序，该实用程序可以在无线网络之间进行切换时保存会话。 关于它的信息可以在
官方项目存储库中找到 。
QUIC还
包括一种数据完整性控制方法-直接纠错或前向纠错（FEC）。 通过QUIC发送的每个数据包都有邻居信息。 因此，如果丢失，则可以恢复软件包的内容。
对技术的批评
到目前为止，该技术具有某些缺点。 例如，
易受 DDoS攻击的
漏洞 。 据信息安全专家称，用于组织DDoS攻击的流行工具包具有内置的UDP支持，这构成了巨大的威胁。 因此，在实现QUIC时，重要的是确保握手机制正常工作-应该对其进行优化和实现，使其与硬件尽可能接近。 否则，内核之前可能会处理的那些攻击必须由第三方解决方案（例如nginx）处理。
/ Wikimedia / Sagor Kumar sr / CC第二个缺点是协议与使用NAT，Anycast或ECMP技术的网络
不兼容 。 它们使用TCP连接，将无法识别和管理QUIC通信。 这种不兼容限制了使用范围。
此外，QUIC的测试结果表明，该协议在移动设备上的效果不如技术创造者所希望的那样。 根据
实验 ，随着网络带宽的增加和数据传输量的增加，TCP和QUIC的页面加载时间趋于平稳。 这是因为QUIC在
用户空间而不是内核空间中工作。
QUIC的另一个
缺点是难以排除故障。 该协议不仅加密数据，还加密在其中传输数据包的报头。 这使系统管理员难以评估网络性能并快速排除故障。
前景展望
由于存在漏洞，保护基于QUIC设计的系统可能很困难。 为了消除该协议的缺陷，开发人员需要在实际条件下获取有关其工作的数据。 为此，IETF让IT公司参与测试。
大型组织已经支持该协议。 借助QUIC，
CDN服务开始工作-Cloudflare和Verizon数字媒体服务（VDMS）。 在Cloudflare中，QUIC连接功能处于beta中。 自2016年以来，VDMS团队一直在
致力于协议的实施，现在QUIC可以被该服务的所有客户使用。 苹果，Pandora，Facebook也对QUIC协议的版本进行了测试。 完整的公司列表可在
GitHub上
找到 。
尽管QUIC仍然是一项实验技术，但支持此协议的站点数量却在不断增长-研究机构W3Techs的
数据表明了这一点。 专家
估计 ，随着该标准的采用，该协议将得到更广泛的使用-尽管目前尚不清楚IETF何时发布QUIC的最终版本。
PS我们在VAS Experts公司博客上还写些什么：