2021 March 03 计算机网络

网络协议八：HTTPS、HTTP的改进

HTTPS

  1. 简介
    1. HTTPS（HyperText Transfer Protocol Secure），译为：超文本传输安全协议
      1. 常称为HTTP over TLS、HTTP over SSL、HTTP Secure
      2. 由网景公司于1994年首次提出
    2. HTTPS的默认端口号是443（HTTP是80）
    3. 现在在浏览器上输入http://www.baidu.com,会自动重定向到https://www.baidu.com

SSL/TLS

  1. HTTPS是在HTTP的基础上使用SSL/TLS来加密报文，对窃听和中间人攻击提供合理的防护
  2. SSL/TLS也可以用在其他协议上，比如
    1. FTP → FTPS
    2. SMTP → SMTPS
  3. TLS（Transport Layer Security），译为：传输层安全性协议
    1. 前身是SSL（Secure Sockets Layer），译为：安全套接层
  4. 历史版本信息
    1. SSL 1.0：因存在严重的安全漏洞，从未公开过
    2. SSL 2.0：1995年，已于2011年弃用（RFC 6176）
    3. SSL 3.0：1996年，已于2015年弃用（RFC 7568）
    4. TLS 1.0：1999年（RFC 2246）
    5. TLS 1.1：2006年（RFC 4346）
    6. TLS 1.2：2008年（RFC 5246）
    7. TLS 1.3：2018年（RFC 8446）
      1. 有没有发现：TLS的RFC文档编号都是以46结尾
  5. SSL/TLS工作在哪一层
    1. 在传输层与应用层之间
    2. 因为SSL/TLS是对HTTP报文进行加密的，HTTP报文下一步传递到传输层，所以如果加密只能在传输层之前。

OpenSSL

  1. OpenSSL是SSL/TLS协议的开源实现，始于1998年，支持Windows、Mac、Linux等平台
    1. Linux、Mac一般自带OpenSSL
    2. Windows下载安装OpenSSL：https://slproweb.com/products/Win32OpenSSL.html
  2. 常用命令
    1. 生成私钥：openssl genrsa -out mj.key
    2. 生成公钥：openssl rsa -in mj.key -pubout -out mj.pem
      1. 注意：只有给出公钥的路径mj.key,才能生成私钥
  3. 可以使用OpenSSL构建一套属于自己的CA，自己给自己颁发证书，称为“自签名证书”

HTTPS的成本

  1. 证书的费用
  2. 加解密计算
  3. 降低了访问速度
  4. 有些企业的做法是：包含敏感数据的请求才使用HTTPS，其他保持使用HTTP
    1. 比如工商银行： http://www.icbc.com.cn/

TLS1.2的连接

  1. HTTPS的通信过程总的可以分为3大阶段
    1. TCP的3次握手
    2. TLS的连接
    3. HTTP请求和响应
  2. 大概是有10大步骤，如下图
    1. 图片中省略了中间产生的一些ACK确认

    图1

  3. 通过wireshark抓取https请求数据如下 图1

1.第一步Client Hello

  1. 主要发送的内容有：
    1. TLS的版本号
    2. 支持的加密组件（Cipher Suite）列表
      1. 加密组件是指所使用的加密算法及密钥长度等
      2. 一个随机数（Client Random）

2.第二步Server Hello

  1. 主要发送的内容有：
    1. TLS的版本号
    2. 选择的加密组件
      1. 是从接收到的客户端加密组件列表中挑选出来的，就是服务器所支持的
    3. 一个随机数（Server Random）

3.第三步Certificate

  1. 主要发送的内容有：
    1. 服务器的公钥证书（被CA签名过的）

4.第四步Server Key Exchange

  1. Server Key Exchange主要发送的内容有
    1. 用以实现ECDHE算法的其中一个参数（Server Params）
      1. ECDHE是一种密钥交换算法
      2. 为了防止伪造，Server Params经过了服务器私钥签名

5.第五步Server Hello Done

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

