http、https 体系结构

http

超文本传输协议，是一个基于请求与响应，无状态无连接的，应用层的协议，常基于TCP/IP协议传输数据

<协议>://<域名>:<端口>/<路径>

HTTP通常跑在TCP/IP协议栈之上，依靠IP协议实现寻址和路由、TCP协议实现可靠数据传输、DNS协议实现域名查找、SSL/TLS协议实现安全通信

http 特点

1. 无状态：协议对客户端没有状态存储，对事物处理没有“记忆”能力，比如访问一个网站需要反复进行登录操作
2. 无连接：HTTP/1.1之前，由于无状态特点，每次请求需要通过TCP三次握手四次挥手，和服务器重新建立连接。比如某个客户机在短时间多次请求同一个资源，服务器并不能区别是否已经响应过用户的请求，所以每次需要重新响应请求，需要耗费不必要的时间和流量。
3. HTTP/1.1 出现了长连接
   • 长连接：就是多个 http 请求共用一个 tcp 连接; 这样可以减少多次临近 http 请求导致 tcp建立关闭所产生的时间消耗.其中Keep-Alive:timeout=30,max=5, timeout 是两次 http 请求保持的时间(s), ,max 是这个 tcp 连接最多为几个 http请求重用
   • keep-alive 还有一个有效期，有效期结束后服务端会发侦查帧探查 TCP 是否有效，HTTP 的 keep-alive 是为了让 TCP 活久一点，而 TCP 本身也有一个 keepalive（注意没有横杠哦）机制。这是 TCP 的一种检测连接状况的保活机制，keepalive 是 TCP 保活定时器：TCP 建立后，如果闲置没用，服务器不可能白等下去，闲置一段时间[可设置]后，服务器就会尝试向客户端发送侦测包，来判断 TCP 连接状况，如果没有收到对方的回答（ACK包），就会过一会[可设置]再侦测一次，如果多次[可设置]都没回答，就会丢弃这个 TCP 连接
4. 基于请求和响应：基本的特性，由客户端发起请求，服务端响应
5. 简单快速、灵活
6. 通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性

http建立连接过程

• 先通过域名系统（Domain Name System，DNS）查询将域名转换为 IP 地址。即将 test.com 转换为 221.239.100.30 这一过程。
• 通过三次握手建立 TCP 连接。
• 发起 HTTP 请求。
• 目标服务器接收到 HTTP 请求并处理。
• 目标服务器往浏览器发回 HTTP 响应。
• 浏览器解析并渲染页面。

https

经由HTTP进行通信，利用SSL/TLS建立全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。关于TLS就是SSL的升级版本。

SSL 安全套接层(Secure Sockets Layer)
TSL 传输层安全(Transport Layer Security)

• HTTPS 连接建立过程和 HTTP 差不多，区别在于 HTTP（默认端口 80） 请求只要在 TCP 连接建立后就可以发起，而 HTTPS（默认端口 443） 在 TCP 连接建立后，还需要经历 SSL 协议握手，成功后才能发起请求。
• HTTPS 在HTTP和TCP之间建立了一个安全层，当HTTP和TCP通信时并不是像以前那样直接通信，经过了一个中间层进行加密，将加密后的数据包传给TCP, 相应的，TCP必须将数据包解密，才能传给上面的HTTP。

对称加密

如果信息在传输过程中被劫持，传输的内容就完全暴露了，他还可以篡改传输的信息且不被双方察觉，这就是中间人攻击。所以我们才需要对信息进行加密。最直接的加密方式就是对称加密。

对称加密就是加密和解密使用同一个密钥。如AES、DES。加解密过程：

• 浏览器给服务器并发送一个随机数client-random和加密套件(一个支持的加密方法列表)
• 服务器生成给浏览器返回另一个随机数server-random和加密套件
• 两边分别返回确认消息。然后两者用加密方法将两个随机数混合生成密钥，这就是通信上加解密的密钥

问题是client-random和server-random都是明文的，也就是密钥的相关信息在传输过程中很可能被窃取，中间人只要计算出密钥任何人都能解密，所以不能让第三方拿到密钥

如果通信双方都各自持有同一个密钥，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）。

• 试想一下，如果浏览器内部就预存了网站A的密钥，且可以确保除了浏览器和网站A，不会有任何外人知道该密钥，那理论上用对称加密是可以的，这样浏览器只要预存好世界上所有HTTPS网站的密钥就行啦！这么做显然不现实。

