认真总结 HTTP常见面试题（持续更新）

这两天学习了一些HTTP相关的知识点，总结记录一下。

《好看的版本！！》

https://www.yuque.com/docs/share/6f16ec3a-9418-49a6-9cde-be445776f362?#

1. 在浏览器输入URL后敲下回车后发生了什么？

1.1 简单分析

1.2 详细分析

1.2.1 URL解析

首先，浏览器做的第一步就是解析 URL 得到里面的参数，将域名和需要请求的资源分离开来，从而了解需要请求的是哪个服务器，请求的是服务器上什么资源等等。

一个URL的结构解析如下：

1.2.2 DNS域名解析获取IP地址

然后，浏览器会根据你输入的URL地址是否被本地DNS缓存。

• 首先搜索浏览器的 DNS 缓存，缓存中维护着一张域名与 IP 地址的对应表；如果浏览器缓存了你想访问的URL地址，那就直接返回IP。
• 如果浏览器没有缓存你的URL地址，浏览器就会发起搜索操作系统的 DNS 缓存，如果找到，直接返回。

• 如果找不到，则操作系统将域名发送至本地域名服务器，本地域名服务器查询自己的 DNS 缓存，查找成功则返回结果（**注意： **主机和本地域名服务器 之间的查询方式是 递归查询）；
• 若本地域名服务器的 DNS 缓存没有命中，则本地域名服务器向上级域名服务器进行查询，通过以下方式进行迭代查询（注意：本 地域名服务器和其他域名服务器 之间的查询方式是 迭代查询 ，防止根域名服务器压力过大）：

• • • 首先本地域名服务器向根域名服务器发起请求，根域名服务器是最高层次的，它并不会直接指明这个域名对应的 IP 地址，而是返回顶级域名服务器的地址，也就是说给本地域名服务器指明一条道路，让他去这里寻找答案。
    • 本地域名服务器拿到这个顶级域名服务器的地址后，就向其发起请求，获取权限域名服务器的地址。

• • • 本地域名服务器根据权限域名服务器的地址向其发起请求，最终得到该域名对应的 IP 地址！！

• 本地域名服务器将得到的 IP 地址返回给操作系统，同时自己将 IP 地址缓存起来。
• 操作系统将 IP 地址返回给浏览器，同时自己也将 IP 地址缓存起来。

• 至此，浏览器就得到了域名对应的 IP 地址，并将 IP 地址缓存起来。

最终，获取到了域名对应的目标服务器IP地址。

需要注意的是，DNS 使用的是 UDP 协议，也就是说上面各种请求的转发，都是基于 UDP 这个无连接协议的。

1.2.3 建立TCP连接

第三步，在获取了目标服务器的IP地址之后，浏览器需要和目标服务器建立 TCP 连接，通过三次握手为浏览器和服务器之间建立可靠的连接，保证双方都具有可靠的接收和发送能力。

链接：https://www.yuque.com/blueheart/kxmiti/beoemo#It95p

1.2.4 浏览器发送请求

TCP 三次握手完成后，浏览器与目标服务器之间就建立了一个可靠的虚拟通道，于是浏览器就可以发送自己的 HTTP 请求了。

• 请求的内容包括：https://www.yuque.com/blueheart/kxmiti/beoemo#fxRk8

1.2.5 服务器响应请求

浏览器的 HTTP 请求报文通过 TCP 三次握手建立的连接通道被切分成若干报文段分别发送给服务器，服务器在收到这些报文段后，按照序号以原来的顺序重组 HTTP 请求报文。然后处理并返回一个 HTTP 响应。当然，HTTP 响应报文也要经过和 HTTP 请求报文一样的过程。

• 响应的内容包括：https://www.yuque.com/blueheart/kxmiti/beoemo#mLFnE

需要注意的是，HTTP 请求报文或者响应报文在 TCP 连接通道上进行传输的时候，由于这些报文比较大，为了更容易和准确可靠的传输，TCP 会将 HTTP 报文按序号分割成若干报文段 并加上 TCP 首部，分别进行传输。接收方在收到这些报文段后，按照序号以原来的顺序 重组 HTTP 报文 。

1.2.6 断开 TCP 连接

浏览器和服务器都不再需要发送数据后，四次挥手断开 TCP 连接。https://www.yuque.com/blueheart/kxmiti/beoemo#FYZg2

