http/2时代的web性能

http/2时代的web性能

2015年HTTP/2已经开始取代SPDY而登上历史的舞台。一直以来我们耳熟能详的那些Web性能优化技术，很可能会成为历史。HTTP/2在Web性能优化方面有哪些优势呢？与HTTP/1.1有什么不同？

本文和本次分享参考：第二届前端开发者大会讲师Holger Bartel的ppt

本文是为分享的PPT做准备的。叙述可能不具体和不到位。分享：Lecture 01 HTTP/2时代的Web性能

Slider: http://slides.com/wujiarong/deck#/

0 等待和延迟

生活中，我们经常处于各种各样的等待状态。







当我们打开浏览器。情况仍然得不到很好的改善。

loading…



没有人愿意等待。通常，等待都要等很长时间。

你应该听朋友说过。请等我一下，结果等了十几分钟。

你应该听女朋友说过。很快就好，结果等了将近1小时。

没有人喜欢等待。

何为等待：

直到某个时间点或者某个事件发生，才采取某些行动的延迟行为。

等待即延迟

1 网页性能

定义：wiki百科

Web performance refers to the speed in which web pages are downloaded and displayed on the user’s web browser.

由此可见。web性能分为两个部分：网页加载的速度和网页渲染出来的速度。

网页加载的速度往往用时间来衡量。也就是网页加载时间。我们通常说是，网页性能。

一般来说，我们说网页性能，说的其实是网页加载时间：page loading time。顾名思义，这个时间当然是越短越好。

随着互联网和web技术的快速发展，我们想呈现给用户的东西越来越多。从一开始的纯文本、到少量图片、到更多的图片、甚至视频。

为了提升用户体验，使得呈现内容以更友好的形式呈现给用户。我们开始添加大量的css改善效果，添加js动画和css3动画增加动态性。

用户角度所谓的快：期待2-3秒加载一个网页。

50%的用户会关掉浏览器的tab，如果一个网页加载时间超过4s。

无可厚非，动态性的增加和呈现优化，大大地提升了用户体验。但随之而来的代价是，网页加载时间越来越长。

研究表明，1s时间的网页延迟，将导致：

减少11%的网页浏览量

减少16%的用户满意度

减少7%的利润转化

我们来看一个用户体验表格。



From: Chapter 10. Primer on Web Performance

web性能社区的非官方公认：在250ms内，页面加载完成或者能有尽可能多的可视化反馈，能留住用户！

总结：越快越好！

2 web性能影响案例

亚马逊：网页加载速度增加100ms，销售额减少1%（参考：Amazon）

Walmart: 每优化1s，增加2%的利润转化。



Akamai研究发现：

47%的用户希望网页在2s以内加载完成

40%的用户会关闭网页，如果网页加载时间超过3秒

52%的网购者更愿意到网页加载速度更快的购物网站购物

3 全球带宽情况

两个数据

全球平均带宽（下载）：21.3Mbps (21.3/8 MB/s)

全球手机平均下载速度：10.9Mbps (10.9/8 MB/s)

From: netindex

几张图片

全球下载带宽情况：



欧洲：



北美：



南美洲：



非洲：

Bandwidth and Round-Trip Time

RTT(Round-Trip Time): 往返时延。在计算机网络中它是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。

更大的带宽不代表更快的网页加载速度！More Bandwidth Doesn’t Matter(much)





相对带宽，RTT对于网页性能的影响更大。





结论：

增加带宽对网页加载速度的提升不会有很大的影响。相反，应该减少RTT，或者RTT的个数。

4 改善web性能

4.0 HTTP是如何工作的？

超文本传输协议（HTTP，HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。

1960年美国人Ted Nelson构思了一种通过计算机处理文本信息的方法，并称之为超文本（hypertext）,这成为了HTTP超文本传输协议标准架构的发展根基。

Ted Nelson组织协调万维网协会（World Wide Web Consortium）和互联网工程工作小组（Internet Engineering Task Force ）共同合作研究，最终发布了一系列的RFC，其中著名的RFC 2616定义了HTTP 1.1。

