关于HTTP协议性能优化的几个点

在建立HTTP标准规范的时候，制订者主要想把HTTP当作传输HTML文档的协议。随着时代的发展，Web的用途更具多样性，比如演化成在线购物网站等等，由于HTTP协议上的限制以及自身性能有限，逐渐不能满足这些网站的对性能的需求。目前基于HTTP的Web浏览器的使用环境已经遍布全球，因此无法完全抛弃HTTP。只能着手从HTTP协议本身上，进行性能优化，满足网站的开发需求。

HTTP/1.1如何优化

本片文章针对的是HTTP/1.1协议进行优化。对于HTTP/1.1来说，有如下三种优化思路：

• 尽量避免向服务器发送HTTP请求
• 考虑如何减少HTTP请求次数
• 减少服务器的HTTP响应的数据大小

尽量避免向服务器发送HTTP请求

大家都知道，HTTP/1.1是请求/响应的协议，要想获取服务端的资源，客户端必须要向服务器发出请求。如果网络中大量的客户端都向同一个服务器发出请求，势必会造成网络的拥堵以及服务器响应速度降低的情况出现。所以，避免发送 HTTP 请求的⽅法就是通过缓存技术， HTTP 设计者早在之前就考虑到了这点，因此 HTTP 协议的头部有不少是针对缓存的字段。

利用缓存技术，客户端会把第⼀次请求以及响应的数据保存在本地磁盘上，其中将请求的 URL 作为 key，⽽响应作为 value，两者形成映射关系。

如果下次还请求同一份资源的话，浏览器是直接调用系统中的缓存，不再向服务器发出请求。一般来说，直接从系统中调用缓存的速度是比向服务器发出请求得到响应的速度要快不少的。利用缓存技术提高了HTTP响应的速度。

图片来源：小林图解网络

由于缓存资源是在第一次请求的时候下载保存在缓存服务器的，不可避免的，这里需要注意一个时效性的问题。HTTP/1.1在设计的时候，也是注意到了这个问题，因此他们设置了这么几个首部字段用来维护缓存资源的时效性：

• 通用首部字段：Cache-Control：

  Cache-Control是操作缓存的工作机制的指令，该指令有很多参数可以选择，这里拣几个重要的参数说明一下该指令的作用：

  • max-age指令：Cache-Control: max-age=604800（单位：秒）

  
  当客户端发送的请求中包含max-age指令时，如果判定缓存资源的缓存时间数值比指定时间的数值更小，那么客户端就接收缓存的资源。另外，当指定max-age值为0时，那么缓存服务器通常需要将请求转发源服务器。

  • no-cache指令：Cache-Control: no-cache
    

    使用no-cache指令的目的是为了防止从本地缓存中返回过期的资源

    客户端发送的请求中如果包含no-cache指令，则表示客户端将不会接收缓存过的响应。于是，缓存服务器必须把客户端请求转发给源服务器。

• 请求首部字段：If-Modified-Since：

  对HTTP报文有了解的同学对这个字段应该是不陌生的。If-Modified-Since用于确认代理或者客户端拥有的本地资源的有效性。如果请求的资源在源服务器上没有发生过更新，源服务器则返回状态码304 Not Modified的响应。

• 响应首部字段：ETag：

  ETag是一种可将资源以字符串形式做唯一标识的方式。服务器会为每一份资源分配对应的ETag值。如果源服务器上的资源发生了更新，相应地，其ETag值也会发生变化。通过比较客户端和服务器上资源对应的ETag值，即可得知资源是否发生了更新。

缓存真的是性能优化的⼀把万能钥匙，⼩到 CPU Cache、 Page Cache、 Redis Cache，⼤到 HTTP 协议的缓存。

减少HTTP请求次数

减少HTTP的请求次数，可以降低网络拥堵程度，自然也就提升了HTTP性能，可以从3个方面入手：

• 减少重定向请求次数
• 合并请求
• 延迟发送请求

减少重定向请求次数

何为重定向请求？

服务器上的资源可能发生了迁移，原来的网站被封了，这时响应报文中会给予301/302重定向的状态码反馈，浏览器会根据响应报文中的Location字段自动向新的URL发出请求。

如果重定向请求越多，那么客户端就要多次发起 HTTP 请求，每⼀次的 HTTP 请求都得经过⽹络，这⽆疑会越降低⽹络性能。

如果我们在客户端和服务器之间设置一个代理服务器，重定向的⼯作交由代理服务器完成，就能减少 HTTP 请求次数了，如下图：

合并请求

如果把多个访问⼩⽂件的请求合并成⼀个⼤的请求，虽然传输的总资源还是⼀样，但是减少请求，也就意味着减少了重复发送的 HTTP 头部。