1.2.7 浏览器渲染页面

浏览器接收到服务器返回的数据包，根据浏览器的渲染机制对相应的数据进行渲染。

1. 首先会对资源进行解析：

• 查看响应头的信息，根据不同的指示做对应处理，比如重定向，存储cookie，解压gzip，缓存资源等等。
• 查看响应头的 Content-Type的值，根据不同的资源类型采用不同的解析方式。

2. 关于页面的渲染过程如下：

• 解析HTML，构建 DOM 树。
• 解析 CSS ，生成 CSS 规则树。

• 合并 DOM 树和 CSS 规则，生成 render 树。
• 布局 render 树（ Layout / reflow ），负责各元素尺寸、位置的计算。

• 绘制 render 树（ paint ），绘制页面像素信息。
• 浏览器会将各层的信息发送给 GPU，GPU 会将各层合成（ composite ），显示在屏幕上。

2.HTTP协议的发展历史

HTTP/0.9 – 单行协议

最早定义的HTTP版本是0.9，它只有一个命令GET ,没有HEADER等描述数据的信息，服务器发送完毕，就关闭TCP连接。这里注意TCP连接对应多个HTTP请求，一个HTTP请求一定是在某一个TCP连接里面发送的。

HTTP/1.0 – 构建可扩展性

然后是HTTP/1.0，增加了很多命令，增加了status code(状态码)和header(HTTP头),增加了对多字符集支持、多部分发送、权限、缓存等。状态码会在响应开始时发送，使浏览器能了解请求执行成功或失败，并相应调整行为（如更新或使用本地缓存）。引入了HTTP头的概念，无论是对于请求还是响应，允许传输元数据，使协议变得非常灵活，更具扩展性。在新HTTP头的帮助下，具备了传输除纯文本HTML文件以外其他类型文档的能力（Content-Type头）。

HTTP/1.1 – 标准化的协议

HTTP/1.1，在HTTP/1.0基础上增加了 持久连接 ****，原来是发送一个HTTP，就建立一个TCP连接，当发送端接收到以后，就关闭这个TCP连接，这样的成本是比较高的，而现在可以持久连接，不关闭，连接可以复用，节省了多次打开TCP连接加载网页文档资源的时间，性能有了很大提高；服务端增加了pipline(管线化技术)，允许在第一个应答被完全发送之前就发送第二个请求，以降低通信延迟。增加了host和其他一些命令, 能够使不同域名配置在同一个IP地址的服务器上。

HTTP/2 - 为了更优异的表现

1. HTTP/2是二进制协议而不是文本协议。不再可读，也不可无障碍的手动创建，抛弃了 ASCII 码，提升了解析效率。
2. 压缩了headers。由于 HTTP 1.1 经常会出现 User-Agent 、Cookie 、Accept 、Server 、Range 等字段可能会占用几百甚至几千字节，而 Body 却经常只有几十字节，所以导致头部偏重。HTTP 2.0 使用 HPACK 算法进行压缩。

3. 强化安全 ，由于安全已经成为重中之重，所以 HTTP 2.0 一般都跑在 HTTPS 上。
4. 允许服务器在客户端缓存中填充数据，通过一个叫服务器推送的机制 来提前请求。

5. 多路复用协议。并行的请求能在同一个链接中处理，移除了HTTP/1.x中顺序和阻塞的约束。

多路复用

3.HTTP与HTTPS 的区别

3.1 HTTP

HTTP 是一种 超文本传输协议(Hypertext Transfer Protocol)，HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范。 HTTP （ HyperText Transfer Protocol 主要内容分为三部分，超文本（Hypertext）、传输（Transfer）、协议（Protocol） 。

• 超文本就是不单单只是文本，它还可以传输图片、音频、视频，甚至点击文字或图片能够进行 超链接 的跳转。
• 上面这些概念可以统称为数据，传输就是数据需要经过一系列的物理介质从一个端系统传送到另外一个端系统的过程。通常我们把传输数据包的一方称为 请求方 ，把接到二进制数据包的一方称为 应答方 。

• 而协议指的就是是网络（包括互联网）中传递、管理信息的一些规范。如同人与人之间相互交流是需要遵循一定的规矩一样，计算机之间的相互通信需要共同遵守一定的规则，这些规则就称为协议，只不过是网络协议。

