HTTPS性能优化原理与实践——如何优化HTTPS( 二 ) _HTTPS

流量控制是基于WINDOW_UPDATE帧的。接收方公布自己打算在每个流以及整个连接上分别接收多少字节。这是一个以信用为基础的方案。

流量控制是有方向的，由接收者全面控制。接收方可以为每个流和整个连接设置任意的窗口大小。发送方必须尊重接收方设置的流量控制限制。客户方、服务端和中间代理作为接收方时都独立地公布各自的流量控制窗口，作为发送方时都遵守对端的流量控制设置。

无论是新流还是整个连接，流量控制窗口的初始值是65535字节。

帧的类型决定了流量控制是否适用于帧。目前，只有DATA帧服从流量控制，所有其它类型的帧并不消耗流量控制窗口的空间。这保证了重要的控制帧不会被流量控制阻塞。

流量控制不能被禁用。

HTTP/2只定义了WINDOW_UPDATE帧的格式和语义，并没有规定接收方如何决定何时发送帧、发送什么样的值，也没有规定发送方如何选择发送包。具体实现可以选择任何满足需求的算法。

多路复用在HTTP1.1中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量的限制。超过限制数目的请求会被阻塞，而HTTP2.0中的多路复用优化了这一性能
基于二进制分帧层，HTTP2.0可以在共享TCP连接的基础上，同时发送请求和响应。HTTP消息被分解为独立的帧，而不破坏消息本身的语义，交错发送出去，最后在另一端根据流ID和首部将他们重新组合。对比看一下HTTP1.x和HTTP2.0，这里不考虑HTTP1.x的pipeline机制http1.x

文章插图

http2.0

文章插图

HTTP2.0成功解决了HTTP1.x的队首阻塞问题(TCP层的阻塞仍无法解决)，同时，也不需要通过pipeline机制多条TCP连接来实现并行请求与响应。减少了TCP连接数对服务器性能有很大提升，同时也消除不必要的延迟，从而减少页面加载的时间。
请求优先级把HTTP消息分为很多独立帧之后，就可以通过优化这些帧的交错和传输顺序进一步优化性能
每个流都可以带有一个31bit的优先值：0表示最高优先级；2的31次方-1表示最低优先级。
客户端明确指定优先级，服务端可以根据这个优先级作为交互数据的依据，比如客户端优先设置为.css>.js>.jpg 。服务端按此顺序返回结果更加有利于高效利用底层连接，提高用户体验。然而，在使用请求优先级时应注意服务端是否支持请求优先级，是否会引起队首阻塞问题，比如高优先级的慢响应请求会阻塞其他资源的交互。
服务器推送HTTP2.0增加了服务端推送功能，服务端可以根据客户端的请求，提前返回多个响应，推送额外的资源给客户端
如下图，客户端请求stream 1(/page.html) 。服务器在返回stream 1的消息的同时推送了stream 2(/script.js)和stream4(/style.css)

文章插图

PUSH_PROMISE帧是服务端向客户端有意推送资源的信号。
PUSH_PROMISE帧中只包含预推送资源的首部。如果客户端对PUSH_PROMISE帧没有意见，服务端在PUSH_PROMISE帧后发送响应的DATA帧。如果客户端已经缓存了该资源，不需要推送，可以拒绝PUSH_PROMISE帧。
PUSH-PROMISE必须遵循请求-响应原则，只能借着对请求的响应推送资源。
PUSH_PROMISE帧必须在返回响应之前发送，以免客户端出现竞态条件（竞态条件是指在多线程的情况下不同的执行顺序会导致计算机执行出不同的结果正确性不同）
HTTP2.0连接后，客户端与服务端交换SETTINGS帧，借此限定双向并发的最大数量。因此，客户端可以限定推送流的数量，或者通过把这个只设置为0来完全禁止服务器推送。
所有推送的资源都必须遵守同源策略。换句话说，服务器不能随便将第三方资源推送给客户端，而必须是经过双方的确认才行

HTTP/2现在已经获得绝大多数浏览器的支持，不过在使用过程中HTTP/2需要使用1.0.1e之后的openssl版本，通过nginx -V，可以查看nginx的openssl版本，如果版本低，重新编译nginx即可。