另外由于 HTTP/1.1 是请求响应模型，如果第⼀个发送的请求，未收到对应的响应，那么后续的请求就不会发送，于是为了防⽌单个请求的阻塞，所以⼀般浏览器会同时发起 5-6 个请求，每⼀个请求都是不同的 TCP 连接，那么如果合并了请求，也就会减少 TCP 连接的数量，因⽽省去了 TCP 握⼿和慢启动过程耗费的时间。

有的⽹⻚会含有很多⼩图⽚、⼩图标，有多少个⼩图⽚，客户端就要发起多少次请求。那么对于这些⼩图⽚，我们可以考虑使⽤ CSS Image Sprites 技术把它们合成⼀个⼤图⽚，这样浏览器就可以⽤⼀次请求获得⼀个⼤图⽚，然后再根据 CSS 数据把⼤图⽚切割成多张⼩图⽚。

除了将⼩图⽚合并成⼤图⽚的⽅式，还有服务端使⽤ webpack 等打包⼯具将 js、 css 等资源合并打包成⼤⽂件，也是能达到类似的效果。

可以看到， 合并请求的⽅式就是合并资源，以⼀个⼤资源的请求替换多个⼩资源的请求。

但是这样的合并请求会带来新的问题， 当⼤资源中的某⼀个⼩资源发⽣变化后，客户端必须重新下载整个完整的⼤资源⽂件，这显然带来了额外的⽹络消耗。

延迟发送请求

请求⽹⻚的时候，没必要把全部资源都获取到，⽽是只获取当前⽤户所看到的⻚⾯资源，当⽤户向下滑动⻚⾯的时候，再向服务器获取接下来的资源，这样就达到了延迟发送请求的效果。

减少HTTP响应的数据大小

对于 HTTP 的请求和响应，通常 HTTP 的响应的数据⼤⼩会⽐较⼤，也就是服务器返回的资源会⽐较⼤。

于是，我们可以考虑对响应的资源进⾏压缩，这样就可以减少响应的数据⼤⼩，从⽽提⾼⽹络传输的效率。

压缩的⽅式⼀般分为 2 种，分别是：

• 无损压缩
• 有损压缩

无损压缩

⽆损压缩是指资源经过压缩后，信息不被破坏，还能完全恢复到压缩前的原样，适合⽤在⽂本⽂件、程序可执⾏⽂、件、程序源代码。

gzip 就是⽐较常⻅的⽆损压缩。客户端⽀持的压缩算法，会在 HTTP 请求中通过头部中的 Accept-Encoding 字段告诉服务器：

Accept-Encoding：gzip, deflate, br

服务器收到后，会从中选择⼀个服务器⽀持的或者合适的压缩算法，然后使⽤此压缩算法对响应资源进⾏压缩，最后通过响应头部中的 content-encoding 字段告诉客户端该资源使⽤的压缩算法。

Content-Encoding: gzip

有损压缩

⽆损压缩相对的就是有损压缩，经过此⽅法压缩，解压的数据会与原始数据不同但是⾮常接近。

有损压缩主要将次要的数据舍弃，牺牲⼀些质量来减少数据量、提⾼压缩⽐，这种⽅法经常⽤于压缩多媒体数据，⽐如⾳频、视频、图⽚。

可以通过 HTTP 请求头部中的 Accept字段⾥的「 q 质量因⼦」，告诉服务器期望的资源质量。

Accept: audio/*; q=0.2, audio/basic

关于图⽚的压缩，⽬前压缩⽐较⾼的是 Google 推出的 WebP 格式，它与常⻅的 Png 格式图⽚的压缩⽐例对⽐如下图：

可以发现，相同图⽚质量下， WebP 格式的图⽚⼤⼩都⽐ Png 格式的图⽚⼩，所以对于⼤量图⽚的⽹站，可以考虑使⽤ WebP 格式的图⽚，这将⼤幅度提升⽹络传输的性能。

总结

这次主要是从三个方面去优化HTTP/1.1：

• 通过缓存技术避免向源服务器发送请求：客户端收到第⼀个请求的响应后，可以将其缓存在本地磁
  盘，下次请求的时候，如果缓存没过期，就直接读取本地缓存的响应数据。

• 减少HTTP请求的次数：

  • 使用代理服务器减少重定向请求次数。
  • 多个资源合并成一个资源，一个请求代替之前的多次请求。
  • 按需请求。只针对要显示的页面进行请求，不显示的不作请求。

• 减少HTTP响应数据的大小

  通过对响应报文的实体部分进行压缩，降低响应报文的体积大小，减轻报文传输对网络的压力，也是能提高响应的速度。