QUIC

QUIC（Quick UDP Internet Connection）是谷歌制定的一种基于UDP的低时延的互联网传输层协议。在2016年11月国际互联网工程任务组(IETF)召开了第一次QUIC工作组会议，受到了业界的广泛关注。这也意味着QUIC开始了它的标准化过程，成为新一代传输层协议

 

QUIC support for Go

 

移动互联网的难度
在Devsisters，服务器团队不断研究改善手机游戏用户在线体验的方法。越来越多的手机游戏变得越来越复杂。今天发布的许多游戏都需要互联网才能享受。但与PC游戏同行不同，移动环境在托管在线手机游戏时会带来一些独特的挑战。

手机实际上是“移动的”。因此，他们的在线连接随着手机物理位置的变化而变化。从这个wifi到无线网络的持续过渡，间歇性的蜂窝数据使用，偶尔的蜂窝信号停电 - 这一切都使得移动互联网连接非常不稳定和不可靠。

这种环境会带来严重的用户体验问题。拥有智能手机的每个人都会同意他们的wifi信号弱到足以过渡到蜂窝数据网络时会有多么沮丧。它使网页浏览几秒钟无法忍受。

当在网络浏览会话期间丢失wifi信号时，wifi被断开并转换到其他可用的wifi或蜂窝数据网络。有时在此期间，目前加载网页似乎需要很长时间才能完成。在这种情况下，按下刷新按钮不仅仅是等待，而是经常使页面加载更快。敏锐的用户可能已经观察到这种现象。

出现这种问题是因为TCP处理数据包丢失的方式。 TCP将丢包视为网络拥塞的信号。在“网络中断”的情况下，它以指数方式减慢了将数据包发送到不再发送数据包的点。发生此类事件时，即使底层网络恢复，TCP连接也需要更多时间来恢复其连接。因此 - 从用户的角度来看 - 在这种情况下简单地按下刷新按钮而不是等待加载完成更为明智。

在HTTP上只有两种方法可以解决这个问题：无限期等待或“超时并重试”。在HTTP / 2上也存在这种问题，它也使用TCP。事实上，它在HTTP / 2上更糟糕，因为它使用连接多路复用网络中断来停止所有逻辑HTTP请求，从而导致显着的性能下降。这种问题称为线头阻塞。

线头阻塞不是HTTP中唯一的问题。由于越来越多的服务使用HTTPS，初始化连接的成本变得越来越高。因此它直接影响“超时和重试”策略。在移动环境中，3G连接的蜂窝延迟在200~300ms范围内，3次往返HTTPS连接握手太昂贵了。

谷歌的实验：QUIC
幸运的是，谷歌正试图通过开发和研究一种名为QUIC的新协议来解决这个问题。由于HTTP / TLS和TCP导致此问题，我们无法在TCP层上修复它。因此，QUIC直接在UDP传输层上开发。

QUIC旨在解决线头阻塞问题和TLS连接往返问题。 QUIC项目页面中提供了详细的项目描述。

不幸的是，由于QUIC是一种实验性协议，因此该协议只有一种实现方式。并且该实现存在于项目Chromium中。谷歌提供玩具服务器/客户端。但源代码本身并不是一个库。它与现有的铬源密切相关。

libquic和goquic的诞生
我们最初的计划是将Chromium的网络运行时整合到我们的游戏客户端和服务器中。但结果却非常艰难。然后，我们尝试从Chromium中提取最少量的源代码，几乎不运行QUIC代码。这促成了项目libquic的诞生：这是从Chromium中提取的一个简单的必需品，独立的源代码。它可以在Mac和Linux平台上构建并生成libquic库。

我们的下一步是创建一个Golang绑定。由于我们的服务器堆栈是在Go中开发的，因此它是一个自然的选择。这导致了goquic的诞生。它试图模仿内置的HTTP库，并且还包含bradfitz的http2库，以便在QUIC不可用时启用HTTP / 2。