3.2 HTTPS

HTTPS 的全称是 Hypertext Transfer Protocol Secure ，从名称我们可以看出 HTTPS 要比 HTTP 多了 secure 安全性这个概念，实际上， HTTPS 并不是一个新的应用层协议，它其实就是 HTTP + TLS/SSL 协议组合而成，而安全性的保证正是 TLS/SSL 所做的工作。

也就是说，HTTPS 就是身披了一层 SSL 的 HTTP 。

HTTP 与 HPPTS

那么，HTTP 和 HTTPS 的主要区别是什么呢？

• 最简单的，HTTP 在地址栏上的协议是以 http://开头，而 HTTPS 在地址栏上的协议是以 https://开头。

http://www.google.com
https://www.google.com

• HTTP 是未经安全加密的协议，它的传输过程容易被攻击者监听、数据容易被窃取、发送方和接收方容易被伪造；而 HTTPS 是安全的协议，它通过 密钥交换算法 - 签名算法 - 对称加密算法 - 摘要算法 能够解决上面这些问题。

• HTTP 的默认端口是 80 ，而 HTTPS 的默认端口是 443 。

说到 HTTP ，不得不提的就是 TCP/IP 网络模型，一般是五层模型。如下图所示：

3.3 经典五层网络模型

五层网络模型

物理层 主要作用是定义物理设备如何传输数据：机器的硬件，网卡端口，网线等硬件设备相关的东西。

数据链路层 在通信的实体间建立数据链路连接，比如最基础的数据传输数据流，可以自己选择二进制或者ASCII码形式等。

网络层 为数据在结点之间传输创建逻辑链路，比如输入百度，网络层会为我们找到百度的网址，如何寻找到的过程就是网络层要做的事。

传(运)输层 ：向用户提供可靠的端到端（end-to-end）服务；传输层主要有两个协议，一个是TCP\IP协议，一个是UDP协议，在更多的情况下，我们使用的是TCP\IP协议，因为它是一个更可靠的一个协议，帮我们去传输数据。传输层向高层屏蔽了下层数据通信的细节（比如一个post请求，如何分片、分包如何发送使服务端很好接收到，这个规则由传输层实现）。

应用层 ： 为应用软件提供了很多服务，帮我们实现了HTTP协议，我们只要按照规则去使用HTTP协议；它构建于TCP协议之上；屏蔽了网络传输相关细节。

但是也可以分为四层，就是把 链路层和物理层 都表示为网络接口层。

四层网络模型

还有一种就是 OSI 七层网络模型，它就是在五层协议之上加了表示层和会话层。

七层网络模型

4. TCP的三次握手与四次挥手

4.1 TCP协议格式字段

TCP在OSI模型的第四层，TCP是没有IP信息的。应用程序将数据封装到TCP的Segment中，然后TCP的Segment会封装到IP的Packet中，然后再封装到以太网Ethernet的Frame中，传送给对端后，各层解析自己的协议，然后把数据交给应用程序处理。

• Sequence Number 是记录包的序号，用来解决包在网络中乱序的问题。
• Acknowledgement Number 就是 ACK ，用于确认已经收到了哪些包，用来解决不丢包的问题。

• Window 又叫 Advertised-Window，也就是著名的滑动窗口，用来解决流控的。
• TCP Flag 也就是包的类型，主要是用于操控 TCP 状态机的。

4.2 TCP 三次握手

TCP三次握手，其实就是TCP应用在发送数据前，通过TCP协议跟对端协商好连接信息，建立起TCP的连接关系。我们需要知道，TCP连接并非是在通信设备两端之间建立信号隧道，而本质上就是双方各自维护所需的状态信息，以达到TCP连接的效果。所以TCP状态机是TCP的核心内容，学些TCP就是要搞懂这些状态机。

• SYN ： 它的全称是 Synchronize Sequence Numbers，同步序列编号。是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立 TCP 连接时，首先会发送的一个信号。客户端在接受到 SYN 消息时，就会在自己的段内生成一个随机值 X 。
• SYN-ACK ： 服务器收到 SYN 后，打开客户端连接，发送一个 SYN-ACK 作为答复。确认号设置为比接收到的序列号多一个，即 X + 1，服务器为数据包选择的序列号是另一个随机数 Y 。

