Google/QUIC, Quick UDP Internet Connections 是一种实验性的网络传输协议，位于OSI模型的传输层。由Google开发，在2013年实现。QUIC使用UDP协议，它在两个端点间创建连线，且支持多路复用连线。

现代 TCP 是在 RFC 793 中定义的，进过数十年的的实验，实践出来。它在 1981 年发布。HTTP Working Group 在2013开始关注 HTTP/2 的工作，他们聚焦到如何优化 HTTP 在 TCP 的使用上。他们尽可能的消除队头阻塞, 提升对连接的利用。HTTP/2 支持了多路复用，从而高效的利用 TCP 连接。但是 队头阻塞的问题并没有完全解决，因为包传输是有序的，于是 QUIC 为了克服这个问题，将 数据流层移至传输层，它在 UDP 之上构建了一个类似 TCP 的服务。UDP 并不能确保有序可靠的传输，但是 QUIC 在 UDP 之上构建了新的一层。 在实践上谷歌文章指出:

QUIC 在 YouTube的视频服务上更为突出。用户报告通过QUIC协议在观看视频的时候可以减少30%的重新缓冲时间。

接下来我们看下 QUIC 协议对视频播放有哪些提升点？

减少握手次数，优化起播速度

TCP 需要进行 三次握手 才能建立连接，具有一定的连接等待时延，如果用了 TLS 加密，还会有其他的步骤，进一步增加时延；然而对于QUIC来说，如果是客户端首次连接到服务器，由于QUIC将传输与加密结合在一起的特性所在，一般来说正常情况下初次握手只需要1个RTT就可以完成握手；这对于视频的起播时间非常重要，我们在播放 HLS 的时候，我们需要建立 m3u8 的 请求然后再建立分片 TS 的请求，这样握手建立连接的成本可想而知。

切换网络无影响

QUIC 的连接不再以 IP 及端口四元组标识，而是以一个 64 位的随机数作为 ID 来标识每一次连接，这样就算 IP 或者端口发生变化时，只要 ID 不变，这条连接依然维持着，上层业务逻辑感知不到变化，不需要重新握手，不会中断，也就不需要重连，继续传输数据。这对我们现在大多数流媒体 APP 来说，无论是短视频还是长视频我们都不用太担心移动网络切换或者 WIFI 切换，保证流的稳定性。

卡顿一直都是播放体验最重要的监测环节。在流媒体的传输链路中，任何一个环节丢包都可能导致用户观看卡顿。QUIC 传输层基于 UDP 协议，但却是一种可靠的传输协议，因为它将很多可靠性的验证策略从系统层转移到应用层来做，这样可以使用更适合现代流媒体传输的拥塞控制策略；QUIC 最基本的传输单元是 Packet，不会超过 MTU 的大小，整个加密和认证过程都是基于 Packet 的，不会跨越多个 Packet。这样就能缓解 TLS 协议存在的队头阻塞问题；特别是在传输大量数据是，比如 视频、直播流，受队头阻塞的影响很小；QUIC 采用前向纠错（FEC）方案，即每个数据包除了本身的数据以外，会带有其他数据包的部分数据，在少量丢包的情况下，可以使用其他数据包的冗余数据完成数据组装而无需重传，从而提高数据的传输速度。

加密版权保护

QUIC 推动了 TLS1.3, QUIC 对 SSL 证书进行压缩，减少了证书传输量，且针对包头进行验证。有利于音视频秒开。* QUIC 对每个散装的 UDP 包都进行了加密和认证的保护，并且避免使用前向依赖的处理方法（如CBC模式），这样每个 UDP 包可以独立地根据IV进行加密或认证处理； QUIC 采用了两级密钥机制：初始密钥和会话密钥。初次连接时不加密，并协商初始密钥。初始密钥协商完毕后会马上再协商会话密钥，这样可以保证密钥的前向安全性，之后可以在通信的过程中就实现对密钥的更新。接收方意识到有新的密钥要更新时，会尝试用新旧两种密钥对数据进行解密，直到成功才会正式更新密钥，否则会一直保留旧密钥有效；

你可以在 Chrome 输入 chrome://flags 开启 quic 协议。