HTTP协议解析

目录

1.HTTP协议的概念

2.HTTP协议格式

3.HTTPS

---

1.HTTP协议的概念

在我们之前学习网络的过程中，我们知道了目前主流网络分层模型共分为5层，分别是物理层，数据链路层，网络层，传输层，应用层。而我们HTTP协议就属于应用层协议，主要决定了数据传输过去之后具体怎么使用。

HTTP协议目前已经发展到了3.0版本了，但目前我们主要使用的还是 HTTP1.1 和 HTTP2.0 。所以当前我们讨论的还是以HTTP1.1为主。HTTP 往往是基于传输层的 TCP 协议实现的. (HTTP1.0, HTTP1.1, HTTP2.0 均为TCP, HTTP3 基于 UDP 实现)。

我们平时打开一个网站, 就是通过 HTTP 协议来传输数据的.

 当我们在浏览器中输入一个 Google搜索的 "网址" (URL) 时, 浏览器就给Google的服务器发送了一个 HTTP 请求, Google的服务器返回了一个 HTTP 响应.

这个响应结果被浏览器解析之后, 就展示成我们看到的页面内容. (这个过程中浏览器可能会给服务器发 送多个 HTTP 请求, 服务器会对应返回多个响应, 这些响应里就包含了页面 HTML, CSS, JavaScript, 图片, 字体等信息).

1.1 理解什么是应用层协议

我们已经学过 TCP/IP , 已经知道目前数据能从客户端进程经过路径选择跨网络传送到服务器端进程 [ IP+Port ]

可是，仅仅把数据从A点传送到B点就完了吗？

很明显，对于传输过来的数据，我们还需要对其进行加工处理或者使用。

这就好比，在淘宝上买了一部手机，卖家[ 客户端 ]把手机通过顺丰[ 传送+路径选择 ] 送到买家 [ 服务器 ] 手里就完了吗？

当然不是，买家还要使用这款产品，还要在使用之后，给卖家打分评论。

 所以，我们把数据从A端传送到B端， TCP/IP 解决的是传输的功能，而两端还要对数据进行加工处理或者使用，所以我们还需要一层协议，不关心通信细节，关心应用细节。

这层协议叫做应用层协议。而应用是有不同的场景的，所以应用层协议是有不同种类的，其中经典协议 之一的HTTP就是其中的佼佼者.

1.2 HTTP协议工作过程 

当我们在浏览器中输入一个 "网址", 此时浏览器就会给对应的服务器发送一个HTTP请求. 对方服务器收 到这个请求之后, 经过计算处理, 就会返回一个HTTP响应。例如下图。

事实上, 当我们访问一个网站的时候, 可能涉及不止一次的 HTTP 请求/响应 的交互过程. 

2. HTTP协议格式

