图 19 页面请求15个，大小465KB
公司业务接入步骤
● 客户端支持
X5内核团队（移动端）
依赖用户浏览器支持QUIC情况（PC端）
● 服务端支持
STGW团队
● 业务自身
按照路径灰度，控制灰度策略
QQ会员页面接入效果
以上测试demo数据是基于公司良好的网络情况下测试得到的，在实际运用过程中，大家可能更关心在复杂的网络环境下QUIC的表现。于是QQ会员团队通过灰度现网的一个页面来考察QUIC在现网的性能情况。
● 页面情况
Android日PV100w，页面大小95KB
总请求30个，其中主资源请求1个，CDN请求24个，其他请求5个
展示部分依赖php直出和js渲染
● 灰度情况
QUIC请求1个（php页面主资源），HTTP2请求29个
● 灰度策略
客户端每天放量，对比灰度过程中页面主资源的HTTP2和QUIC的性能数据
● 灰度效果
图20 QQ会员页面QUIC灰度情况
● 效果说明
因为建连依赖于1RTT和0RTT机制，使得QUIC建连平均耗时仅需46ms，比HTTP2的225ms减少180ms左右。
由于目前灰度量只占到总请求量的10%，因此更严谨的性能对比数据有待进一步提高灰度范围，以上仅作现阶段参考。
但依然可以看到QUIC在现网环境总体表现忧于HTTP2。
注意问题
在实践QUIC的过程中，我们也遇到了一些需要注意的问题。
● QUIC支持头部alt-svc的缓存机制面向整个域名
业务即使只在一个页面路径下加了支持头部（STGW可以是路径级别支持，X5只能是域名级别支持），浏览器也会根据头部的缓存时长作用于用户访问该域名下的其他页面，但STGW可能只支持了路径级别。所以灰度过程中，尽量使用有独立域名的页面。从而保证尽量不影响其他页面的请求情况（虽然QUIC请求失败会降级H2），尽量减少ma缓存时间。
● 客户端对于QUIC的协商机制有待改善
在X5目前的实现机制中，无论如何首次请求都会基于HTTP2，后续才会尝试QUIC，但如果缓存时间设置的不够长（譬如1天），会使得用户一般1天内很难通过再次请求走到QUIC。所以，目前我们做的是推动X5在请求时候让白名单链接直接尝试QUIC。同时，避免缓存时间随着用户退出手Q而失效，推动让其落地。
● 目前客户端基于X5的QUIC与一些基于缓存和预加载的页面秒开方案冲突
如果你们的页面是基于X5内核，但是使用了上述类似的技术，那么存在一个问题是原本直接通过X5走QUIC协议的页面不直接走X5了，而是基于你当前方案的缓存或者自定义的webview请求方式。于是通过统计数据会发现QUIC的请求量很少，因为上述技术目前还不支持QUIC协议。当前的做法是在QUIC和该方案中二选一。
● CDN请求灰度需要自支持
由于CDN请求不基于STGW代理，因而需要CDN团队针对业务方域名灰度支持，目前CDN整体处于运营商灰度QUIC阶段。在此之前如果需要灰度CDN请求就需要业务方自己处理转发。
● 运营商的Qos影响需要更完善的上报数据进行评估
使用QUIC协议比较担心的一个问题就是在网络质量差的情况下运行商Qos会对其产生怎样的影响。从目前整体的统计数据，包括慢速用户占比等情况来看，影响不是很大。后续需要推动各方完善上报监控该情况下耗时。
未来工作List
● 和X5团队一起解决首次请求必走HTTP2请求问题
● 和X5团队一起解决alt-svc缓存有效期落地问题
● 和终端团队一起解决秒开方案下Webview对QUIC的支持，争取既能使用QUIC协议又能使用秒开方案
● 配合CDN团队验证QUIC扩大灰度的支持效果
● 推动各方更细粒度的数据统计完善
参考资料
https://docs.google.com/document/d/1gY9-YNDNAB1eip-RTPbqphgySwSNSDHLq9D5Bty4FSU/edit
QUIC Crypto Adam Langley Wan-Teh Chang
https://segmentfault.com/a/1190000007060218
https://segmentfault.com/a/1190000007075961
https://blog.csdn.net/xiaofei0859/article/details/77512746
https://imququ.com/post/http-alt-svc.html
HTTP over UDP: an Experimental Investigation of QUIC
QUIC FEC v1 Author: ianswett@google.com Last Updated: 2016-02-19
Understanding QUIC wire protocol
IETF93 QUIC BarBoF: Congestion Control and Loss Recovery
QUIC: Performance and Security at the Transport Layer