短视频视频：Basic concepts of web applications, how they work and the HTTP protocol

Different types of HTTP requests

GET：This request is Used to get the Response header and the response body

HEAD：This request is used to get back The response header only (not the response body as returned by the GET request..)

POST：This request is used to submit data (eg : for to be used in HTML forms etc..)…

PUT：Used for uploading resource

PATCH：Is used to modify the resource

DELETE：Used for deleting resource

TRACE：simply echoes back the request sent by the client…This can be used for testing the servers and Checking weather the server is alive or not..

使用Telnet展现HTTP请求

Telnet www.baidu.com 80
GET / HTTP/1.1
TRACE / HTTP/1.1

4.1 HTTP/0.9 (1991)

HTTP 0.9作为HTTP协议的第一个版本。是非常弱的。请求(Request)只有一行,比如:

GET www.cnblogs.com

从如此简单的请求体，没有POST方法，没有HTTP 头可以看出，那个时代的HTTP客户端只能接收一种类型：纯文本。并且，如果得不到所求的信息，也没有404 500等错误出现。

虽然HTTP 0.9看起来如此弱，但已经能满足那个时代的需求了。

4.2 HTTP/1.0 (1996)

由于万维网需求激增，HTTP/0.9深感不能满足需求。这时候，拓展了很多功能的HTTP/1.0出来了。

HTTP/1.1的变化包括：

引入了POST方法

引入了HTTP头、状态码

HTTP传输内容不局限于文本。可以是图片、视频、文档等

4.3 HTTP/1.1 (1999)

HTTP/1.1相对于1.0的改变不算太大。

主要是：

1. 增加了host头字段。

2. 增加了Range字段，使得客户端通过HTTP下载时只下载内容的一部分，这使得多线程下载也成为可能。

这里对于HTTP/1.1及以前的几个版本不做具体且深入的介绍。如果有兴趣或者质疑，请自行google。



从1.1发布到SPDY提出，中间11年时间。HTTP在这么长的时间内没有做任何更新。

我们知道HTTP/1.1在web性能方面存在着很多问题。

比如：

较为庞大的HTTP Head，占用较多的网络流量。

明文传输，不安全。

非持久连接：每个请求都要建立TCP连接，耗时巨大。

持久连接：单个TCP连接，可以发送多次请求。但是多个请求之间是有先后顺序的，后面发送的请求必须等待上一个请求返回才能发送响应。这会很容易导致后面的请求被阻塞，同样耗时。

这些问题足以导致出现很多安全性问题，和很差的网页性能，也就是很长的网页加载时间。

为了解决这些问题。关注web性能的社区或公司，就想出了很多的处理方案和诞生了一些针对改善web性能的技术。

比如：

雅虎14条网页性能优化原则。参考：YaHoo Web优化的14条法则



减少HTTP请求次数

使用CDN(Content Delivery Network, 内容分发网络)

增加Expires Header（web cache）

压缩页面元素

把样式表放在头上

把脚本文件放在底部

避免CSS表达式

把JavaScript和CSS放到外部文件中

减少DNS查询次数

最小化JavaScript代码

避免重定向

删除重复的脚本文件

配置ETags

缓存Ajax

我们来分析一下什么因素影响网页性能，也就是会延长网页的加载时间。



一个网页，从浏览器请求，到服务器响应，返回数据或者资源，到浏览器接受完毕。其实宏观来说涉及了三个对象。

浏览器：请求数量影响PLT

路由网络：带宽和RTT影响PTL

服务器：服务器响应时间、数据库响应时间等影响PTL

我们暂时不讨论服务器响应时间，因为这个是人为可控的，而且一般来说是后台工程师的任务。

我们来看看浏览器和路由网络对PTL的影响。

在浏览器端，请求数量多少取决于网页结构和内容。如果图片、小图标、CSS文件、JS文件等太多，请求数量自然居高不下。这样就大大增加了PTL。

因此，在浏览器这个对象的视角。我们应该尽可能减少请求次数、增加并发连接数、尽量避免阻塞加载。

这样就产生了以上14条实践中的：1、3、5、6、8、12、13、14



