写点什么

HTTP/2 in GO(五)-- 大结局

  • 2019-11-18
  • 本文字数:1859 字

    阅读完需:约 6 分钟

HTTP/2 in GO(五)--大结局

本章作为一个收尾,我来谈一些自己对 HTTP/2 的理解,以及 HTTP/2 的应用前景展望。


通过前边四章,我们了解了 HTTP/2 的特性,以及如何在 Go 中利用 HTTP/2 的相关特性进行一些开发工作。本章作为一个收尾,我来谈一些自己对 HTTP/2 的理解,以及 HTTP/2 的应用前景展望,个人观点,不一定对,欢迎大家留言讨论。


先回顾下:

HTTP/2 新特性

  • 二进制分帧(HTTP Frames)

  • 多路复用

  • 头部压缩

  • 服务端推送(server push)


HTTP/2 通过多种多种技术手段(如:多路复用,头部压缩,优先级等),极大的优化了 HTTP 的 C/S 双端的数据交互体验,解决很多以往 HTTP/1.1 协议本身不能解决的问题。

HTTP/2 的优势

  • 低延迟的内容传输(多路复用,优化 RTT)

  • 带宽占用减小(头部压缩,编码,HPACK)

  • 连接数减少(多路复用,二进制分帧)


先来看下带宽和延迟对页面加载的影响,数据来源:HTTP/2 is here, let’s optimize! - Velocity SC 2015



  • 在 5M 以下的带宽内,对页面加载速度影响较大,5M 以上的带宽,对页面加载速度影响较小。

  • 延迟的减少对页面加载时间的提升呈线性增长


目前国内及一些发达国家,家庭带宽普遍也能达到 5M 以上了,所以 HTTP/2 即使减小了带宽占用,对我们 WEB 业务来说,提升也非常有限,收益不可观。但如果换一个角度来说,HTTP/2 减小了带宽占用,那么对国内的网络基础设施,甚至是跨洋光纤来说,要求都会降低,也相当于变相提升了网络基础设置的品质。对那些像 CDN 这种靠带宽来收费的场景来说,减小带宽也会减小成本(特定场景,不一定所有的 CDN 场景都能减小带宽占用)。


RTT 的优化导致延迟的减少,应该能极大程度上提升一些用户体验,这点看起来收益应该会比较明显,可事实又会怎样呢?程序猿们的智慧不可小觑,在 HTTP/1.1 阶段虽然不能通过多路复用来减少 RTT,但是我们可以用连接并发啊。页面内的资源链接放到不同的域名下,单个域名连接数有限制就用泛域名分散-Domain sharding 下。如果是 icon 这种小图标,资源太多又导致页面内链接太多,那就用雪碧图-CSS Sprites 啊。所以,经过这么一折腾,HTTP/2 减少 RTT 的优势也不存在了。


最后一点就是连接数的减少,这个是有绝对的优势了,之前 HTTP/1.1 甚至都通过增加连接数来优化页面性能。但这点优势也无非就是减少一些服务端的压力,对用户体验没有什么提升。对于不差钱的互联网公司门来说,减小的那一点压力还不至于去大动干戈。


HTTP/2 的 Server Push 功能,看起来能加速资源的获取速度,可是在目前的互联网环境下,大家都是把静态资源放到独立的域名,利用 CDN 进行加速,不会占用自己的服务带宽;CDN 拥有更多的服务节点,比服务本身能提供更好的接入和访问效果,所以目前看起来 Server Push 也没有很好的用武之地。即使要使用 Server Push,服务端也要关注客户端的 Cache,避免重复推送,浪费带宽,这点也还没有很好的服务端生态来解决。


另一个是关于 HTTP/2 服务的七层反向代理,当我们希望在一些网关对业务进行一些基础逻辑的处理时,需要使用这个。但由于 HTTP/2 引入了 Stream States,这个流程略显复杂,相当于针对客户端和服务端要维护两套不相同的状态,使得这个七层代理的实现也有一些难度。Nginx 官方也暂时不计划在 Proxy Module 中支持 upstream 的 HTTP/2,因为他们认为 HTTP/2 在性能的提升上,对 proxy 上的使用没有收益,甚至可能有反作用; 而且实现该功能,需要重写 upstream 模块,没有收益 + 工作体量大,就更没有必要去做了。nghttp2 应该是当前最完善的 HTTP/2 相关的组件了,但是其实现的代理 nghttpx 对 HTTP/2 代理也只实现了部分功能,无法代理实现 Server Push。


