https 加密、http2.0、keep-alive

原文地址：https://ainyi.com/44

HTTP：是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少

http协议属于明文传输协议，交互过程以及数据传输都没有进行加密，通信双方也没有进行任何认证，通信过程非常容易遭遇劫持、监听、篡改，严重情况下，会造成恶意的流量劫持等问题，甚至造成个人隐私泄露（比如银行卡卡号和密码泄露）等严重的安全问题

https：是以安全为目标的 HTTP 通道，简单讲是 HTTP 的安全版，即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL

https

多了 SSL 层的 HTTP 协议
简而言之，HTTPS 就是在 HTTP 下加入了 SSL 层，从而保护了交换数据隐私和完整性，提供对网站服务器身份认证的功能，简单来说它就是安全版的 HTTP

TLS 是 SSL 的升级版本

HTTPS 主要用途有三个：

通过证书等信息确认网站的真实性
建立加密的信息通道
数据内容的完整性

真实性
我们可以通过点击浏览器地址栏锁标志来查看网站认证之后的真实信息，SSL证书保证了网站的唯一性与真实性
加密了哪些信息

数字证书，它可以通过加密技术（对称加密与非对称加密）对我们在网上传输的信息进行加密

比如我登录账号上输入：

账号：krry

密码：1234567

若这个数据被黑客拦截盗窃了，那么加密后，黑客得到的数据可能就是这样的：

账号：çµø…≤¥ƒ∂ø†®∂˙∆¬

密码：∆ø¥§®†ƒ©®†©˚¬

数据内容完整性
当数据包经过无数次路由器转发后可能会发生数据劫持，黑客将数据劫持后进行篡改，比如植入小广告。开启HTTPS后黑客就无法对数据进行篡改，就算真的被篡改了，我们也可以检测出问题

对称加密与非对称加密

对称加密

对称加密是指加密与解密都使用同一个密钥的加密算法

目前常见的加密算法有：DES、AES、IDEA 等

非对称加密

非对称加密使用的是两个密钥，公钥与私钥，我们会使用公钥对网站账号密码等数据进行加密，再用私钥对数据进行解密。这个公钥会发给查看网站的所有人，而私钥是只有网站服务器自己拥有。
用户对网站输入的信息使用公钥加密，传到服务端使用私钥对数据解密

目前常见非对称加密算法：RSA，DSA，DH等

优缺点

非对称加密与对称加密相比，其安全性更好：对称加密的通信双方使用相同的秘钥，如果一方的秘钥遭泄露，那么整个通信就会被破解。而非对称加密使用一对秘钥（私钥和公钥），一个用来加密（公钥），一个用来解密（私钥），而且公钥是公开的，秘钥是自己保存的，不需要像对称加密那样在通信之前要先同步秘钥

非对称加密的缺点是加密和解密花费时间长、速度慢，只适合对少量数据进行加密

https 加密

https = 数据加密（对称和非对称） + 网站认证 + 完整性验证 + HTTP
通过上文，我们已经知道，HTTPS 就是在 HTTP 传输协议的基础上对网站进行认证，给予它独一无二的身份证明，再对网站数据进行对称加密和非对称加密，并对传输的数据进行完整性验证。

HTTPS 作为一种加密手段不仅加密了数据，还给了网站一张身份证

HTTPS保证数据安全的机制

在 HTTP 的概念中介绍了 HTTP 是非常不安全的，下面介绍 https 如何保证安全传输

使用非对称和对称加密

客户端向服务器端发起SSL连接请求；（在此过程中依然存在数据被中间方盗取的可能，下面将会说明如何保证此过程的安全）
服务器把公钥发送给客户端，并且服务器端保存着唯一的私钥；
客户端用公钥对双方通信的对称秘钥进行加密，并发送给服务器端；
（使用非对称加密的公钥对对称加密的私钥进行加密）
服务器利用自己唯一的私钥对客户端发来的对称秘钥进行解密，在此过程中，中间方无法对其解密（即使是客户端也无法解密，因为只有服务器端拥有唯一的私钥），这样保证了对称秘钥在收发过程中的安全，此时，服务器端和客户端拥有了一套完全相同的对称秘钥
进行数据传输，服务器和客户端双方用公有的相同的对称秘钥对数据进行加密解密，可以保证在数据收发过程中的安全，即是第三方获得数据包，也无法对其进行加密，解密和篡改

加密的详细过程

首先服务器端用非对称加密（RSA）产生公钥和私钥。
然后把公钥交给数字证书，并进行包装发给客户端。
当公钥到达客户端之后，客户端的TLS首先验证公钥是否有效（颁发机构，公钥有效期，CA数字签名）
若存在问题则弹出警告框，提示证书存在问题。
若证书没有问题，则客户端会用对称加密产生一个秘钥，并用服务端返回的公钥（非对称加密）对对称加密的秘钥加密后发送给服务器。这个秘钥就是以后用来通信的秘钥。
这样服务器端收到公钥加密的秘钥就用自己的私钥解开公钥从而获得秘钥。
这样客户端和服务器都获得了秘钥，信息交流相对是安全的

CA（电子商务认证机构）数字证书

https 协议中身份认证的部分是由数字证书来完成的，证书由公钥、证书主题、数字签名等内容组成，在客户端发起SSL请求后，服务端会将数字证书发给客户端，客户端对证书进行验证，并获取用于秘钥交换的非对称秘钥