• ACK ： Acknowledge character ，确认字符，表示发来的数据已确认接收无误。最后，客户端将 ACK 发送给服务器。序列号被设置为所接收的确认值即 Y + 1 。

TCP 三次握手

• 第一次握手：建立连接时，客户端发送 SYN 包（SYN=1 ACK=0 seq = x），并进入 SYN_SENT 状态，等待服务器确认。
• 第二次握手：服务器收到 SYN 包，必须确认客户端的 SYN（ack = x + 1），同时服务器也要发送一个 SYN 包（seq = y），即 SYN+ACK 包（SYN=1 ACK=1 seq=y, ack=x+1），此时服务器进入 SYN_RCVD 状态。

• 第三次握手：客户端收到服务器的 SYN+ACK 包，向服务器发送确认包（ack=y+1），此时发送完毕，客户端进入 ESTABLISHED 状态。等服务器端收到客户端发送的 ACK 包后也进入 ESTABLISHED 状态，完成三次握手。

4.3 TCP 四次挥手

在连接终止阶段使用四次挥手，连接的每一端都会独立的终止。也就是应用程序不需要数据通信了，发起断开TCP连接。下面我们来描述一下这个过程。

• 第一次挥手。客户端发起 FIN 包（FIN = 1）,客户端进入 FIN_WAIT_1 状态。TCP 规定，即使 FIN 包不携带数据，也要消耗一个序号。
• 第二次挥手。服务器端收到 FIN 包，发出确认包 ACK（ack = u + 1），并带上自己的序号 seq=v，服务器端进入了 CLOSE_WAIT 状态。这个时候客户端已经没有数据要发送了，不过服务器端有数据发送的话，客户端依然需要接收。客户端接收到服务器端发送的 ACK 后，进入了 FIN_WAIT_2 状态。

• 第三次挥手。服务器端数据发送完毕后，向客户端发送 FIN 包（seq=w ack=u+1），半连接状态下服务器可能又发送了一些数据，假设发送 seq 为 w。服务器此时进入了 LAST_ACK 状态。
• 第四次挥手。客户端收到服务器的 FIN 包后，发出确认包（ACK=1，ack=w+1），此时客户端就进入了 TIME_WAIT 状态。注意此时TCP连接还没有释放，必须经过 2*MSL 后，才进入 CLOSED 状态。 而服务器端收到客户端的确认包 ACK 后就进入了 CLOSED 状态，可以看出服务器端结束 TCP 连接的时间要比客户端早一些。

4.4 TCP相关补充问题：

1. 为什么连接的时候是三次握手，关闭的时候是四次挥手？

其实在 TCP 握手的时候，服务端发送 SYN + ACK 的包是将一个 ACK 和一个 SYN 合并到一个包中，所以减少了一次包的发送。而因为 TCP 是全双工通信，在 客户端发送 FIN 包 后， 服务端可能还要发送数据 ，不能立即关闭服务器端到客户端的数据通道，所以也就不能将服务器端的 FIN 包与对客户端的 ACK 包合并发送，只能先确认 ACK，然后等待无需发送数据时再发送 FIN 包，所以四次挥手时必须是四次数据包的交互。

2. 为什么TIME_WAIT状态需要经过 2MSL 才能返回到CLOSE状态？

1. 确保最后一个确认报文能够到达。MSL 指的是最大的报文生存时间。在客户端发送对服务器端的 FIN 的确认包 ACK 后，这个 ACK 包是有可能不可达的，服务器端如果收不到 ACK 的话会重新发送 FIN 包。所以客户端发送 ACK 后需要留出 2xMSL 时间（ACK 到达服务器 + 服务器发送 FIN 重传包）等待确认服务器端确实收到了 ACK 包。也就是说客户端如果等待 2xMSL 时间也没有收到服务器端的重传包FIN，说明可以确认服务器已经收到客户端发送的 ACK。
2. 避免新旧连接混淆。 等待2MSL可以让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接请求不会出现旧的连接请求报文。

3. 三次握手的作用？

1. 确认双方的 接受能力、发送能力 是否正常。

1. 1. 第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
   2. 第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

1. 3. 第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。所以，只有三次握手才能确认双方的接受与发送能力是否正常。

2. 指定自己的初始化序列号，为后面的可靠传送做准备。
3. 如果是 https 协议的话，三次握手这个过程，还会进行数字证书的验证以及加密密钥的生成。

