入门Http和Https

什么是超文本

【文本】互联网早期，输入的信息只能保存在本地，无法和其他电脑进行交互，保存的信息通
常都以文本即简单字符的形式存在，文本是一种能够被计算机解析的有意义的二进制数据包，

而随着互联网的高速发展，两台电脑之间能够进行数据的传输后，人们不满足只能在两台电脑之间传输文字，
还想要传输图片、音频、视频，甚至点击文字或图片能够进行超链接的跳转，那么文本的语义就被扩
大了， 这种语义扩大后的文本就被称为超文本(Hypertext) 

不单单只是本文

它还可以传输图片、音频、视频，甚至点击文字或图片能够进行超链接的跳转。

上面这些概念可以统称为数据

什么是传输

他们之间的关系如下：

什么是协议

那么网络协议是什么呢?

请求方法、URI、状态码、原因短语、头字段等

优点：

缺点：

五层网络协议的示意图如下

四层网络协议的示意图如下：

应用层

运输层

网络层

链路层

物理层

7层网络协议栈图解

TCP协议是什么

TCP的主要特点

UDP协议是什么

UDP协议的特点

TCP和UDP都位于计算机网络模型中的运输层

它们负责传输应用层产生的数据

图解TCP协议与UDP协议的主要区别

通过主机名

通过IP地址

一种能够把主机名到IP地址的转换服务

首先， 查询请求会先找到本地DNS服务器来查询是否包含IP地址，

如果本地DNS无法查询到目标IP

地址， 就会向根域名服务器发起一个DNS查询。

【递归查询】如果根域名服务器，无法告知本地DNS服务器下一步需要访问哪个顶级域名服务器， 就会使用递归查询；

【迭代查询】如果根域名服务器，能够告知DNS服务器下一步需要访问的顶级域名服务器， 就会使用迭代查询。

在由根域名服务器→顶级域名服务器→权威DNS服务器后， 由权威服务器告诉本地服务器目标IP地址， 再有本地DNS服务器告诉用户需要访问的IP地址。

递归查询(Recursive query)

迭代查询(Iteration query)

《计算机网络：自顶向下方法》竟然没有给出递归查询和代查询的区别，找了一下网上的资料大概明白了下。

认识几个概念

图解

它的全称是Synchronize Sequence Numbers， 同步序列编号， 

是TCP/IP建立连接时使用的握手信号， 在客户机和服务器之间建立TCP连接时， 首先会发送的一个信号。

客户端在接受到SYN消息时， 就会在自己的段内生成一个随机值X.

这个消息是用来初始化和建立连接的。

本地的SYN消息和较早的ACK数据包

服务器收到SYN后， 打开客户端连接， 发送一个SYN-ACK作为答复。

确认号设置为比接收到的序列号多一个，即X+1，服务器为数据包选择的序列号是另一个随机数Y.

帮助对方确认收到的SYN消息

Acknowledge character， 确认字符， 表示发来的数据已确认接收无误。

最后， 客户端将ACK发送给服务器。

序列号被设置为所接收的确认值即Y+1.

用来断开连接

小明-客户端

小红-服务端

【SYN】小明给小红打电话，接通了后，小明说喂，能听到吗

【SYN-ACK】小红给小明回应，能听到，你能听到我说的话吗

【ACK】小明听到小红的回应后，好的

在这之后小明和小红就可以通话/交换信息了。

图解TCP四次挥手过程

第一步【FIN】

第二步【ACK】

第三步【FIN】

第四步【ACK】

小明-客户端

小红-服务端

小明对小红说，我所有的东西都说完了，我要挂电话了。

小红说，收到，我这边还有一些东西没说。

经过若干秒后，小红也说完了，小红说，我说完了，现在可以挂断了

小明收到消息后，又等了若干时间后，挂断了电话。

DNS是什么（略）

首先， 查询请求会先找到本地DNS服务器来查询是否包含IP地址，

如果本地DNS无法查询到目标IP

地址， 就会向根域名服务器发起一个DNS查询。

【递归查询】如果根域名服务器，无法告知本地DNS服务器下一步需要访问哪个顶级域名服务器， 就会使用递归查询；

【迭代查询】如果根域名服务器，能够告知DNS服务器下一步需要访问的顶级域名服务器， 就会使用迭代查询。

在由根域名服务器→顶级域名服务器→权威DNS服务器后， 由权威服务器告诉本地服务器目标IP地址， 再有本地DNS服务器告诉用户需要访问的IP地址。

GET获取资源

POST传输实体

PUT传输文件

HEAD获得响应首部

DELETE删除文件

OPTIONS询问支持的方法

TRACE追踪路径

CONNECT要求用隧道协议连接代理

HTTP 1.0和HTTP 1.1支持的方法清单

比如http：//ww.example.com：80/path/to/myfile.html?key l=value 1&key 2=value 2#Somewhere In The Document

这个URL比较繁琐了吧， 你把这个URL搞懂了其他的URL也就不成问题了。

http

主机

端口

路径

查询参数

锚点

HTTP 1.0是在1996年引入的， 从那时开始， 它的普及率就达到了惊人的效果，

HTTP 1.0仅仅提供了最基本的认证， 这时候用户名和密码还未经加密， 因此很容易收到窥探。
HTTP 1.0被设计用来使用短链接， 即每次发送数据都会经过TCP的三次握手和四次挥手， 效率比较低。
HTTP 1.0只使用header中的If-Modified-Since和Expires作为缓存失效的标准。
HTTP 1.0不支持断点续传， 也就是说， 每次都会传送全部的页面和数据，
HTTP 1.0认为每台计算机只能绑定一个IP， 所以请求消息中的URL并没有传递主机名(hostname) 。

HTTP 1.1是HTTP 1.0开发三年后出现的， 也就是1999年， 它做出了以下方面的变化

HTTP 1.1便用了摘要算法来进行身份验证
HTTP 1.1默认使用长连接， 长连接就是只需一次建立就可以传输多次数据， 传输完成后， 只需要
一次切断连接即可。长连接的连接时长可以通过请求头中的keep-alive来设置
HTTP 1.1中新增加了E-tag， If-Unmodified-Since， If-Match， If-None-Match等缓存控制标头来控制缓存失效。
HTTP 1.1支持断点续传， 通过使用请求头中的Range来实现。
HTTP 1.1使用了虚拟网络， 在一台物理服务器上可以存在多个虚拟主机(Multi-homed WebServers) ， 并且它们共享一个IP地址。

HTTP 2.0是2015年开发出来的标准， 它主要做的改变如下