6.第六步Client Key Exchange

  1. 客户端发送给服务器的用以实现ECDHE算法的另一个参数（Client Params）
  2. 目前为止，客户端和服务器都拥有了ECDHE算法需要的2个参数：Server Params、Client Params
  3. 客户端、服务器都可以
    1. 使用ECDHE算法根据Server Params、Client Params计算出一个新的随机密钥串：Pre-master secret
    2. 然后结合Client Random、Server Random、Pre-master secret生成一个主密钥
    3. 最后利用主密钥衍生出其他密钥：客户端发送用的会话密钥、服务器发送用的会话密钥

7.第七步Change Cipher Spec

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

8.第八步Finished

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

9.第九十步Change Cipher Spec 、Finished

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

图1

Wireshark解密HTTPS

  1. 设置环境变量SSLKEYLOGFILE（浏览器会将key信息导出到这个文件）
  2. 设置完成后，最好重启一下操作系统
  3. 在Wireshark中选择这个文件
    1. 编辑 → 首选项 → Protocols → TLS
  4. 如果环境变量不管用，可以直接设置浏览器的启动参数（下图是使用了Rolan进行启动）

配置服务器HTTPS （略）

HTTP的改进

  1. 协议的不足（HTTP/1.1）
    1. 同一时间，一个连接只能对应一个请求
      1. 针对同一个域名，大多数浏览器允许同时最多6个并发连接
    2. 只允许客户端主动发起请求
      1. 一个请求只能对应一个响应
    3. 同一个会话的多次请求中，头信息会被重复传输
      1. 通常会给每个传输增加500~800字节的开销
      2. 如果使用 Cookie，增加的开销有时会达到上千字节

        HTTP/2

SPDY

  1. SPDY（speedy的缩写），是基于TCP的应用层协议，它强制要求使用SSL/TLS
    1. 2009年11月，Google宣布将SPDY作为提高网络速度的内部项目
  2. SPDY与HTTP的关系
    1. SPDY并不用于取代HTTP，它只是修改了HTTP请求与响应的传输方式
    2. 只需增加一个SPDY层，现有的所有服务端应用均不用做任何修改
    3. SPDY是HTTP/2的前身
      1. 2015年9月，Google宣布移除对SPDY的支持，拥抱HTTP/2

HTTP/2简介

  1. HTTP/2，于2015年5月以RFC 7540正式发表
    1. 根据W3Techs的数据，截至2019年6月，全球有36.5%的网站支持了HTTP/2
  2. HTTP/1.1和HTTP/2速度对比
    1. http://www.http2demo.io/
    2. https://http2.akamai.com/demo
  3. HTTP/2在底层传输做了很多的改进和优化，但在语意上完全与HTTP/1.1兼容
    1. 比如请求方法（如GET、POST）、Status Code、各种Headers等都没有改变
    2. 因此，要想升级到HTTP/2
      1. 开发者不需要修改任何代码
      2. 只需要升级服务器配置、升级浏览器

