目录
一、相关面试题
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 文件,減少了 消息传递的 次数。