有关这一部分，我们需要通过抓包工具Fiddler(下载地址: https://www.telerik.com/fiddler/)，分析 HTTP 请求/响应的细节。

有关该工具的使用大家可以在网上自行学习，我们这里只会用到最基础的功能，大家不了解也可以直接看到结果。

2.1 HTTP协议格式概述

以下是一个HTTP响应/请求的抓包结果：

HTTP请求

首行: [方法] + [url] + [版本]

Header: 请求的属性, 冒号分割的键值对;每组属性之间使用\n分隔;遇到空行表示Header部分结束

Body: 空行后面的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有 一个Content-Length属性来标识Body的长度

 HTTP响应

首行: [版本号] + [状态码] + [状态码解释]

Header: 请求的属性, 冒号分割的键值对;每组属性之间使用\n分隔;遇到空行表示Header部 分结束

Body: 空行后面的内容都是Body. Body允许为空字符串. 如果Body存在, 则在Header中会有 一个Content-Length属性来标识Body的长度; 如果服务器返回了一个html页面, 那么html页面内容就是在body中.

协议格式总结 

 那么空行存在的意义是什么？

因为 HTTP 协议并没有规定报头部分的键值对有多少个. 空行就相当于是 "报头的结束标记", 或者 是 "报头和正文之间的分隔符".

HTTP 在传输层依赖 TCP 协议, TCP 是面向字节流的. 如果没有这个空行, 就会出现 "粘包问题".

2.2 HTTP请求（Request） 

2.2.1 URL

平时我们俗称的 "网址" 其实就是说的 URL (Uniform Resource Locator 统一资源定位符). 互联网上的每个文件都有一个唯一的URL，它包含的信息指出文件的位置以及浏览器应该怎么处理它.

 

一个具体的URL

https://www.bilibili.com/bangumi/play/ss41410?from_spmid=666.4.0.0

似乎格式和我们在上面看到的不太一样，事实上在这个URL中有部分信息被省略了。

https : 协议方案名. 常见的有 http 和 https, 也有其他的类型. (例如访问 mysql 时用的 jdbc:mysql )

user:pass : 登陆信息. 现在的网站进行身份认证一般不再通过 URL 进行了. 一般都会省略

www.bilibili.com: 服务器地址. 此处是一个 "域名", 域名会通过 DNS 系统解析成一个具体的 IP 地址.

端口号: 上面的 URL 中端口号被省略了. 当端口号省略的时候, 浏览器会根据协议类型自动决定使用 哪个端口. 例如 http 协议默认使用 80 端口, https 协议默认使用 443 端口.

/bangumi/play/ss41410: 带层次的文件路径。相当于告诉我们要获取服务器上的具体哪个资源

from_spmid=666.4.0.0: 查询字符串(query string). 本质是一个键值对结构. 键值对之间使 用 & 分隔. 键和值之间使用 = 分隔.

片段标识: 此 URL 中省略了片段标识. 片段标识主要用于页面内跳转. (例如 Vue 官方文档: https://c n.vuejs.org/v2/guide/#%E8%B5%B7%E6%AD%A5, 通过不同的片段标识跳转到文档的不同章节 

关于服务器地址，端口号与带层次的文件路径：

服务器地址相当于我们买东西时去的百货公司，百货公司里又有许多不同的商铺，而端口号就相当于告诉我们要去哪一个商铺，带层次的文件路径就具体到了我们具体要在这个商铺内买的东西

关于 query string 

query string 中的内容是键值对结构. 其中的 key 和 value 的取值和个数, 完全都是程序猿自己约定的. 我们可以通过这样的方式来自定制传输我们需要的信息给服务器. 

URL 中的可省略部分 

协议名: 可以省略, 省略后默认为 http://

ip 地址 / 域名: 在 HTML 中可以省略(比如 img, link, script, a 标签的 src 或者 href 属性). 省 略后表示服务器的 ip / 域名与当前 HTML 所属的 ip / 域名一致.

端口号: 可以省略. 省略后如果是 http 协议, 端口号自动设为 80; 如果是 https 协议, 端口号自 动设为 443.

带层次的文件路径: 可以省略. 省略后相当于 / . 有些服务器会在发现 / 路径的时候自动访问 /index.html

查询字符串: 可以省略

片段标识: 可以省略

2.2.2 关于 URL encode 

像 / ? : 等这样的字符, 已经被url当做特殊意义理解了. 因此这些字符不能随意出现.

比如, 某个参数中需要带有这些特殊字符, 就必须先对特殊字符进行转义.

一个中文字符由 UTF-8 或者 GBK 这样的编码方式构成, 虽然在 URL 中没有特殊含义, 但是仍然需 要进行转义. 否则浏览器可能把 UTF-8/GBK 编码中的某个字节当做 URL 中的特殊符号. 

转义的规则如下: 将需要转码的字符转为16进制，然后从右到左，取4位(不足4位直接处理)，每2位做一 位，前面加上%，编码成%XY格式  

urldecode就是urlencode的逆过程 。在服务器收到客户端请求后就会进行urldecode。

2.2.3 有关方法（method）

 虽然看上去有很多的方法，但实际上我们最常用的就只有GET和POST方法，因为其他的方法几乎都能被GET和POST所替代，甚至其实GET和POST也没有本质区别，所以部分企业为了方便就统一只使用GET或者POST

1. GET 方法 

GET 是最常用的 HTTP 方法. 常用于获取服务器上的某个资源.

在浏览器中直接输入 URL, 此时浏览器就会发送出一个 GET 请求.

另外, HTML 中的 link, img, script 等标签, 也会触发 GET 请求. 

GET 请求的特点

首行的第一部分为 GET

URL 的 query string 可以为空, 也可以不为空.

header 部分有若干个键值对结构.

body 部分为空.

关于 GET 请求的 URL 长度问题 

网上有些资料上描述: get请求长度最多1024kb 这样的说法是错误的.

HTTP 协议由 RFC 2616 标准定义, 标准原文中明确说明: "Hypertext Transfer Protocol -- HTTP/1.1," does not specify any requirement for URL length.

没有对 URL 的长度有任何的限制.

实际 URL 的长度取决于浏览器的实现和 HTTP 服务器端的实现. 在浏览器端, 不同的浏览器最大长 度是不同的, 但是现代浏览器支持的长度一般都很长; 在服务器端, 一般这个长度是可以配置的. 

2. POST 方法

POST 方法也是一种常见的方法. 多用于提交用户输入的数据给服务器(例如登陆页面).

通过 HTML 中的 form 标签可以构造 POST 请求, 或者使用 JavaScript 的 ajax 也可以构造 POST 请求. 

POST 请求的特点

首行的第一部分为 POST

URL 的 query string 一般为空 (也可以不为空) header 部分有若干个键值对结构.

body 部分一般不为空. body 内的数据格式通过 header 中的 Content-Type 指定. body 的长度由 header 中的 Content-Length 指定. 

接下来我们看一道经典面试题: 谈谈 GET 和 POST 的区别 

首先回答，两者并没有本质区别

语义不同: GET 一般用于获取数据, POST 一般用于提交数据.

GET 的 body 一般为空, 需要传递的数据通过 query string 传递, POST 的 query string 一般 为空, 需要传递的数据通过 body 传递

GET 请求一般是幂等的, POST 请求一般是不幂等的. (即得到的结果是可预测的。如果多次请求得到的结果一样, 就视为请求是幂等的).

GET 可以被缓存, POST 不能被缓存. (这一点也是承接幂等性).

补充说明:

关于语义: GET 完全可以用于提交数据, POST 也完全可以用于获取数据.

关于幂等性: 标准建议 GET 实现为幂等的. 实际开发中 GET 也不必完全遵守这个规则(主流网 站都有 "猜你喜欢" 功能, 会根据用户的历史行为实时更新现有的结果.

关于安全性: 有些资料上说 "POST 比 GET 请安全". 这样的说法是不科学的. 是否安全取决于 前端在传输密码等敏感信息时是否进行加密, 和 GET POST 无关.

关于传输数据量: 有的资料上说 "GET 传输的数据量小, POST 传输数据量大". 这个也是不科 学的, 标准没有规定 GET 的 URL 的长度, 也没有规定 POST 的 body 的长度. 传输数据量多少, 完全取决于不同浏览器和不同服务器之间的实现区别.

关于传输数据类型: 有的资料上说 "GET 只能传输文本数据, POST 可以传输二进制数据". 这 个也是不科学的. GET 的 query string 虽然无法直接传输二进制数据, 但是可以针对二进制数 据进行 url encode. 

3. 其他方法 

PUT 与 POST 相似，只是具有幂等特性，一般用于更新

DELETE 删除服务器指定资源

OPTIONS 返回服务器所支持的请求方法

HEAD 类似于GET，只不过响应体不返回，只返回响应头

TRACE 回显服务器端收到的请求，测试的时候会用到这个

CONNECT 预留，暂无使用

2.2.4 有关请求 "报头" (header) 

header 的整体的格式也是 "键值对" 结构.

每个键值对占一行. 键和值之间使用分号分割.

由于报头的种类很多，这里只介绍几个常用的。

这里我截取一个请求的部分截图来帮助大家理解。

 Host ：表示服务器主机的地址和端口。这里我们可以看到是gitee.com

————————————————————————————————————————

Content-Length ：表示 body 中的数据长度。这里我们可以看到是436。主要是帮助接收端识别不同请求的body，避免出现粘连现象。

————————————————————————————————————————

Content-Type：表示请求的 body 中的数据格式

常见选项主要有：

application/x-www-form-urlencoded: form 表单提交的数据格式

multipart/form-data: form 表单提交的数据格式(在 form 标签中加上 enctyped="multipart/form-data" . 通常用于提交图片/文件.

application/json: 数据为 json 格式

————————————————————————————————————————

User-Agent (简称 UA)：表示浏览器/操作系统的属性. 形如我们上面看到的

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.36

————————————————————————————————————————

Referer ：表示这个页面是从哪个页面跳转过来的. 形如

Referer: https://gitee.com/login

如果直接在浏览器中输入URL, 或者直接通过收藏夹访问页面时是没有 Referer 的.

Cookie 

Cookie 中存储了一个字符串, 这个数据可能是客户端(网页)自行通过 JS 写入的, 也可能来自于服务器(服务器在 HTTP 响应的 header 中通过 Set-Cookie 字段给浏览器返回数据).

往往可以通过这个字段实现 "身份标识" 的功能.

每个不同的域名下都可以有不同的 Cookie, 不同网站之间的 Cookie 并不冲突

 我们通过一个登录过程来理解Cookie的身份标识功能

 这个过程和去医院看病很相似

1. 到了医院先挂号. 挂号时候需要提供身份证, 同时得到了一张 "就诊卡", 这个就诊卡就相当于 患者的 "令牌".

2. 后续去各个科室进行检查, 诊断, 开药等操作, 都不必再出示身份证了, 只要凭就诊卡即可识别 出当前患者的身份.

3. 看完病了之后, 不想要就诊卡了, 就可以注销这个卡. 此时患者的身份和就诊卡的关联就销毁 了. (类似于网站的注销操作)

4. 又来看病, 可以办一张新的就诊卡, 此时就得到了一个新的 "令牌"

当然为了数据安全和Cookie的大小不会太大，Cookie一般保存的只是一个用户id，而用户数据保存在服务器上，服务器可以根据Cookie的用户id来返回相应的用户数据。

 同时Cookie上存储的信息其实是程序猿自定义的,所以也可以存储其他信息。

2.2.5 有关请求 "正文" (body)

正文中的内容格式和 header 中的 Content-Type 密切相关. 上面也罗列了三种常见的情况

常见情况有3种：

1) application/x-www-form-urlencoded 表单提交的数据格式

2) multipart/form-data 通常用于提交图片/文件

3) application/json 数据为 json 格式

这里大家了解一下即可，想要进一步理解只能通过不断去抓包学习

2.2.6 HTTP状态详解

认识 "状态码" (status code)

状态码表示访问一个页面的结果. (是访问成功, 还是失败, 还是其他的一些情况...)

以下为常见的状态码：

200 OK

这是一个最常见的状态码, 表示访问成功，例如访问百度主页

————————————————————————————————————————

 404 Not Found

没有找到资源。浏览器输入一个 URL, 目的就是为了访问对方服务器上的一个资源. 如果这个 URL 标识的资源不存 在, 那么就会出现 404

————————————————————————————————————————

403 Forbidden

表示访问被拒绝. 有的页面通常需要用户具有一定的权限才能访问(登陆后才能访问). 如果用户没有登陆 直接访问, 就容易见到 403.

————————————————————————————————————————

405 Method Not Allowed

前面我们已经学习了 HTTP 中所支持的方法, 有 GET, POST, PUT, DELETE 等. 但是对方的服务器不一定都支持所有的方法(或者不允许用户使用一些其他的方法)

————————————————————————————————————————

500 Internal Server Error

服务器出现内部错误. 一般是服务器的代码执行过程中遇到了一些特殊情况(服务器异常崩溃)会产生这个 状态码

————————————————————————————————————————

504 Gateway Timeout

当服务器负载比较大的时候, 服务器处理单条请求的时候消耗的时间就会很长, 就可能会导致出现超时的 情况

————————————————————————————————————————

302 Move temporarily

临时重定向

就相当于手机号码中的 "呼叫转移" 功能。比如我本来的手机号是 186-1234-5678, 后来换了个新号码 135-1234-5678, 那么不需要让我的朋 友知道新号码, 只要我去办理一个呼叫转移业务, 其他人拨打 186-1234-5678 , 就会自动转移到 135-1234-5678 上。

在登陆页面中经常会见到 302. 用于实现登陆成功后自动跳转到主页.

响应报文的 header 部分会包含一个 Location 字段, 表示要跳转到哪个页面.

————————————————————————————————————————

301 Moved Permanently

永久重定向.

当浏览器收到这种响应时, 后续的请求都会被自动改成新的地址. 301 也是通过 Location 字段来表示要重定向到的新地址.

 

2.3 HTTP响应

2.3.1 认识响应 "报头" (header)

响应报头的基本格式和请求报头的格式基本一致.

类似于 Content-Type , Content-Length 等属性的含义也和请求中的含义一致.

2.3.2 Content-Type 

text/html : body 数据格式是 HTML

text/css : body 数据格式是 CSS

application/javascript : body 数据格式是 JavaScript

application/json : body 数据格式是 JSON

2.3.3 认识响应 "正文" (body) 

正文的具体格式取决于 Content-Type.类似于请求的正文，也是需要我们不断去抓包观察才能进一步了解，所以这里不过多赘述。

3.HTTPS

HTTPS 也是一个应用层协议. 是在 HTTP 协议的基础上引入了一个加密层.（SSL/TLS）

HTTP 协议内容都是按照文本的方式明文传输的. 这就导致在传输过程中出现一些被篡改的情况.

数据在互联网中明文传输是一件比较危险的事情，诸如运营商劫持或者黑客窃取信息等。因此HTTPS 就是在 HTTP 的基础上进行了加密, 进一步的来保证用户的信息安全

3.1 HTTPS 的工作过程 

既然要保证数据安全, 就需要进行 "加密".

网络传输中不再直接传输明文了, 而是加密之后的 "密文".

加密的方式有很多, 但是整体可以分成两大类: 对称加密和非对称加密

3.2 对称加密 

对称加密其实就是通过同一个 "密钥" , 把明文加密成密文, 并且也能把密文解密成明文。

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

假设 明文 a = 1234, 密钥 key = 8888 则

加密 a ^ key 得到的密文 b 为 9834

然后针对密文 9834 再次进行运算 b ^ key, 得到的就是原来的明文 1234

(对于字符串的对称加密也是同理, 每一个字符都可以表示成一个数字)

当然, 按位异或只是最简单的对称加密. HTTPS 中并不是使用按位异或.

引入对称加密之后, 即使数据被截获, 由于黑客不知道密钥是啥, 因此就无法进行解密, 也就不知道请求的 真实内容是啥了

但是事情往往不会那么简单。服务器同一时刻其实是给很多客户端提供服务的. 这么多客户端, 每个人用的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了, 黑客就也能拿到了). 因此服务器就需要维护每个客户端和每个密钥之间的关联关系, 这也是个很麻烦的事情 

