这样理解 HTTP，面试再也不用慌了~

深藏阁楼爱情的钟 2021-07-26 17:48 299阅读 0赞

![1803089889.png][]

开源Linux

长按二维码加关注~

![undefined][]

![format_png][]

上一篇：[SSH只能用于远程Linux主机？][SSH_Linux]

## 1 HTTP ##

HTTP 协议是个无状态协议，不会保存状态。

## 2 Post 和 Get 的区别 ##

先引入副作用和幂等的概念。

副作用指对服务器上的资源做改变，搜索是无副作用的，注册是副作用的。

幂等指发送 M 和 N 次请求（两者不相同且都大于 1），服务器上资源的状态一致，比如注册 10 个和 11 个帐号是不幂等的，对文章进行更改 10 次和 11 次是幂等的。

在规范的应用场景上说，Get 多用于无副作用，幂等的场景，例如搜索关键字。Post 多用于副作用，不幂等的场景，例如注册。

在技术上说：

*  Get 请求能缓存，Post 不能
 *  Post 相对 Get 安全一点点，因为Get 请求都包含在 URL 里，且会被浏览器保存历史记录，Post 不会，但是在抓包的情况下都是一样的。
 *  Post 可以通过 request body来传输比 Get 更多的数据，Get 没有这个技术
 *  URL有长度限制，会影响 Get 请求，但是这个长度限制是浏览器规定的，不是 RFC 规定的
 *  Post 支持更多的编码类型且不对数据类型限制

## 3 常见状态码 ##

**2XX 成功**

*  200 OK，表示从客户端发来的请求在服务器端被正确处理
 *  204 No content，表示请求成功，但响应报文不含实体的主体部分
 *  205 Reset Content，表示请求成功，但响应报文不含实体的主体部分，但是与 204 响应不同在于要求请求方重置内容
 *  206 Partial Content，进行范围请求

**3XX 重定向**

*  301 moved permanently，永久性重定向，表示资源已被分配了新的 URL
 *  302 found，临时性重定向，表示资源临时被分配了新的 URL
 *  303 see other，表示资源存在着另一个 URL，应使用 GET 方法获取资源
 *  304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况
 *  307 temporary redirect，临时重定向，和302含义类似，但是期望客户端保持请求方法不变向新的地址发出请求

**4XX 客户端错误**

*  400 bad request，请求报文存在语法错误
 *  401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息
 *  403 forbidden，表示对请求资源的访问被服务器拒绝
 *  404 not found，表示在服务器上没有找到请求的资源

**5XX 服务器错误**

*  500 internal sever error，表示服务器端在执行请求时发生了错误
 *  501 Not Implemented，表示服务器不支持当前请求所需要的某个功能
 *  503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求

## 4 HTTP 首部 ##

![format_png 1][]

## 5 HTTPS ##

HTTPS 还是通过了 HTTP 来传输信息，但是信息通过 TLS 协议进行了加密。

## 6 TLS ##

TLS 协议位于传输层之上，应用层之下。首次进行 TLS 协议传输需要两个 RTT ，接下来可以通过 Session Resumption 减少到一个 RTT。

在 TLS 中使用了两种加密技术，分别为：对称加密和非对称加密。

**对称加密：**

对称加密就是两边拥有相同的秘钥，两边都知道如何将密文加密解密。

**非对称加密：**

有公钥私钥之分，公钥所有人都可以知道，可以将数据用公钥加密，但是将数据解密必须使用私钥解密，私钥只有分发公钥的一方才知道。

TLS 握手过程如下图：

![format_png 2][]

1.  客户端发送一个随机值，需要的协议和加密方式
2.  服务端收到客户端的随机值，自己也产生一个随机值，并根据客户端需求的协议和加密方式来使用对应的方式，发送自己的证书（如果需要验证客户端证书需要说明）
3.  客户端收到服务端的证书并验证是否有效，验证通过会再生成一个随机值，通过服务端证书的公钥去加密这个随机值并发送给服务端，如果服务端需要验证客户端证书的话会附带证书
4.  服务端收到加密过的随机值并使用私钥解密获得第三个随机值，这时候两端都拥有了三个随机值，可以通过这三个随机值按照之前约定的加密方式生成密钥，接下来的通信就可以通过该密钥来加密解密

