HTTP和HTTPS

目录

HTTP和HTTPS的基本概念(应用层协议）

HTTP的版本

HTTP状态码

HTTP请求报文

GET和POST请求

GET和POST请求的区别

条件GET方法

HTTP与HTTPS有什么区别？

HTTP的工作原理

HTTP的长链接 

http1.1长链接判断一个请求已经结束了

HTTP管线化

HTTPS的工作原理

HTTPS的优点

HTTPS的缺点：

HTTPS的优缺点（总结）

对称加密

非对称加密

证书

HTTPS的加密

---

HTTP和HTTPS的基本概念(应用层协议）

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

HTTPS（HyperText Transfer Protocol Secure：超文本传输安全协议）：是以安全为目标的HTTP通道，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。HTTPS 开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

HTTP的版本

HTTP协议主要有1.0,1.1,2.0三个版本:

HTTP/1.0:

1. 0.9版本,第一次定义HTTP基本功能。
2. 1.0版本,增加内容类型信息。定义了GET、POST、HEAD等方法。

HTTP/1.1：

1. 增加Host请求头,支持同时连接多个主机。
2. 新增缓存处理机制。
3. 增加Range请求头,支持断点续传。
4. 增加PUT和DELETE方法。
5. 增加流水线的概念,支持在同一个TCP连接上发起多个请求。

HTTP/1的长连接：

        HTTP长连接（long connection）与短连接（short connection）本质上是TCP长连接和短连接：短连接是指在一次HTTP请求和响应之后立即关闭本次TCP连接，下次请求响应重建一个新的TCP连接；而长连接是指请求响应之后并不立即关闭本次TCP连接，下次请求响应继续重用该TCP连接。HTTP/1.0默认短连接，HTTP/1.1起默认长连接，长连接通过请求头Connection: keep-alive启用长连接、通过Keep-Alive: timeout=20设置长连接的超时时间（秒）。

HTTP/1的长轮询： 

而HTTP长轮询（long polling）是指服务端收到请求后若有数据立即返回，若无数据则保持到有数据或一段时间后超时，浏览器收到响应后立即重新发送相同的请求；HTTP短轮询（short polling）是指服务端收到请求后无论是否有数据都立即返回，浏览器收到响应后间隔一段时间后重新发送相同的请求。轮询建立在连接基础上，轮询是长是短与连接是长是短无关。

 HTTP长轮询主要用于实现需要实时获取数据的地方，例如：即时消息、实时股票价格等，其主要技术要点在于服务端无数据时如何保持到有数据或超时。另外在请求发生频率上，长轮询也可以在入短连接一样收到响应后间隔一段时间后才发送，只是会不够实时；短轮询也可以如长连接一样在收到响应后立即发送，只是会给服务器端造成过大压力。

HTTP/2.0:

1. 二进制协议,更高效。
2. 全双工:客户端和服务器之间可以同时发送数据。
3. 数据流:可以在一个连接中交替使用多个流进行数据传输。
4. 首部压缩:发送相同的首部只发送一次。
5. 服务端推送:服务器可以在客户端请求时主动推送数据。

HTTP/2的队头阻塞：

HTTP1.1中引入了长连接，允许多个连接复用一个TCP连接。

当多个请求先后调用HTTP发送的时候，如果前一个请求不响应的话，后一个请求是不会发送的。
所以如果前一个响应阻塞的话，后边的请求也会被迫阻塞，叫做队头阻塞。

HTTP2.0时，引入了帧、流的概念。

HTTP2是基于TCP的。HTTP2允许多个请求不按照先后顺序发送数据，并允许穿插的发送数据，也就是每次发送一个帧。

那么怎么区分帧属于哪个HTTP请求呢？

会对每个HTTP请求进行编号，然后再帧中插入对应的HTTP编号和其在HTTP请求中的位置序号，然后发送到服务器，服务器根据HTTP编号和位置序号来将帧重组，然后同时乱序的发送应答，客户端也通过HTTP编号和位置序号来重组帧。

这样就避免了HTTP层面的队头阻塞。

但是仍无法解决TCP的队头阻塞。

TCP由于引入了滑动窗口，并且每次可以发送多个数据，并且可以乱序接受。当序号大的数据先到达后，仍然不能被应用程序读取，需要等到序号靠前的数据到了之后，才能被应用程序读取，这也出现了队头阻塞。

这个队头阻塞是TCP实现可靠传输的副作用，无法解决。

HTTP/3.0:

1. 实现了类似TCP的流量控制，传输可靠性的功能。
2. 实现了快速握手功能（QUIC基于UDP，UDP是面向无连接的，不需要握手和挥手，比TCP快
3. 集成了TLS加密功能
4. 多路复用，彻底解决TCP中队头阻塞的问题（单个“流”是有序的，可能会因为丢包而阻塞，但是其他流不会受到影响）

总结

• HTTP1.1的缺点：安全性不足和性能不高；
• HTTP2.0完全兼容HTTTP1.0，是“更安全的HTTP，更快的HTTPS”，头部压缩，多路复用等技术充分利用了带宽，降低了延迟。
• HTTP3.0的底层支撑协议QUIC基于UDP实现，又含TCP的特点，实现了又快又可靠的协议。
   

HTTP状态码

HTTP状态码的职责：

当客户端向服务器端发送HTTP请求后，用于描述服务器端返回的请求结果。

HTTP状态码的分类：

（1）1xx 信息性状态码

（2）2xx 成功状态码

（3）3xx 重定向状态码

（4）4xx 客户端错误状态码

（5）5xx 服务器端错误状态码

常用的状态码：

2打头：

（请求成功）表示成功处理了请求的状态代码。
200 （成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
201 （已创建） 请求成功并且服务器创建了新的资源。
202 （已接受） 服务器已接受请求，但尚未处理。
203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
204 （无内容） 服务器成功处理了请求，但没有返回任何内容。
205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。
206 （部分内容） 服务器成功处理了部分 GET 请求。

3打头：

（请求被重定向）表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。
300 （多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301 （永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302 （临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304 （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305 （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。

4打头：
（请求错误）这些状态代码表示请求可能出错，妨碍了服务器的处理。
400 （错误请求） 服务器不理解请求的语法。
401 （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
403 （禁止） 服务器拒绝请求。
404 （未找到） 服务器找不到请求的网页。
405 （方法禁用） 禁用请求中指定的方法。
406 （不接受） 无法使用请求的内容特性响应请求的网页。
407 （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
408 （请求超时） 服务器等候请求时发生超时。
409 （冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410 （已删除） 如果请求的资源已永久删除，服务器就会返回此响应。
411 （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
412 （未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
413 （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414 （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
415 （不支持的媒体类型） 请求的格式不受请求页面的支持。
416 （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
417 （未满足期望值） 服务器未满足"期望"请求标头字段的要求。

5打头：
（服务器错误）这些状态代码表示服务器在尝试处理请求时发生内部错误。 这些错误可能是服务器本身的错误，而不是请求出错。
500 （服务器内部错误） 服务器遇到错误，无法完成请求。
501 （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505 （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。

HTTP请求报文

 http请求报文由三部分组成： 请求行、请求头 、请求正文。请求行、每个请求头与请求正文都由CRLF（回车换行，也即\r\n）分割开来，首行为请求行，余下的为请求头和请求正文，而请求正文有可能会为空，也可能包含CRLF情况，因此不能通过一个CRLF与请求头区别开来，所以采用两个CRLF来间隔请求头和请求正文
1.请求行

请求行的格式为：Method Request-URI HTTP-version CRLF

method为大写，有以下几种：GET、POST、HEAD、OPTIONS、PUT、DELETE、TRACE、CONNECT。但是实际使用中一般使用GET和POST就可以任何需求了，其他的被设计出来主要是让人从语义来直观看出该怎么处理数据，但是即使使用了DELETE方法，具体的删除还是得我们自己来实现。

Request-URI是一个统一资源标识符

HTTP-version为请求的HTTP的协议版本

GET请求示例GET /form.html HTTP/1.1 (CRLF)

POST请求示例POST /reg.jsp HTTP/1.1 (CRLF)
Accept:image/gif,image/x-xbit,... (CRLF)

2.请求头

请求头的格式为键值对。一般常见的请求头如下：

User-Agent:PostmanRuntime/7.26.8     表示产生请求的客户端程序

Accept:*/*     表示可接受的响应的类型为全部类型

Accept-Language:zh     表示可接受的响应的语言为中文

Accept-Encoding:gzip     表示客户端请求的压缩方式

Cookie:value     值由登陆之后服务端下发

token:value     值由登陆之后服务端下发

3.请求正文
 

 

HTTP的相应也是由三部分组成：状态行、响应头、响应正文

状态行的组成为HTTP-version Status-code Reason-phrase CRLF

HTTP-version 为HTTP的版本，Status-code为响应状态码，Reason-phrase表示状态码的文本描述

状态码由三个数字组成，第一个数字表示响应类别

GET和POST请求

• get 和 post请求是http协议中的两种请求方式。
• get一般用来获取服务器的信息的，post一般是用来更新信息。

GET和POST请求的区别

1. GET可以存在cache(缓存)中，POST不可以
2. GET请求在url中传递的参数是有长度限制的，POST对长度没有限制。
3. GET参数通过URL传递，POST放在Requestbody中。
4. GET请求参数会完整的保留在浏览器的历史记录中，POST请求的参数不会保留
5. 原则上post肯定要比get安全，毕竟传输参数时url不可见
6. GET产生一个TCP数据包，POST产生两个TCP数据包。
7. 对于GET请求，浏览器会把http header和data一起发送出去，服务器响应200，请求成功。
8. 对于POST请求，浏览器先发送header，服务器会响应100（已经收到请求的第一部分，正在等待其余部分），浏览器再次发送data，服务器返回200，请求成功。并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

条件GET方法

尽管缓存可以减少用户感知到的响应时间，但是缓存引入了一个新的问题。
存储在cache中的对象可能是陈旧的。换句话说，自从对象的副本被缓存到这个cache,存储在web服务器端的对象可能被修改过。

幸运的是，HTTP提供了条件GET(conditional GET)机制，这个机制使得cache能够确认它的对象是最新的。

什么样的HTTP请求报文属于条件请求报文呢？
（1）请求报文使用了GET方法
（2）请求报文包括了一个If-Modified-Since头行

HTTP与HTTPS有什么区别？

1、HTTPS协议需要到CA（Certificate Authority，数字证书认证机构）申请证书，一般免费证书较少，因而需要一定费用。

2、HTTP是超文本传输协议，信息是明文传输，数据是不加密的，而HTTPS则是具有安全性的SSL加密传输协议。

3、HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，HTTP是80端口，HTTPS是443端口。

4、HTTP的连接很简单，是无状态的，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP协议安全。

HTTP的工作原理

1.客户端与服务器建立TCP连接（三次握手）
2.连接成功后，客户端发送请求给服务器
3.服务器接收到客户端发送的请求后作出相应，并将响应信息发送给客户端
4.服务器发送完响应信息后，就会断开TCP连接，因此HTTP是无状态的，下一次访问的时候不会知道之前访问的过程
5.客户端接收到响应信息，浏览器进行解析，将html文件解析后呈现一个网页在浏览器上

HTTP的长链接 

HTTP协议的长连接本质上就是TCP的长连接。所以HTTP长连接的保持就是tcp的保活机制

http1.1长链接判断一个请求已经结束了

可以理解为判断是否结束为判断是否读取完整个请求

-> 是否拥有请求体，有点的话
  -> 判断请求体大小判断
    -> 静态判断利用Content-Length
    -> 动态判断利用Transfer-Encoding为chunked
-> 判断请求是否结束

• 判断传输数据是否达到了 Content-Length 指示的大小
• 动态生成的文件没有Content-Length，它是分块传输（chunked），这时候要根据chunked 编码来判断，chunked 编码的数据在最后有一个空的 chunked 块，表明本次传输数据结束。

HTTP管线化

http的管线化，也叫管道化，英文是HTTP Pipelining。管道化是指：客户端可以发送多次请求到服务端，而不需要等待上一次请求得到响应的时候才能进行下一次请求，这样就可以实现并发。在等待上一个请求响应的同时，发送下一个请求。HTTP Pipelining其实是把多个HTTP请求放到一个TCP连接中一一发送，因为http本质还是基于tcp的，而在发送过程中不需要等待服务器对前一个请求的响应；只不过，客户端还是要按照发送请求的顺序来接收响应。这也是管道的特点，而不会出现一个前面的请求被后面的请求覆盖的情况。

HTTPS的工作原理

1、客户端发起HTTPS请求

这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。

2、服务端的配置

采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。

这套证书其实就是一对公钥和私钥，如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。

3、传送证书

这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。

4、客户端解析证书

这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。

如果证书没有问题，那么就生成一个随机值，然后用证书对该随机值进行加密，就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。

5、传送加密信息

这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。

6、服务段解密信息

服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密，所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。

7、传输加密后的信息

这部分信息是服务段用私钥加密后的信息，可以在客户端被还原。

8、客户端解密信息

客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容，整个过程第三方即使监听到了数据，也束手无策。

HTTPS的优点

1、SEO方面

谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。

2、安全性

尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：

（1）、使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；

（2）、HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。

（3）、HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

HTTPS的缺点：

1、SEO方面

据ACM CoNEXT数据显示，使用HTTPS协议会使页面的加载时间延长近50%，增加10%到20%的耗电，此外，HTTPS协议还会影响缓存，增加数据开销和功耗，甚至已有安全措施也会受到影响也会因此而受到影响。

而且HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。

最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。

2、经济方面

（1）、SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。

（2）、SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗（SSL有扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器、操作系统支持，Windows XP就不支持这个扩展，考虑到XP的装机量，这个特性几乎没用）。

（3）、HTTPS连接缓存不如HTTP高效，大流量网站如非必要也不会采用，流量成本太高。

（4）、HTTPS连接服务器端资源占用高很多，支持访客稍多的网站需要投入更大的成本，如果全部采用HTTPS，基于大部分计算资源闲置的假设的VPS的平均成本会上去。

（5）、HTTPS协议握手阶段比较费时，对网站的相应速度有负面影响，如非必要，没有理由牺牲用户体验。

HTTPS的优缺点（总结）

1.优点：
（1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；

（2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。

（3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

（4）谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。

2.缺点：
（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；

（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；

（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。

（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。

（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。
 

对称加密

•  采⽤单钥密码系统的加密⽅法，同⼀个密钥可以同时⽤作信息的加密和解密，这种加密⽅法称为对称加密，也称为单密钥加密，特征：加密和解密所⽤的密钥是相同的
• 常⻅对称加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等
• 特点：算法公开、计算量⼩、加密速度快、加密效率⾼
• 对称加密其实就是通过同⼀个 "密钥" , 把明⽂加密成密⽂, 并且也能把密⽂解密成明⽂

⼀个简单的对称加密, 按位异或

假设 明⽂ a = 1234, 密钥 key = 8888 则加密 a ^ key 得到的密⽂ b 为 9834. 然后针对密⽂ 9834 再次进⾏运算 b ^ key, 得到的就是原来的明⽂ 1234. (对于字符串的对称加密也是同理, 每⼀个字符都可以表⽰成⼀个数字) 当然, 按位异或只是最简单的对称加密. HTTPS 中并不是使⽤按位异或

非对称加密

• 需要两个密钥来进⾏加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。
• 常⻅⾮对称加密算法(了解)：RSA，DSA，ECDSA
• 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，⽽使得加密解密速度没有对
• 称加密解密的速度快。
• ⾮对称加密要⽤到两个密钥, ⼀个叫做 "公钥", ⼀个叫做 "私钥".
• 公钥和私钥是配对的. 最⼤的缺点就是运算速度⾮常慢，⽐对称加密要慢很多.
• 通过公钥对明⽂加密, 变成密⽂
• 通过私钥对密⽂解密, 变成明⽂
• 也可以反着⽤
• 通过私钥对明⽂加密, 变成密⽂
• 通过公钥对密⽂解密, 变成明⽂

⾮对称加密的数学原理⽐较复杂, 涉及到⼀些 数论 相关的知识. 这⾥举⼀个简单的⽣活上的例⼦.

A 要给 B ⼀些重要的⽂件, 但是 B 可能不在. 于是 A 和 B 提前做出约定:

B 说: 我桌⼦上有个盒⼦, 然后我给你⼀把锁, 你把⽂件放盒⼦⾥⽤锁锁上, 然后我回头拿着钥匙来开锁取⽂件.

在这个场景中, 这把锁就相当于公钥, 钥匙就是私钥. 公钥给谁都⾏(不怕泄露), 但是私钥只有 B ⾃⼰持有. 持有私钥的⼈才能解密.

证书

中间⼈有没有可能篡改该证书？

• 中间⼈篡改了证书的明⽂
• 由于他没有CA机构的私钥，所以⽆法hash之后⽤私钥加密形成签名，那么也就没法办法对篡改后的证书形成匹配的签名
• 如果强⾏篡改，客⼾端收到该证书后会发现明⽂和签名解密后的值不⼀致，则说明证书已被篡改，证书不可信，从⽽终⽌向服务器传输信息，防⽌信息泄露给中间⼈

中间⼈整个掉包证书？

• 因为中间⼈没有CA私钥，所以⽆法制作假的证书(为什么？)
• 所以中间⼈只能向CA申请真证书，然后⽤⾃⼰申请的证书进⾏掉包
• 这个确实能做到证书的整体掉包，但是别忘记，证书明⽂中包含了域名等服务端认证信息，如果整体掉包，客⼾端依旧能够识别出来。
• 永远记住：中间⼈没有CA私钥，所以对任何证书都⽆法进⾏合法修改，包括⾃⼰的

 为什么摘要内容在⽹络传输的时候⼀定要加密形成签名?

假设我们的证书只是⼀个简单的字符串 hello, 对这个字符串计算hash值(⽐如md5), 结果为

BC4B2A76B9719D91

如果 hello 中有任意的字符被篡改了, ⽐如变成了 hella, 那么计算的 md5 值就会变化很⼤.

BDBD6F9CF51F2FD8

然后我们可以把这个字符串 hello 和 哈希值 BC4B2A76B9719D91 从服务器返回给客⼾端, 此时客⼾端如何验证 hello 是否是被篡改过?

那么就只要计算 hello 的哈希值, 看看是不是 BC4B2A76B9719D91

 但是还有个问题, 如果⿊客把 hello 篡改了, 同时也把哈希值重新计算下, 客⼾端就分辨不出来了呀

 

所以被传输的哈希值不能传输明⽂, 需要传输密⽂.

所以，对证书明⽂(这⾥就是“hello”)hash形成散列摘要，然后CA使⽤⾃⼰的私钥加密形成签名，将

hello和加密的签名合起来形成CA证书，颁发给服务端，当客⼾端请求的时候，就发送给客⼾端，中间 ⼈截获了，因为没有CA私钥，就⽆法更改或者整体掉包，就能安全的证明，证书的合法性。

最后，客⼾端通过操作系统⾥已经存的了的证书发布机构的公钥进⾏解密, 还原出原始的哈希值, 再进⾏校验.

为什么签名不直接加密，⽽是要先hash形成摘要?

缩⼩签名密⽂的⻓度,加快数字签名的验证签名的运算速度

HTTPS的加密

HTTPS ⼯作过程中涉及到的密钥有三组.

第⼀组(⾮对称加密): ⽤于校验证书是否被篡改. 服务器持有私钥(私钥在形成CSR⽂件与申请证书时获

得), 客⼾端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器在客

⼾端请求是，返回携带签名的证书. 客⼾端通过这个公钥进⾏证书验证, 保证证书的合法性，进⼀步保

证证书中携带的服务端公钥权威性。

第⼆组(⾮对称加密): ⽤于协商⽣成对称加密的密钥. 客⼾端⽤收到的CA证书中的公钥(是可被信任的)

给随机⽣成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥.

第三组(对称加密): 客⼾端和服务器后续传输的数据都通过这个对称密钥加密解密.

其实⼀切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥⼯作的.

第⼆组⾮对称加密的密钥是为了让客⼾端把这个对称密钥传给服务器.

第⼀组⾮对称加密的密钥是为了让客⼾端拿到第⼆组⾮对称加密的公钥.