前四天综合总结

一、HTTPS过程

HTTPS（Hypertext Transfer Protocol Secure）是一个用于在计算机之间传输超文本数据的安全协议。它在 HTTP 的基础上添加了安全性措施，通过使用 SSL（Secure Socket Layer）或 TLS（Transport Layer Security）协议来对数据进行加密和保护。
https工作流程：

TLS 第一次握手
客户端首先会发一个「Client Hello」消息，字面意思我们也能理解到，这是跟服务器「打招呼」。

消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，支持的压缩算法，以及生成的随机数（*Client Random*），这个随机数会被服务端保留，它是生成对称加密密钥的材料之一。

TLS 第二次握手
当服务端收到客户端的「Client Hello」消息后，会确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，还有选择压缩算法（安全性原因，一般不压缩），以及生成随机数（*Server Random*）。

接着，返回「Server Hello」消息，消息里面有服务器确认的 TLS 版本号，也给出了随机数（Server Random），然后从客户端的密码套件列表选择了一个合适的密码套件。

然后，服务端为了证明自己的身份，会发送「Server Certificate」给客户端，这个消息里含有数字证书。

随后，服务端发了「Server Hello Done」消息，目的是告诉客户端，我已经把该给你的东西都给你了，本次打招呼完毕。

TLS 第三次握手
客户端验证完证书后，认为可信则继续往下走。接着，客户端就会生成一个新的随机数 (pre-master)，用服务器的 RSA 公钥加密该随机数，通过「Change Cipher Key Exchange」消息传给服务端。

服务端收到后，用 RSA 私钥解密，得到客户端发来的随机数 (pre-master)。

至此，客户端和服务端双方都共享了三个随机数，分别是 Client Random、Server Random、pre-master。

于是，双方根据已经得到的三个随机数，生成会话密钥（Master Secret），它是对称密钥，用于对后续的 HTTP 请求/响应的数据加解密。

生成完会话密钥后，然后客户端发一个「Change Cipher Spec」，告诉服务端开始使用加密方式发送消息。

然后，客户端再发一个「Encrypted Handshake Message（Finishd）」消息，把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下，让服务器做个验证，验证加密通信是否可用和之前握手信息是否有被中途篡改过。

TLS 第四次握手
服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。

最后，就用「会话密钥」加解密 HTTP 请求和响应了。

CA证书工作流程

1）申请认证：服务器需自己生成公钥私钥对 pub_svr & pri_svr，同时根据 pub_svr 生成请求文件 csr, 提交给 CA，csr 中含有公钥、组织信息、个人信息 (域名) 等信息。(图二中 server.req 就是 csr 请求文件)
2）审核信息：CA 通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等。
3）签发证书：如信息审核通过，CA 会向申请者签发认证文件 - 证书。 证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名。 签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名。（图二中生成 server.crt）
4）返回证书：client 如果请求验证服务器，服务器需返回证书文件。（图二中 handshake 传回 server.crt
5）client 验证证书：client 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法。客户端然后验证证书相关的域名信息、有效时间是否吊销等信息。 客户端会内置信任 CA 的证书信息 (包含公钥)，如果 CA 不被信任，则找不到对应 CA 的证书，证书也会被判定非法。(图二中 check 可选，我们可以选择不验证服务器证书的有效性)
6）秘钥协商：验证通过后，Server 和 Client 将进行秘钥协商。接下来 Server 和 Client 会采用对称秘钥加密。(对称加密时间性能优)（图二中 pre-master/change_cipher_spec/encrypted_handshake_message 过程）
7）数据传输：Server 和 Client 采用对称秘钥加密解密数据。

3.2 创建一个自签名的SSL证书(X509)

证书链
但事实上，证书的验证过程中还存在一个证书信任链的问题，因为我们向 CA 申请的证书一般不是根证书签发的，而是由中间证书签发的，比如百度的证书，从下图你可以看到，证书的层级有三级， 对于这种三级层级关系的证书的验证过程如下：

客户端收到 baidu.com 的证书后，发现这个证书的签发者不是根证书，就无法根据本地已有的根证书中的公钥去验证 baidu.com 证书是否可信。于是，客户端根据 baidu.com 证书中的签发者，找到该证书的颁发机构是 “GlobalSign Organization Validation CA - SHA256 - G2”，然后向 CA 请求该中间证书。

请求到证书后发现 “GlobalSign Organization Validation CA - SHA256 - G2” 证书是由 “GlobalSign Root CA” 签发的，由于 “GlobalSign Root CA” 没有再上级签发机构，说明它是根证书，也就是自签证书。应用软件会检查此证书有否已预载于根证书清单上，如果有，则可以利用根证书中的公钥去验证 “GlobalSign Organization Validation CA - SHA256 - G2” 证书，如果发现验证通过，就认为该中间证书是可信的。

“GlobalSign Organization Validation CA - SHA256 - G2” 证书被信任后，可以使用 “GlobalSign Organization Validation CA - SHA256 - G2” 证书中的公钥去验证 baidu.com 证书的可信性，如果验证通过，就可以信任 baidu.com 证书。