通过以上步骤可知，在 TLS 握手阶段，两端使用非对称加密的方式来通      信，但是因为非对称加密损耗的性能比对称加密大，所以在正式传输数据时，两端使用对称加密的方式通信。

PS：以上说明的都是 TLS 1.2 协议的握手情况，在 1.3 协议中，首次建立连接只需要一个 RTT，后面恢复连接不需要 RTT 了。

## 7 HTTP 2.0 ##

HTTP 2.0 相比于 HTTP 1.X，可以说是大幅度提高了 web 的性能。

在 HTTP 1.X 中，为了性能考虑，我们会引入雪碧图、将小图内联、使用多个域名等等的方式。这一切都是因为浏览器限制了同一个域名下的请求数量，当页面中需要请求很多资源的时候，队头阻塞（Head of line blocking）会导致在达到最大请求数量时，剩余的资源需要等待其他资源请求完成后才能发起请求。

![format_png 3][]

在 HTTP 1.X 中，因为队头阻塞的原因，你会发现请求是这样的

![format_png 4][]

在 HTTP 2.0 中，因为引入了多路复用，你会发现请求是这样的

![format_png 5][]

## 8 二进制传输 ##

HTTP 2.0 中所有加强性能的核心点在于此。在之前的 HTTP 版本中，我们是通过文本的方式传输数据。在 HTTP 2.0 中引入了新的编码机制，所有传输的数据都会被分割，并采用二进制格式编码。

![format_png 6][]

## 9 多路复用 ##

在 HTTP 2.0 中，有两个非常重要的概念，分别是帧（frame）和流（stream）。

帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。

多路复用，就是在一个 TCP 连接中可以存在多条流。换句话说，也就是可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。通过这个技术，可以避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能。

![format_png 7][]

## 10 Header 压缩 ##

在 HTTP 1.X 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千的字节。

在 HTTP 2.0 中，使用了 HPACK 压缩格式对传输的 header 进行编码，减少了 header 的大小。并在两端维护了索引表，用于记录出现过的 header ，后面在传输过程中就可以传输已经记录过的 header 的键名，对端收到数据后就可以通过键名找到对应的值。

## 11 服务端 Push ##

在 HTTP 2.0 中，服务端可以在客户端某个请求后，主动推送其他资源。

可以想象以下情况，某些资源客户端是一定会请求的，这时就可以采取服务端 push 的技术，提前给客户端推送必要的资源，这样就可以相对减少一点延迟时间。当然在浏览器兼容的情况下你也可以使用 prefetch 。

## 12 QUIC ##

这是一个谷歌出品的基于 UDP 实现的同为传输层的协议，目标很远大，希望替代 TCP 协议。

*  该协议支持多路复用，虽然 HTTP 2.0 也支持多路复用，但是下层仍是 TCP，因为 TCP 的重传机制，只要一个包丢失就得判断丢失包并且重传，导致发生队头阻塞的问题，但是 UDP 没有这个机制
 *  实现了自己的加密协议，通过类似 TCP 的 TFO 机制可以实现 0-RTT，当然 TLS 1.3 已经实现了 0-RTT 了
 *  支持重传和纠错机制（向前恢复），在只丢失一个包的情况下不需要重传，使用纠错机制恢复丢失的包
 *   *  纠错机制：通过异或的方式，算出发出去的数据的异或值并单独发出一个包，服务端在发现有一个包丢失的情况下，通过其他数据包和异或值包算出丢失包
     *  在丢失两个包或以上的情况就使用重传机制，因为算不出来了

## 13 DNS ##

DNS 的作用就是通过域名查询到具体的 IP。

因为 IP 存在数字和英文的组合（IPv6），很不利于人类记忆，所以就出现了域名。你可以把域名看成是某个 IP 的别名，DNS 就是去查询这个别名的真正名称是什么。

在 TCP 握手之前就已经进行了 DNS 查询，这个查询是操作系统自己做的。当你在浏览器中访问 www.google.com 时，会进行以下操作：

