【HTTP】HTTP/1.1如何优化？

摘要：我们可以从三个方面对HTTP/1.1协议进行优化，第一个是尽量避免发送HTTP请求，其次是在需要发送HTTP请求时，考虑如何减少请求次数，最后是减少服务处的HTTP响应的数据大小。

如何避免发送HTTP请求？

对于一些具有重复性的HTTP请求，比如每次请求得到的数据都是一样的，我们的可以把这对 请求-响应的数据都缓存在本地，那么下次就直接读取本地的数据，不必在通过网络获取服务器的响应了，这样的话HTTP/1.1的性能会得到较大的提升。

所以，避免发送HTTP请求的方法就是通过缓存技术，HTTP设计者早在之前就考虑到了这点，因此HTTP协议的头部有不少是针对缓存的字段。

那缓存是如何做到的呢？

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

这样当后续发起相同的请求时，就可以现在本地磁盘上通过key查到对应的vale，也就是响应，如果找到了，就直接从本地读取该响应。毋庸置疑，读取本地磁盘的速度肯定比网络请求快得多。

如果缓存的响应不是最新的怎么办？

服务器在发送HTTP响应时，会估算一个过期的时间，并把这个信念放到响应头部中，这样客户端在查看响应头部的信息时，一旦发现缓存的响应时过期的，则就很会重新发送网络请求。

如果客户端第一次请求得到的响应头中发现该响应过期了，客户端重新发送请求，假设服务器上的资源并没有变更，那么还需要在服务器的响应带上这个资源么？

如果不带怎么做呢？

只需要客户端在重新发送请求时，在请求的Etag头部带上第一次请求的响应头部中的摘要，这个摘要是唯一标识响应的资源，当服务器收到请求后，会将本地资源的摘要与请求中的摘要做个对比。

如果不同，那么说明客户端的缓存已经没有价值，服务器在响应中带上最新的资源。

如果相同，说明客户端的缓存还是可以继续使用的，那么服务器靳返回不含有包体的304 Not Modified响应，告诉客户端仍然有效，这样就可以减少响应资源在网络中传输的延时。

如何减少HTTP请求次数？

减少HTTP请求次数自然也就提升了HTTP性能，可以从这3个方面入手：

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

减少重定向请求次数

我们先来看看什么是重定向请求？

服务器上的一个资源可能由于迁移、维护等原因从url1移至url2后，而客户端不知情，他还是继续请求url1,这是服务器不能粗暴地返回错误，而是通过302响应码和Location头部，告诉客户端该资源已经迁移至url2了，于是客户端需要在发送url2请求以获取服务器的资源。

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

另外，服务端这一方往往不只有一台服务器，比如源服务器上一级是代理服务器，然后代理服务器才与客户端通信，这是客户端重定向就会导致客户端与代理服务器之间须要次消息传递。

如果重定向的工作交由代理服务器完成，就能减少HTTP请求次数了。

301和308响应码是告诉客户端可以将重定向响应缓存到本地磁盘，之后客户端就自动用url2替代url1访问服务器的资源。

合并请求

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

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

接下来，具体看看合并请求的几种方式。

有的网页会含有很多小图片，小图标，有多少个小图片，客户端就要发起多少次请求，那么对于这些小图片，women可以考虑使用CSS Image Sprites技术把它们合成一个大图片，这样浏览器就快出用一次请求获得一个大图片，然后在根据CSS数据把大图片切割成多张小图片。

这种方式就是通过将多个小图片合并成一个大图片来减少HTTP请求的次数，以减少HTTP请求的次数，从而减少网络的开销。

除了将小图片合并成大图片的方式，还有服务端使用webpack等打包工具将js/css等资源合并打包成大文件，也是能达到类似的效果。

另外，还可以将图片的二进制数据用base6e编码后，以URL的形式嵌入到HTML文件，跟随HTML文件一并发送。这样，客户端收到HTML后，就可以直接解码出数据，然后直接显示图片，就不在发起图片相关的请求，这样边减少了请求的次数。

可以看到，合并请求的方式就是合并资源，以一个大资源的请求替换多个小资源的请求。