下图是通过配置了 nghttpx 的 http2-proxy 后,通过我们前边的 GO 代码实例,访问/push,返回的不支持 Server Push:



最后做个总结,我个人的意见是:HTTP/2 有优势,但其优势对现在通过应用层优化后的 HTTP/1.x 来说,优势没有那么大,并且,如果要发挥 HTTP/2 的优势,就必须将之前在 HTTP/1.x 阶段做的很多事情进行"回退",这种吃力并且讨不到什么好处的事情,大家没有动力去做。所以,可以预见的是,短时间内,HTTP/2 还是不会得到大范围的应用。但是随着国外一些互联网巨头们的带动,提供越来越多的可以便捷的使用 HTTP/2 的生态工具,HTTP/2 终究还是会发展起来的,毕竟它的优势还是存在的。


当前时间:2018 年 08 月 25 日 21:36:22,给 BAT 三家的首页截了个图,可以看到,都还是 HTTP/1.1,并没有启用 HTTP/2.(但起码都是 HTTPS 了>_>)





本文转载自公众号 360 云计算(ID:hulktalk)。


原文链接:


https://mp.weixin.qq.com/s/qaqN4Eqndjg95TPBOC4d_g


2019-11-18 22:59932

评论

发布
暂无评论
发现更多内容

TiCDC 实现 TiDB 备份方案

TiDB 社区干货传送门

Raft 算法浅析

TiDB 社区干货传送门

TiDB GC 之监控及日志解读

TiDB 社区干货传送门

【TUG 话题探讨001】TiDB 的应用场景有哪些?看看 TUG 的技术专家怎么说

TiDB 社区干货传送门

在Windows下调试TiDB4PG的填坑实记

TiDB 社区干货传送门

记一次 Lightning 导入失败导致的 TiDB 集群重启失败事故处理

TiDB 社区干货传送门

TiDB v4.0.12 VS v5.0.0 insert 性能对比

TiDB 社区干货传送门

TiDB 常⻅架构应⽤场景

TiDB 社区干货传送门

docker方式部署的tidb-v3.0扩容缩容pd节点后需要滚动升级整个集群

TiDB 社区干货传送门

YiDB在翼支付账单业务的应用实践

TiDB 社区干货传送门

使用 TiDB 时的连接池和负载均衡器配置策略

TiDB 社区干货传送门

DM v1 升级v2初体验

TiDB 社区干货传送门

DM2.0初体验

TiDB 社区干货传送门

TiKV 源码略读 - Server Start

TiDB 社区干货传送门

TiFlash 5.x 与 4.x 对比测试

TiDB 社区干货传送门

【TUG 话题探讨002】看看 TUG 的技术专家都在用哪些数据库?

TiDB 社区干货传送门

【TUG 话题探讨003】TUG 专家们如何做 TiDB 性能调优

TiDB 社区干货传送门

【TiDB 社区版主推荐阅读】SQL 窗口函数速查表

TiDB 社区干货传送门

TiDB 4.0 新 Feature 原理及实践:统一读线程池

TiDB 社区干货传送门

升级5.1.1小问题

TiDB 社区干货传送门

使用MySQL Workbench 迁移SQL Server 2012数据库到TiDB 5.0

TiDB 社区干货传送门

TiCDC使用心得

TiDB 社区干货传送门

如何使用 minio 进行 BR 备份

TiDB 社区干货传送门

TiDB 整体架构

TiDB 社区干货传送门

DM问题处理总结

TiDB 社区干货传送门

【 AskTUG 每周精选】 SOP 系列问题拆解合集

TiDB 社区干货传送门

TiDB 5.0 升级性能初体验

TiDB 社区干货传送门

TiDB GC 之处理案例 & FAQ

TiDB 社区干货传送门

带着问题读 TiDB 源码:Hive 元数据使用 TiDB 启动报错

TiDB 社区干货传送门

【TiDB 社区版主话题探讨】-深入讨论 BR 备份

TiDB 社区干货传送门

DM同步过程问题汇总

TiDB 社区干货传送门

HTTP/2 in GO(五)--大结局_文化 & 方法_付坤_InfoQ精选文章