头部压缩

二进制格式

强化安全

多路复用

子主题

比如你在浏览器地址栏输入www.cxuanblog.com其实就是发送了一个get请求

它的主要特征是请求服务器返回资源

get相当于一个是pulll拉的操作

因为在发送请求的过程中， 请求参数会拼在URL后面， 从而导致容易被攻击者窃取，对你的信息造成破坏和伪造；

get请求的URL有长度限制

·get请求会被浏览器主动cache

get请求在浏览器反复的回退/前进操作是无害的

get请求在发送过程中会产生一个TCP数据包

对于get方式的请求， 浏览器会把http header和data一并发送出去， 服务器响应200(返回数据)

而post方法一般用于<form>表单的提交

相当于是把信息提交给服务器， 等待服务器作出响应

而post相当于是一个push推的操作

而post方法是把参数放在请求体body中的， 这对用户来说不可见，

post方法相对安全些

而post请求会把参数和值放在消息体中， 对数据长度没有要求。

post不会被浏览器主动cache， 除非手动设置。

post操作会再次提交表单请求。

post在发送过程中会产生两个TCP数据包。

对于post， 浏览器会先发送header， 服务器响应100continue， 浏览器再发送data， 服务器响应200ok(返回数据)

缓存(Cache)是什么？

Cache-Control介绍

HTTP协议使用TCP来管理连接方式

Connection决定当前事务(一次三次握手和四次挥手) 完成后， 是否会关闭网络连接。

逐跳首部、连接的管理

主要有两种连接方式

Date是一个通用标头， 它可以出现在请求标头和响应标头中

创建报文的日期时间

它的基本表示如下

Pragma是http 1.1之前版本的历史遗留字段， 仅作为与http的向后兼容而定义。

报文指令

它的一般形式如下

只用于客户端发送的请求中。客户端会要求所有的中间服务器不返回缓存的资源，

如果所有的中间服务器都以实现HTTP/1.1为标准， 那么直接使用Cache-Control：no-cache即可

如果不是的话，就要包含两个字段，如下

首部字段Trailer会事先说明在报文主体后记录了哪些首部字段。

报文末端的首部一览

该首部字段可应用在HTTP/1.1版本分块传输编码时

一般用法如下

以上用例中， 指定首部字段Trailer的值为Expires， 在报文主体之后(分块长度0之后) 出现了首部字段Expires.

Transfer-Encoding属于内容协商的范畴

规定了传输报文主体时采用的编码方式

HTTP/1.1的传输编码方式仅对分块传输编码有效。

Transfer-Encoding：chunked

Transfer-Encoding也属于Hop-by-hop(逐跳) 首部

回顾HTTP报文标头

Transfer-Encoding用于两个节点之间传输消息， 而不是资源本身。

在多个节点传输消息的过程中， 每一段消息的传输都可以使用不同的Transfer-Encoding.

如图所示

Transfer-Encoding支持文件压缩

如果想要以文件压缩后的形式发送，Transfer-Encoding所有可选类型如下

也可以列出多个值，以逗号分隔，类似一个集合列表

首部字段Upgrade用于检测HTTP协议及其他协议是否可使用更高的版本进行通信， 

其参数值可以用来指定一个完全不同的通信协议。

升级为其他协议

Upgrade

上图用例中， 首部字段Upgrade指定的值为TLS/1.0.请注意此处两个字段首部字段的对应关系，
 Connection的值被指定为Upgrade， Upgrade首部字段产生作用的对象仅限于客户端和临近服务器之间。

因此， 使用首部字段Upgrade时， 还需要额外指定Connection：Upgrade.

对于附有首部字段Upgrade的请求， 服务器可用1015 witching Protocols状态码作为响应返回.

使用Via是为了跟踪客户端和服务器之间的请求/响应路径， 避免请求循环以及能够识别请求/响应链
中发送者协议的功能.

代理服务器的相关信息

Via字段由代理服务器添加， 不论是正向代理还是反向代理， 并且可以出现在请
求标头和响应标头中，它用于跟踪消息转发。

例如下图所示

Via后面的的1.1， 1.0表示接收服务器上的HTTP版本， Via首部是为了跟踪路径， 经常和TRACE方法一起使用。

注意：Warning字段即将被弃用

错误通知