在这四个步骤中，最开始客户端只信任根证书 GlobalSign Root CA 证书的，然后 “GlobalSign Root CA” 证书信任 “GlobalSign Organization Validation CA - SHA256 - G2” 证书，而 “GlobalSign Organization Validation CA - SHA256 - G2” 证书又信任 baidu.com 证书，于是客户端也信任 baidu.com 证书。 总括来说，由于用户信任 GlobalSign，所以由 GlobalSign 所担保的 baidu.com 可以被信任，另外由于用户信任操作系统或浏览器的软件商，所以由软件商预载了根证书的 GlobalSign 都可被信任。

二、DNS传输过程

DNS是域名系统（Domain Name Service）的缩写，我们通常用来识别主机的方式有两种，一种是通过主机名，另外一种是通过IP地址。主机名便于我们的记忆，而路由器则更喜欢定长的、有着层次结构的IP地址。所以需要一个能将域名转变到IP地址的目录服务，这就是域名服务器存在的意义。

DNS解析过程

当用户在浏览器中输入www.baidu.com的时候，DNS解析大概会有以下过程：

1. 首先浏览器会检查自身缓存是否解析过这个域名的IP地址，如果有即缓存命中，那么解析结束；
2. 如果浏览器缓存中没有，那么浏览器会检查操作系统缓存中是否有相应的解析过的结果。而操作系统也有一个域名解析的过程。像我们熟悉的hosts文件，如果用户在这里定义了一个域名对应的IP地址，那么浏览器会首先使用这里定义的IP地址；
3. 如果此时还没有命中域名，才会真正地去请求本地域名服务器（LDNS）来解析这个域名，这台服务器一般在你的城市的某个角落，距离你不是很远，并且这台服务器的性能很好，一般这里会缓存域名解析的结果。大约80%的域名解析到这里就完成了；
4. 如果LDNS仍然没有命中，那么LDNS就会向根域名服务器（Root Server）发起域名请求解析；
5. 根域名服务器返回给LDNS一个所查询域的主域名服务器（gTLD Server，国际顶尖域名服务器，如.com、.cn、.org等）地址；
6. 此时LDNS再发送请求到上一步返回的gTLD的IP地址；
7. 接受请求的gTLD查找并返回这个域名对应的Name Server的地址，这个Name Server就是网站注册的域名服务器；
8. Name Server根据映射关系表找到目标IP地址，并将其返回给LDNS；
9. LDNS缓存这个域名和对应的IP；
10. LDNS把解析的结果返回给用户，用户根据TTL值缓存到本地系统缓存中，域名解析过程至此结束。

DNS服务器的体系架构

DNS的传输层协议

从上面内容我们了解了DNS主要解析流程，DNS主要作用就是将主机域名转换为IP地址。当用户主机的DNS客户端接收到应用程序的这种转换请求时（例如调用gethostbyname()系统函数），那么就会向网络中发送一个DNS查询报文。需要了解的是，DNS请求和回答报文的下层都是使用UDP数据报经过53端口发送的。

那么为什么使用UDP（User Datagram Protocol）这样面向无连接的，尽最大能力交付的不可靠数据连接，而不是使用TCP（Transmission Control Protocol）这样的面向连接的可靠数据连接。

因为相比较与TCP来说，一次UDP域名服务器的交换可以短到只有两个报文，一个查询报文、一个响应报文。一次TCP交换则至少包含九个传送报文：三次握手初始化TCP会话、一个查询报文、一个响应报文、四次挥手的TCP中断连接（或许是八个报文，毕竟连接建立时第二个ACK报文是可以携带数据的，谁知道呢，反正也比两个报文要多）。所以考虑到效率的原因，TCP连接的开销更大，故而采用UDP作为DNS的传输层协议。

当然还有另外一点需要注意，整个DNS服务体系中，并不是只有UDP一种协议存在，上述域名解析时使用的是UDP，但是在区域传送时还是使用TCP。辅域名服务器会定时（一般是三小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动，则会执行一次区域传送，进行数据同步。区域传送将使用TCP而不是UDP，因为数据同步传送的数据量比一个请求和应答的数据量要多得多，使用TCP更加可靠。

DNS的分布式集群工作方式

DNS解析过程有两种类型：分布域名解析和集中式域名解析。

集中式域名解析

DNS的一种简单设计是在因特网上只使用一个DNS服务器，该服务器包含了所有的映射。在这种集中式设计中，客户直接将所有查询直接发往单一的DNS服务器，同时该DNS服务器直接对所有的查询客户做出响应。尽管这种设计十分简单，但是由于因特网有着数据量巨大的主机。这种集中式设计会有以下问题：①单点故障：如果该DNS服务器奔溃，整个因特网随之瘫痪；②通信容量：单个DNS服务器不得不处理所有的DNS查询。

分布式域名解析

所以单一DNS服务器上运行集中式数据库完全没有可扩展能力。因此，DNS采用了分布式的设计方案。

事实上DNS服务器是一种分布式并且分层次的数据库系统，从上面DNS的解析过程中我们也看出来了，DNS系统中有多种类型的DNS服务器，它们之间以层次划分开来：

根DNS服务器：根域名服务器提供TLD服务器的IP地址；
顶级域（DNS）服务器：对于每个顶级域（如com、org、net）都有TLD服务器（或集群服务器）。TLD服务器提供了DNS服务器的IP地址；
权威DNS服务器：在因特网上具有公共可访问主机（如Web服务器和邮件服务器）的每个组织机构必须提供公共可访问的DNS记录，这些记录将这些主机的名字映射为IP地址。多数大学和大公司是实现和维护它们自己的基本和辅助（备份）的权威DNS。