怎么办？所以我们就需要神奇的非对称加密

非对称加密

为什么会出现非对称加密，就是因为对称加密的算法是可以被攻破的，(最坏的情况下穷举攻击能攻破的
非对称加密分为两个密钥：公钥和私钥。公钥是谁都能有，用于对信息加密，只有私钥才能解密。

用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。

• 使用公钥反推出私钥是非常困难，但不是做不到，随着计算机运算能力提高，非对称密钥至少要2048位才能保证安全性，这就导致加解密速度慢，效率太低

只有一方使用非对称加密

• 浏览器给服务器发送加密套件
• 服务器选好支持的加密方法和公钥(明文) 传给浏览器
• 两边分别返回确认消息。然后浏览器用公钥对数据进行加密，这个密钥只能用私钥解密

通俗版:

• 服务器先把公钥直接明文传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，这样浏览器到服务器的数据传输能够保证，因为只有服务器有相应的私这样钥能解开这条数据。
• 然而由服务器到浏览器的这条路不能保障安全
  • 如果之后服务端向浏览器端发送数据用公钥加密，但因为浏览器端没有私钥，所以无法解密
  • 如果服务器用它的的私钥加密数据传给浏览器，那浏览器是可以用公钥可以解密它，但这个公钥是一开始通过明文传输给浏览器的，这个公钥被谁劫持到的话，他也能用该公钥解密服务器传来的信息了

总结：无法保证服务器发送给浏览器的这条线路的数据安全。

浏览器和服务器都使用非对称加密

浏览器和服务器都各自有一对公钥和私钥

• 某网站拥有用于非对称加密的公钥A、私钥A’；浏览器拥有用于非对称加密的公钥B、私钥B’。
• 浏览器像网站服务器请求，服务器把公钥A明文给传输浏览器。
• 浏览器把公钥B明文传输给服务器
• 之后浏览器向服务器传输的所有东西都用公钥A加密，服务器收到后用私钥A’解密。由于只有服务器拥有这个私钥A’可以解密，所以能保证这条数据的安全。
• 服务器向浏览器传输的所有东西都用公钥B加密，浏览器收到后用私钥B’解密。同上也可以保证这条数据的安全

HTTPS的加密却没使用这种方案，最主要的原因是非对称加密算法非常耗时，特别是加密解密一些较大数据的时候有些力不从心，而对称加密快很多

混合加密（非对称加密+对称加密）

TLS实际用的是两种算法的混合加密。**通过 非对称加密算法 交换 对称加密算法 的密钥，交换完成后，再使用对称加密进行加解密传输数据。**这样就保证了会话的机密性。过程如下

• 浏览器给服务器发送一个随机数client-random、对称和非对称加密套件
• 服务器把另一个随机数server-random、加密套件、公钥传给浏览器
• 浏览器又生成另一个随机数pre-random，并用公钥对 pre-random 加密后传给服务器
• 服务器再用私钥解密，得到pre-random，并返回确认消息
• 这样浏览器和服务器都有三个随机数了，然后各自将三个随机数用加密方法混合生成最终的对称密钥

然后开始数据加密传输
这样即便被截持，中间人没有私钥就拿不到pre-random，就无法生成最终密钥

通俗版:

• 某网站拥有用于非对称加密的公钥A、私钥A’。
• 浏览器像网站服务器发送请求，服务器把公钥A明文给传输浏览器。
• 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
• 服务器拿到后用私钥A’解密得到密钥X。
• 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都用密钥X加密解密。
• HTTPS基本就是采用了这种方案

中间人攻击

中间人的确无法得到浏览器生成的密钥B，这个密钥本身被公钥A加密了，只有服务器才有私钥A’解开拿到它呀！然而中间人却完全不需要拿到密钥A’就能干坏事了

• 某网站拥有用于非对称加密的公钥A、私钥A’。
• 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
• 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
  • 黑客如果采用 DNS 劫持，将目标地址替换成黑客服务器的地址
• 浏览器随机生成一个用于对称加密的密钥X，用公钥B（浏览器不知道公钥被替换了）加密后传给服务器。
• 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。
• 服务器拿到后用私钥A’解密得到密钥X。

这样在双方都不会发现异常的情况下，中间人得到了密钥X。根本原因是浏览器无法确认自己收到的公钥是不是网站自己的。
那么下一步就是解决下面这个问题：

数字证书

网站在使用HTTPS前，需要向“CA机构”申请颁发一份数字证书，数字证书里有证书持有者、证书持有者的公钥等信息，服务器把证书传输给浏览器，浏览器从证书里取公钥就行了，证书就如身份证一样，可以证明“该公钥对应该网站”。

数字签名

• 如何放防止数字证书被篡改?我们把证书内容生成一份“签名”，比对证书内容和签名是否一致就能察觉是否被篡改。这种技术就叫数字签名

那么如何申请数字证书呢？

• 首先，服务器准备一套公钥和私钥，私钥留着自己用
• 服务器将公钥和站点等信息提交给CA认证，这个是要钱的
• CA验证服务器提供的信息
• 审核通过后签发认证的数字证书，包含了公钥、CA信息、有效时间、证书序列等这些都是明文的，还有一个CA生成的签名

CA的签名过程（数字签名）

• CA也有一套公钥和私钥
• CA使用摘要算法计算服务器提交的明文信息并得出信息摘要
• 然后CA再用它的私钥和特定的算法对信息摘要加密，生成签名
• 把签名、服务器公钥等信息打包放入数字证书，并返回给服务器
• 服务器配置好证书，以后浏览器连接服务器，都先把证书发给客户端验证

摘要算法：主要用于保证信息的完整性。常见的MD5算法、散列函数、hash函数都属于这类算法，其特点就是单向性、无法反推原文

图中左侧是数字签名的制作过程，右侧是验证过程
数字签名的制作过程：

• CA拥有非对称加密的私钥和公钥。
• CA对证书明文信息进行hash。
• 对hash后的值用私钥加密，得到数字签名。

明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了

浏览器如何验证数字证书

• 浏览器连接服务器，都先把证书发给客户端验证
• 使用CA公钥和声明的签名算法对CA中的签名进行解密，得到服务器的摘要内容和服务器公钥
• 再用摘要算法对证书里的服务器公钥生成摘要，再把这个摘要和上一步得到的摘要对比
  然后将两个信息摘要对比，如果是一致的，就说明证书是合法的，即证明了服务器自己，否则就是非法的

通俗版:

• 拿到证书，得到明文T，数字签名S。
• 用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥。详情见下文），得到S’。
• 用证书里说明的hash算法对明文T进行hash得到T’。
• 比较S’是否等于T’，等于则表明证书可信

证书认证又分为单向认证和双向认证

• 单向认证：服务器发送证书，客户端验证证书
• 双向认证：服务器和客户端分别提供证书给对方，并互相验证对方的证书

不过大多数https服务器都是单向认证，如果服务器需要验证客户端的身份，一般通过用户名、密码、手机验证码等之类的凭证来验证。只有更高级别的要求的系统，比如大额网银转账等，就会提供双向认证的场景，来确保对客户身份提供认证性

另外在申请和使用证书的过程中，需要注意

• 申请数字证书是不需要提供私钥的，要确保私钥永远只能由服务器掌握
• 数字证书最核心的是CA使用它的私钥生成的数字签名
• 内置CA对应的证书称为根证书，根证书是最权威的机构，它们自己为自己签名，这称为自签名证书

为什么这样可以证明证书可信呢?

• 假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。
• 假设中间人截取了公钥解密出了信息摘要，然后篡改，但因为没有私钥，无法再对信息摘要进行加密
• 假设有另一个网站B也拿到了CA机构认证的证书，它想搞垮网站A，想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，又会导致上文提到的混合加密的漏洞。其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。

为什么制作数字签名时需要hash一次？

最显然的是性能问题，前面我们已经说了非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息（比如用md5算法hash后可以得到固定的128位的值），这样加密解密就会快很多。当然还有安全上的原因，这部分内容相对深一些，感兴趣的可以看这篇解答：详情

怎么证明CA机构的公钥是可信的？

即“该公钥是否对应该网站/机构等”，那这个CA机构的公钥是不是也可以用数字证书来证明？没错，操作系统、浏览器本身会预装一些它们信任的根证书，如果其中有该CA机构的根证书，那就可以拿到它对应的可信公钥了

• 实际上证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，我们把它叫做信任链或数字证书链，也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。
• 另外，不知你们是否遇到过网站访问不了、提示要安装证书的情况？这里安装的就是根证书。说明浏览器不认给这个网站颁发证书的机构，那么没有该机构的根证书，你就得手动下载安装（风险自己承担XD）。安装该机构的根证书后，你就有了它的公钥，就可以用它验证服务器发来的证书是否可信了。

HTTPS必须在每次请求中都要先在SSL/TLS层进行握手传输密钥吗?

显然每次请求都经历一次密钥传输过程非常耗时，那怎么达到只传输一次呢？靠“session”。服务器会为每个浏览器（或客户端软件）维护一个session ID，在TSL握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了！

HTTPS 缺点

• SSL证书需要购买申请，功能越强大的证书费用越高
• SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗（SSL有扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器、操作系统支持，Windows XP就不支持这个扩展，考虑到XP的装机量，这个特性几乎没用）。
  根据ACM CoNEXT数据显示，使用HTTPS协议会使页面的加载时间延长近50%，增加10%到20%的耗电。
• HTTPS连接缓存不如HTTP高效，流量成本高。
• HTTPS连接服务器端资源占用高很多，支持访客多的网站需要投入更大的成本。
• HTTPS协议握手阶段比较费时，对网站的响应速度有影响，影响用户体验。比较好的方式是采用分而治之，类似12306网站的主页使用HTTP协议，有关于用户信息等方面使用HTTPS。

几种版本的握手加密方法

传统的TLS握手也就是RSA握手；

• 客户端首先向服务端发送一个HTTPS请求
• 服务端会把事先配置好的公钥证书随着其它的信息返回给客户端
• 客户端在收到服务端发来的证书之后进行验证，验证的过程参考数字证书验证，会得到服务端的信息以及它的公钥
• 验证成功之后会用伪随机函数计算出一个加密所需要的对称密钥(secret)，并且用服务端的公钥加密这个对称密钥发送给服务端
• 服务端再用自己的私钥解密刚刚的消息，得到里面的对称密钥。此时服务端和客户端都有了对称密钥。
• 后面的传输都会用这个 secret 进行对称密钥加解密传输

详细的RSA握手

• 客户端首先发送 client_random、TSL版本号、加密套件列表给服务器
• 服务器在接收到之后确认TSL版本号，同时发送server_random、需要使用的加密套件、自己的证书给客户端
• 客户端在收到这些信息之后，首先是会对服务器的证书进行验证(也就是题目7)，若是验证成功则会用RSA算法生成一个pre_random，且用服务器的公钥(在证书中)加密pre_random发送给服务器。
• 此时，客户端有了 client_random、server_random、pre_random，它会将这三个参数通过一个伪随机函数计算得出最终的secret，这个secret就是它们后续通信所要用的对称密钥。
• 服务器接收到了刚刚用自己公钥加密的pre_random之后，用自己的私钥进行解密，得到里面的 pre_random，用和客户端一样的方式生成secret。
• 之后就用这个 secret对称密钥加密报文传输。

现在主流的TLS1.2版本的握手，也就是ECDHE握手。

• 客户端在第一次发送HTTPS请求的时候，会把 client_random、TSL版本号、加密套件列表发送给服务器

• 服务器在接收到之后确认TSL的版本号，同时发送 server_random、server_params、需要使用的加密套件、以及自己的证书给客户端

• 客户端在收到这些信息之后，首先是会对服务器的证书进行验证(也就是题目7)，若是验证成功则会传递一个 client_params 给服务器

• 与此同时客户端会通过ECDHE算法计算出一个pre_random，其中是传入了两个参数，一个是 client_params，还一个是 server_params。(也就是说：ECDHE(client_params, server_params) = per_random)

• 这时候客户端就同时拥有了 client_random、server_random、pre_random，它会将这三个参数通过一个伪随机函数计算得出最终的secret，这个secret就是它们后续通信所要用的对称密钥。

• 而在客户端生成完secret之后，会给服务器发送一个收尾消息，告诉服务器之后都要用对称加密，且对称加密的算法是用第一次约定好的。

• 服务器它在接收到刚刚传递过来的client_params之后，也会使用和客户端一样的方式生成secret，并且也会发送一个收尾消息给客户端。

• 当双方都收到收尾消息并验证成功之后，握手就结束了。后面开始用这个secret对称密钥加密报文进行传输。

• （ECDHE基于椭圆曲线离散对数，传入的两个参数也被叫做椭圆曲线的公钥）

ECDHE握手和RSA握手又有什么区别

• 生成secret(对称密钥)的过程不同。RSA中是使用RSA算法生成一个pre_random并用服务器的公钥加pre_random发送给服务器，然后各自用伪随机函数生成相同的secret对称密钥；而在ECDHE握手中，它没有用到RSA算法，而是用ECDHE算法生成的pre_random，且这个过程中比RSA多了client_params和server_params两个参数。
• 在生成完secret之后，ECDHE握手在客户端发送完收尾消息后可以提前抢跑，直接发送 HTTP 报文，节省了一个 RTT，不必等到收尾消息到达服务器，然后等服务器返回收尾消息给自己，直接开始发请求。这也叫TLS False Start。
• 最主要的：RSA不具备向前安全性（向前安全性：一次破解并不影响历史信息的性质就是向前安全性），ECDHE有

向前安全性

• 比如在RSA握手的过程中，客户端拿到了服务端的公钥，然后用此公钥加密pre_random给服务端。如果此时有第三方有服务端的私钥，并且截获了之前所有报文的时候，那么它就可以破解这段密文并拿到pre_random、client_random、server_random并根据对应的伪随机函数生成secret，即拿到了最终通信的对称密钥，每一个历史报文都能通过这样的方式进行破解。它就不具有向前安全性。
• 但是ECDHE在每次握手的时候都会产生一个零时的密钥对(也就是client_params、server_params)，即使第三方有了私钥能破解，但是对之前的历史报文并没有影响。它就具有向前安全性。

HTTPS 实现过程

• client向server发送请求https://baidu.com，然后连接到server的443端口，发送的信息主要是随机值1和客户端支持的加密算法。
• server接收到信息之后给予client响应握手信息，包括随机值2和匹配好的协商加密算法，这个加密算法一定是client发送给server加密算法的子集。
• 随即server给client发送第二个响应报文是数字证书。服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。传送证书，这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间、服务端的公钥，第三方证书认证机构(CA)的签名，服务端的域名信息等内容。
• 客户端解析证书，这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（预主秘钥）。
• 客户端认证证书通过之后，接下来是通过随机值1、随机值2和预主秘钥组装会话秘钥。然后通过证书的公钥加密会话秘钥。
• 传送加密信息，这部分传送的是用证书加密后的会话秘钥，目的就是让服务端使用秘钥解密得到随机值1、随机值2和预主秘钥。
• 服务端解密得到随机值1、随机值2和预主秘钥，然后组装会话秘钥，跟客户端会话秘钥相同。
• 客户端通过会话秘钥加密一条消息发送给服务端，主要验证服务端是否正常接受客户端加密的消息。
• 同样服务端也会通过会话秘钥加密一条消息回传给客户端，如果客户端能够正常接受的话表明SSL层连接建立完成了。

HTTPS 第一次请求会携带什么？

当使用HTTPS进行第一次请求时，客户端与服务器之间会进行SSL/TLS握手的过程，以建立加密通信信道。

• 客户端Hello（ClientHello）：客户端首先向服务器发送一个ClientHello消息，其中包含以下信息：
  • 客户端支持的SSL/TLS版本，如TLSv1.2、TLSv1.3等。
  • 客户端支持的加密套件列表，包括密钥交换算法、对称加密算法、摘要算法等。
  • 一个随机生成的客户端随机数（Client Random），用于后续计算密钥。
  • 可选的扩展信息，例如支持的应用层协议、支持的压缩方法等。
• 服务端Hello（ServerHello）：服务器收到客户端Hello后，会发送一个ServerHello消息作为回应，该消息中包含：
  • 服务器选择使用的SSL/TLS版本。
  • 从客户端提供的加密套件列表中选择一个加密套件。
  • 一个随机生成的服务端随机数（Server Random），用于后续计算密钥。
  • 可选的扩展信息，如应用层协议等。
• 服务端证书（Certificate）：服务器会发送其数字证书给客户端。数字证书包含服务器的公钥、服务器的域名信息，以及由可信的证书颁发机构（CA）对该证书的签名。
• 服务端密钥交换或证书验证（ServerKeyExchange，可选）：某些密钥交换方案，例如Diffie-Hellman（DH）或Ephemeral Diffie-Hellman（DHE），可能需要服务器向客户端提供额外的密钥信息。此时，服务器会发送一个ServerKeyExchange消息。
• 客户端证书请求（CertificateRequest，可选）：服务器可以要求客户端提供其证书以进行双向身份验证。这种情况下，服务器会发送CertificateRequest消息。
• 服务端Hello结束（ServerHelloDone）：服务器发送一个ServerHelloDone消息，表示握手的第一阶段已经完成。