所以我们有一种比较理想的做法，就是每次在客户端和服务器建立连接时，双方协商确定这次的密钥是什么。

 

 但是这有一个非常严重的问题，因为密钥是明文传输的，假如被黑客截获后，那么加密就形同虚设了。

因此密钥的传输也必须加密传输

但是要想对密钥进行对称加密, 就仍然需要先协商确定一个 "密钥的密钥". 这就成了 "先有鸡还是先有蛋" 的问题了.

此时密钥的传输再用对称加密就行不通了. 就需要引入非对称加密.

3.3 非对称加密 

非对称加密要用到两个密钥, 一个叫做 "公钥", 一个叫做 "私钥".

公钥和私钥是配对的. 最大的缺点就是运算速度非常慢，比对称加密要慢很多。所以在传输大量数据时一般不会使用非对称加密。

通过公钥对明文加密, 变成密文

通过私钥对密文解密, 变成明文

也可以反着用

通过私钥对明文加密, 变成密文

通过公钥对密文解密, 变成明文 

非对称加密的数学原理比较复杂, 涉及到一些数论相关的知识. 这里举一个简单的生活上的例子 。比如我有下面一个信箱

 由于我只想接收我期望与之通信的朋友信件。于是我在投递口加了一把锁，这把锁的钥匙（公钥）我可以复制n份，发给我想接受其信件的人。只有这些人可以用这把钥匙打开寄信口，把信件投入。

