HTTP 有什么缺陷?为什么需要引入 TLS 协议?

SSL（安全套接字层）是在 90 年代初开发的。TLS（传输层安全）实际上就是 SSL 的继任者，可以说 TLS 是 SSL 的”后代”。第一个 TLS 版本（TLS 1.0）其实就是 SSL 3.0 的升级版。顺便一提，现代浏览器中也不再支持SSL啦。

关于这个问题，我想还是得从HTTP->SSL->TLS的顺序开始讲解会好理解一些：

·通信使用明文(不加密)，内容可能会被窃听。

·不验证通信方的身份，因此有可能遭遇伪装。

·无法证明报文的完整性，所以有可能已遭篡改

为了统一解决上述这些问题，需要在 HTTP上再加入加密处理和认证等机制。我们把添加了加密及认证机制的 HTTP 称为 HTTPS（HTTP Secure ）。HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用SSL(Secure SocketLayer)和TS(Transport Layer Security)协议代替而已。通常，HTTP 直接和 TCP 通信。当使用 SSL时，则演变成先和 SSL通信，再由 SSL和 TCP 通信了。简言之，所谓 HTTPS，其实就是身披SSL协议这层外壳的 HTTP。之后的TLS技术也是同理。

对称密钥和非对称密钥有什么区别?

在对 SSL进行讲解之前，我们先来了解一下加密方法。SSL采用一种叫做公开密钥加密(Public-key cryptography)的加密处理方式。
近代的加密方法中加密算法是公开的，而密钥却是保密的，就像保险箱的构造是公开的，但是密码只保存在主人这里一样：通过这种方式得以保持加密方法的安全性。
加密和解密都会用到密钥。没有密钥就无法对密码解密，反过来说任何人只要持有密钥就能解密了。如果密钥被攻击者获得，那加密也就失去了意义。这就是对称密钥加密的困境。

公开密钥加密方式很好地解决了共享密钥加密的困难。
公开密钥加密使用一对非对称的密钥。一把叫做私有密钥(private key)，另一把叫做公开密钥(public key)。顾名思义，私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得
使用公开密钥加密方式，发送密文的一方使用对方的公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听而盗走。但是，由于非对称加密处理起来非常复杂，每条请求都如此处理非常耗费性能，因此最终HTTPS混合加密诞生了。

答案是：在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。天才！

数字签名是什么?数字证书是什么?

但是非对称加密仍然存在问题：那就是无法证明公开密钥本身就是货真价实的公开密钥。比如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥?

为了解决上述问题，可以使用由数字证书认证机构(CA，Certificate Authority)和其相关机关颁发的公开密钥证书。

数字证书认证机构处于客户端与服务器双方都可信赖的第三方机构的立场上。威瑞信(VeriSign)就是其中一家非常有名的数字证书认证机构。我们来介绍一下数字证书认证机构的业务流程。首先，服务器的运营人员向数字证书认证机构提出公开密钥的申请。数字证书认证机构在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公钥证书后绑定在一起。就像当你收到朋友给你的支票（?）却无法确认最后的落款是不是他的时，一个专业的机构在上面敲了章说没问题放心用。

CA干的就是这：接到证书的客户端可使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可明确两件事：一，认证服务器的公开密钥的是真实有效的数字证书认证机构。二：服务器的公开密钥是值得信赖的。

那么问题来了，如何确认这个权威机构是可信的呢？很显然，此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。

整个图解过程如下：

OpenSSL：自签名

如果使用 OpenSSL这套开源程序，每个人都可以构建一套属于自己的认证机构，从而自己给自己颁发服务器证书。但该服务器证书在互联网上不可作为证书使用，似乎没什么帮助。

独立构建的认证机构叫做自认证机构，由自认证机构颁发的“无用”证书也被戏称为自签名证书。

浏览器访问该服务器时，会显示“无法确认连接安全性”或“该网站的安全证书存在问题”等警告消息。

但是！如果当Openssl尽管没什么作用，但是仍然遵守了HTTPS协议。这也就意味着，当你想要在强制规定必须接入HTTPS的网站却购买不起SSL证书时，它能帮上你大忙！（说的就是你，微信小程序😡😡😡）

HTTPS 握手流程是怎么样的?(基于 RSA 算法）

也许应该讲讲HTTPS的通信机制了？上图！

上图简要概述了 TLS 的握手过程，其中每一个「框」都是一个记录(record)，记录是 TLS 收发数据的基本单位，类似于 TCP 里的 segment。多个记录可以组合成一个 TCP 包发送，所以通常经过「四个消息」就可以完成 TLS 握手，也就是需要 2个 RTT(Round-Trip-Time) 的时延，然后就可以在安全的通信环境里发送 HTTP 报文，实现 HTTPS 协议。

所以可以发现，HTTPS 是应用层协议，需要先完成 TCP 连接建立，然后走 TLS 握手过程后，才能建立通信安全的连接。

接下来，我们就以最简单的 RSA密钥交换算法，来看看它的 TLS 握手过程。

注：RSA算法当然是非对称算法啦！当然，如果你第一次看觉得迷糊也是很正常的，但是请牢牢把握住重点：RSA算法的最终目的是为了让客户端和服务端双方都共享了三个随机数(Client Random、Server Random、pre-master)以生成会话密钥，经过再一次握手确认无内鬼后才开始交易。

当然，最精彩的图是要放在最后细品的：

Guess You Like It.png

每个 HTTP 版本新的特性？解决了什么问题？

HTTP/1.1:缓存机制，默认长连接，明文传输，队头阻塞，不支持服务器推送，头部臃肿，管道机制。

HTTP/2：流、帧、多路复用、请求优先级、HTTP 报头压缩、服务器推送，解决了 HTTP 层面的队头阻塞。

缺点：TCP层的队头阻塞问题。好比漫画书的传输，HTTP/2允许同时传输多个”故事”（Stream），但每个”故事”内部的页面（字节）还是要按顺序来。如果一个故事的第1页丢了，这个故事就要暂停等待；虽然其他故事还能继续看，但这个被阻塞的故事就卡在那里了。

HTTP/3：基于UDP 协议的“QUIC“协议，更快的连接建立。解决了TCP+TLS 建立连接的延时，连接id设置与连接迁移，QPACK 解决动态表跟新问题。

了解跨域

https://www.51cto.com/article/689093.html

了解RESTful规范

REST (Representational State Transfer) 是一种软件架构风格，由 Roy Fielding 在 2000 年提出。它的核心理念是：

面向资源(Resource)：所有事物都被抽象为资源
状态转移：通过 HTTP 动词对资源进行操作
无状态：服务器不保存客户端状态

其中最重要的是统一接口原则：

-资源标识：每个资源都有唯一的 URI

-通过表述操作资源：客户端不直接操作服务器资源，而是操作资源的表述

-自描述消息：请求和响应应该是自描述的，包含足够的信息

-HATEOAS：通过超链接指引客户端后续操作

1.资源设计

一切都是资源
资源应该是名词
资源 URI 应该是层级性的
避免动词，用 HTTP 方法表达动作

2.URL 设计

1
2
3

/api/v1/resources              # 资源集合
/api/v1/resources/{id}         # 具体资源
/api/v1/resources/{id}/sub     # 子资源

3.查询参数规范

?page=2&per_page=100          # 分页
?sort=name:asc                # 排序
?status=active                # 过滤
?fields=id,name               # 字段选择

4.响应格式

{
    "code": 200,
    "message": "success",
    "data": {
        "key": "value"
    }
}