QUIC协议(快速UDP网络连接)是一种全新的网络协议，该协议是在UDP的基础上开发的，用于替代TCP。有些人甚至开玩笑地称其为TCP/2。

QUIC协议真正有趣的地方是对UDP的改进。

现在，由于TCP作为传输协议的可靠性，所以网络都是建立在TCP之上的。想要建立一个TCP连接需要进行三次握手。这意味着每次连接都会产生额外的往返(网络数据包在来回发送)，从而给每个连接增加了显著的延迟。

除此之外，如果你还需要TLS协商来创建一个安全、加密的https连接，那么就需要来回传送更多的网络数据包。

一些像TCP Fast Open的创新可以改善TCP的这种情况，但这并没有得到广泛采用。

UDP另一方面更多的像是一种发出即不管的协议。一个消息如果经由UDP发送，则认为已经到达了目的地。好处是只会在网络上花费很少的时间来验证数据包,缺点是为了验证数据的可靠性,必须在UDP之上建立一些东西来确认数据包的交付。

这就是谷歌QUIC协议的切入点。

QUIC协议可以在1个或2个包中启动一个连接并且商谈所有的TLS(HTTPs)参数 (取决于你想要连接的是一个新的服务器还是一个已知主机)。

这对于初始连接和开始下载来说会产生一个巨大的差异。

为什么需要QUIC ？

QUIC协议开发团队所做的事情是绝对不可思议的。他们想把UDP协议的速度、可能性与TCP协议的可靠性综合起来。

维基百科的解释相当好：

改善TCP协议是谷歌的一个长期目标,QUIC旨在等效于一个独立的TCP连接,但能更好地减少延迟，同时更好地得到像SPDY一样的流多路复用的支持。

如果QUIC的功能证明是有效的,那么这些功能就可以迁移到最新版本的TCP和TLS中。

TCP协议是高度管制的。它的实现嵌入在Windows和Linux的内核中,在每一个手机操作系统之中,几乎存在于每一个低级设备中。提高TCP的工作方式是困难的,因为每个设备都需要遵循TCP的实现。

而UDP的设计却是相对简单的。所以如果想要验证谷歌关于TCP的一些理论，在UDP上能够更快地实现一个新的协议。这样,一旦他们可以证实他们关于网络拥塞,流阻塞的理论,他们就可以开始把QUIC协议中好的部分移植到 TCP协议中。

但修改TCP协议栈需要从Linux和Windows内核开始,中间还需要用户更新他们的协议栈。对于协议的开发人员来说，在UDP上做同样的事情是更加困难的。不过这可以允许他们更快地迭代，并且可以在几个月内实现这些理论，而不是几年或几十年。

QUIC应该放在哪里？

如果你看看现代HTTPs连接层的组成,QUIC取代了TLS堆栈和HTTP/2的一部分。

QUIC协议实现了自己的加密层，所以不能使用现有的TLS 1.2。

它用UDP取代了TCP，QUIC上面是一个较小的HTTP / 2 API，用来与远程服务器通信。变小的原因是QUIC已经处理了多路复用和连接管理。接下来是HTTP协议的解释。

TCP head-of-line阻塞

有了SPDY和HTTP/2，我们现在可以用一个TCP连接来连接到服务器,而不是为每个页面上的资源建立多个连接。

现在一切都取决于这一个TCP连接,缺点是:head-of-line阻塞。

在TCP中，数据包需要以正确的顺序到达。如果一个数据包丢失,它需要被重新传输。TCP连接需要等待TCP包才能继续解析其他包,因为处理TCP数据包的顺序很重要。

在QUIC中,决定不再使用TCP。

UDP不依赖于收到数据包的顺序。虽然在传输过程中数据包仍然可能丢失,但它们只会影响单个资源,而不是整个连接块。

QUIC本质上是一个结合了SPDY和HTTP2(复用)的非阻塞传输协议。

为什么更少的数据包那么重要

如果你足够幸运建立了快速网络连接,你和远程服务器之间可能会有10-50ms的延迟。如果延迟< 50 ms,好处可能并不明显。