而收信门是另一把锁，打开后可以获取所有信件。这把锁的钥匙（私钥）只有我有。我可以用这把钥匙打开信箱门，取出所有发给我的信件。

对称加密中，我们只需要一个密钥，通信双方同时持有。而非对称加密需要4个密钥。通信双方各自准备一对公钥和私钥。其中公钥是公开的，由信息接受方提供给信息发送方。公钥用来对信息加密。私钥由信息接受方保留，用来解密。而公钥是公开的，所以我们可以互相利用双方的公钥加密后再去传输信息，这样就保证了数据安全。

具体的步骤如下： 

1、消息接收方和发送方准备好公钥和私钥

2、私钥接收方自己留存、公钥发布给消息发送方

3、消息发送方使用接收方公钥对消息进行加密

4、消息接收方用自己的私钥对消息解密

我们可以总结出非对称加密的核心就是：

公钥只能用做数据加密。公钥加密的数据，只能用对应的私钥才能解密。双方互相利用对方的公钥进行加密，接收方用自己的私钥解密。

3.4 中间人攻击 

中间人攻击指的是在通信双方的通道上，混入攻击者。他对接收方伪装成发送者，对放送放伪装成接收者。

        比如黑客可以自己生成一对密钥，然后拦截下发送方给接收方发送的公钥，替换成黑客自己的公钥，这样接收方就会利用黑客的公钥来加密，然后将加密后数据返回，此时黑客就可以利用自己的私钥解密。同时为了伪装他也会用之前拦截下来的发送方给接收方发送的公钥来加密数据再返回给发送方。

        反过来对于另一方也重复同样的步骤，这样就可以获取到双方通信的数据了。

