笔记：HTTP优缺点与HTTPS

HTTP简介

HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。
将“超文本传输协议”拆分成，“超文本”，“传输”，“协议”，会更好理解。

• 超文本：普通的字符的组合我们称之为文本，那么超文本则会更高级一点，有文字，图片，音频，视频等其他的信息组合而成的混合体，就像HTML，它虽然只是一个由标签组成的文件，但是其中很多定义了音频，视频等链接，通过浏览器的解释渲染，就会程序一个既有文字又有图片视频的画面了。
• 传输：简单讲就是网络两端的数据的相互传输。我们常见的就是客户端和服务器的传输。A和B之间传输数据，并且允许中间有C进行中转或者接力。
• 协议：协议简单理解就是一种约定，这种约定是计算机之间通信的一种约定。HTTP 是一个用在计算机世界里的协议。它使用计算机能够理解的语言确立了一种计算机之间交流通信的规范（两个以上的参与者），以及相关的各种控制和错误处理方式（行为约定和规范）。
  总的来说：HTTP 是一个在计算机世界里专门用来在两点之间传输数据的约定和规范。

HTTP优点与缺点（HTTP1.1）

优点：

• 简易：HTTP 基本的报文格式就是 header + body ，头部信息也是 key-value 简单文本的形式，易于理解，降低了学习和使用的门槛。
• 灵活和易于扩展：HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。
  同时 HTTP 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化。
  HTTPS 也就是在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层，HTTP/3 甚至把 TCP 层换成了基于 UDP 的 QUIC。
• 应用广泛和跨平台：HTTP 的应用范围非常的广泛，从PC端到手机APP，从看新闻、听音乐到购物和游戏。

缺点：

• 无状态：这个是一把双刃剑，好处是服务器不会去记忆HTTP的状态，所以可以不用消耗额外的资源。坏处就是在完成一些有关联性的操作时会很麻烦。
  例如登录->添加购物车->下单->支付->收货，这一系列操作，都需要是有的身份才能进行。但是服务器并不知道这些操作是有关联的，每一次都要询问一遍身份。
  这种无状态的问题，可以使用比较简单的cookie来解决，cookie通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了了。
• 明文传输：传输过程中，可以通过浏览器的控制台和抓包工具直接获取传输过程中的信息。正是因为这样，HTTP的所有信息都暴露了出来，传输的过程中没有任何隐私可言，很容易就可以窃取你的账号密码等重要信息。
• 不安全：
  通信使用明文（不加密），内容可能会被窃听。比如，账号信息容易泄漏，那你号没了。
  不验证通信方的身份，因此有可能遭遇伪装。比如，访问假的淘宝、拼多多，那你钱没了。
  无法证明报文的完整性，所以有可能已遭篡改。比如，网页上植入垃圾广告，视觉污染，眼没了。
  HTTP 的安全问题，可以用 HTTPS 的方式解决，也就是通过引入 SSL/TLS 层，使得在安全上达到了极致。

HTTP与HTTPS

1. 区别

• HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全
  的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
• HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP
  三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
• HTTP 的端口号是 80，HTTPS 的端口号是 443。
• HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

2. HTTPS解决了哪些问题？
   HTTP 由于是明文传输，所以安全上存在以下三个风险：

• 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
• 篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
• 冒充风险，比如冒充淘宝网站，用户钱容易没。

HTTPS 在 HTTP 与 TCP 层之间加入了 SSL/TLS 协议，可以很好的解决了上述的风险：

• 信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。
• 校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。
• 身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。
  可见，只要自身不做「恶」，SSL/TLS 协议是能保证通信是安全的。

3. HTTPS 是如何解决上面的三个风险的？

• 混合加密的方式实现信息的机密性，解决了窃听的风险。
• 摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。
• 将服务器公钥放入到数字证书中，解决了冒充的风险。

混合加密：

HTTPS 采用的是对称加密和非对称加密结合的「混合加密」方式：

• 在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
• 在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。
  采用「混合加密」的方式的原因：
• 对称加密只使用一个密钥，运算速度快，密钥必须保密，无法做到安全的密钥交换。
• 非对称加密使用两个密钥：公钥和私钥，公钥可以任意分发而私钥保密，解决了密钥交换问题但速度慢。

摘要算法：
摘要算法用来实现完整性，能够为数据生成独一无二的「指纹」，用于校验数据的完整性，解决了篡改的风险。

客户端在发送明文之前会通过摘要算法算出明文的「指纹」，发送的时候把「指纹 + 明文」一同加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文，通过比较客户端携带的「指纹」和当前算出的「指纹」做比较，若「指纹」相同，说明数据是完整的。

数字证书：
客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
这就存在些问题，如何保证公钥不被篡改和信任度？
所以这里就需要借助第三方权威机构 CA （数字证书认证机构），将服务器公钥放在数字证书（由数字证书认证机构颁发）中，只要证书是可信的，公钥就是可信的。

4. HTTPS 是如何建立连接的？其间交互了什么？
   SSL/TLS 协议基本流程：

• 客户端向服务器索要并验证服务器的公钥。
• 双方协商生产「会话秘钥」。
• 双方采用「会话秘钥」进行加密通信。
  前两步也就是 SSL/TLS 的建立过程，也就是握手阶段。
  SSL/TLS 的「握手阶段」涉及四次通信，可见下图：

SSL/TLS 协议建立的详细流程：

1. ClientHello
   首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。
   在这一步，客户端主要向服务器发送以下信息：
   （1）客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。
   （2）客户端生产的随机数（ Client Random ），后面用于生产「会话秘钥」。
   （3）客户端支持的密码套件列表，如 RSA 加密算法。
2. SeverHello
   服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello 。服务器回应的内容有如下内容：
   （1）确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。
   （2）服务器生产的随机数（ Server Random ），后面用于生产「会话秘钥」。
   （3）确认的密码套件列表，如 RSA 加密算法。
   （4）服务器的数字证书。
3. 客户端回应
   客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。
   如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：
   （1）一个随机数（ pre-master key ）。该随机数会被服务器公钥加密。
   （2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
   （3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。
   上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。
4. 服务器的最后回应
   服务器收到客户端的第三个随机数（ pre-master key ）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发生最后的信息：
   （1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。
   （2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。
   至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。