QUIC or TCP

QUIC诞生历程

QUIC协议，全称是quick udp internet connection，最初由Google设计实现，并于2013年发布，目的是解决TCP协议在拥塞控制、多路复用等场景下的问题，并被应用到Google的多个服务上。

2018年10月，IETF正式将基于QUIC的http协议命名为HTTP/3，使得QUIC具备了全球流行的条件。

在2021年5月IETF公布RFC9000，正式推出QUIC标准化版本规范。至此未来已来。

gQUIC 和 iQUIC

由Google最初设计发布的QUIC，一般称之为gQUIC，后面由IETF发布的QUIC，被称之为iQUIC。虽然两个名字都是QUIC但是底层实现相差甚大。iQUIC相比于gQuic在协议上进一步进行了优化改进，据Google自己对外发布消息成，iQUIC应用于Google搜索和YouTube播放上都有更优的效果。

目前比较常用的gQUIC版本有Q39、Q43、Q46、Q50;

比较常用的iQUIC版本有h3-27、h3-29 和 h3 v1。

QUIC解决的问题

1. 快速建连问题

支持0RTT快速建连，规避TCP和TLS必须至少两个RTT握手造成的连接延迟，加速建连，减少耗时。

对于直播、短视频等非常重视首屏体验的场景，可以大幅优化首帧耗时，提升用户体验。

2. TCP对头阻塞问题

基于TCP的HTTP/2仍然存在对头阻塞问题，一旦出现丢包重传，就会阻塞后续的报文发送。QUIC不再依赖TCP的报文序列号，使用UDP报文通讯，队头报文丢失不影响后续报文传送。

3. 连接迁移问题

QUIC真正摆脱了TCP五元组，在移动互联网时代具有无比的优势。对于自动连接wifi，进出电梯4/5G网络和wifi切换，wifi弱网时自动切换运营商优化体验等场景，不需要重新握手建连，可以使用自己唯一的连接标识继续通讯。 对于移动场景下主播或观众的连续性体验非常方便。

除了解决TCP的固有问题外，QUIC在多路传输、协议栈优化等场景也进行了有效的优化，对于弱网场景下的应用也具有显著的优势。

QUIC的体验

很多浏览器和开源客户端可以支持QUIC协议的通讯，大部分最新版浏览器比如chrome、firefox、Opera、Safari、使用chrome内核的QQ浏览器等都支持QUIC协议，开源客户端比如quic_client，lsquic，nginx-quic都支持QUIC协议。

但所有的工具中，chrome无疑是最方便，支持也非常完善的工具。下面是简单的chrome使用QUIC的体验方法。

默认chrome是支持QUIC的，为了保险起见，可以手动强制打开 Chrome 的 QUIC 开关，在 Chrome 浏览器地址栏输入chrome://flags/#enable-quic，将开关设置成 Enabled，并重启 Chrome 浏览器。

使用chrome访问支持quic协议的网址，并打开开发者工具，查看使用的Protocol。

新版本的Chrome目前默认使用IETF QUIC，如果要测试Google QUIC协议，可以使用命令行工具打开Chrome并指定QUIC版本，例如：进入 Chrome 安装目录，执行chrome --enable-quic --quic-version=QUIC_VERSION_43。

--quic-version后面的版本可以指定gQUIC版本（如QUIC_VERSION_43），也可以指定iQUIC版本（如h3-27）。

腾讯云直播支持QUIC推流播放

从腾讯云直播的官网文档，可以看到目前腾讯云直播已支持QUIC的推流播放，并且gQUIC和iQUIC均可支持，按指定方式开通后可以支持，对弱网场景下的体验更优。

参考文档：

[1] wikipedia quic: https://zh.wikipedia.org/wiki/QUIC#cite_note-:1-13

[2] RFC9000: https://datatracker.ietf.org/doc/html/rfc9000

[3] chromimu log: https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html

[4] 腾讯云QUIC协议直播: https://cloud.tencent.com/document/product/267/52522