那么我们该如何防范这种事情的发生呢？接下来我们要引入证书的概念。

3.5 证书 

证书是为了解决中间人攻击而产生的。

在客户端和服务器刚一建立连接的时候, 服务器给客户端返回一个证书

这个证书包含了刚才的公钥, 也包含了网站的身份信息

这个证书就好比人的身份证, 作为这个网站的身份标识. 搭建一个 HTTPS 网站要在CA机构先申请 一个证书. (类似于去公安局办个身份证).

 

这个证 可以理解成是一个结构化的字符串, 里面包含了以下信息:

证书发布机构 证书有效期 公钥 证书所有者 签名 ...... 

当客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的) 

判定证书的有效期是否过期

判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构).

验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等. 如果相等, 则说明证书是没有被篡改过的.

 3.5.1 证书的原理

理解数据摘要 / 签名

以后我们参加工作后, 经常会涉及到 "报销" 的场景. 你拿着发票想报销, 需要领导批准. 但是领导又 不能和你一起去找财务. 那咋办?

很简单, 领导给你签个字就行了. 财务见到领导的签字, "见字如见人".

因为不同的人, "签名" 的差别会很大. 使用签名就可以一定程度的区分某个特定的人.

类似的, 针对一段数据(比如一个字符串), 也可以通过一些特定的算法, 对这个字符串生成一个 "签名". 并保证不同的数据, 生成的 "签名" 差别很大. 这样使用这样的签名就可以一定程度的区分不同的数据

