HTTP：网络资源是怎么加载和表述的？

爱被打了一巴掌 2024-04-19 12:35 51阅读 0赞

**“** 阅读本文需要 **3.6** 分钟**”**

![640?wx\_fmt=jpeg][640_wx_fmt_jpeg]

作者 l 闹闹

来源 l 闹闹吃鱼（ID：UpUp005）

网络协议之所以是叫做协议，而不是规定，就是因为传输什么内容，前后端都得商量着来

客户端需要什么，需要告诉服务端；服务端发什么给客户端，要看客户端能不能看懂

那他们又是怎么商量的呢？以前学习过HTTP协议的同学肯定知道，是根据请求行来进行协商的

而**HTTP协议中又是怎么定义协商内容的呢？协商好之后又该怎么表述呢？**

今天就来聊聊上面的这些个问题，希望我的文字能让你把这些内容弄清楚

—

**HTTP内容协商**

在HTTP中，内容协商分为2种，分别是**主动式内容协商**与**响应式内容协商**

之前没接触过的童鞋，听到这些名词肯定是稀里糊涂的，别着急，咱们一个一个的来

#### 1、主动式内容协商 ####

千言万语不如一张图来的形象，先上张主动式内容协商的过程图

起点是`客户端(Client)`，先看看图，看不懂没关系，有个印象就好了。不然接下来我说的内容，对你来说可能就是天书了

![640?wx\_fmt=png][640_wx_fmt_png]

这图猛的一看挺复杂的，花里胡哨一大堆。其实过程非常简单

其实就是客户端发起了一个HTTP1.1的`GET`请求资源后，服务端返回资源的一个情况

发起GET请求后，通过`Accept`、`Accept-Language`、`Accept-Encoding`这三个请求头，客户端告诉服务器：我现在要一个`text/`类型的文件，并且我只接受这个文件语言为`en（英语）`，我这里能看得懂的编码格式只有`br、gzip`格式，`q(权重)`都是`0.8`，你（服务器）有哪种编码格式随便给我都行

服务器看到我们的要求，根据我们的要求以及请求的URL，就到这个URL里定位的资源，寻找是否有符合我们要求的资源

我们请求的URL在服务器是存在对应文件的，所以告诉我们状态码是200，并且把`URLe`对应的资源给到了我们（客户端）

告诉了我们这是个`text/html`文件，语言是`en`，编码方式为`br`，均是符合我们上述提出的要求

我们（客户端）拿到符合要求的文件，也就可以正常解析数据了

#### 2、响应式内容协商 ####

来，咱们再来看看什么是响应式内容协商，还是老规矩，先上一张图，韵个味

![640?wx\_fmt=png][640_wx_fmt_png 1]

看懂了之前的主动式内容协商，我相信这张图你也能看的七七八八。因为区别并不大

区别就在于`Client（客户端）`请求了之后，居然给我们一个300（重定向），而不是我们之前的200（OK）

居然还要我们再去请求一次，才把`URLe`的内容给我们

其实这就是响应式与主动式的区别所在了

在响应式内容协商中，客户端发送请求，服务器端无法抉择要返回什么内容，所以就把客户端请求的URL对应的资源列表全部返回，然后由客户端自行抉择。客户端进行选择后再去访问指定资源

而因为RFC中没有明确指出客户端应该依据怎样的规则去对资源进行抉择，所以各大浏览器的实现方式都不一致

又因为各大浏览器实现方式都不统一，相对来说，用到响应式内容协商的地方就很少了

#### 3、质量因子 ####

上面有些内容大家如果没有学过HTTP协议，会发现有些东西看不太明白，比如`q`是什么玩意？

前面为了便于你们的理解，我在最开始出现的时候，写了个注释--权重

它本身的含义是表示**内容的质量**或者**可接受因子的优先级**

内容的质量，就比如说图片展示的质量：

若只需要展示供用户快速浏览的缩略图，我们可以对图片进行大范围的压缩，这样图片质量会很低，质量因子也很低

若为医学用图，需要展示高清图，我们不能丢失图片细节，图片内容质量高，质量因子自然也就很高了

可接受因子的优先级，最常用的就是字符编码与语言的优先级展示

这次就拿个实例来说，这样感触也更深一点

Accept-Language:zh-cn,zh;q=0.8,en-us;q=0.7,en;q=0.6

zh-cn：简体中文，zh：中文，这两个质量因子都是0.8，但是优先展示简体中文，如果服务器中没有简体中文的资源，则寻找中文资源，若还是没有该资源，则接着就是美式英语（en-us），最后再是展示英语（en）

总结来说：**质量因子越大，意味着资源权重越高，越优先展示。质量因子一致，则排序在前面的先展示**

常见的协商要素除了质量因子之外，还有以下几个请求头

*  字符编码Accept-Charset:ISO8859-1,UTF-8;q=0.7,\*;q=0.7
 *  内容编码`Accept-Encoding:gzip,br`
 *  表述语言
    
    Accept-Language:zh-cn,zh;q=0.8,en-us;q=0.7,en;q=0.6

看懂前面的内容了，这三个应该还算很好理解的吧

—

**资源表述**

我们要的资源也跟服务器要到了，那我们该怎么**表述**这个资源呢？

注意我的用词哦，是表述资源，不是解析资源

换句话说，就是资源的自我介绍，告诉别人它是属于哪一种编码类型，内容又是如何编码的，对应的是什么地方的语言

主要是通过以下三个头字段来进行资源的表述

*  媒体类型编码
    
     *  Content-type:text/html;charset=utf-8

内容编码

*  Content-encoding:gzip

语言

*  Content-Languague:zh;en

是不是有种似曾相识的感觉？没错，上面我们在告诉服务端我们需要什么文件时，请求头上有三个字段与这三哥们特别相似

没印象的可以往上面翻一翻，基本上就是`Content`与`Accept`一个单词的区别

**这也体现出了HTTP协议的特性，可读性高与低门槛**

`Content`与`Accept`就像是相亲中的一男一女，女方(Accept)提出要求，作为媒婆的服务器，就把符合条件的男方(Content)拿出来，男方把自己的简历拿出来(Content-type等资源表述请求头)，俩人对上眼了，自然也就过上了幸福生活(200 OK)

还记得十年前的上网环境么？经常有小网站出现乱码，其实就是因为媒体类型编码格式不对导致

内容编码就是告诉我们客户端/服务器所支持的编码类型，假如客户端不支持gzip的编码，服务器发给客户端gzip资源，客户端拿到这东西，也看不懂这是啥玩意

最后一个`Content-Language`我想大家都应该熟悉的，毕竟混迹互联网这么长时间，你就没上过国外的小网站？

别想多了，我说的是apple.com之流，**截图以证清白！**

![640?wx\_fmt=png][640_wx_fmt_png 2]

![640?wx\_fmt=gif][640_wx_fmt_gif]

**EN**

[640_wx_fmt_jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/1c8bed2316a54f30ab8645f10655062e.png
[640_wx_fmt_png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/d737b263c40f4ed9bc7cbf956431958c.png
[640_wx_fmt_png 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/0d5e946c91c34530b57d15e6eeecfc6f.png
[640_wx_fmt_png 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/152eb43601c348fb832682001f7c74ff.png
[640_wx_fmt_gif]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/18/9021fdf68257404f982f3032fe3a52e4.gif