HTTP 1.0 → HTTP 1.1
长连接
HTTP 1.1默认支持长连接，减少了TCP连接次数，节约开销。
HTTP 1.0所保持的TCP每次只能处理一个请求，最典型的就是pipline管线化模型，虽然能一次性接收多个请求，但是还是得按顺序一次处理一个请求，这样很容易造成后续请求等待前序请求完成，造成阻塞，也就是我们常说的”线头阻塞”。
总结：HTTP 1.0需要使用keep-alive参数来告知服务器建立长连接，而HTTP 1.1默认支持长连接，减少了TCP连接次数，减少了开销和延迟！！！
_缓存_
HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准。
HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略
新增状态码：
HTTP1.1 中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删！
http1.1带宽优化
HTTP 1.1支持只发送header信息(不带任何body信息)，如果服务器认为客户端有权限请求服务器，则返回100，否则返回401。客户端如果接受到100，才开始把请求body发送到服务器。这样当服务器返回401的时候，客户端就可以不用发送请求body了，节约了带宽。另外HTTP还支持传送内容的一部分。这样当客户端已经有一部分的资源后，只需要跟服务器请求另外的部分资源即可。这是支持文件断点续传的基础。HTTP1.1在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
HOST域
HTTP 1.1支持host域，服务端可以通过host域设置多个虚拟站点来共享一个ip和端口。因为随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）
HTTP 1.1 → HTTP 2.0
多路复用
HTTP 2.0使用多路复用技术，使用一个TCP连接_并发_处理多个请求，不但节约了开销而且可处理请求的数量也比HTTP 1.1大了很多。
当然HTTP1.1也可以多建立几个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。
TCP连接有一个预热和保护的过程，先检查数据是否传送成功，一旦成功过，则慢慢加大传输速度。因此对应瞬时并发的连接，服务器的响应就会变慢。所以最好能使用一个建立好的连接，并且这个连接可以支持瞬时并发的请求。
头部压缩
HTTP 1.1不支持header数据压缩，HTTP 2.0使用HPACK算法对header的数据进行压缩，使得数据传输更快。
服务器推送
当我们对支持HTTP 2.0的服务器请求数据额时候，服务器会顺便把一些客户端需要的资源一起推送到服务器，这种方式适用于加载静态资源，节约带宽。服务器端推送的这些资源其实存在客户端的某处地方，客户端直接从本地加载这些资源就可以了，不用走网络，速度自然是快很多的。
HTTP → HTTPS HTTPS = HTTP + TLS/SSL加密 + 认证 + 完整性保护 （80 443）
在讲 HTTPS 之前，我们先来看看 HTTP 有哪些不足：
- 使用明文通信，内容可能会被窃听
- 不验证通信双方身份，有可能遭遇伪装
- 无法证明报文的完整性，内容可能遭到篡改
为了解决这些不足，所以HTTPS 应运而生，先看看https的特性：
- TLS/SSL内容加密
- 数字证书(CA)验明身份: 防范中间人攻击
- MD5、SHA-1等散列值方法防止信息篡改（中间人攻击：运营商等）
先来谈谈“对称加密”和“非对称加密”的概念
对称加密
所谓的“对称加密技术”，意思就是说：“加密”和“解密”使用相同的密钥。这个比较好理解，就好比你用 7zip 或 WinRAR 创建一个带密码（口令）的加密压缩包，当你下次要把这个压缩文件解开的时候，你需要输入同样的密码，在这个例子中，密码/口令就如同刚才说的“密钥”。
对称加密是最快速、最简单的一种加密方式，加密（encryption）与解密（decryption）用的是同样的密钥（secret key），这种方法在密码学中叫做对称加密算法，对称加密有很多种算法，由于它效率很高，所以被广泛使用在很多加密协议的核心当中。
非对称加密
所谓的“非对称加密技术”，意思就是说：“加密”和“解密”使用不同的密钥，这玩意儿比较难理解，也比较难想到，当年“非对称加密”的发明，还被誉为“密码学”历史上的一次革命。
非对称加密为数据的加密与解密提供了一个非常安全的方法，它使用了一对密钥，公钥（public key）和私钥（private key），私钥只能由一方安全保管，不能外泄，而公钥则可以发给任何请求它的人，非对称加密使用这对密钥中的一个进行加密，而解密则需要另一个密钥。
总结：非对称相对更安全，但是性能要求更高！
https加密方式
虽然TLS/SSL采用公开密钥这种非对称加密方式，但是HTTPS并不是全部使用非对称加密，而是使用混合加密方式，即：公开密钥(非对称加密)+共享密钥(对称加密)
因为公开密钥与共享密钥加密相比，其处理速度要慢很多。所以HTTPS冲锋利用了两者各自的优势，将多种方法组合起来用于通信。https在交换密钥环节使用公开密钥加密方式，之后建立的通信交换报文阶段则使用共享密钥加密方式
证明公开密钥的正确性的证书
遗憾的是, 公开密钥加密方式还是存在一些问题的, 那就是无法证明公开密钥本身就是货真价实的公开密钥. 比如, 正准备和某台服务器建立公开密钥加密方式下的通信时, 如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥. 或许在公开密钥传输途中, 真正的公开密钥已经被攻击者替换了.
为了解决上述问题, 可以使用有数字证书认证机构（CA）和其他相关机关颁发的公开密钥证书
基本流程为:
- 1.服务器把自己的公开密钥登录至数字证书认证机构
- 2.数字证书认证机构用自己的私有密钥向服务器的公开密钥署数字签名并颁发公钥证书
- 3.客户端拿到服务器的公钥证书后, 使用数字证书认证机构的公开密钥, 向数字证书认证机构验证公钥证书上的数字签名, 以确认服务器的公开密钥的真实性
- 4.使用服务器的公开密钥对报文加密后发送
- 5.服务器用私有密钥对报文解密
性能问题
通常我们会认为，使用HTTPS会导致网站加载速度变慢。实际上，只要我们合理优化使用HTTPS过程，使用HTTPS可能会比使用HTTP还快！
使用HTTPS相比于HTTP所增加的延迟点：
-
HTTP 302 跳转到 HTTPS 的耗时
-
CPU 进行 RSA 加解密运算的耗时
-
请求和验证 CA 所花的时间
优化方式：
-
使用 HSTS 技术，去掉从80跳转到443的跳转(HSTS使用的是内部307跳转技术，不会产生多余的网络请求) PS：302 和 307 效果相同，只是307强制使用post
-
使用专门的加解密硬件处理加解密，减轻CPU负担。这样不仅减少了处理时间，所能承受的qps也会增加。
-
减少证书链，减少 CA 请求时间
-
session复用，减少建立连接的次数
为什么不都使用https
- 性能问题
- 金钱问题