HTTP/2 in GO（五）-大结局

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

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

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

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

当前时间：，给BAT三家的首页截了个图，可以看到，都还是HTTP/1.1，并没有启用HTTP/2.(但起码都是HTTPS了>_>)