5. URL、URI 和 URN 区别

5.1 URI(Uniform Resource Identifier)-统一资源标志符

URI是用来唯一标识互联网上的信息资源。URI有两个主要的子集，即URL和URN。

URI语法 ： scheme:[//[user:password@]host[:port]][/]path[?query][#fragment]

Sample URI: foo://example.com:8848/over/there?name=zhleon#article

5.2 URL(Uniform Resource Locator)-统一资源定位符

URL是URI的一个子集。URL不过是网络上某个独特资源的地址，表明该独特网络资源的位置。用户是通过URL来浏览互联网的。如果我们点击任何应用程序中的任何超链接，它就会将我们重定向到相关的URL或可以在浏览器的地址栏中轻松输入的URL，并可以加载特定的资源。

*URL语法： *scheme://host:port/path?query-string#fragment-id

Sample URL: https://baidu.com/p/123456

• 协议：通常是 https 或 http，一种告诉浏览器或者设备如何访问资源的方法，当然还有其他的协议，如 ftp 、mailto 或者 file。
• 接下来是 😕/ 。

• 主机名：表示 IP 地址的注册名称（域名） 或 IP 地址，用于识别连接到网络的设备的数字标识符。
• 后面是可选的端口好，前面是冒号 ： 。

• 路径：可以引用文件系统路径，通常作为一个代码段使用。
• 参数：以问号开头的可选查询参数，其中多个参数用 & 连接

• hash：用于为页面上的标题提供快速链接，如锚点链接。

5.3 URN(Uniform Resource Name)-统一资源名称

URN 是一种具有静态名称的 Internet 资源，即使其数据被移动到另一个位置，它仍然有效。与 URL 如果内容移动就无法工作不同，URN 可以始终跟踪 Web 上某些数据的资源，从而解决经常发生的数据移动问题。

*URN语法： *scheme:NID: NSS

URN 的一个最好的例子是 ISBN 号，它被用来唯一地识别一本书。

*Sample URN: ***urn:ISSN:0167–6423

6. HTTP报文格式

HTTP报文分为：请求报文(request)+响应报文(response)

6.1 HTTP请求(request)报文格式

请求报文是由三个部分组成： 请求行+请求头+请求体

请求行：请求方法+URI(非URL，要请求资源的地址，一般放的是路由)+HTTP版本

6.2 HTTP响应(response)报文格式

响应报文是由三个部分组成： 状态行+响应头+响应体

请求行：HTTP版本+状态码+状态码描述

6.3 报文详细说明

	1.报文格式
		 request 报文
			<method> <request-URL> <version>
			<headers>
			<entity-body>
		response 报文
			<version> <status> <reason-phrase>
			<headers>
			<entity-body>
      
	2.method：请求方法，标明客户端希望服务器对资源执行的动作。
		GET ：从服务器获取一个资源
		HEAD ：只从服务器获取文档的响应首部
		POST ：向服务器输入数据，通常会再由网关程序继续处理
		PUT ：将请求的主体部分存储在服务器中，如上传文件
		DELETE ：请求删除服务器上指定的文档
		TRACE ：追踪请求到达服务器中间经过的代理服务器
		OPTIONS ：请求服务器返回对指定资源支持使用的请求方法
    
	3.version:
		HTTP/<major>.<minor>
    
	4.status:
		三位数字，标记请求处理过程中发生的情况。
			1xx ：100-101 信息提示
			2xx ：200-206 成功
			3xx ：300-305 重定向
			4xx ：400-415 错误类信息，客户端错误
			5xx ：500-505 错误类信息，服务器端错误
		常用状态码
			200：成功，请求数据通过响应报文的entity-body 部分发送;OK
			301：请求的URL 指向的资源已经被删除；但在响应报文中通过首部Location 指明了资源现在所处的新位置；Moved Permanently
			302：响应报文Location置 指明资源临时新位置 Moved Temporarily
			304：客户端发出了条件式请求，但服务器上的资源未曾发生改变，则通过响应此响应状态码通知客户端；Not Modified
			401：需要输入账号和密码认证方能访问资源；Unauthorized
			403：请求被禁止；Forbidden
			404：服务器无法找到客户端请求的资源；Not Found
			500：服务器内部错误；Internal Server Error
			501：
			502：代理服务器从后端服务器收到了一条伪响应，如无法连接到网关；Bad Gateway
			503：服务不可用，临时服务器维护或过载，服务器无法处理请求
			504：网关超时
      
	5.reason-phrase： 
		状态码所标记的状态的简要描述
	6.headers：每个请求或响应报文可包含任意个首部；每个首部都有首部名称，后面跟一个冒号，而后跟一个可选空格，接着是一个值。
	7.entity-body；请求时附加的数据或响应时附加的数据。

6.4 HTTP协议首部

	1.首部的分类：
		通用首部
		请求首部
		响应首部
		实体首部
		扩展首部
	2.通用首部：
		Date：报文的创建时间
		Connection：连接状态，如keep-alive(持久性连接), close(非持久性连接)。
				 - Connection决定当前事务（一次三次握手和四次挥手）完成后，是否会关闭网络连接。Connection 有两种。
		Via：显示报文经过的中间节点（代理，网关）
		Cache-Control：控制缓存，如缓存时长
		MIME-Version: 发送端使用的MIME
	3.请求首部：
		Accept：通知服务器自己可接受的媒体类型
		Accept-Charset： 客户端可接受的字符集
		Accept-Encoding：客户端可接受编码格式，如gzip。Accept-Encoding: gzip, deflate //请求头
		Accept-Language：客户端可 接受的语言
		Client-IP:  请求的客户端IP
		Host:  请求的服务器名称和端口号
		Referer：跳转至当前URI 的前一个URL
		User-Agent：客户端代理，浏览器版本
		3.1 条件式请求首部：
			Expect：允许客户端列出某请求所要求的服务器行为
			If-Modified-Since ：自从指定的时间之后，请求的资源是否发生过修改。大白话就是如果在 Last-Modified 之后更新了服务器资源，那么服务器会响应 200 ，如果在 Last-Modified 之后没有更新过资源，则返回 304 。
			If-Unmodified-Since ：与上面相反
			If-None-Match ：本地缓存中存储的文档的ETag 标签是否与服务器文档的Etag 不匹配。如果在 Last-Modified 之后更新了服务器资源，那么服务器会响应 200 ，如果在 Last-Modified 之后没有更新过资源，则返回 304 。
			If-Match ：与上面相反
		3.2 安全请求首部：
			Authorization：向服务器发送认证信息，如账号和密码
			Cookie：客户端向服务器发送cookie
			Cookie2：用于说明请求端支持的cookie 版本
		3.3 代理请求首部：
			Proxy-Authorization: 向代理服务器认证
	4.响应首部：
		信息性：
			Age ：从最初创建开始，响应持续时长
			Server ：服务器程序软件名称和版本
		协商首部：某资源有多种表示方法时使用
			Accept-Ranges ：服务器可接受的请求范围类型
			Vary ：服务器查看的其它首部列表
		安全响应首部：
			Set-Cookie ：向客户端设置cookie	
			Set-Cookie2:  以上面相似
			WWW-Authenticate：来自服务器对客户端的质询列表
	5.实体首部：
		Allow:  列出对此资源实体可使用的请求方法
		Location ：告诉客户端真正的实体位于何处
		Content-Encoding: 对主体执行的编码。常见的内容编码有这几种：gzip 、compress 、deflate 、identity ，这个属性可以应用在请求报文和响应报文中。
				 - Content-Encoding: gzip  //响应头
		Content-Language: 理解主体时最适合的语言
		Content-Length:  主体的长度
		Content-Location:  实体真正所处位置
		Content-Type ：主体的对象类型，如text
		缓存相关：
			ETag ：实体的扩展标签
			Expires ：实体的过期时间
			Last-Modified ：最后一次修改的时间

参考文献：

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP
https://www.linuxblogs.cn/articles/15061700.html
https://www.niewenjun.com/2020/05/19/408/ji-suan-ji-wang-luo/http-chang-jian-mian-shi-ti/#toc-heading-9
https://enlear.academy/uri-vs-url-vs-urn-51b8167cafad
https://blog.nowcoder.net/n/be862c8c52344a5ead723b3966e2577f?from=nowcoder_improve
http://www.3a4a5a.com/article/398509.html
https://github.com/febobo/web-interview/issues/150
https://mp.weixin.qq.com/s/pb2Qk0dEsowFnPPUIXV4Qg
https://zhuanlan.zhihu.com/p/80551769