计算机网络|用白话讲（HTTP/1.1 如何优化（【图解】））网络|https|计算机网络|网络协议

文章目录

一、如何避免发送HTTP请求？
二、如何减少HTTP请求次数
- - 1. 减少重定向请求次数
  - 2. 合并请求
  - 延迟发送请求
三、如何减少 HTTP 响应的数据大小？
- - 无损压缩
  - 有损压缩
四、总结

问你?句：「你知道 HTTP/1.1 该如何优化吗？」
我想你第?时间想到的是，使? KeepAlive 将 HTTP/1.1 从短连接改成?链接。
这个确实是?个优化的?段，它是从底层的传输层这??向??的，通过减少 TCP 连接建?和断开的次数，来减少了?络传输的延迟，从?提? HTTP/1.1 协议的传输效率。
但其实还可以从其他?向来优化 HTTP/1.1 协议，?如有如下 3 种优化思路：

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

下?，就针对这三种思路具体看看有哪些优化?法。

文章图片

一、如何避免发送HTTP请求？这个思路你看到是不是觉得很奇怪，不发送 HTTP 请求，那还客户端还怎么和服务器交互数据？你这不是耍流氓嘛？
冷静冷静，你说的没错，客户端当然要向服务器发送请求的。
但是，对于?些具有重复性的 HTTP 请求，?如每次请求得到的数据都?样的，我们可以把这对「请求-响应」的数据都缓存在本地，那么下次就直接读取本地的数据，不必在通过?络获取服务器的响应了，这样的话 HTTP/1.1
的性能肯定?眼可?的提升。
所以，避免发送 HTTP 请求的?法就是通过缓存技术，HTTP 设计者早在之前就考虑到了这点，因此 HTTP 协议的头部有不少是针对缓存的字段。
那缓存是如何做到的呢？
客户端会把第?次请求以及响应的数据保存在本地磁盘上，其中将请求的 URL 作为 key，?响应作为 value，两者形成映射关系。
这样当后续发起相同的请求时，就可以先在本地磁盘上通过 key 查到对应的 value，也就是响应，如果找到了，就直接从本地读取该响应。毋庸置疑，读取本次磁盘的速度肯定?网络请求快得多，如下图：

文章图片

聪明的你可能想到了，万?缓存的响应不是最新的，?客户端并不知情，那么该怎么办呢？
【计算机网络|用白话讲（HTTP/1.1 如何优化（【图解】））】放?，这个问题 HTTP 设计者早已考虑到。
所以，服务器在发送 HTTP 响应时，会估算?个过期的时间，并把这个信息放到响应头部中，这样客户端在查看响应头部的信息时，?旦发现缓存的响应是过期的，则就会重新发送?络请求。
如果客户端从第?次请求得到的响应头部中发现该响应过期了，客户端重新发送请求，假设服务器上的资源并没有变更，还是?样?，那么你觉得还要在服务器的响应带上这个资源吗？
很显然不带的话，可以提? HTTP 协议的性能，那具体如何做到呢？
只需要客户端在重新发送请求时，在请求的 Etag 头部带上第?次请求的响应头部中的摘要，这个摘要是唯?标识响应的资源，当服务器收到请求后，会将本地资源的摘要与请求中的摘要做个?较。
如果不同，那么说明客户端的缓存已经没有价值，服务器在响应中带上最新的资源。
如果相同，说明客户端的缓存还是可以继续使?的，那么服务器仅返回不含有包体的 304 Not Modified 响应，告诉客户端仍然有效，这样就可以减少响应资源在?络中传输的延时，如下图：

文章图片

缓存真的是性能优化的?把万能钥匙，?到 CPU Cache、Page Cache、Redis Cache，?到 HTTP 协议的缓存。
二、如何减少HTTP请求次数减少 HTTP 请求次数?然也就提升了 HTTP 性能，可以从这 3 个????：

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

