唯心主义蠢货的[网络相关] https的加密过程和http的版本比较

http详细内容

https加密过程

HTTPS与HTTP的一些区别

• HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。
• HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。
• HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
• HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。

HTTPS要解决如下问题：

A发给B的hello消息包，即使被中间人拦截到了，也无法得知消息的内容

A与B这样的简单通信模型，我们很容易做出选择：

这就是对称加密算法，其中图中的密钥S同时扮演加密和解密的角色。

只要这个密钥S不公开给第三者，同时密钥S足够安全，就可以解决通信的安全问题。

但是，在WWW环境下，我们的Web服务器的通信模型没有这么简单：

如果服务器端对所有的客户端通信都使用同样的对称加密算法，无异于没有加密。那怎么办呢？即能使用对称加密算法，又不公开密钥？

答案是：Web服务器与每个客户端使用不同的对称加密算法：

首先需要解决服务器端怎么告诉客户端该使用哪种对称加密算法问题。

可以通过协商。

但是，你协商的过程是没有加密的，还是会被中间人拦截。那再对这个协商过程进行对称加密好了，但是对协商过程加密的加密还是没有加密，怎么办？再加密不就好了……进入了鸡生蛋蛋生鸡的问题了。

如何对协商过程进行加密

密码学领域中，有一种称为“非对称加密”的加密算法，特点是私钥加密后的密文，只要是公钥，都可以解密，但是公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。

虽然服务器端向A、B……的方向还是不安全的，但是至少A、B向服务器端方向是安全的。

使用非对称加密算法，客户端A，B需要一开始就持有公钥，否则无法进行加密。

所以需要解决A，B客户端安全的获得公钥问题。

可以有以下方案：

方案1. 服务器端将公钥发送给每一个客户端

方案2. 服务器端将公钥放到一个远程服务器，客户端可以请求得到

选择方案1，因为方案2又多了一次请求，还要另外处理公钥的存放问题。

公钥被调包了怎么办

对于方案1如果服务器端发送公钥给客户端时，被中间人调包了，怎么办？

通过下图来理解：

显然，让每个客户端的每个浏览器默认保存所有网站的公钥是不现实的。

使用第三方机构的公钥

公钥被调包的问题出现，是因为我们的客户端无法分辨返回公钥的人到底是中间人，还是真的服务器。这其实就是密码学中提的身份验证问题。

使用数字证书来解决，不能直接将服务器的公钥传递给客户端，而是第三方机构使用它的私钥对我们的公钥进行加密后，再传给客户端。客户端再使用第三方机构的公钥进行解密。

假如下图是设计的第一版“数字证书”，证书中只有服务器交给第三方机构的公钥，而且这个公钥被第三方机构的私钥加密了：

如果能解密，就说明这个公钥没有被中间人调包。因为如果中间人使用自己的私钥加密后的东西传给客户端，客户端是无法使用第三方的公钥进行解密的。

话到此，我以为解决问题了。但是现实中HTTPS，还有一个数字签名的概念，我没法理解它的设计理由。

仔细思考，其实第三方机构不可能只给你一家公司制作证书，它也可能会给中间人这样有坏心思的公司发放证书。这样的，中间人就有机会对你的证书进行调包，客户端在这种情况下是无法分辨出是接收的是你的证书，还是中间人的。因为不论中间人，还是你的证书，都能使用第三方机构的公钥进行解密。像下面这样：

第三方机构向多家公司颁发证书的情况：

客户端能解密同一家第三机构颁发的所有证书：

最终导致其它持有同一家第三方机构证书的中间人可以进行调包：

这个问题需要使用数字签名技术。

数字签名

数字签名可以解决同一机构办法的不同证书被篡改的问题。

证书应该放到客户端，客户端拿到证书后应该可以分辨证书是否被篡改了，如何才能具有这个辨别能力？

**举例：**比如你是HR，你手上拿到候选人的学历证书，证书上写了持证人，颁发机构，颁发时间等等，同时证书上，还写有一个最重要的：证书编号！我们怎么鉴别这张证书是的真伪呢？只要拿着这个证书编号上相关机构去查，如果证书上的持证人与现实的这个候选人一致，同时证书编号也能对应上，那么就说明这个证书是真实的。

客户端也同样可以采用这种机制，如下图：

这个"第三方机构"如果是个远端服务，整个交互都会慢了。所以，这个第三方机构的验证功能只能放在客户端的本地。

客户端本地如何验证证书

证书本身就已经告诉客户端怎么验证证书的真伪。