HTTP/2的特性

  1. 二进制格式
    1. HTTP/2采用二进制格式传输数据，而非HTTP/1.1的文本格式
    2. 二进制格式在协议的解析和优化扩展上带来更多的优势和可能
  2. 一些基本概念
    1. 数据流：已建立的连接内的双向字节流，可以承载一条或多条消息
      1. 所有通信都在一个TCP连接上完成，此连接可以承载任意数量的双向数据流
    2. 消息：与逻辑HTTP请求或响应消息对应，由一系列帧组成
    3. 帧：HTTP/2通信的最小单位，每个帧都包含帧头（会标识出当前帧所属的数据流）
      1. 来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装
  3. 多路复用（Mulitiplexing)
    1. 客户端和服务器可以将 HTTP消息分解为互不依赖的帧，然后交错发送，最后再在另一端把它们重新组装起来
    2. 并行交错地发送多个请求，请求之间互不影响
    3. 并行交错地发送多个响应，响应之间互不干扰
    4. 使用一个连接并行发送多个请求和响应
    5. 不必再为绕过HTTP/1.1限制而做很多工作
      1. 比如image sprites、合并CSS\JS、内嵌CSS\JS\Base64图片、域名分片等
  4. 优先级
    1. HTTP/2 标准允许每个数据流都有一个关联的权重和依赖关系
      1. 可以向每个数据流分配一个介于1至256之间的整数
      2. 每个数据流与其他数据流之间可以存在显式依赖关系
    2. 客户端可以构建和传递“优先级树”，表明它倾向于如何接收响应
    3. 服务器可以使用此信息通过控制CPU、内存和其他资源的分配设定数据流处理的优先级
      1. 在资源数据可用之后，确保将高优先级响应以最优方式传输至客户端
    4. 应尽可能先给父数据流分配资源
    5. 同级数据流（共享相同父项）应按其权重比例分配资源
  5. 头部压缩
    1. HTTP/2使用HPACK压缩请求头和响应头
      1. 可以极大减少头部开销，进而提高性能
    2. 早期版本的HTTP/2和SPDY使用 zlib压缩
      1. 可以将所传输头数据的大小减小85%~88%
      2. 但在2012年夏天，被攻击导致会话劫持
      3. 后被更安全的HPACK取
  6. 服务器推送(Server Push)
    1. 服务器可以对一个客户端请求发送多个响应
      1. 除了对最初请求的响应外，服务器还可以向客户端推送额外资源，而无需客户端额外明确地请求
      2. 注意：前提是客户端先发了请求

HTTP/2的问题

  1. 队头阻塞
  2. 握手延迟

HTTP/3

  1. Google觉得HTTP/2仍然不够快，于是就有了HTTP/3
    1. HTTP/3由Google开发，弃用TCP协议，改为使用基于UDP协议的QUIC协议实现
    2. QUIC（Quick UDP Internet Connections），译为：快速UDP网络连接，由Google开发，在2013年实现
    3. 于2018年从HTTP-over-QUIC改为HTTP/3
  2. 疑问：
    1. HTTP/3基于UDP，如何保证可靠传输？
      1. 由QUIC来保证
    2. 为何Google不开发一个新的不同于TCP、UDP的传输层协议？
      1. 目前世界上的网络设备基本只认TCP、UDP
      2. 如果要修改传输层，意味着操作系统的内核也要修改
      3. 另外，由IETF标准化的许多TCP新特性都因缺乏广泛支持而没有得到广泛的部署或使用
      4. 因此，要想开发并应用一个新的传输层协议，是极其困难的一件事情

图1

HTTP/3的特性-连接迁移

  1. TCP基于4要素（源IP、源端口、目标IP、目标端口）
    1. 切换网络时至少会有一个要素发生变化，导致连接发生变化
    2. 当连接发生变化时，如果还使用原来的TCP连接，则会导致连接失败，就得等原来的连接超时后重新建立连接
    3. 所以我们有时候发现切换到一个新网络时，即使新网络状况良好，但内容还是需要加载很久
    4. 如果实现得好，当检测到网络变化时立刻建立新的TCP连接，即使这样，建立新的连接还是需要几百毫秒的时间
  2. QUIC的连接不受4要素的影响，当4要素发生变化时，原连接依然维持
    1. QUIC连接不以4要素作为标识，而是使用一组Connection ID（连接ID）来标识一个连接
    2. 即使IP或者端口发生变化，只要Connection ID没有变化，那么连接依然可以维持
    3. 比如
      1. 当设备连接到Wi-Fi时，将进行中的下载从蜂窝网络连接转移到更快速的Wi-Fi连接
      2. 当Wi-Fi连接不再可用时，将连接转移到蜂窝网络连接

HTTP/3的问题-操作系统内核、CPU负载

  1. 据Google和Facebook称，与基于TLS的HTTP/2相比，它们大规模部署的QUIC需要近2倍的CPU使用量
    1. Linux内核的UDP部分没有得到像TCP那样的优化，因为传统上没有使用UDP进行如此高速的信息传输
    2. TCP和TLS有硬件加速，而这对于UDP很罕见，对于QUIC则基本不存在
  2. 随着时间的推移，相信这个问题会逐步得到改善

All content is licensed under CC BY-NC-SA

Buit with Jekyll and 3-Jekyll theme • Hosted on Github

Table of Contents