1. 减少重定向请求次数
我们先来看看什么是重定向请求？
服务器上的?个资源可能由于迁移、维护等原因从 url1 移? url2 后，而客户端不知情，它还是继续请求 url1，这时服务器不能粗暴地返回错误，?是通过302响应码和 Location 头部，告诉客户端该资源已经迁移? url2
了，于是客户端需要再发送 url2 请求以获得服务器的资源。
那么，如果重定向请求越多，那么客户端就要多次发起 HTTP 请求，每?次的 HTTP 请求都得经过?络，这?疑会越降低?络性能。
另外，服务端这??往往不只有?台服务器，比如源服务器上?级是代理服务器，然后代理服务器才与客户端通信，这时客户端重定向就会导致客户端与代理服务器之间需要 2 次消息传递，如下图：

文章图片

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

文章图片

?且当代理服务器知晓了重定向规则后，可以进?步减少消息传递次数，如下图：

文章图片

除了 302 重定向响应码，还有其他?些重定向的响应码，你可以从下图看到：

文章图片

其中，301和 308响应码是告诉客户端可以将重定向响应缓存到本地磁盘，之后客户端就?动? url2 替代 url1访问服务器的资源。
2. 合并请求
如果把多个访问小文件的请求合并成?个?的请求，虽然传输的总资源还是?样，但是减少请求，也就意味着减少重复发送的 HTTP 头部。
另外由于 HTTP/1.1 是请求响应模型，如果第?个发送的请求，未收到对应的响应，那么后续的请求就不会发送，于是为了防止单个请求的阻塞，所以?般浏览器会同时发起 5-6 个请求，每?个请求都是不同的 TCP 连接，那么如果合并了请求，也就会减少 TCP 连接的数量，因?省去了 TCP 握?和慢启动过程耗费的时间。
接下来，具体看看合并请求的几种?式。
有的网页会含有很多小图片、小图标，有多少个小图片，客户端就要发起多少次请求。那么对于这些?图?，我们可以考虑使? CSS Image Sprites技术把它们合成?个大图片，这样浏览器就可以??次请求获得?个大图片，
然后再根据 CSS 数据把大图片切割成多张?图?。

文章图片

这种方式就是

通过将多个小图片合并成?个大图片来减少 HTTP 请求的次数，以减少 HTTP 请求的次数，从?减少?络的开销。

除了将小图片合并成大图片的?式，还有服务端使? webpack 等打包?具将 js、css 等资源合并打包成大文件，也是能达到类似的效果。
另外，还可以将图片的?进制数据用base64编码后，以 URL 的形式潜?到 HTML ?件，跟随 HTML ?件?并发送.
src="data:image/png; base64,iVBORw0KGgoAAAANSUhEUgAAAPoAAAFKCAIAAAC7M9WrAAAACXBIWXMAA …
/>
这样客户端收到 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 质量因?」，告诉服务器期望的资源质量。

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

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

可以发现，相同图片质量下，WebP 格式的图片大小都比 Png 格式的图片小，所以对于大量图片的?站，可以考虑使用 WebP 格式的图片，这将?幅度提升?络传输的性能。
关于?视频的压缩，?视频主要是动态的，每个帧都有时序的关系，通常时间连续的帧之间的变化是很?的。
比如，?个在看书的视频，画?通常只有?物的?和书桌上的书是会有变化的，?其他地?通常都是静态的，于是只需要在?个静态的关键帧，使?增量数据来表达后续的帧，这样便减少了很多数据，提?了?络传输的性能。对于视频常?的编码格式有 H264、H265 等，?频常见的编码格式有AAC、AC3。
四、总结这次主要从 3 个方面介绍了优化 HTTP/1.1 协议的思路。
第?个思路是，通过缓存技术来避免发送 HTTP 请求。客户端收到第?个请求的响应后，可以将其缓存在本地磁盘，下次请求的时候，如果缓存没过期，就直接读取本地缓存的响应数据。如果缓存过期，客户端发送请求的时候带上响应数据的摘要，服务器?对后发现资源没有变化，就发出不带包体的 304 响应，告诉客户端缓存的响应仍然有效。
第?个思路是，减少 HTTP 请求的次数，有以下的?法：