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/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 -> FTPSSMTP -> 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 等平台。
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
人生如逆旅，我亦是行人。
——《临江仙 · 送钱穆父》（宋）苏轼
430
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
