---

title: 《网络协议》06. HTTP 补充 · HTTPS · SSL/TLS
date: 2022-10-06 18:09:55
updated: 2023-11-15 07:53:52
categories: 学习记录：网络协议
excerpt: HTTP/1.1 协议的不足、HTTP/2、HTTP/3、HTTP 协议的安全问题、SPDY、HTTPS、SSL/TLS、OpenSSL。
comments: false
tags:
top_image: /images/backimg/SunsetClimbing.png

---

---

网络协议从入门到底层原理。

1：HTTP/1.1 协议的不足

• 同一时间，一个连接只能对应一个请求
  针对同一个域名，大多数浏览器允许同时最多 6 个并发连接

• 只允许客户端主动发起请求
  一个请求只能对应一个响应

• 同一个会话的多次请求中，头信息会被重复传输
  通常会给每个传输增加 500~800 字节的开销
  如果使用 Cookie，增加的开销有时会达到上千字节

2：HTTP/2

HTTP/2，于 2015 年 5 月以 RFC 7540 正式发表

• 根据 W3Techs 的数据，截至 2019 年 6 月，全球有 36.5% 的网站支持了 HTTP/2

下列两个网站可以进行 HTTP/1.1 和 HTTP/2 速度对比

• http://www.http2demo.io/
• https://http2.akamai.com/demo

HTTP/2 在底层传输做了很多的改进和优化，但在语意上完全与 HTTP/1.1 兼容

• 比如请求方法（如 GET、POST）、Status Code、各种 Headers 等都没有改变
• 因此，要想升级到 HTTP/2，开发者不需要修改任何代码，只需要升级服务器配置、升级浏览器

2.1：HTTP/2 特性

2.1.1：二进制格式

HTTP/2 采用二进制格式传输数据，而非 HTTP/1.1 的文本格式。

二进制格式在协议的解析和优化扩展上带来更多的优势和可能。

一些基本概念：

• 数据流：已建立的连接内的双向字节流，可以承载一条或多条消息。
  所有通信都在一个 TCP 连接上完成，此连接可以承载任意数量的双向数据流。

• 消息：与逻辑 HTTP 请求或响应消息对应，由一系列帧组成。

• 帧：HTTP/2 通信的最小单位，每个帧都包含帧头（会标识出当前帧所属的数据流）
  来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装

2.1.2：多路复用

多路复用（Multiplexing），客户端和服务器可以将 HTTP 消息分解为互不依赖的帧，然后交错发送，最后再在另一端把它们重新组装起来

• 并行交错地发送多个请求，请求之间互不影响
• 并行交错地发送多个响应，响应之间互不干扰
• 使用一个连接并行发送多个请求和响应

不必再为绕过 HTTP/1.1 限制而做很多工作。比如精灵图（image sprites）、合并 CSS/JS、内嵌 CSS/JS/Base64 图片、域名分片等。

精灵图（image sprites），也叫做 CSS Sprites，将多张小图合并成一张大图。最后通过 CSS 结合小图的位置、尺寸进行精准定位。

2.1.3：优先级

• HTTP/2 标准允许每个数据流都有一个关联的权重和依赖关系
  可以向每个数据流分配一个介于 1 至 256 之间的整数
  每个数据流与其他数据流之间可以存在显式依赖关系

• 客户端可以构建和传递 “ 优先级树 ”，表明它倾向于如何接收响应

• 服务器可以使用此信息通过控制 CPU、内存和其他资源的分配设定数据流处理的优先级
  在资源数据可用之后，确保将高优先级响应以最优方式传输至客户端

示例：

2.1.4：头部压缩

HTTP/2 使用 HPACK 压缩请求头和响应头，可以极大减少头部开销，进而提高性能。

早期版本的 HTTP/2 和 SPDY 使用 zlib 压缩请求头和响应头，可以将所传输头数据的大小减小 85% ~ 88%。
但在 2012 年夏天被攻击，导致会话劫持。
后被更安全的 HPACK 取代。

2.1.5：服务器推送

服务器推送（Server Push）：服务器可以对一个客户端请求发送多个响应。

除了对最初请求的响应外，服务器还可以向客户端推送额外资源，而无需客户端额外明确地请求。

2.2：HTTP/2 的问题

2.2.1：队头阻塞

队头阻塞（head of line blocking）。

2.2.2：握手延迟

RTT（Round Trip Time）：往返时延，可以简单理解为通信一来一回的时间。

