目录

一、相关面试题

1. HTTP 与 HTTPS 有哪些区别？

2. HTTPS 的工作原理？（https 是怎么建立连接的）

（1）ClientHello

（2）SeverHello

（3）客户端回应

（4）服务器的最后回应

综述

3. HTTP1.0 和 HTTP1.1的区别？

（1）长连接

（2）缓存

（3）管道化

（4）增加 Host 字段

（5）状态码

（6）带宽优化

4. HTTP2.0 与 HTTP1.1 的区别？

（1）二进制分帧

（2）多路复用 （MultiPlexing）

（3）首部压缩

（4）服务端推送（server push）

补充：详述 HTTP2.0 改进点

① 头部压缩

② 二进制格式

③ 并发传输

④ 服务器推送

---

一、相关面试题

1. HTTP 与 HTTPS 有哪些区别？

• HTTP 是 超文本传输协议，信息是 明文传输，存在 安全风险的 问题。HTTPS 则解决 HTTP 不安全的 缺陷，在 TCP 和 HTTP 网络层之间 加入了 SSL/TLS 安全协议，使得 报文 能够 加密传输。
• HTTP 连接建立 相对简单，TCP 三次握手 之后便可 进行 HTTP 的 报文传输。而 HTTPS 在TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入 加密报文 传输。
• 两者的 默认端口 不一样，HTTP 默认端口号是 80，HTTPS 默认端口号是 443。
• HTTPS 协议需要 向 CA（证书权威机构）申请数 字证书，来 保证服务器的 身份是 可信的。

2. HTTPS 的工作原理？（https 是怎么建立连接的）

SSL/TLS 协议基本流程：

• 客户端 向服务器 索要并 验证服务器的 公钥。
• 双方协商生产「会话秘钥」。
• 双方采用「会话秘钥」进行加密通信。

        前两步也就是 SSL/TLS 的建立过程，也就是 TLS 握手阶段。TLS的「握手阶段」涉及 四次通信，使用 不同的 密钥交换算法，TLS 握手流程也会不一样的，现在常用的 密钥交换算法 有两种：RSA 算法 和 ECDHE 算法。下图为 TLS 握手过程：

TLS 协议建立的详细流程：

（1）ClientHello

        首先，由 客户端 向服务器 发起加密通信 请求，也就是 ClientHello 请求。在这一步，客户端 主要向 服务器发送 以下信息：

• 客户端 支持的 TLS 协议版本，如 TLS 1.2 版本。
• 客户端 生产的 随机数（Client Random ），后面 用于生成「会话秘钥」条件之一。
• 客户端 支持的 密码套件列表，如 RSA 加密算法。

（2）SeverHello

        服务器 收到客户端 请求后，向 客户端 发出响应，也就是 SeverHello。服务器 回应的内容 有如下内容：

• 确认 TLS 协议版本，如果 浏览器 不支持，则 关闭 加密通信。
• 服务器生产的 随机数（Server Random ），也是 后面 用于 生产「会话秘钥」条件之一。
• 确认的 密码套件列表，如 RSA 加密算法。
• 服务器的 数字证书。

（3）客户端回应

        客户端 收到 服务器的 回应之后，首先 通过 浏览器 或者 操作系统中的 CA 公钥，确认 服务器的数字证书的 真实性。如果 证书 没有问题，客户端会 从数字证书中 取出 服务器的 公钥，然后 使用它 加密报文，向 服务器发送如下信息：

• 一个随机数（ pre-master key ）。该 随机数会 被服务器 公钥加密。
• 加密通信算法 改变通知，表示 随后的信息 都将用「会话秘钥」加密通信。
• 客户端 握手结束 通知，表示 客户端的 握手阶段 已经结束。这一项 同时把 之前 所有内容的 发生的数据 做个摘要，用来 供服务端 校验。

        上面 第一项的 随机数是 整个握手阶段的 第三个随机数，会发给 服务端，所以 这个随机数 客户端 和 服务端 都是一样的。服务器和客户端 有了这 三个随机数（Client Random、Server Random、pre-master key），接着就用 双方协商的 加密算法，各自生成 本次 通信的「会话秘钥」。