1.  操作系统会首先在本地缓存中查询
2.  没有的话会去系统配置的 DNS 服务器中查询
3.  如果这时候还没得话，会直接去 DNS 根服务器查询，这一步查询会找出负责 com 这个一级域名的服务器
4.  然后去该服务器查询 google 这个二级域名
5.  接下来三级域名的查询其实是我们配置的，你可以给 www 这个域名配置一个 IP，然后还可以给别的三级域名配置一个 IP

以上介绍的是 DNS 迭代查询，还有种是递归查询，区别就是前者是由客户端去做请求，后者是由系统配置的 DNS 服务器做请求，得到结果后将数据返回给客户端。

PS：DNS 是基于 UDP 做的查询。

## 14 从输入 URL 到页面加载完成的过程 ##

这是一个很经典的面试题，在这题中可以将本文讲的内容都串联起来。

1.  首先做 DNS 查询，如果这一步做了智能 DNS 解析的话，会提供访问速度最快的 IP 地址回来
2.  接下来是 TCP 握手，应用层会下发数据给传输层，这里 TCP 协议会指明两端的端口号，然后下发给网络层。网络层中的 IP 协议会确定 IP 地址，并且指示了数据传输中如何跳转路由器。然后包会再被封装到数据链路层的数据帧结构中，最后就是物理层面的传输了
3.  TCP 握手结束后会进行 TLS 握手，然后就开始正式的传输数据
4.  数据在进入服务端之前，可能还会先经过负责负载均衡的服务器，它的作用就是将请求合理的分发到多台服务器上，这时假设服务端会响应一个 HTML 文件
5.  首先浏览器会判断状态码是什么，如果是 200 那就继续解析，如果 400 或 500 的话就会报错，如果 300 的话会进行重定向，这里会有个重定向计数器，避免过多次的重定向，超过次数也会报错
6.  浏览器开始解析文件，如果是 gzip 格式的话会先解压一下，然后通过文件的编码格式知道该如何去解码文件
7.  文件解码成功后会正式开始渲染流程，先会根据 HTML 构建 DOM 树，有 CSS 的话会去构建 CSSOM 树。如果遇到 script 标签的话，会判断是否存在 `async` 或者 `defer` ，前者会并行进行下载并执行 JS，后者会先下载文件，然后等待 HTML 解析完成后顺序执行，如果以上都没有，就会阻塞住渲染流程直到 JS 执行完毕。遇到文件下载的会去下载文件，这里如果使用 HTTP 2.0 协议的话会极大的提高多图的下载效率。
8.  初始的 HTML 被完全加载和解析后会触发 DOMContentLoaded 事件
9.  CSSOM 树和 DOM 树构建完成后会开始生成 Render 树，这一步就是确定页面元素的布局、样式等等诸多方面的东西
10. 在生成 Render 树的过程中，浏览器就开始调用 GPU 绘制，合成图层，将内容显示在屏幕上了

来源：公众号运维军团

- End -
    关注「开源Linux」加星标，提升IT技能
    好文章，分享、点赞、在看三连哦❤️↓↓↓

[1803089889.png]: /images/20210726/9979840b120f4914ae055a084351f41b.png
[undefined]: /images/20210726/aae286dc1d45441f858e89bb4f88ba34.png
[format_png]: /images/20210726/5871cd1a30274a77a82f7fd19bf70a6a.png
[SSH_Linux]: http://mp.weixin.qq.com/s?__biz=MzI3NzQ4MTE4Mw%3D%3D&chksm=eb673144dc10b85256f58931be15872309c560dbfae3adea92819a7c574a31977956ead1fb17&idx=1&mid=2247492340&scene=21&sn=e0716a583f9dc479bc03bc514f86c5ed#wechat_redirect
[format_png 1]: /images/20210726/f124ab41a088422bb86c2c8c4f4633c8.png
[format_png 2]: /images/20210726/a1a98b34cce24b2fb5c02f93942dfdae.png
[format_png 3]: /images/20210726/2c595f60e68e4eb2b9cb5d07428fdc33.png
[format_png 4]: /images/20210726/49cb52f125354022ad286fca3265a36f.png
[format_png 5]: /images/20210726/b27fbdf70ce943d1882ede36b2238bc7.png
[format_png 6]: /images/20210726/bb923e7f79734a7e877834a7ea6f0d91.png
[format_png 7]: /images/20210726/038f390cc9d8410b816c6199345fd974.png