http/2时代的web性能
近几年来，Web性能的话题逐渐升温，大家开始认识到它在设计过程中的重要性。今天，随着HTTP/2这个新协议的采用，Web已经进入HTTP/2时代。
一直以来我们耳熟能详的那些Web性能优化技术，很可能会成为历史。这次分享将带大家重温当前最佳实践，哪些技术在HTTP/2时代会发生变化，以及如何恰到好处地实现从1向2的过渡。
本文是为分享的PPT做准备的。叙述可能不具体和不到位。分享：Lecture 01 HTTP/2时代的Web性能
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.14.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服务。
代码：