但是这样的合并请求会带来新的问题，当大资源的某一个小资源发生变化后，客户端必须重新下载整个完整的大资源文件，这显然带来了额外的网络消耗。

延迟发送请求

不要一口气吃撑大胖子，一般HTML里会含有很多HTTP的url，当前不需要的资源，我们没必要也获取过来，于是可以通过按需获取的方式，来减少第一时间HTTP请求次数。

请求网页的时候，没必要把全部资源都获取到，而是只获取当前用户所看到的页面资源，当用户向下滑动页面的时候，再向服务器获取接下来的资源，这样就大袋了延迟发送请求的效果。

如何减少HTTP响应的数据大小？

对于HTTP的请求和响应，通常HTTP的响应的数据大小会比较大，也就是服务器返回的自然会比较大。于是，我们可以考虑对响应的资源进行压缩，这样就可以减少响应的数据大小，从而提高网络传输的效率。

压缩的方式一般分为2种，分别是：

• 无损压缩；
• 有损压缩

无损压缩

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

首先，我们针对代码的语法规则进行压缩，因为通常代码文件都有很多换行符或者空格，这些是为了帮助程序员刚好点阅读，但是机器执行时不需要这些符号，把这些多余的符号给去除掉。

接下来，就是无损压缩了，需要对原始资源建立统计模型，利用这个统计模型，将常出现的数据用较短的二进制比特序列表示，将不常出现的数据用较长的二进制比特序列表示【霍夫曼编码】。

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

Accept-Encoding:gzip,deflate,br

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

content-encoding:gzip

gzip的压缩效率相比Google推出的Brotli算法还是差一点，也就是上文中的br，所以如果可以，服务器应该选择压缩效率更高的br压缩算法。

有损压缩

与无损压缩相对的是有损压缩，经过此方法压缩，解压的数据会与原始梳不通但是非常接近。

有损压缩主要将次要的数据舍弃，牺牲一些质量来减少数据量、提高压缩比，这种方法经常用于压缩多媒体数据，比如音频、视频、图片、

可以通过HTTP请求头部中的Accept字段里的【q质量因子】，告诉服务器期望的资源质量。

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

关于图片的压缩，目前压缩比较高的是Google推出的是WebP格式。图片质量基本相同，但大小变小。

关于音视频的压缩，音视频主要是动态的，每个帧都有时序的关系，通常时间连续的帧之间的变化是很小的。 比如，一个在看书的视频，画面通常只有人物的手和书桌上的书是会有变化的，而其他地方通常都是静态的，于是只需要在一个静态的关键帧，使用增量数据来表达后续的帧，这样便减少了很多数据，提高了网络传输的性能。对于视频常见的编码格式有H264/H265等，音频常见的编码格式有AAC、AC3.

总结

这次主要从3个方面介绍了优化HTTP/1.1协议的思路。

第一个思路是，通过缓存技术来避免发送HTTP请求。客户端收到第一个请求的响应后，可以将其缓存在本地磁盘，下次请求的时候，如果缓存没过期，就直接读取本地缓存的响应数据。如果缓存过期，客户端发送请求的时候带上响应数据的摘要，服务器比对后发现资源没有变化，就发出不带包体的304响应，告诉客户端缓存的响应数据仍然有效。

第二个思路是，减少HTTP请求的次数，有以下的方法：

1.将原本有客户端处理的重定向请求，交给代理服务器处理，这样可以减少重定向请求的次数；

2.将多个小资源合并成一个大资源在传输，能够减少HTTP请求次数以及头部的重复传输再来减少TCP连接数量，进而省去TCP握手和慢启动的网络消耗。

3.按需访问资源，只访问当前用户看得到、用得到的资源，当客户往下滑动，在访问接下来的资源，一次达到延迟请求，也就减少了统一时间的HTTP请求次数。

第三思路是，通过压缩响应资源，降低传输资源的大小，从而提高传输效率，所以应当选择更优秀的压缩算法。

不关怎么优化HTTP/1.1协议都是有限的，不然也不会出现HTTP/2和HTTP/3协议。