————————————————————————————————————————

常见的生成签名的算法有: MD5 和 SHA 系列

以 MD5 为例, 我们不需要研究具体的计算签名的过程, 只需要了解 MD5 的特点: 定长: 无论多长的字符串, 计算出来的 MD5 值都是固定长度 (16字节版本或者32字节版本) 分散: 源字符串只要改变一点点, 最终得到的 MD5 值都会差别很大. 不可逆: 通过源字符串生成 MD5 很容易, 但是通过 MD5 还原成原串理论上是不可能的.

正因为 MD5 有这样的特性, 我们可以认为如果两个字符串的 MD5 值相同, 则认为这两个字符串相 同.

3.5.2 证书的篡改 

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

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

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

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

但是还有个问题, 如果黑客把 hello 篡改了, 同时也把哈希值（数字签名）重新计算下, 客户端就无法分辨了。

所以被传输的哈希值（数字签名）不能传输明文, 需要传输密文.

这个哈希值（数字签名）在服务器端通过另外一个私钥加密(这个私钥是申请证书的时候, 证书发布机构给服务器的, 不是客户端和服务器传输对称密钥的私钥).

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

 3.6 总结

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

第一组(非对称加密): 用于校验证书是否被篡改. 服务器持有私钥(私钥在注册证书时获得), 客户端持有公 钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥). 服务器使用这个私钥对证书的 签名进行加密. 客户端通过这个公钥解密获取到证书的签名, 从而校验证书内容是否是篡改过.

第二组(非对称加密): 用于协商生成对称加密的密钥. 服务器生成这组 私钥-公钥 对, 然后通过证书把公钥传递给客户端. 然后客户端用这个公钥给生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密密钥

第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密（用于解决非对称密钥传输慢的问题）

其实这一切都是为了确保对称密钥的传输安全，从而为对称密钥加密数据的安全性做出保障

第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器.

第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