数字证书作用：
身份授权：确保浏览器访问的网站是经过CA验证的可信任网站
分发公钥：每个数字证书都包含了注册者生成的公钥。在SSL握手时通过certificate消息传输给客户端

数字证书验证：
申请者拿到CA的证书并部署在网站服务器端，浏览器发起握手接收到证书后，如何确认这个证书就是CA签发的呢？怎样避免第三方伪造这个证书？答案就是数字签名（digital signature）。数字签名是证书的防伪标签，目前使用最广泛的是SHA-RSA（SHA用于哈希算法，RSA用于非对称加密算法）数字签名

http2.0

http1.1 存在的问题

1、TCP 连接数限制
对于同一个域名，浏览器最多只能同时创建 6~8 个 TCP 连接，调用接口的时候可以看到 (不同浏览器不一样)

2、线头阻塞 (Head Of Line Blocking) 问题
每个 TCP 连接同时只能处理一个请求 - 响应，浏览器按 FIFO 原则处理请求，如果上一个响应没返回，后续请求 - 响应都会受阻。
为了解决此问题，出现了管线化 - pipelining 技术，但是管线化存在诸多问题，比如第一个响应慢还是会阻塞后续响应、服务器为了按序返回相应需要缓存多个响应占用更多资源、浏览器中途断连重试服务器可能得重新处理多个请求、还有必须客户端 - 代理 - 服务器都支持管线化

3、Header 内容多，而且每次请求 Header 不会变化太多，没有相应的压缩传输优化方案

4、为了尽可能减少请求数，需要做合并文件、雪碧图、资源内联等优化工作，但是这无疑造成了单个请求内容变大延迟变高的问题，且内嵌的资源不能有效地使用缓存机制

5、明文传输不安全

http2.0 新特性

与 http1.1 相比，http2.0 有：

采用二进制格式而非文本格式
是完全多路复用的，而非有序并阻塞的——只需一个连接即可实现并行
使用报头压缩，http2.0 降低了开销
让服务器可以将响应主动“推送”到客户端缓存中

采用二进制传输
帧是数据传输的最小单位，以二进制传输代替原本的明文传输，原本的报文消息被划分为更小的数据帧，二进制协议解析起来更高效、“线上”更紧凑，更重要的是错误更少
多路复用
在一个 TCP 连接上，我们可以向对方不断发送帧，每帧的 stream identifier 的标明这一帧属于哪个流，然后在对方接收时，根据 stream identifier 拼接每个流的所有帧组成一整块数据。
把 HTTP/1.1 每个请求都当作一个流，那么多个请求变成多个流，请求响应数据分成多个帧，不同流中的帧交错地发送给对方，这就是 HTTP/2 中的多路复用。
流的概念实现了单连接上多请求 - 响应并行，解决了线头阻塞的问题，减少了 TCP 连接数量和 TCP 连接慢启动造成的问题
所以 http2 对于同一域名只需要创建一个连接就可以加载页面，而不是像 http/1.1 那样创建 6~8 个连接
头部压缩
在 http/1.x 协议中，每次请求都会携带 header 数据，而类似 User-Agent, Accept-Language 等信息在每次请求过程中几乎是不变的，那么这些信息在每次请求过程中就变成了浪费。所以， http2 中提出了一个 HPACK 的压缩方式，用于减少 http header 在每次请求中消耗的流量
服务端推送 (Server Push)
浏览器发送一个请求，服务器主动向浏览器推送与这个请求相关的资源，这样浏览器就不用发起后续请求。
Server-Push 主要是针对资源内联做出的优化，相较于 http/1.1 资源内联的优势:

  客户端可以缓存推送的资源

  客户端可以拒收推送过来的资源

  推送资源可以由不同页面共享

  服务器可以按照优先级推送资源

流量控制
每个 http2 流都拥有自己的公示的流量窗口，它可以限制另一端发送数据。对于每个流来说，两端都必须告诉对方自己还有足够的空间来处理新的数据，而在该窗口被扩大前，另一端只被允许发送这么多数据

http/1.x 转 http2

http/1 的几种优化可以放弃使用
在 http/1.x 的时代，为了减少浏览器的请求数/提高浏览器的并发数，通常会使用如下的手段来进行优化：
合并文件、内联资源、雪碧图、域名分片

以上对于 HTTP/2 来说是不必要的，使用 http/2 尽可能将资源细粒化，文件分解地尽可能散，不用担心请求数多

http keep-Alive 长连接

http 协议采用“请求-应答”模式

当使用普通模式，即非 keep-alive 模式时（短连接），每个请求/应答，客户端和服务器都要新建一个连接，完成之后立即断开连接

当使用 keep-alive 模式时，keep-alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，keep-alive功能避免了建立或者重新建立连接

http1.0 默认是关闭的，需要在 http 头加入”Connection: keep-alive”，才能启用Keep-Alive
http 1.1 默认启用 keep-alive，加入”Connection: close “才关闭

目前大部分浏览器都是用 http1.1 协议，也就是说默认都会发起 keep-alive 的连接请求了，所以是否能完成一个完整的Keep- Alive连接就看服务器设置情况。

下图是普通模式和长连接模式的请求对比：

keep-alive 的优缺点

优点：keep-alive 模式更加高效，因为避免了连接建立和释放的开销
缺点：长时间的 tcp 连接容易导致系统资源无效占用，浪费系统资源