3：HTTP/3

Google 觉得 HTTP/2 仍然不够快，于是就有了 HTTP/3。

HTTP/3 由 Google 开发，弃用 TCP 协议，改为使用基于 UDP 协议的 QUIC 协议实现。

• QUIC（Quick UDP Internet Connections，快速 UDP 网络连接），由 Google 在 2013 年实现
• 于 2018 年从 HTTP-over-QUIC 改为 HTTP/3

思考：

HTTP/3 基于 UDP，如何保证可靠传输？

• 由 QUIC 来保证

为何 Google 不开发一个新的不同于 TCP、UDP 的传输层协议？

• 目前世界上的网络设备基本只认TCP、UDP
• 如果要修改传输层，意味着操作系统的内核也要修改
• 另外，由 IETF 标准化的许多 TCP 新特性都因缺乏广泛支持而没有得到广泛的部署或使用，因此，要想开发并应用一个新的传输层协议，是极其困难的一件事情

3.1：HTTP/3 特性

3.1.1：连接迁移

TCP 基于 4 要素：源 IP、源端口、目标 IP、目标端口。

• 切换网络时至少会有一个要素发生变化，导致连接发生变化
• 当连接发生变化时，如果还使用原来的 TCP 连接，则会导致连接失败，就得等原来的连接超时后重新建立连接
• 所以有时发现切换到一个新网络时，即使新网络状况良好，但内容还是需要加载很久
• 即使当检测到网络变化时立刻建立新的 TCP 连接，还是需要几百毫秒的时间

QUIC 的连接不受 4 要素的影响，当 4 要素发生变化时，原连接依然维持。

• QUIC 连接不以 4 要素作为标识，而是使用一组 Connection ID（连接ID）来标识一个连接
• 即使 IP 或者端口发生变化，只要 Connection ID 没有变化，那么连接依然可以维持

例如：
当设备连接到 Wi-Fi 时，将进行中的下载从蜂窝网络连接转移到更快速的 Wi-Fi 连接。
当 Wi-Fi 连接不再可用时，将连接转移到蜂窝网络连接。

3.1.2：向前纠错

目前还没有成为标准，以后是否会成为标准也不确定。

HTTP/3 的向前纠错，丢包以后可以根据其他包推测出这个包的数据（只适合丢失少量数据）。

如果是之前的基于 TPC 协议，丢包以后会重传。

3.2：HTTP/3 的问题

操作系统内核、CPU 负载。

• Linux 内核的 UDP 部分没有像 TCP 那样的优化，因为传统上没有使用 UDP 进行如此高速的信息传输
• TCP 和 TLS 有硬件加速，而这对于 UDP 很罕见，对于 QUIC 则基本不存在

据 Google 和 Facebook 称，与基于 TLS 的 HTTP/2 相比，它们大规模部署的 QUIC 需要近 2 倍的 CPU 使用量

随着时间的推移，相信这个问题会逐步得到改善

4：HTTP 协议的安全问题

HTTP 协议默认是采取明文传输的，因此会有很大的安全隐患。

常见的提高安全性的方法是：对通信内容进行加密后，再进行传输。

常见的加密方式：

• 不可逆
  单向散列函数：MD5、SHA 等
• 可逆
  对称加密：DES、3DES、AES 等
  非对称加密：RSA 等
• 其它
  混合密码系统
  数字签名
  证书

encrypt：加密
decrypt：解密
plaintext：明文
ciphertext：密文

为了便于学习，设计 4 个虚拟人物：

• Alice、Bob：互相通信
• Eve：窃听者
• Mallory：主动攻击者

如何防止被窃听：

4.1：SPDY

SPDY（speedy 的缩写），是基于 TCP 的应用层协议，它强制要求使用 SSL/TLS。

2009 年 11 月，Google 宣布将 SPDY 作为提高网络速度的内部项目。

SPDY 与 HTTP 的关系：

• SPDY 并不用于取代 HTTP，它只是修改了 HTTP 请求与响应的传输方式
• 只需增加一个 SPDY 层，现有的所有服务端应用均不用做任何修改
• SPDY 可以看做是 HTTP/2 的前身

5：HTTPS

HTTPS（HyperText Transfer Protocol Secure，超文本传输安全协议）

• 也称为 HTTP over TLS、HTTP over SSL、HTTP Secure
• 由网景公司于 1994 年首次提出
• HTTPS 的默认端口号是 443（HTTP 是 80）

