QUIC协议(FastUDPInternetConnection)是一种全新升级的互联网协议，基本上是基于UDP开发设计的，用来替代TCP。甚至有人开玩笑称之为TCP/2。
QUIC协议真正的兴趣在于UDP的改进。
现在因为TCP作为传输协议的可信度，互联网都是基于TCP的。要建立TCP连接，必须进行三次握手。这意味着每个连接都会导致额外的往返(互联网数据包被来回推送)，进而增加每个连接的延迟时间。
另外，如果要通过TLS协商建立安全加密的https连接，就必须来回传输大量的互联网数据包。
一些像TCPFastOpen这样的自主创新，可以改善TCP的情况，但是并没有得到广泛的应用。
另一方面，UDP似乎是一种不管是什么协议的输出协议。如果一个消息通过UDP推送，感觉已经到了到达站。好处是在网上认证数据包总要花一点时间，但坏处是为了更好地认证数据信息的可信度，需要在UDP之上建立一些项来确定数据包的传递。
这是GoogleQUIC协议的突破。
QUIC协议可以在一个或两个库中发起一个连接，并讨论TLS(HTTPs)的所有主要参数(不管你是想连接一个新的网络服务器还是一个已经知道的服务器)。
这将在原始连接和下载开始之间产生巨大的差异。
为什么是QUIC？
QUIC协议开发设计精英团队所做的事情绝对令人难以置信。他们想把UDP协议的速度和概率与TCP协议的可信度结合起来。
维基的表达维基很好:
改进TCP协议是Google的一个长期总体目标。QUIC致力于等价于单个TCP连接，但它可以更好地减少延迟时间，此外，它可以更好地获得类似SPDY的流时分复用的应用。
如果证明QUIC的功能合理，可以转移到最新版本的TCP和TLS上。
TCP由纵横比控制。它的完成嵌入在Windows和Linux的核心，嵌入在每一个手机 *** 作系统中，基本上存在于每一个底层的机器和设备中。TCP的工作模式是困难的，因为每一台机器和设备都必须遵从TCP的完成。
但是UDP的设计方案比较简单。所以，如果你想验证Google关于TCP的一些基本理论，可以快速完成一个关于UDP的新协议。通过这种方式，一旦他们能够确认他们关于互联网延迟和流阻塞的基本理论，他们就可以开始将QUIC协议的优秀部分移植到TCP协议中。
但是TCP协议栈的改变必须从Linux和Windows内核开始，客户必须在中间升级自己的协议栈。对于协议的开发者来说，在UDP上做同样的事情更困难。但这可以让他们快速迭代更新，他们可以在很多个月内完成这个基础理论，而不是两年或几十年。
QUIC应该放在哪里？
如果看当代HTTPs连接层的构成，QUIC替代了TLS局部变量和HTTP/2的一部分。
QUIC协议完成了自己的数据加密层，所以目前的TLS1.2不能适用。
它用UDP代替了TCP，在QUIC之上是一个更小的HTTP/2API，用于与虚拟服务器通信。减少的原因是QUIC已经解决了时分复用和连接管理方法。接下来是HTTP协议的表达。
TCP行首阻塞
有了SPDY和HTTP/2，您现在可以使用一个TCP连接来连接到网络服务器，而不是为每个网页上的资源建立多个连接。
现在一切都在于这个TCP连接，缺陷是:线头阻塞。
在TCP中，数据包必须以正确的顺序到达。如果数据包丢失，必须重新发送。TCP连接必须等待TCP包之后才能再次分析其他包，因为TCP包的顺序非常重要。
在QUIC中，TCP不再用于决策。
UDP不依赖于接收数据包的顺序。尽管数据包在整个传输过程中仍有可能丢失，但它们总是会危及单个资源，而不是所有相连的块。
QUIC本质上是一种结合了SPDY和HTTP2(多路复用)的非阻塞传输协议。
为什么越来越少的数据包如此重要？
如果你足够幸运地建立了一个快速的互联网连接，你和虚拟服务器之间可能会有10-50米的延迟时间。如果延迟时间
但如果你和另一个大陆的网络服务器通信，或者按照通信运营商(3G/4g/LTE)通信，实际效果不言而喻。如果你从欧洲到达英国的网络服务器，你必须穿越北大西洋。您可能会获得超过100毫秒或更长的延迟时间。
正向修正:避免失败。
QUIC的一个非常好的功能是FEC或前向纠错。每个推送的数据分组将继续包括其他分组的足够信息，使得丢失的数据分组可以被重建而无需再次推送。
这是互联网层面的RAID5。
正因为如此，这里有一个度量:每个UDP包将包含比它所需要的更大的重力梯度，因为它包含潜在的丢失包。这种方法可以更容易地重建丢失的数据包。
关注对话&并行免费下载处理
切换到UDP的另一个令人兴奋的机会是，它不再依赖于连接的源IP。
在TCP中，需要四个主要参数来形成连接。要启动新的TCP连接，您需要源IP、源端口号、目的IP和目的端口号。
如果所有的主要参数都改变了，就需要一个新的TCP连接。
这就是为什么在移动设备上保持流畅的连接非常困难，因为你很可能会不断在WiFi和3G/LTE之间切换。
QUIC为唯一的连接完成它自己的标识符，它被称为连接UUID。从无线网络切换到LTE时，可以保持您的连接UUID，因此无需再次连接或讨论TLS。你之前的联系还是合理的。
这打开了一扇新的大门，可以应用几个来源来获取内容。如果连接的UUID可以根据WiFi和蜂窝连接共享资源，理论上它可以下载附加内容。您可以使用所有可用的套接字并行合理地处理流或下载内容。
QUIC协议已经在运行。
Chrome浏览器从2014年开始应用(测试)QUIC。如果想检测QUIC，可以在Chrome上打开协议。事实上，你只能测试Google服务的QUIC协议。
有一个方便的Chrome软件可以在你的电脑浏览器上显示HTTP/2和QUIC协议的信息作为标志:HTTP/2和SPDY索引值。
可以打开Chrome://net-internal/#QUIC，看到已经应用了QUIC。
如果你对最低的关键点感兴趣，你甚至可以看到所有的活动链接，捕捉每一个包:chrome://net-internal/#events&q=type:QUIC_SESSIONis:active。
会有人想到服务器防火墙吗？
如果你是一个站长或者软件设计师，在一开始，当我提到QUIC用UDP代替TCP的时候，你可能会有一些疑惑。
例如，当我们在网站服务器上安装服务器防火墙时，服务器防火墙标准如下所示:
注意协议一栏:TCP。
大家的服务器防火墙和其他站长的部署没什么区别。此时，网站服务器没有理由允许80/TCP或443/TCP之外的连接。
如果我们想要QUIC协议工作，我们必须允许443/UDP基础。
对于web服务器来说，这代表了443/UDP对外界的开放。对于手机客户端，这意味着允许443/UDP。
在知名企业，这很可能是个问题。因为他们的互联网一般只允许TCP端口基础，如果允许UDP基础，听起来就不正常。
虽然我认为这将是连接层面的关键问题，但谷歌进行的实验证明事实并非如此。
在服务器端运行QUIC
现在唯一能给你应用QUIC的网站服务器是Caddy，而且是从0.9版本才开始的。
手机和服务器的应用被认为是实验性的，是否运营要看自身情况。
由于没有人的手机客户端默认设置为应用QUIC，你大概还是要在自己的电脑浏览器中允许QUIC并运行。
QUIC的特点和优势
在2015年的一篇博文中，谷歌分享了QUIC执行的一些结果:
结果，在糟糕的互联网标准下，QUIC的表现优于TCP，谷歌搜索引擎网页的加载时间至少增加了1%。
这种好处在YouTube等视频直播系统中更加明显。客户报告说，使用QUIC视频观看时，他们可以减少30%的缓存文件时间。
YouTube数据信息尤其有趣。如果这个改进可行，你很快就会在类似Vimeo或者“成人流媒体服务器服务项目”的rtmp协议业务流程中看到这个应用。
总结
我发现QUIC协议非常漂亮！
我迫不及待地想看到QUIC协议在其他计算机浏览器和网络服务器中完成！
全文:https://ma.ttias.be/Googlees-quic-protocol-moving-weB-TCP-UDP/
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）