（4）服务器的最后回应

        服务器收到 客户端的 第三个随机数（pre-master key）之后，通过 协商的 加密算法，计算出 本次通信的「会话秘钥」。然后，向客户端发送最后的信息：

• 加密通信算法 改变通知，表示 随后的 信息都 将用「会话秘钥」加密通信。
• 服务器 握手结束 通知，表示 服务器的 握手阶段 已经结束。这一项 同时 把之前 所有内容的 发生的数据 做个摘要，用来 供客户端 校验。

        至此，整个 TLS 的握手阶段 全部结束。接下来，客户端 与 服务器 进入加密通信，就 完全是 使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

综述

• 客户端发送连接请求：当 客户端 想要与 服务器 建立 HTTPS 连接时，它会 发送一个 连接请求 到 服务器 的 443 端口，表明 它想要 使用 HTTPS 进行 通信。
• 服务器响应：服务器 收到连接请求 后，会 发送一个 CA 数字证书 给客户端。这个 证书 包含了 服务器的 公钥、证书的 颁发者信息 以及 其他相关信息。
• 客户端验证证书：客户端 接收到 服务器 发送的 数字证书 后，会 验证证书的 合法性。这个过程 包括 验证证书的 签名、证书 是否过期、是否 与 预期域名匹配 等。
• 生成会话密钥：如果 证书验证 成功，客户端 会 生成一个 用于该 连接的 随机 会话密钥（对称 密钥）。这个 密钥将用于 加密 通信数据。
• 用公钥加密会话密钥：客户端 使用 服务器的 公钥，将 生成的 会话密钥 进行加密，并将 加密后的 会话密钥 发送给 服务器。
• 服务器解密会话密钥：服务器 使用 自己的 私钥 对 客户端 发送的 加密 会话密钥 进行解密，获得 会话密钥。
• 建立安全通信：从 此时开始，客户端 和 服务器 都有了 相同的 会话密钥，他们 使用 对称加密算法（如 AES）来 加密 和 解密 通信数据，保证了 通信的 隐私性 和 完整性。

3. HTTP1.0 和 HTTP1.1的区别？

（1）长连接

• HTTP1.1 支持 长连接，每一个 TCP 连接上可以 传送 多个 HTTP 请求和响应，默认 开启 Connection:Keep-ALive。
• HTTP1.0 默认为 短连接，每次 请求 都需要 建立一个 TCP 连接。

（2）缓存

• HTTP1.0 主要使用 If-Modified-Since/Expires 来做为 缓存 判断的 标准。
• HTTP1.1 则 引入了 更多的 缓存控制 策略 例如 Entity tag / If-None-Match 等 更多 可供选择的 缓存头来 控制 缓存策略。

（3）管道化

• 基于 HTTP1.1 的 长连接，使得 请求 管线化 成为可能。管线化 使得 请求能够 “并行” 传输，但是响应 必须按照 请求 发出的顺序 依次返回，性能 在一定 程度上 得到了改善。（管道网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间）

（4）增加 Host 字段

• 使得 一个服务器 能够 用来 创建 多个 web 站点。

（5）状态码

• 新增了 24 个 错误状态 响应码。

（6）带宽优化

• HTTP1.0 中，存在 一些 浪费带宽的 现象，例如 客户端 只是 需要 某个对象的 一部分，而 服务器却 将整个 对象 送过来了，并且 不支持 断点 续传功能。
• HTTP1.1 则在 请求头 引入了 range 头域，它 允许 只请求 资源的 某个部分，即 返回码 是 206（Partial Content）。

4. HTTP2.0 与 HTTP1.1 的区别？

（1）二进制分帧

• 在 应用层（HTTP/2.0） 和 传输层（TCP or UDP） 之间增加一个二进制分帧层，从而 突破 HTTP1.1 的 性能限制，改进 传输性能，实现 低延迟 和 高吞吐量。

（2）多路复用 （MultiPlexing）

• 允许 同时 通过 单一的 HTTP/2 连接 发起 多重的请求-响应消息，这个 强大的 功能则是 基于 “二进制分帧” 的特性。

（3）首部压缩