也就是证书上写着如何根据证书的内容生成证书编号。客户端拿到证书后根据证书上的方法自己生成一个证书编号，如果生成的证书编号与证书上的证书编号相同，那么说明这个证书是真实的。

同时，为避免证书编号本身又被调包，所以使用第三方的私钥进行加密。

这地方有些抽象，通过下图帮助理解：

证书的制作如图所示。证书中的“编号生成方法MD5”就是告诉客户端：你使用MD5对证书的内容求值就可以得到一个证书编号。

当客户端拿到证书后，开始对证书中的内容进行验证，如果客户端计算出来的证书编号与证书中的证书编号相同，则验证通过：

但是第三方机构的公钥怎么跑到了客户端的机器中呢？世界上这么多机器。

其实呢，现实中，浏览器和操作系统都会维护一个权威的第三方机构列表（包括它们的公钥）。因为客户端接收到的证书中会写有颁发机构，客户端就根据这个颁发机构的值在本地找相应的公钥。

到这里上文提到的，证书就是HTTPS中数字证书，证书编号就是数字签名，而第三方机构就是指数字证书签发机构（CA）。

总结

HTTPS要保证客户端与服务器端的通信安全，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。

图例+自己的理解：

**目标：**通信过程使用对称加密，客户端要安全地得到服务端的密钥。

整体过程：

1. 网站通过第三方权威机构将自己的公钥进行加密，这一工程使用第三方机构的私钥，得到证书
2. 客户端发起请求，获取服务器证书
3. 客户端通过证书的加密方法，利用第三方的公钥进行解密，得到服务端的公钥
4. 如果生效则随机生成会话密钥
5. 将会话密钥通过服务端的公钥进行加密，发送给服务端
6. 服务端通过自身密钥进行解密，得到会话密钥
7. 将信息利用会话密钥进行对称加密
8. 将加密后的信息返回给客户端
9. 客户端利用会话密钥进行解密

流程图：

过程中出现的问题：

（1）如果使用对称加密，将密钥发给客户端，那么中间过程如果被恶意机构获取，将密钥修改或者替换，那么通信过程不安全

我们可以使用非对称加密的方式，即服务端持有密钥，客户端持有公钥，然后在这个过程中进行加密解密

（2）那如何将公钥安全地发给客户端

显然浏览器不能存储所有网址的公钥，但是我们可以持有少量权威机构的公钥，那么我们就可以利用一个权威的第三方机构的公钥，然后利用这个公钥对第三方机构加密的信息进行解密

（3） 为什么需要数字编号

如果没有数字编号，每个通过第三方机构获得的公钥都可以对信息进行解密和再次加密，第三方机构也不能分辨这个过程，因为只要是公钥加密的信息，私钥就可以解密，所有我们需要一个编号，根据加密编号和公钥来第三方机构查询，来确定我们访问的网站是否是这个编号

（4）如何加快效率

通过第三方查询的方式显然会降低我们的响应速度，那么我们可不可以利用浏览器进行本地解密，

我们的数字证书可以有一个编号的生成方法，我们根据证书的内容利用生成方法得到证书编号，和被第三方机构私钥加密后的密文根据我们持有的第三方机构的公钥解密得到的证书编号进行匹配，如果匹配成功则通信进行

（5）如何获得对称加密的密钥

如果认证通过后，我们将可以获得服务器的公钥，然后随机生成会话密钥，在客户端利用服务端公钥进行加密，然后服务端使用服务端私钥进行解密，然后得到生成会话密钥，之后的通信即可用这个密钥进行加密。

其他补充
https://developer.51cto.com/art/201912/607603.htm

版本比较

HTTP1.0最早在网页中使用是在1996年，那个时候只是使用一些较为简单的网页上和网络请求上，而HTTP1.1则在1999年才开始广泛应用于现在的各大浏览器网络请求中，同时HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在：

1. 缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
2. 带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
3. 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
4. Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。
5. 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。

HTTP2.0的多路复用和HTTP1.X中的长连接复用有什么区别？

• HTTP/1.0 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；

• HTTP/1.1 Pipeling解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；

• HTTP/2多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；
  具体如图：

  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EbHE5TOL-1582031108977)(C:\Users\lenovo\AppData\Roaming\Typora\typora-user-images\image-20200218170159202.png)]

资料

• https://www.cnblogs.com/heluan/p/8620312.html
• 加密：https://blog.csdn.net/chendasheng/article/details/102683901
• 加密：https://blog.csdn.net/qq_32998153/article/details/80022489