小林计网笔记-3.2HTTP/1.1如何优化？

3.2HTTP/1.1如何优化？

可以从3种优化思路来优化HTTP/1.1协议：

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

如何避免发送HTTP请求？

对于一些具有重复性的HTTP请求，比如每次请求得到的数据都是一样的，我们可以把这对请求-响应的数据都缓存在本地，那么下次就直接读取本地的数据，不必再通过网络获取服务器的响应了，这样的话HTTP/1.1的性能可以得到提升。
避免发送HTTP请求的方法就是通过缓存技术，HTTP设计者早在之前就考虑到了这点，因此HTTP协议的头部有不少是针对缓存的字段。
客户端会把第一次请求以及响应的数据保存在本地磁盘上，其中将请求的URL作为key，而响应作为value，两者形成映射关系。
当后续发起相同的请求时，就可以先在本地磁盘上通过key查找到响应的value，也就是响应，如果找到了，就直接从本地读取该响应。读取本地磁盘的速度肯定比网络请求快得多：

服务器在发送HTTP响应时，会估算一个过期的时间，并把这个信息放到响应头部中，这样客户端在查看响应头部的信息时，一旦发现缓存的响应是过期的，则会重新发送网络请求，
如果客户端从第一次请求得到的响应头部中发现该响应已经过期，客户端重新发送请求，但是服务器上的资源并没有变更，如何处理？
只需要客户端在重新发送请求时，在请求的Etag头部带上第一次请求的响应头部中的摘要，这个摘要是唯一标识响应的资源，当服务器收到请求后，会将本地资源的摘要与请求中的摘要做个比较。
如果不同，那么说明客户端的缓存已经没有价值，服务器在响应中带上最新的资源，
如果相同，说明客户端缓存还是可以继续使用的，那么服务器仅返回不含有包体的304 not Modified响应，告诉客户端仍然有效，这样就可以减少响应资源在网络中的传输延时。

如何减少HTTP请求次数

从3个方面减少HTTP请求次数：

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

减少重定向请求次数

重定向请求
服务器上的一个资源可能由于迁移、维护等原因从url1移至url2后，客户端不知情，它还是继续请求url1，这时服务器不能粗暴地返回错误，而是通过302响应码和Location头部，告诉客户端该资源已经迁移至url2，于是客户端需要再发送url2请求以获取服务器地资源。
如果重定向请求越多，那么客户端就要多次发起HTTP请求，每一次地HTTP请求都得经过网络，降低网络性能。
服务器这一方往往不知有一台服务器，比如源服务器上一级是代理服务器，然后代理服务器才与客户端通信，这时客户端重定向就会导致客户端与代理服务器之间需要两次消息传递。

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

当代理服务器知晓重定向规则后，可以进一步减少消息传递次数。

除了302重定向响应码，还有其他一些重定向地响应码。

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

合并请求

如果把多个访问小文件地请求合并成一个大的请求，虽然传输的总资源还是一样，但是减少请求，意味着减少重复发送的HTTP头部。
由于HTTP/1.1是请求响应模型，如果第一个发送的请求，未收到对应的响应，那么后续的请求就不会发送（HTTP/1.1管道模式默认不使用的），为了防止单个请求的阻塞，所以一般浏览器会同时发起5-6个请求，每个请求都是不同的TCP连接，如果合并了请求，就会减少TCP连接的数量，省去TCP握手和慢启动过程耗费的时间。
有的网页含有很多小图片、小图标，有多少个小图片，客户端就要发起多少次请求，那么对于这些小图片，我们可以考虑使用CSS Image Sprites技术把它们合并成一个大图片，这样浏览器就可以用一次请求获得一个大图片，然后再根据CSS数据把大图片切割成多种小图片。