• HTTP1.1 不支持 header 数据的压缩， HTTP/2.0 使用 HPACK 算法对 header 的数据 进行压缩，这样 数据体积 小了，在 网络上 传输就会 更快。高效的 压缩算法 可以 很大的压缩 header，减少发送包的 数量从而 降低延迟。

（4）服务端推送（server push）

• 在 HTTP/2 中，服务器 可以 对 客户端的 一个请求 发送 多个响应，即 服务器 可以 额外的 向客户端 推送资源，而 无需 客户端 明确的 请求。

---

补充：详述 HTTP2.0 改进点

① 头部压缩

        HTTP/2 会 压缩 头（Header）如果你 同时 发出多个请求，他们的 头 是一样的 或是 相似的，那么，协议 会 帮你 消除 重复的 部分。

        这就是 所谓的 HPACK 算法：在 客户端 和 服务器 同时 维护一张 头信息表，所有字段 都会 存入 这个表，生成 一个 索引号，以后就 不发送 同样字段了，只发送 索引号，这样就 提高速度了。

② 二进制格式

        HTTP/2 不再像 HTTP/1.1 里的 纯文本形式的 报文，而是 全面 采用了 二进制 格式，头信息 和 数据体 都是 二进制，并且 统称为 帧 （frame）：头信息帧（Headers Frame） 和 数据帧 （Data Frame）。

        因为 计算机 只懂二进制，那么 收到报文后，无需 再将 明文的报文 转成 二进制，而是 直接 解析二进制报文，这 增加了 数据传输的 效率。

③ 并发传输

        HTTP/1.1 的实现是 基于 请求-响应模型 的。同一个连接中，HTTP 完成一个 事务（请求 与 响应），才能 处理 下一个事务，也就是说 在 发出 请求等待响应 的过程中，是 没办法 做其他 事情的，如果 响应 迟迟不来，那么 后续的 请求是 无法发送的，也 造成了 队头阻塞的 问题。

        HTTP/2 引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接。

        从上图可以看到，1 个 TCP 连接包含多个 Stream，Stream 里可以包含 1 个 或 多个 Message，Message 对应 HTTP/1 中的 请求或响应，由 HTTP 头部 和 包体构成。Message 里 包含 一条 或 者多个 Frame，Frame 是 HTTP/2 最小单位，以 二进制 压缩格式 存放 HTTP/1 中的内容（头部和包体）。

        针对 不同的 HTTP 请求 用 独一无二 的 Stream ID 来区分，接收端 可以 通过 Stream ID 有序 组装成 HTTP 消息，不同 Stream 的帧是 可以 乱序 发送的，因此 可以 并发 不同的 Stream，也就是HTTP/2 可以 并行交错地 发送请求 和 响应。

        如下图，服务端 并行交错 地 发送了 两个响应：Stream 1 和 Stream 3，这两个 Stream 都是 跑在一个 TCP 连接上，客户端 收到后，会 根据 相同的 Stream ID 有序 组装成 HTTP 消息。

④ 服务器推送

        HTTP/2 还 在一定程度上 改善了 传统的「请求- 应答」工作模式，服务端 不再是 被动地 响应，可以 主动 向客户端 发送消息。

        客户端 和 服务器 双方 都可以 建立 Stream， Stream ID 也是 有区别的，客户端 建立的 Stream 必须是 奇数号，而 服务器 建立的 Stream 必须是 偶数号。

        如下图，Stream 1 是 客户端 向 服务端 请求的资源，属于 客户端 建立的 Stream，所以该 Stream 的 ID 是奇数（数字 1）；Stream 2 和 4 都是 服务端 主动向 客户端 推送的 资源，属于 服务端 建立的 Stream，所以 这两个 Stream 的 ID 是 偶数（数字 2 和 4）。

        再比如，客户端 通过 HTTP/1.1 请求 从 服务器 那获 取到了 HTML 文件，而 HTML 可能 还需要 依赖 CSS 来 渲染页面，这时 客户端 还要 再发起 获取 CSS 文件的 请求，需要 两次 消息往返，如下图 左边部分：

---

        如 上图 右边部分，在 HTTP/2 中，客户端在 访问 HTML 时，服务器 可以 直接主动推送 CSS 文件，減少了 消息传递的 次数。