但当你跟在另一个大陆的一个服务器或通过移动运营商（使用3G/4G/LTE）进行通讯的时候，这个效果就显而易见了。如果从欧洲到达位于美国的一个服务器,你必须横渡大西洋。你将会得到一个超过100ms或更高的延迟。

前向纠错:防止失败

QUIC中一个很棒的功能是FEC或前向纠错。每一个发送的数据包还会包含其它包的足够信息，这样丢失的数据包可以重建，而不必重新发送它。

这就是网络水平上的RAID 5。

正因为如此,这里有一种权衡:每个UDP数据包会包含比实际需要更多的有效载荷,因为它包含了潜在的丢失数据包,这种方式可以更容易地重塑丢失数据包。

会话重用&并行下载

切换到UDP的另一个激动人心的机会是不再依赖于连接的源IP。

在TCP,你需要4个参数组成一个连接。开始一个新的TCP连接,你需要源IP、源端口、目的IP和目的端口。

如果有任何参数发生了变化,就会需要一个新的TCP连接。

这就是为什么在移动设备上保持一个稳定的连接非常困难,因为你可能会不断切换WiFi和3 G/LTE。

而QUIC为唯一的连接实现了自己的标识符，称为连接UUID。有可能从无线切换到LTE时仍然保持你的连接UUID,所以不需要重新连接或商谈TLS。你以前的连接仍然是有效的。 

这打开了一扇新大门,可以使用多个源来获取内容。如果连接UUID可以通过WiFi和蜂窝连接共享,理论上可以同时下载内容。你可以使用所有可用的接口来有效地并行流传输或下载内容。

QUIC协议已经在运转

Chrome浏览器自2014年以来已经支持(实验)QUIC。如果你想测试QUIC,您可以启用Chrome上的协议。实际上,你只能针对谷歌服务来测试QUIC协议。

有一个方便的Chrome插件可以在您的浏览器上将HTTP/2和QUIC协议显示为一个图标:HTTP/2和SPDY指标。

你可以打开chrome:/ / net-internals / #quic看到QUIC已经使用了。

如果你对底层细节感兴趣,你甚至可以看到所有的活跃连接，并且可以捕获每个包: chrome://net-internals/#events&q=type:QUIC_SESSION%20is:active.

 会有人想到防火墙吗？

如果你是一个系统管理员或网络工程师,在一开始我提到QUIC用UDP代替TCP时，你可能会有点疑惑。

例如,当我们在网络服务器的主机上配置防火墙时,防火墙规则看起来像这些：

要特别注意协议列:TCP。

我们的防火墙与其他系统管理员的部署并没有什么不同。在这个时候,对一个网络服务器来说，没有任何理由允许除了80 / TCP或443 / TCP之外的连接。

而如果我们想让QUIC协议生效,我们就需要允许443 / UDP通过。

对于服务器,这意味着开放443/UDP传入。对于客户端来说,这意味着允许443/UDP传出。

在大型企业中,这可能会是一个问题。因为他们的网络通常只允许TCP端口通过，如果允许UDP通过听起来有些可疑。

虽然我认为这在连接方面会是一个主要问题,但是谷歌所做的实验证明事实并非如此。

在服务器端运行QUIC 

现在,唯一可以让你使用QUIC的网络服务器是Caddy,而且从0.9版开始。　　　

客户端和服务器端的支持都被认为是实验性的,所以是否要运行它取决于你的选择。

因为没有人的客户端是默认支持QUIC的,所以你可能仍然需要在自己的浏览器中允许QUIC，并运行它。

QUIC的性能优势

在2015年的一篇博文中，谷歌分享了QUIC实施的一些结果：

结果是,QUIC在比较差的网络条件下胜过了TCP,谷歌搜索页面的加载时间最少提升了1%。

这些好处在YouTube等视频服务上更加明显。用户报告在使用QUIC观看视频时可以减少30%的缓存时间。

YouTube数据尤其有趣。如果这些改进是可行的，我们很快就会在像Vimeo一样的视频流业务或“成人流媒体服务”上看到这个应用。

总结

我发现QUIC协议十分迷人的！

我已经迫不及待的想要看到QUIC协议在其他浏览器和网络服务器中实现了！

原文链接：https://ma.ttias.be/googles-quic-protocol-moving-web-tcp-udp/