这种方式就是通过将多个小图片合并成一个大图片来减少HTTP请求的次数，以减少HTTP请求的次数，从而减少网络的开销。
除了将小图片合并成大图片的方式，还有服务端使用webpack等打包工具将js、css等资源合并打包成大文件。
还可以将图片的二进制数据用base64编码后，以URL的形式嵌入到HTML文件，跟随HTML文件一并发送。这样客户端收到HTML后，就可以直接解码出数据，然后显示图片，就不用再发去图片相关的请求，减少请求的次数。

合并请求的方式就是合并资源，以一个大资源的请求替换多个小资源的请求。
带来新的问题：当大资源中的某一个小资源发生变化后，客户端必须重新下载整个完整的大资源文件，带来额外的网络消耗。

延迟发送请求

一般HTML里会含有很多HTTP的URL，当前不需要的资源，我们没必要也获取过来，于是通过按需获取的方式，来减少第一时间的HTTP请求次数。
请求网页的时候，没必要把全部资源都获取到，而是只获取当前用户所看到的页面资源，当用户向下滑动页面的时候，再向服务器获取接下来的资源，达到延迟发送请求的效果。

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

对于HTTP的请求和响应，通常HTTP的响应的数据大小会比较大，也就是服务器返回的资源会比较大。考虑对响应的资源进行压缩，减少响应的数据大小，提高网络传输的效率。
两种压缩方式：

• 无损压缩
• 有损压缩

无损压缩

无损压缩是指资源经过压缩后，信息不被破坏，还能完全恢复到压缩前的原样，适合用在文本文件、程序可执行文件、程序源代码。
首先，我们针对代码的语法规则进行压缩，因为通常代码文件都有很多换行符或者空格，这些是为了帮助程序员更多地阅读，但是机器执行时并不需要这些符，把这些多余的符号都去除掉。
接下来，就是无损压缩，需要对原始资源建立统计模型，利用这个统计模型，将常出现的数据用较短的二进制比特序列表示，将不常出现的数据用较长的二进制比特序列表示，生成二进制比特序列一般是霍夫曼编码算法。
gzip就是比较常见的无损压缩。客户端支持的压缩算法，会在HTTP请求中通过头部中的Accept-Encoding字段告诉服务器：

Accept-Encoding:gzip,deflate,br

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

Content-Encoding:gzip

gzip的压缩效率相比Google推出的Brotli算法还是差点意思，br，如果可以，服务器应该选择压缩效率更高的br压缩算法

有损压缩

有损压缩，经过此方法压缩，解压的数据会与原始数据不同但是非常接近。
有损压缩主要将次要的数据丢弃，牺牲一些质量来减少数据量、提高压缩比，这种方法常用于压缩多媒体数据，比如音频、视频、图片。
可以通过HTTP请求头部的Accept字段里的q质量因子，告诉服务器期望的资源质量。

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

关于图片的压缩，目前压缩比较高的是Google推出的WebP格式，他与常见的png格式图片压缩比例如下：

相同图片质量下，WebP格式的图片大小都比Png格式的图片小，对于大量图片的网站。可以考虑使用WebP格式的图片，大幅度提升网络传输的性能。
关于音视频的压缩，音视频主要是动态的，每个帧都是由时序的关系，通常时间连续的帧之间的变化都是很小的。
比如，一个在看书的视频，画面通常只有人物的手和书桌上的书是会有变化的，而其他地方通常都是静态的，于是只需要在一个静态的关键帧，使用增量数据来表达后续的帧，减少很多数据，提高网络传输性能。对于视频常见的编码有H264、H265等，音频常见的编码格式有AAC、AC3。

总结

3个方面优化HTTP/1.1协议：

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

1、将原本由客户端处理的重定向请求，交由代理服务器处理，减少重定向请求次数
2、将多个小资源合并成一个大资源再传输，减少HTTP请求次数以及头部重复传输，减少TCP连接数量，省去TCP握手和慢启动的网络消耗
3、按需访问资源，只访问当前用户看得到、用得到的资源，当客户往下滑动，再访问接下来的资源，一次达到延迟请求，减少同一时间的HTTP请求次数。

• 通过压缩响应资源，降低传输资源的大小，提高传输效率，选择更优秀的压缩算法。