InfoQ的性能对比,HTTP/3与HTTP/2( 二 )


从简洁性和安全性角度出发 , 丢失检测和拥塞控制规范建议使用Reno算法 , 但允许用户根据自身情况选择任何算法 。 我们的实现从NewReno算法开始 , 基于以往经验 , 我们知道可以通过其他方式获得更好的性能 。 我们最近已迁移到CUBIC算法 , 在数据传输量大且数据包丢失频繁的网络情况下 , CUBIC算法性能与NewReno算法相比有很大提升 。
对于现有的HTTP/2技术栈 , 我们目前支持BBRV1(TCP) 。 这意味着在我们的测试中 , 我们无法进行精确的比较 , 因为这些拥塞控制算法在较小数据传输和较大数据传输之间的行为会有所不同 。 虽然如此 , 与HTTP/2相比 , 我们已经看到使用HTTP/3在较小内容传输下的速度更快 。 对于较大区域 , 改进后的HTTP/2的拥塞控制在性能上大放异彩 。
对于15KB的小型测试网页 , HTTP/3平均需要443ms加载 , 而HTTP/2则为458ms 。 但是 , 一旦我们将页面大小增加到1MB , 优势就会消失:HTTP/3仅比当今网络上的HTTP/2慢一点 , HTTP/3加载花费2.33秒 , 而HTTP/2加载花费2.30秒 。
基准测试很有意思 , 然而我们更想知道HTTP/3在现实世界中的表现 。
为进行衡量 , 我们希望有一个第三方可以像浏览器一样在我们的网络上加载网站 。 WebPageTest是一个通用框架 , 通过漂亮的瀑布图来展示页面加载时间 。 为了分析后端 , 我们使用了自家的BrowserInsights来捕获白屏时间 。 然后 , 我们将这两部分数据通过自动化的方式结合在一起 。
作为测试用例 , 我们决定对公司博客进行性能监控 。 我们在全球范围配置了WebPageTest实例 , 以同时通过HTTP/2和HTTP/3加载站点 。 我们还启用了HTTP/3和BrowserInsight 。 因此 , 每当我们的测试脚本检测到使用支持HTTP/3的浏览器访问该站点加载网页时 , 浏览器就会将报告数据返回 。 清洗数据并与HTTP/2的报告数据进行比较 。
下图显示了真实页面(blog.cloudflare.com)的页面加载时间 , 以比较HTTP/3和HTTP/2的性能 。 同时我们还从不同的地理位置进行了这些性能评估 。
如上图所见 , 在北美 , HTTP/3性能仍落后于HTTP/2性能 , 性能差距平均水平约为1-4% , 在欧洲 , 亚洲和南美也得到类似结论 。 我们怀疑这可能是由于拥塞算法不同所致:BBRv1上的HTTP/2与CUBIC上的HTTP/3不同 。 将来 , 我们将努力在两者上支持相同的拥塞算法 , 以实现更准确的性能对比 。
结论
总体而言 , 我们很高兴一起参与推动这一标准的发展 。 我们的实现效果很好 , 在某些情况下提供了更好的性能 , 并且在最坏的情况下性能也和HTTP/2相近 。 随着标准的定稿 , 我们期待浏览器在主流版本中增加对HTTP/3的支持 。 对我们来说 , 我们将继续支持最新的草案 , 同时寻找更多的方法 , 比如拥塞调整、优先级划分或者系统容量(CPU和原始网络吞吐量) , 利用HTTP/3获得更好的性能 。
同时 , 如果您想尝试一下 , 只需在我们的仪表板上启用HTTP/3并下载支持该协议的浏览器 。 有关如何启用HTTP/3的说明 , 请参见我们的开发文档 。
https://developers.cloudflare.com/http3/intro/
参考阅读:
https://blog.cloudflare.com/http-3-vs-http-2/
【InfoQ的性能对比,HTTP/3与HTTP/2】点个在看少个bug