从路由网络的视角。影响PTL的，是我们上面分析过的两个指标：带宽和RTT。

因此，在资源传输的中间环节，我们可以通过：增加带宽、带宽一定是减少数据量、减少RTT，这三个途径来减少PTL。

也因此产生了14条实践中的：2、4、9、10、11



把以上的内容再归结起来，涉及到的技术就有：

文件拼接和压缩

雪碧图

Inline Image

Domain Sharding

为了从根本上解决以上的问题，而不是需要前端后台工程师做大量的性能优化工作，一个伟大的尝试出现了。那就是SPDY。

4.4 SPDY (2010)

我们看看SPDY做了什么。参考：SPDY 协议介绍

多路复用

允许在一个TCP连接里面，允许无限并发流（在双方资源可承受的情况下）。因为请求是在一个单一的通道交错传输，TCP的可以达到很高的效率，从而更少的网络连接需要，可以以很高的 数据密度做传输。

具备优先级的请求

虽然无限的并行数据流的解决了序列化的问题，但是它们引入了另一个问题：如果由于信道带宽的限制，客户端可能会阻止怕堵塞通道的要求。为了克服这个问题，SPDY实现请求的优先次序：客户端可以请求尽可能多的项目，每个请求分配一个优先级。这样即使高优先级的请求仍处在pending状态，通道也不会传输非关键的，低优先级的请求，这样就有效地阻止了传输拥塞。

HTTP Header 压缩

对于HTTP 请求，响应头，SPDY都做了压缩，这样包更小，对于RESTFUL类型的WEB2.0 ,or OpenAPI 业务，将会有可观的效率提升。

服务器端推送

SPDY通过X-Associated-Content 协议头来向客户端推送数据，头通知客户端，我要向你推送资源，准备接收好了。最近火爆的Google+ ,如果你用chrome浏览器，默认就采用SPDY技术，并且开启了服务器推送技术。服务器的推技术，全面提升了用户体验，是G+ 产品很快占据了足够多的优势，最近Facebook 开发自己的浏览器，也有摆脱现在技术限制的考虑

服务器暗示

不像上面提到的PUSH 技术，服务器会先告诉浏览器，你可以下载ABC资源了，这个ABC资源，可能就是下一个页面的JS ,CSS ，或者内容。服务器不会主动推送的，仍旧等待客户端请求，这对于低速网络，是个很大的优化，有点类似于我们的预加载技术。

4.5 HTTP/2 (2015)

HTTP/2基于SPDY，优于SPDY。参考：HTTP/2 新特性浅析

不同点：

HTTP/2 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS

HTTP/2 消息头的压缩算法采用 HPACK ，而非 SPDY 采用的 DELEFT

HTTP2优势：

HTTP/2 采用二进制格式传输数据，而非 HTTP/1.x 的文本格式。二进制格式在协议的解析和优化扩展上带来更多的优势和可能。

HTTP/2 对消息头采用 HPACK 进行压缩传输，能够节省消息头占用的网络的流量。而 HTTP/1.x 每次请求，都会携带大量冗余头信息，浪费了很多带宽资源。头压缩能够很好的解决该问题。

多路复用，直白的说就是所有的请求都是通过一个 TCP 连接并发完成。HTTP/1.x 虽然能利用一个连接完成多次请求，但是多个请求之间是有先后顺序的，后面发送的请求必须等待上一个请求返回才能发送响应。这会很容易导致后面的请求被阻塞，而 HTTP/2 做到了真正的并发请求。

同时， 流还支持优先级和流量控制。

Server Push：服务端能够更快的把资源推送给客户端。例如服务端可以主动把 JS 和 CSS 文件推送给客户端，而不需要客户端解析 HTML 再发送这些请求。当客户端需要的时候，它已经在客户端了。

5 拥抱HTTP/2

使用HTTP/2

第一步：使用SSL\TLS加密你的HTTP连接，也就是使用HTTPS



第二步：配置支持HTTP/2的服务器



第三步：检查浏览器兼容性

nodejs width HTTP/2

利用Package: http2可以部署nodejs的http2服务。



代码：