查阅Warning(https：//github.com/httpwg/http-core/issues/139)andWaming：header&
stale-while-revalidate(https：//github.com/whatwg/fetch/issues/913) 获取更多细节

Warning通用HTTP标头通常会告知用户一些与缓存相关的问题的警告

HTTP/1.1中定义了7种警告

图解HTTP/1.1中定义了7种警告

HTTP请求标头会告知客户端能够接收的MIME类型是什么

用户代理可处理的媒体类型

接受请求HTTP标头会通告客户端其能够理解的MIME类型

什么是MIME ？ 

什么是MIME类型呢?

一般MIME类型也会和q这个属性一起使用

Accept-Charset表示客户端能够接受的字符编码。

优先的字符集

规定服务器处理表单数据所接受的字符集。

Accept-charset属性规定服务器处理表单数据所接受的字符编码

Accept-charset属性允许你指定一系列字符集，服务器必须支持这些字符集，从而得以正确解释表单中的数据。

Accept-Charset也是属于内容协商的一部分

Accept-Charset没有对应的标头， 服务器会把这个值放在Content-Type中用charset=xxx来表示

它和Accept一样， 也可以用q来表示字符集， 用退号进行分割

例如

事实上， 很多以Accept-*开头的标头， 都是属于内容协商的范畴， 关于内容协商我们下面会说。

常用的字符集

优先的内容编码

表示HTTP标头会标明客户端希望服务端返回的内容编码， 这通常是一种压缩算法， Accept-Encoding
也是属于内容协商的一部分， 使用并通过客户端选择Content-Encoding内容进行返回。

即使客户端和服务器都能够支持相同的压缩算法，服务器也可能选择不压缩井返回，这种情况可能是由
于这两种情况造成的：

要发送的数据已经被压缩了一次，第二次压缩并不会导致发送的数据更小

服务器过载， 无法承受压缩带来的性能开销， 通常， 如果服务器使用CPU超过80%，Microsoft则建议不要使用压缩

下面是Accept-Encoding的使用方式

优先的语言(自然语言)

首部字段Accept-Language用来告知服务器用户代理能够处理的自然语言集(指中文或英文等) ， 以及自然语言集的相对优先级。

Accept-Language请求表示客户端需要服务端返回的语言类型，

Accept-Language也属于内容协商的范畴。

服务端通过Content-Language进行响应，

和Accept首部字段一样， 按权重值q=来表示相对优先级。

可一次指定多种自然语言集。

例如

Web认证信息

HTTP Authorization请求头用于向服务器认证用户代理的凭据，

 通常用在服务器以401未经授权状态和WWW-Authenticate标头响应之后， 

啥意思呢?你不明白的话我画张图给你看

请求标头Authorization是用来告知服务器， 用户的认证信息， 

服务器在只有收到认证后，才会返回给客户端200OK的响应，

如果没有认证信息，则会返回401并告知客户端需要认证信息，

详细关于Authorization的信息， 后面也会详细解释

期待服务器的特定行为

Expect HTTP请求标头指示服务器需要满足的期望才能正确处理请求。

如果服务器没有办法完成客服端所期望完成的事情井且服务端存在错误的话， 会返回417 Expectation Failed.

HTTP 1.1只规定了100-continue.

如果服务器能正常完成客户端所期望的事情，会返回100

如果不能满足期望或返回任何其他4xx的状态码，会返回417

例如

用户的电子邮件地址

From请求头用来告知服务器使用用户代理的电子邮件地址， 

通常情况下， 其使用目的就是为了显示搜索引擎等用户代理的负责人的电子邮件联系方式。

在使用代理的情况下， 应尽可能包含From首部字段。

例如

你不应该将From用在访问控制或者身份验证中

请求资源所在服务器

Host请求头指明了服务器的域名(对于虚拟主机来说) ， 以及(可选的) 服务器监听的TCP端口号。

如果没有给定端口号， 会自动使用被请求服务的默认端口(比如请求一个HTTP的URL会自动使用80作为端口)。

Host：developer.mozilla.org

Host首部字段在HTTP/1.1规范内是唯一一个必须被包含在请求内的首部字段

If-Match

If-None-Match

If-Modified-Since

If-Unmodified-Since

If-Range

最大传输逐跳数

MDN把这个标头置灰了， 所以下面内容取自《图解HTTP》

Max-Forwards一般用于TRACE和OPTION方法， 

发送包含Max-Forwards的首部字段时， 每经过一个服务器， Max-Forwards的值就会-1，直到Max-Forwards为0时返回

Max-Forwards是一个十进制的整数值。

Max-Forwards： 18

可以灵活使用首部字段Max-Forwards， 针对以上问题产生的原因展开调查。

由于当Max-Forwards字段值为0时，服务器就会立即返回响应，

由此我们至少可以对以那台服务器为终点的传输路径的通信状况有所把握。

代理服务器要求客户端的认证信息

Proxy-Authorization是属于请求与认证的范畴， 在上面提到一个认证的HTTP标头是Authorization，

这个HTTP请求标头和Proxy-Authenticate拼接很相似， 但是概念不同

这个标头用于向代理服务器提供凭据

 不同于Authorization发生在客户端-服务器之间：Proxy-Authorization发生在代理服务器和客户端之间。

它表示接收到从代理服务器发来的认证时， 客户端会发送包含首部字段Proxy-Authorization的请求， 以告知服务器认证所需要的信息。

Proxy-Authorization：Basic YWxhZGRpbjpvcGVuc2VzYW1L

实体的字节范围请求

Range HTTP请求标头指示服务器应返回文档指定部分的资源， 可以一次请求一个Range来返回多个
部分，服务器会将这些资源返回各个文档中。

如果服务器成功返回，那么将返回206响应；
如果Range范围无效， 服务器返回416 Range Not Satisfiable错误； 
服务器还可以忽略Range标头，并且返回200作为响应。

Range：bytes=208-1000，2000-6576，19800-

对请求中URI的原始获取方

TTP Referer属性是请求标头的一部分

当浏览器向web服务器发送请求时， 一般会带上Referer， 告诉服务器该网页是从哪个页面链接过来的， 服务器因此可以获得一些信息用于处理。

Referer：https://developer.mozilla.org/testpage.html

传输编码的优先级

首部字段TE会告知服务器客户端能够处理响应的传输编码方式及相对优先级。

它和首部字段Accept Encoding的功能很相像， 但是用于传输编码.

TE：gzip， deflate； q=0.5

首部字段TE除指定传输编码之外， 还可以指定伴随traller字段的分块传输编码的方式， 应用后者时，
只需把trailers赋值给该字段值。

TE：trailers， deflate； q=0.5

HTTP客户端程序的信息

首部字段User-Agent会将创建代理的浏览器和用户代理名称等信息传达给服务器

Mozilla/5.0(WindowsNT 6.1； Win 64； x64； rv47.0) Gecko/ 20100101 Firefox /47.0

是否接受字节范围请求

Accept-Ranges HTTP响应标头， 这个标头有两个值

Accept-Ranges：bytes

Accept-Ranges：none

推算资源创建经过时间

Age HTTP响应标头告诉客户端源服务器在多久之前创建了响应， 它的单位为秒， 

Age标头通常接近于0 

代理创建响应时必须加上首部字段Age.

一般表示如下

令客户端重定向至指定URI

ETag对于条件请求来说真是太重要了。

因为条件请求就是根据ETag的值进行匹配的， 下面我们就来详细了解一下。

ETag介绍

ETag资源更新图解

如果给定URL上的资源发生变更， 必须生成一个新的ETag值， 通过比较它们可以确定资源的两个表示形式是否相同。

ETag值有两种

令客户端重定向至指定URI

Location响应标头表示URL需要重定向页面， 它仅仅与3xx(重定向) 或201(已创建) 状态响应一起使用。

下面是一个页面重定向的过程

使用首部字段Location可以将响应接受方引导至某个与请求URI位置不同的资源。

Location和content-Location是不一样的

代理服务器对客户端的认证信息

HTTP响应标头Proxy-Authenticate会定义认证方法， 应该使用身份验证方法来访问代理服务器后面的资源，即客户端。

它与HTTP客户端和服务端之间的访问认证行为相似， 不同之处在于Proxy-Authenticate的认证双方是客户端与代理之间

它将请求认证到代理服务器，从而允许它进一步发送请求。

Proxy-Authenticate：Basic
Proxy-Authenticate：Basic realm="Access to the internal site"

对再次发起请求的时机要求

HTTP响应标头Retry-After告知客户端需要在多久之后重新发送请求，

使用此标头主要有如下三种情况

字段值可以指定为具体的日期时间，也可以是创建响应后所持续的秒数

HTTP服务器的安装信息

服务器标头包含有关原始服务器用来处理请求的软件的信息。

应该避免使用过于冗长和详细的Server值， 因为它们可能会泄露内部实施细节， 这可能会使攻击者容易地发现并利用已知的安全漏洞。

例如下面这种写法 Server：Apache/2.4.1(Unix)

代理服务器缓存的管理信息

Vary HTTP响应标头

确定如何匹配请求标头， 以决定是否可以使用缓存的响应， 而不是从原始服务器请求一个新的响应。

Vary：User-Agent

服务器对客户端的认证信息

HTTP WW-Authenticate响应标头定义了应用于获得对资源的访问权限的身份验证方法。

WWW-Authenticate标头与401未经授权的响应一起发送。

它的一般表示形式如下

Access-Control-Allow-Origin

一个返回的HTTP标头可能会具有Access-Control-Allow-Origin

 Access-Control-Allow-Origin指定一个来源， 它告诉浏览器允许该来源进行资源访问，

 否则-对于没有凭据的请求*通配符，告诉浏览器允许任何源访问资源。

例如，要允许源https://mozilla.org的代码访问资源，可以指定：
Access-Control-Allow-Origin：https：//mozilla.org
Vary：Origin

如果服务器指定单个来源而不是*通配符的话， 则服务器还应在Vary晌应标头中包含Origin，
以向客户端指示服务器响应将根据原始请求标头的值而有所不同。

Cache-Control是一个通用标头， 他可以出现在请求标头和响应标头中

详细见请求标头中

Cache-Control的种类比较多，虽然说这是一个通用标头，但是又一些特性是请求标头具有的，有一些是响应标头才有的。<br>

Keep-Alive表示的是Connection非持续连接的存活时间， 可以进行指定。

持久性连接

Set-Cookie用于服务器向客户端发送sessionID.

HTTP首部字段是可以自行扩展的。所以在Web服务器和浏览器的应用上， 会出现各种非标准的首部字段。

首部字段X-Frame-Options属于HTTP响应首部， 用于控制网站内容在其他Web网站的Frame标签内的显示问题。

其主要目的是为了防止点击劫持(click jacking) 攻击。

HTTP实体标头Allow列出了资源支持的方法集合。

资源可支持的HTTP方法

如果服务器响应405 Method Not Allowed状态码以指示可以使用哪些请求方法，则必须发送此标头。

例如

这段代码表示服务器允许支持GET、POST和HEAD方法。

当服务器接收到不支持的HTTP方法时， 会以状态码405 Method Not Allowed作为响应返回。

上面讲过Accept Encoding是客户端希望服务端返回的内容编码， 但是实际上服务端返回给客
户端的内容编码实际上是通过Content-Encoding返回的。

实体主体适用的编码方式

这又是一个比较麻烦的属性， 这个实体报头用来压缩媒体类型。

Content-Encoding指示对实体应用了何种编码。

Content-Encoding实体标头用于压缩媒体类型，

 它让客户端知道如何进行解码操作， 从而使客户端获得Content-Type标头引用的MIME类型。

内容编码是指在不丢失实体信息的前提下所进行的压缩。

这个属性可以应用在请求报文和响应报文中

主要也是四种， 和Accept-Encoding相同， 它们是

下面是一组请求/响应内容压缩编码

表示如下

首部字段Content-Language会告知客户端， 服务器使用的自然语言是什么， 

实体主体的自然语言

实体报头描述了客户端或者服务端能够接受的语言。

它与Accept-Language相对，下面是一组请求/响应使用的语言类型

例如

Content-Language实体标头用于描述面向受众的语言， 以便使用户根据用户自己的首选语言进行区分

HTTP响应标头Content-Type说明了实体内对象的媒体类型， 

和首部字段Accept一样使用， 表示服务器能够响应的媒体类型。

Content-Type实体标头，用于指示资源的MIME类型。

实体主体的媒体类型

作为响应， Content-Type标头告诉客户端返回的内容的内容类型实际上是什么。

Content-type有两种值：MIME类型和字符集编码， 

例如Content-Type：text/html；charset-UTF-8

在某些情况下， 浏览器将执行MIME嗅探， 并且不一定遵循此标头的值：为防止此行为， 可以将标头X-Content-Type-Options设置为no sniff，

Content-Length的实体标头，指服务器发送给客户端的实际主体大小， 以字节为单位。

实体主体的大小(单位：字节)

实体报头指示实体主体的大小， 以字节为单位， 发送到接收方

Content-Length：3000

如上，服务器返回给客户端的主体大小是3000字节。

Content-Location可不是对应Accept-Location， 因为没有这个标头哈哈哈哈。

实际上Content-Location对应的是Location.Location和Content-Location是不一样的， 

Location表示重定向的URL， 而Content-Location表示用于访问资源的直接URL， 

替代对应资源的URI

以后无需进行进一步的内容协商， Location是与响应关联的标头， 而Content-Location是与返回的数据相关联的标头，

如果你不好理解， 看一下下面的表格

客户端会对接收的报文主体执行相同的MD5算法， 然后与首部字段Content-MD5的字段进行比较。

实体主体的报文摘要

Content-MD5：e10adc3949ba59abbe56e057f20f883e

首部字段Content-MD5是一串由MD5算法生成的值， 

其目的在于检查报文主体在传输过程中是否保持完整，有无被修改的情况，以及确认传输到达。

图解Content-MD5

HTTP的Content-Range响应标头是针对范围请求而设定的， 

实体主体的位置范围

返回响应时使用首部字段Content-Range， 能够告知客户端响应实体的哪部分是符合客户端请求的， 字段以字节为单位。

它的一般表示如下

HTTP Expires实体标头包含日期/时间， 

实体主体过期的日期时间

在该日期/时间之后， 响应被认为过期；

在响应时间之内， 响应被认为有效。

特殊的值比如0表示过去的日期，表示资源已过期。

Expires：Wed， 210ct 201507：28：00GMT

源服务器会将资源失效的日期或时间发送给客户端， 缓存服务器在接受到Expires的响应后， 会判断是否把缓存返回给客户端。

源服务器不希望缓存服务器对资源缓存时， 最好在Expires字段内写入与首部字段Date相同的时间值。

但是， 当首部字段Cache-Control有指定max-age指令时， 比起首部字段Expires， 会优先处理max-age指令。

资源的最后修改日期时间

实体字段Last-Modified指明资源的最后修改时间， 它用作验证器来确定接收或存储的资源是否相同。

它的作用不如ETag那么准确， 它可以作为一种后备机制， 包含If-Modified-Since或If-Unmodified-Since标头的条件请求将使用此字段。

它的一般表示如下

HTTP请求标头会告知客户端能够接收的MIME类型是什么

接受请求HTTP标头会通告客户端自己能够接受的MIME类型

什么是MIME ？ 

什么是MIME类型呢?

一般MIME类型也会和q这个属性一起使用

Accept-Charset表示客户端能够接受的字符编码。

Accept-charset属性规定服务器处理表单数据所接受的字符编码

Accept-charset属性允许你指定一系列字符集，服务器必须支持这些字符集，从而得以正确解释表单中的数据。

Accept-Charset也是属于内容协商的一部分

Accept-Charset没有对应的标头， 服务器会把这个值放在Content-Type中用charset=xxx来表示

它和Accept一样， 也可以用q来表示字符集， 用退号进行分割

例如

事实上， 很多以Accept-*开头的标头， 都是属于内容协商的范畴， 关于内容协商我们下面会说。

首部字段Accept-Language用来告知服务器用户代理能够处理的自然语言集(指中文或英文等) ， 以及自然语言集的相对优先级。

Accept-Language请求表示客户端需要服务端返回的语言类型，

Accept-Language也属于内容协商的范畴。

服务端通过Content-Language进行响应，

和Accept首部字段一样， 按权重值q=来表示相对优先级。

可一次指定多种自然语言集。

例如

表示HTTP标头会标明客户端希望服务端返回的内容编码， 这通常是一种压缩算法， 

Accept-Encoding也是属于内容协商的一部分，

使用并通过客户端选择Content-Encoding内容进行返回。

即使客户端和服务器都能够支持相同的压缩算法，服务器也可能选择不压缩井返回，

这种情况可能是由于这两种情况造成的

下面是Accept-Encoding的使用方式

HTTP响应标头Content-Type说明了实体内对象的媒体类型， 

和首部字段Accept一样使用， 表示服务器能够响应的媒体类型。

Content-Type实体标头，用于指示资源的MIME类型。

作为响应， Content-Type标头告诉客户端返回的内容的内容类型实际上是什么。

Content-type有两种值：MIME类型和字符集编码， 

例如Content-Type：text/html；charset-UTF-8

在某些情况下， 浏览器将执行MIME嗅探， 并且不一定遵循此标头的值：为防止此行为， 可以将标头X-Content-Type-Options设置为no sniff，

上面讲过Accept Encoding是客户端希望服务端返回的内容编码， 但是实际上服务端返回给客
户端的内容编码实际上是通过Content-Encoding返回的。

Content-Encoding实体标头用于压缩媒体类型，

 它让客户端知道如何进行解码操作， 从而使客户端获得Content-Type标头引用的MIME类型。

内容编码是指在不丢失实体信息的前提下所进行的压缩。

主要也是四种， 和Accept-Encoding相同， 它们是gzip、compress、deflate、identity.

下面是一组请求/响应内容压缩编码

表示如下

首部字段Content-Language会告知客户端， 服务器使用的自然语言是什么， 

它与Accept-Language相对，下面是一组请求/响应使用的语言类型

例如

Content-Language实体标头用于描述面向受众的语言， 以便使用户根据用户自己的首选语言进行区分

一般的认证过程如下

首先客户端发起一个HTTP请求， 不带有任何认证标头，

 服务器对此HTTP请求作出响应， 发现此HTTP信息未带有认证凭据， 

服务器通过www-Authenticate标头返回401告诉客户端此请求未通过认证。

然后客户端进行用户认证， 认证完毕后重新发起HTTP请求， 这次HTTP请求带有用户认证凭据
(注意， 整个身份认证的过程必须通过HTTPS连接保证安全) ，

到达服务器后，服务器会检查认证信息

客户端和服务器之间的HTTP连接可以被代理缓存重新发送， 所以认证信息也适用于代理服务器。

Proxy-Authorization是属于请求与认证的范畴， 在上面提到一个认证的HTTP标头是Authorization，

这个HTTP请求标头和Proxy-Authenticate拼接很相似， 但是概念不同

这个标头用于向代理服务器提供凭据

 不同于Authorization发生在客户端-服务器之间：Proxy-Authorization发生在代理服务器和客户端之间。

它表示接收到从代理服务器发来的认证时， 客户端会发送包含首部字段Proxy-Authorization的请求， 以告知服务器认证所需要的信息。

Proxy-Authorization：Basic YWxhZGRpbjpvcGVuc2VzYW1L

HTTP响应标头Proxy-Authenticate会定义认证方法， 应该使用身份验证方法来访问代理服务器后面的资源，即客户端。

它与HTTP客户端和服务端之间的访问认证行为相似， 不同之处在于Proxy-Authenticate的认证双方是客户端与代理之间

它将请求认证到代理服务器，从而允许它进一步发送请求。

Proxy-Authenticate：Basic
Proxy-Authenticate：Basic realm="Access to the internal site"

WWW-Authenticate：<type>realm = <realm>
Proxy-Authenticate：<type>realm=<realm>

<type>是认证协议

Basic是下面协议中最普遍使用的

RFC 7617中定义了Basic HTTP身份验证方案， 

该方案将凭据作为用户ID/密码对传输， 并使用base 64进行编码。

(感兴趣的同学可以看看https：//tools.ietf.org/html/rfc7617)

其他的认证协议主要有

realm用于描述保护区或指示保护范围

这可能是诸如Access to the staging site(访问登陆站点)或者类似的，这样用户就可以知道他们要访问哪个区域。

Authorization：Basic YWxhZGRpbjpvcGVuc2VzYW1l
Proxy-Authorization：BasicYWxhZGRpbjpvcGVuc2VzYW1L

网关缓存

CDN反向代理缓存

负载平衡器

Cache-Control：public

共享缓存示意图

Cache-Control：private

私有缓存示意图

no-cache示意图

Cache-Control：no-cache

Cache-Control：max-age=0

No-Cache就相当于是吃着碗里的， 占着锅里的， 

如果锅里还有新的肉片， 就先吃锅里的，如果锅里没有新的，再吃自己的，

这里锅里的就相当于是源服务器产生的，碗里的就相当于是缓存的。

no-store才是真正意义上的不缓存 

每次服务器接受到客户端的请求后， 都会返回最新的资源给客户端。

Cache-Control：no-store

同上面的不缓存过期资源

同上

缓存中一个很重要的指令就是max-age， 这是资源被视为新鲜的最长时间， 

与Expires相反， 此指令是相对于请求时间的， 对于应用程序中不会更改的文件， 通常可以添加主动緩存。

下面是mag-age的表示

must-revalidate表示缓存必须在使用之前验证过时资源的状态， 并且不应使用过期的资源

Cache-Control：must-revalidate

下面是一个缓存验证图

强验证器和弱验证器， 实现验证器功能的标头正式Etag的作用，

 这意味着HTTP用户代理(例如浏览器) 不知道该字符串表示什么， 并且无法预测其值。

如果Etag标头是资源响应的一部分， 则客户端可以在未来请求的标头中发出If-None-Match， 以验证缓存的资源。

Last-Modified响应标头可以用作弱验证器， 因为它只有1秒可以分辨的时间。

如果响应中存在Last-Modified标头， 则客户端可以发出If-Modified-Since请求标头来验证缓存资源。 

通过使用Etag和If-Match标头， 你可以检测避免碰撞。

例如

Etag标头的另一个典型用法是缓存未更改的资源， 

如果用户再次访问给定的URL(已设置Etag) ， 并且该URL过时， 则客户端将在If-None-Match标头字段中发送其Etag的值

If-None-Match：“33a64df551425fc c55e4d42a148795d9f25f89d 4"

服务器将客户端的Etag(通过If None-Match发送) 与Etag进行比较， 以获取其当前资源版本

如果两个值都匹配(即资源未更改) ， 则服务器会发回304 Not Modified状态， 没有主体， 它告诉客户端响应的缓存仍然可以使用。

用于访问它的URL的端口

(1)http://example.com/opp1/index.html
(2)http://example.com/app 2/index.html

上面两个URL是不具有跨域问题的， 因为这两个URL具有相同的协议(scheme) 和主机(host)

http://Example.com:80
http://example.com

这两个URL也不具有跨域问题， 为什么不具有， 端口不一样啊。

其实它们两个端口是一样的。

或许你会认为这两个URL是不一样的， 放心， 关于一样不一样的论据我给你抛出来了

协议和域名部分是不区分大小写的， 但是路径部分则根据服务器平台而定。

Windows和Mac OS X系统是不区分大小写的， 而采用UNIX和Linux系的服务器系统是区分大小写的，

也就是说，上面的Excmple.com和example.com其实是一个网址，并且由于两个地址具有相同的scheme和host，

默认情况下服务器通过端口80传递HTTP内容， 所以上面这两个地址也是相同的。

http://example.com/app1
https://example.com/app2

这两个URL的scheme不同， 所以这两个URL具有跨域问题

http://example.com
http://www.example.com
http://myapp.example.com

这三个URL也是具有跨域问题的， 因为它们隶属于不通服务器的主机host

http://example.com
http://example.com:8089

这两个URL也是具有跨域问题， 因为这两个URL的默认端口不一样。

所有的现代浏览器都有一个内置的XMLHttpReqeust对象， 这个对象可以用于从服务器请求数据。

XMLHttpRequest对于开发人员来说很重要

XMLHttpRequest对象可以用来做下面这些事情

使用XMLHttpRequest(XHR) 对象与服务器进行交互， 可从URL检索数据从而不必刷新整个页面， 这使网页可更新页面一部分， 而不中断用户操作。

XMLHttpRequest在AJAX异步编程中使用很广泛

Fetch提供了请求和响应对象(以及其他网络请求) 的通用定义。

提供了相关概念的定义， 例如CORS和HTTP Origin头语义， 并在其他地方取代了它们各自的定义。

Accept
Accept-Language
Content-Language
Content-Type
DPR
Downlink
Save-Data
Viewport-Width 
Width

application/x-www-form-urlencoded
multipart/form-data
text/plain

这些可以使用XMLHttpRequest.upload属性进行访问。

例如， 假定web内容https://foo.example想要获取https://bar.other域的资源，

那么JavaScript中的代码可能会像下面这样写

这使用CORS标头来处理特权， 从而在客户端和服务器之间执行某种转换。

在这种情况下浏览器将发送到服务器的内容（浏览器将发送到服务器的内容）

让我们看看服务器是如何响应的（服务器如何响应）

使用Origin标头和Access-Control-Allow-Origin展示了最简单的访问控制协议。

在这个事例中， 服务端使用Access-Control-Allow-Origin作为响应， 也就说明该资源可以被任何域访问。

如果位于https：//bar.other的资源所有者希望将对资源的访问限制为仅来自https：//foo.example的请求，
他们应该发送如下响应Access-Control-Allow-Origin：https：//foo.example

现在除了https：//foo.exomple之外的任何域都无法以跨域方式访问到https：//bar.other的资源

创建了一个XML请求体

如下图所示

下面我们来看一下完整的客户端/服务器交互

在下面这个例子中，最初从http://foo.example加载的内容对设置了Cookies的http://bar.other上的资源进行了简单的GET请求，

foo.example上可能的代码如下

invocation.with Credentials=true；

上面的请求用下图可以表示

这是客户端和服务器之间的示例交换：

请求凭证和通配符

Access-Control-Allow-Origin：https://mozilla.org
Vary：Origin

Request是Fetch API的一类接口，代表着资源请求。

一般创建Request对象有两种方式

Request接口的凭据只读属性指示，在跨域请求的情况下，用户代理是否应从其他域发送cookie 

(其他Request对象的方法详见https://developer.mozilla.org/en-US/docs/Web/API/Request

cookie

认证头

TLS客户端证书

https://www.jianshu.com/p/ea485e5665b3

自定义标头

多个标头

绕过其他限制

Cache-Control

Content-Language

Content-Type

Expires

Last-Modified

Pragma

要公开非CORS安全列出的请求标头， 可以像如下这样指定

要另外公开自定义标头， 例如X-Kuma-Revision， 可以指定多个标头， 并用逗号分隔

在不是凭证请求中，你还可以使用通配符

但是， 这不会通配Authorization标头， 因此如果需要公开它， 则需要明确列出

Access-Control-Max-Age：680

表示预检请求可以缓存10分钟

Origin：https：//developer.mozilla.org

对于HTTP来说， 安全的方法是不会改变服务器状态的方法

换句话说， 如果方法只是只读操作， 那么它肯定是安全的方法，

 比如说GET请求， 它肯定是安全的方法， 因为它只是请求资源。

几种常见的方法肯定是安全的， 它们是GET、HEAD和OPTIONS， 

所有安全的方法都是幂等的 ，但不是所有幂等的方法都是安全的，

 例如PUT和DELETE都是幂等的， 但不安全

如果相同的客户端发起一次或者多次HTTP请求会得到相同的结果， 则说明HTTP是幂等的。 

强验证保证的是字节级别的验证

严格的验证非常严格，可能在服务器级别难以保证

但是它能够保证任何时候都不会丢失数据，但这种验证丢失性能。

要使用Last-Modified很难实现强验证 

通常， 这是通过使用带有资源的MD5哈希值的Etag来完成的。

弱验证不同于强验证，因为如果内容相等，它将认为文档的两个版本相同

例如，一个页面与另一个页面的不同之处仅在于页脚的日期不同，因此该页面被认为与其他页面相同

而使用强验证时则被认为这两个版本是不同的。

构建一个弱验证的Etag系统可能会非常复杂，

 因为这需要了解每个页面元素的重要性，但是对于优化缓存性能非常有用。

Etag响应头是特定版本的标识 

它能够使缓存变得更高效并能够节省带宽

因为如果缓存内容未发生变更， Web服务器则不需要重新发送完整的晌应

除此之外， Etag能够防止资源同时更新互相覆盖。

如果给定URL上的资源发生变更， 必须生成一个新的Etag值， 通过比较它们可以确定资源的两个表示形式是否相同。

强Etag

弱Etag

对于GET和POST方法

对于其他方法， 特别是PUT方法

一般表示如下

注意：这是格林威治标准时间， HTTP日期始终以格林尼治标准时间表示， 而不是本地时间。

它的一般表示如下

它的一般表示如下

客户端初始化请求，缓存是空的，没有条件请求，服务器资源返回，并且设置验证器

服务器在收到客户端请求后，设置验证器Last-Modified和Etag标签， 并把这两个标签随着响应一起发送回客户端。

下一次客户端再发送相同的请求后，会直接从缓存中提取，只要缓存没有过期，就不会有任何新的请求到达服务器重新下载资源，

验证器的值用作If-Modified-Since和If-Match标头的参数。

缓存过期后客户端重新发起请求，服务器收到请求后发现如果资源没有更改，服务器会发回304 NotModified响应，

但是，一旦缓存过期，客户端不会直接使用缓存的值，而是发出条件请求。

缓存过期后客户端重新发起请求， 服务器收到请求后发现如果资源没有更改，服务器会发回304 NotModified响应，

这使缓存再次刷新， 并让客户端使用缓存的资源。

尽管有一个响应/请求往返消耗一些资源，但是这比再次通过有线传输整个资源更有效。

如果资源已经发生更改，则服务器仅使用新版本的资源返回200 OK响应，

就像没有条件请求，并且客户端会重新使用新的资源，从这个角度来讲，缓存是条件请求的前置条件.

图解断点续传

支持断点续传的服务器通过发送Accept-Ranges标头广播此消息，

 一旦发生这种情况， 客户端可以通过发送缺少范围的Ranges标头来恢复下载

子主题

Range 

Content-Range

如果在两次下载资源的期间进行了资源更新，那么获得的范围将对应于资源的两个不同版本，并且最终文档将被破坏，

为了阻止这种情况的出现，就会使用条件请求

对于范围来说，有两种方法可以做到这一点。

方法1：使用If-Modified-Since和If-Match

方法2：使用If-Range 

Web应用程序中最普遍的操作是资源更新。

这在任何文件系统或应用程序中都很常见， 但是任何允许存储远程资源的应用程序都需要这种机制。

使用put方法， 你可以实现这一点， 客户端首先读取原始文件对其进行修改， 然后把它们发送到服务器。

上面这种请求响应存在问题，一旦考虑到并发性，事情就会变得不准确。

当客户端在本地修改资源打算重新发送之前，第二个客户端可以获取相同的资源并对资源进行修改操作，这样就会造成问题。

当它们重新发送请求到服务器时，第一个客户端所做的修改将被第二次客户端的修改所覆盖，因为第二次客户端修改并不知道第一次客户端正在修改。

资源提交并更新的一方不会传达给另外一方，所以要保留哪个客户的更改，将随着他们提交的速度而变化：

这取决于客户端，服务器的性能，甚至取决于人工在客户端编辑文档的性能。

例如下面这个流程

如果没有两个用户同时操作服务器，也就不存在这个问题。

但是，现实情况是不可能只有单个用户出现的，

所以为了规避或者避免这个问题，希望客户端资源在更新时进行提示或者修改被拒绝时收到通知，

条件请求允许实现乐观锁算法。

这个概念是允许所有的客户端获取资源的副本，然后让他们在本地修改资源，

并成功通过允许第一个客户端提交更新来控制并发，基于此服务端的后面版本的更新都将被拒绝。

使用If-Match或If-Unmodified-Since标头实现

如果Etag与原始文件不匹配， 或者自获取以来已对文件进行了修改， 则更改为拒绝更新， 并显示412 Precondition Failed错误。

浏览器内的SQLite,

Indexed DB不属于关系型数据库,是NoSQL。

在Session Cookies中， 用户的登录状态会保存在服务器的内存中， 

当用户登录时， Session就被服务端安全的创建。

在每次请求时， 服务器都会从会话Cookie中读取Sessionld， 

如果服务端的数据和读取的Sessionld相同，那么服务器就会发送响应给浏览器，允许用户登录。

图解会话Cookie

永久Cookie实例

/docs
/docs/Web/
/docs/Web/HTTP

在Session Cookies中， 用户的登录状态会保存在服务器的内存中， 

当用户登录时， Session就被服务端安全的创建。

在每次请求时， 服务器都会从会话Cookie中读取Sessionld， 

如果服务端的数据和读取的Sessionld相同，那么服务器就会发送响应给浏览器，允许用户登录。

图解会话Cookie

JSON Web Token

简称JWT

它和Session都可以为网站提供用户的身份认证， 但是它们不是一回事。

Json Web Token的简称就是JWT， 通常可以称为Json令牌。

它是RFC 7519中定义的用于安全的将信息作为Json对象进行传输的一种形式。

JWT中存储的信息是经过数字签名的， 因此可以被信任和理解。

可以使用HMAC算法或使用RSA/ECDSA的公用/专用密钥对JWT进行签名，

认证(Authorization)

信息交换(Information Exchange)

Header

PayLoad

Signature

拼凑在一起

解读JWT示例

一个非常简单的JWT组成

当你访问某个网页，然后单击同一站点上的另一个页面时，服务器的内存中将不会记住你之前的操作

JWT具有加密签名， 而Session Cookies则没有。

JWT是无状态的， 因为声明被存储在客户端， 而不是服务端内存中。

身份验证可以在本地进行，而不是在请求必须通过服务器数据库或类似位置中进行。

这意味着可以对用户进行多次身份验证，而无需与站点或应用程序的数据库进行通信，也无需在此过程中消耗大量资源。

Session Cookies是存储在服务器内存中， 这就意味着如果网站或者应用很大的情况下会耗费大量的资源.

由于JWT是无状态的， 在许多情况下， 它们可以节省服务器资源。

因此JWT要比SessionCookies具有更强的可扩展性.

Session Cookies只能用在单个节点的域或者它的子域中有效。

如果它们尝试通过第三个节点访问，就会被禁止。

如果你希望自己的网站和其他站点建立安全连接时，这是一个问题。

使用JWT可以解决这个问题， 使用JWT能够通过多个节点进行用户认证， 也就是常说的跨域认证。

可能大多数用户不相信， 他可能觉得每次输入用户名和密码登陆一个网站后， 下次登陆就不再重新输入用户名和密码了。

这其实不是HTTP做的事情， 起作用的是一个叫做小甜饼(Cookie) 的机制。

它能够让浏览器具有记忆能力。

如果你的浏览器允许cookie， 查看方式chrome://settings/content/cookies

也就说明你的记忆芯片通电了

图解会话Cookie的过程

图解会话Cookie的实现原理、

当你想服务端发送请求时，服务端会给你发送一个认证信息，

服务器第一次接收到请求时， 开辟了一块Session空间(创建了Session对象) ， 同时生成一个sessionld，

并通过响应头的Set-Cookie:JSESSIONID=XXXXXXX命令， 向客户端发送要求设置Cookie的响应；

客户端收到响应后， 在本机客户端设置了一个JSESSIONID=XXXXXXX的Cookie信息， 该Cookie的过期时间为浏览器会话结束

接下来客户端每次向同一个网站发送请求时， 请求头都会带上该Cookie信息(包含sessionld) 

然后， 服务器通过读取请求头中的Cookie信息， 获取名称为JSESSIONID的值， 得到此次请求的sessionld。

这样， 你的浏览器才具有了记忆能力。

JWT的Cookie信息存储在客户端， 而不是服务端内存中

图解地址栏的显示

监听他和网站之间的信息交换

跟踪用户的活动，访问记录等

X.509是公开密钥证书的标准格式，

这个文档将加密密钥与(个人或组织)进行安全的关联。

SSL/TLS和HTTPS用于经过身份验证和加密的Web浏览

通过S/MIME协议签名和加密的电子邮件

代码签名 

文档签名

客户端认证

政府签发的电子身份证

整个TLS通信流程图

在进行通信前， 首先会进行HTTP的三次握手， 握手完成后， 再进行TLS的握手过程

Client Hello

Server Hello

认证(Authentication)

加密阶段

实现了安全的非对称加密：

记录协议

握手协议

警告协议

变更密码规范协议

扩展协议

对称加密

非对称加密

身份认证

使用ECD HE进行密钥交换

使用ECDSA进行签名和认证

然后使用AES作为对称加密算法，密钥的长度是256位

使用GCM作为分组模式

最后使用SHA 384作为摘要算法

密钥交换算法-签名算法-对称加密算法-【分组模式】-摘要算法

明文(Plaintext)

一般认为明文是有意义的字符或者比特集， 或者是通过某种公开编码就能获得的消息。

明文通常用m或p表示

密文(Ciphertext)

对明文进行某种加密后就变成了密文

加密(Encrypt)

把原始的信息(明文) 转换为密文的信息变换过程

解密(Decrypt)

把已经加密的信息恢复成明文的过程。

是什么？

图解对称加密

TLS里面有比较多的加密算法可供使用

常用的对称加密算法

对称加密存在风险

加密分组

是什么？

非对称加密中有两个密钥

图解非对称加密

原理说明

非对称加密算法的设计要比对称算法难得多

常用的非对称加密算法

在通信刚开始时,使用非对称算法， 比如RSA、ECDHE，首先解决密钥交换的问题

然后用随机数产生对称算法使用的会话密钥(session key) ， 再用公钥加密， 对方拿到密文后用私钥解密， 取出会话密钥。

这样，双方就实现了对称密钥的安全交换。

图解混合加密过程

在TLS中， 实现完整性的手段主要是摘要算法(Digest Algorithm)

可以把摘要算法理解成一种特殊的压缩算法，它能够把任意长度的数据压缩成一种固定长度的字符串。

这就好像是给数据加了一把锁

图解MD5加密

MD5的全称是Message Digest Algorithm5

它是属于密码哈希算法（cryptographic hash algorithm) 的一种

MD5可用于从任意长度的字符串创建128位字符串值。

MD5使用场景

增强MD5算法

什么是加盐?

什么是单向?

除了常用的MD 5是加密算法外， SHA-1(Secure Hash Algorithm 1) 也是一种常用的加密算法

为什么不是SHA-1 ？

SHA-2是什么？

SHA-2系列包含六个哈希函数

SHA-2还是不够安全

什么是MAC

什么是HMAC

图解HMAC工作流程

我们在向服务器发送数据的过程中，黑客(攻击者)有可能伪装成任何一方来窃取信息，

它可以伪装成你，来向服务器发送信息，

也可以伪装称为服务器，接受你发送的信息

那么怎么解决这个问题呢?

把公钥加密和私钥解密的顺序调换一下，变成私钥加密，公钥解密。

使用私钥再加上摘要算法，就能够实现数字签名，从而实现认证。

子主题

到现在，综合使用对称加密、非对称加密和摘要算法，我们已经实现了加密、数据认证、认证，

那么是不是就安全了呢?

非也，这里还存在一个数字签名的认证问题。

因为私钥是是自己的，公钥是谁都可以发布

所以必须发布经过认证的公钥，才能解决公钥的信任问题

CA的全称是Certificate Authority

证书认证机构

你必须让CA颁布具有认证过的公钥，才能解决公钥的信任问题。

全世界具有认证的CA就几家，分别颁布了DV、OV、EV三种，区别在于可信程度。

DV

OV

EV

不同的信任等级的机构一起形成了层级关系

通常情况下， 数字证书的申请人将生成的密钥对。

密钥对由三者组成

CSR是什么？

密钥对和CSR生成通常在将要安装证书的服务器上完成， 并且CSR中包含的信息类型取决于证书的验证级别。

与公钥不同，申请人的私钥是安全的，永远不要向CA(或其他任何人)展示。

生成CSR后， 申请人将其发送给CA， CA会验证其包含的信息是否正确

如果正确， 则使用颁发的私钥对证书进行数字签名，然后将其发送给申请人

图解CA工作流程