现在在浏览器上输入 http://www.baidu.com
会自动重定向到 https://www.baidu.com

5.1：HTTPS 的成本

• 证书的费用
• 加解密计算
• 降低了访问速度

有些企业的做法是：包含敏感数据的请求才使用 HTTPS，其他保持使用 HTTP。

5.2：HTTPS 通信过程

总的可以分为 3 大阶段：

6：SSL/TLS

SSL（Secure Sockets Layer，安全套接层），是 TLS 的前身。

TLS（Transport Layer Security，传输层安全性协议）。

HTTPS 是在 HTTP 的基础上使用 SSL/TLS 来加密报文，对窃听和中间人攻击提供合理的防护。

SSL/TLS 也可以用在其他协议上，比如：

• FTP -> FTPS
• SMTP -> SMTPS

SSL/TLS 历史版本信息

• SSL 1.0：因存在严重的安全漏洞，从未公开过
• SSL 2.0：1995 年，已于 2011 年弃用（RFC 6176）
• SSL 3.0：1996 年，已于 2015 年弃用（RFC 7568）
• TLS 1.0：1999 年（RFC 2246）
• TLS 1.1：2006 年（RFC 4346）
• TLS 1.2：2008 年（RFC 5246）
• TLS 1.3：2018 年（RFC 8446）

6.1：SSL/TLS 工作在哪一层

6.2：TLS 1.2 的连接

TLS 1.2 的连接（ECDHE 密钥交换算法）大概有 10 大步骤。

下图中省略了中间产生的一些 ACK 确认。

6.2.1：Client Hello

• TLS 的版本号
• 支持的加密组件（Cipher Suite）列表
  加密组件是指所使用的加密算法及密钥长度等
• 一个随机数（Client Random）

6.2.2：Server Hello

• TLS 的版本号
• 选择的加密组件
  是从接收到的客户端加密组件列表中挑选出来的
• 一个随机数（Server Random）

6.2.3：Certificate

• 服务器的公钥证书（被 CA 签名过的）

6.2.4：Server Key Exchange

• 用以实现 ECDHE 算法的其中一个参数（Server Params）
  ECDHE 是一种密钥交换算法
  为了防止伪造，Server Params 经过了服务器私钥签名

6.2.5：Server Hello Done

• 告知客户端：协商部分结束

到目前为止，客户端和服务器之间通过明文共享了：

• Client Random
• Server Random
• Server Params

而且，客户端也已经拿到了服务器的公钥证书，接下来，客户端会验证证书的真实有效性。

6.2.6：Client Key Exchange

• 用以实现 ECDHE 算法的另一个参数（Client Params）

目前为止，客户端和服务器都拥有了 ECDHE 算法需要的 2 个参数：

• Server Params
• Client Params

客户端、服务器都可以使用 ECDHE 算法根据 Server Params、Client Params 计算出一个新的随机密钥串：Pre-master secret。

然后结合 Client Random、Server Random、Pre-master secret 生成一个主密钥。

最后利用主密钥衍生出其他密钥：客户端发送用的会话密钥、服务器发送用的会话密钥等。

6.2.7：Change Cipher Spec

• 告知服务器：之后的通信会采用计算出来的会话密钥进行加密

6.2.8：Finished（Client）

• 包含连接至今全部报文的整体校验值（摘要），加密之后发送给服务器
• 这次握手协商是否成功，要以服务器是否能够正确解密该报文作为判定标准

6.2.9：Change Cipher Spec

6.2.10：Finished（Server）

• 到此为止，客户端服务器都验证加密解密没问题，握手正式结束
• 后面开始传输加密的 HTTP 请求和响应

6.3：OpenSSL

OpenSSL 是 SSL/TLS 协议的开源实现，始于 1998 年，支持 Windows、Mac、Linux 等平台。

官网：https://www.openssl.org/

Linux、Mac 一般自带 OpenSSL。
Windows 下载安装 OpenSSL：https://www.openssl.org/source/

常用命令：

生成私钥：
openssl genrsa -out my.key

生成公钥：
openssl rsa -in my.key -pubout -out my.pem

可以使用 OpenSSL 构建一套属于自己的 CA，自己给自己颁发证书，称为 “ 自签名证书 ”。

除此以外，一个生成免费证书的网站：https://freessl.org

---

人生如逆旅，我亦是行人。

——《临江仙 · 送钱穆父》（宋）苏轼