HTTP和HTTPSHttp http 1.0 短连接每一个请求建立一个 TCP 连接，请求完成后立马断开连接。这将会

http

短连接每一个请求建立一个 TCP 连接，请求完成后立马断开连接。这将会导致 2 个问题：连接无法复用，head of line blocking 连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。head of line blocking 会导致带宽无法被充分利用，以及后续健康请求被阻塞。
缓存主要是用 exprise，If-Modified-Since 来处理

长连接和请求流水线处理：多个 http 请求可以复用一个 TCP 连接，服务器端按照 FIFO 原则来处理不同的 Request
增加 connection header 该 header 用来说明客户端与服务器端 TCP 的连接方式，默认 connection 为 keep-alive 长连接，若 connection 为 close 则使用短连接
在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206
ache 缓存等机制相关的请求头和响应头：Entity tag，If-Unmodified-Since, If-Match, If-None-Match
加 Host header 可以传递主机名：一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个 IP 地址。如果没有 Host 头域会报告一个错误（400 Bad Request）

采取了多路复用（multiplexing）。多路复用通过多个请求 stream 共享一个 tcp 连接的方式，解决了 HOL blocking 的问题，降低了延迟同时提高了带宽的利用率。
请求优先级：允许给每个 request 设置优先级，这样重要的请求就会优先得到响应。
header 压缩
服务端推送（server push）：例如我的网页有一个 sytle.css 的请求，在客户端收到 sytle.css 数据的同时，服务端会将 sytle.js 的文件推送给客户端，当客户端再次尝试获取 sytle.js 时就可以直接从缓存中获取到

HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS HTTP2.0 消息头的压缩算法采用 HPACK ，而非 SPDY 采用的 DEFLATE

多路复用 (Multiplexing) 一个 request 对应一个 id，这样一个连接上可以有多个 request，每个连接的 request 可以随机的混杂在一起，接收方可以根据 request 的 id 将 request 再归属到各自不同的服务端请求里面。更有效的利用了tcp连接
二进制分帧 HTTP/2 在应用层(HTTP/2)和传输层(TCP or UDP)之间增加一个二进制分帧层。在不改动 HTTP/1.x 的语义、方法、状态码、URI 以及首部字段的情况下, 解决了 HTTP1.1 的性能限制，改进传输性能，实现低延迟和高吞吐量。HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码
首部压缩（Header Compression） header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量。SPDY 使用的是通用的 DEFLATE 算法，而 HTTP/2 则使用了专门为首部压缩而设计的 HPACK 算法。
服务端推送（Server Push）服务端推送是一种在客户端请求之前发送数据的机制。在 HTTP/2 中，服务器可以对客户端的一个请求发送多个响应。

Http+SSL/TLS=Https，是为了解决http明文传输可能导致中间人攻击的安全性问题，增加了中间人攻击的成本。

在客户端使用对称加密，服务端使用非对称加密。

数字签名：通过摘要算法（如SHA256）对CA证书进行摘要加密，再用服务端的私钥对摘要进行加密。将数字签名放到证书一起发送给客户端。客户端通过服务端的公钥对数字签名进行解密，再通过相同的摘要算法对证书进行加密，看得到的结果是否和数字签名的解密结果一致。