《网络协议从入门到底层原理》10. HTTPS · SSL/TLS · SPDY · QUIC · HTTP2 · HTTP3

目录

• HTTPS
• SSL / TLS
  • SSL/TLS 工作在哪一层
• OpenSSL
• HTTPS的成本
• HTTPS的通信过程
• TLS 1.2 的连接（ECDHE密钥交换算法）
  • ① Client Hello
  • ② Server Hello
  • ③ Certificate
  • ④ Server Key Exchange
  • ⑤ Server Hello Done
  • ⑥ Client Key Exchange
  • ⑦ Change Cipher Spec
  • ⑧ Finished
  • ⑨ Change Cipher Spec
  • ⑩ Finished
• Wireshark 解密 HTTPS
• HTTP/1.1协议的不足
• SPDY
• HTTP/2
  • HTTP/2的特性
    • 二进制格式
    • 多路复用（Multiplexing）
    • 优先级
    • 头部压缩
    • 服务器推送（Server Push）
  • HTTP/2的问题
    • 队头阻塞（head of line blocking）
    • 握手延迟
• HTTP/3
  • 疑问
  • HTTP/3的特性
    • 连接迁移
    • 向前纠错
  • HTTP/3的问题
    • 操作系统内核、CPU负载

---

HTTPS

SSL / TLS

TLS (Transport Layer Security)，译为：传输层安全性协议
前身是 SSL (Secure Sockets Layer)，译为：安全套接层

历史版本信息
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)

SSL/TLS 工作在哪一层

OpenSSL

OpenSSL 是SSL/TLS协议的开源实现，始于1998年，支持Windows、Mac、Linux等平台
Linux、Mac 一般自带 OpenSSL
Windows下载安装OpenSSL：https://slproweb.com/products/Win32OpenSSL.html

常用命令
生成私钥：openssl genrsa -out mj.key
生成公钥：openssl rsa -in mj.key -pubout -out mj.pem

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

HTTPS的成本

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

有些企业的做法是：包含敏感数据的请求才使用HTTPS，其他保持使用HTTP
http://www.icbc.com.cn/
https://mybank.icbc.com.cn/

HTTPS的通信过程

TLS 1.2 的连接（ECDHE密钥交换算法）

① Client Hello

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

② Server Hello

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

③ Certificate

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

④ Server Key Exchange

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

⑤ Server Hello Done

• 告知客户端：协商部分结束
  
• 到目前为止，客户端和服务器之间通过明文共享了：
  Client Random、Server Random、Server Params
• 而且，客户端也已经拿到了服务器的公钥证书，接下来，客户端会验证证书的真实有效性

⑥ 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 生成一个主密钥
• 最后利用主密钥衍生出其他密钥：客户端发送用的会话密钥、服务器发送用的会话密钥等

⑦ Change Cipher Spec

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

⑧ Finished

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

⑨ Change Cipher Spec

⑩ Finished

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

Wireshark 解密 HTTPS

• 设置环境变量SSLKEYLOGFILE（浏览器会将key信息导出到这个文件）

• 设置完成后，最好重启一下操作系统
• 在Wireshark中选择这个文件
  编辑 → 首选项 → Protocols → TLS
  

如果环境变量不管用，可以直接设置浏览器的启动参数（下图是使用了Rolan进行启动）

HTTP/1.1协议的不足

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

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

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

SPDY

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，开发者不需要修改任何代码，只需要升级服务器配置、升级浏览器

HTTP/2的特性

二进制格式

一些基本概念

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

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

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

多路复用（Multiplexing）

精灵图 （image sprites）

优先级

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

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

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

头部压缩

服务器推送（Server Push）

HTTP/2的问题

队头阻塞（head of line blocking）

握手延迟

HTTP/3

疑问

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

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

HTTP/3的特性

连接迁移

向前纠错

基于TPC协议的话，丢包以后会重传。

HTTP/3的向前纠错，丢包以后可以根据其他包推测出这个包的数据（只适合丢失少量数据）。但是目前还没有成为标准，以后是否会成为标准也不确定。

HTTP/3的问题

操作系统内核、CPU负载

• 据Google和Facebook称，与基于TLS的HTTP/2相比，它们大规模部署的QUIC需要近2倍的CPU使用量
  Linux内核的UDP部分没有像TCP那样的优化，因为传统上没有使用UDP进行如此高速的信息传输
  TCP和TLS有硬件加速，而这对于UDP很罕见，对于QUIC则基本不存在

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