写在最前
超文本传输协议（Hyper Text Transfer Protocol，HTTP）是一个简单的请求-响应协议，它是基于 TCP 协议的应用层传输协议。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。
HTTP 是一种无状态 （stateless） 协议， HTTP 协议本身不会对发送过的请求和响应的通信状态进行持久化处理。这样做的目的是为了保持 HTTP 协议的简单性，从而能够快速处理大量的事务，提高效率。
HTTP 请求体
HTTP 请求体是请求数据时发送给服务器的数据，毕竟向服务器拿数据，先要表明怎么要，以及要什么！
HTTP 请求体由：请求行 、请求头、请求体组成。
常用的 HTTP Method
GET：用于请求访问已经被 URI（统一资源标识符）识别的资源，可以通过 URL 传参给服务器。
POST：用于传输信息给服务器，主要功能与 GET 方法类似，但一般推荐使用 POST 方式。
PUT：传输文件，报文主体中包含文件内容，保存到对应 URI 位置。
HEAD：获得报文首部，与 GET 方法类似，只是不返回报文主体，一般用于验证 URI 是否有效。
DELETE：删除文件，与 PUT 方法相反，删除对应 URI 位置的文件。
OPTIONS：查询相应 URI 支持的 HTTP 方法。
Post 请求示例
# Method URL Version 请求行
POST /httpLearn/postRequest HTTP/1.1
# Request Header 请求头
Host: 127.0.0.1:8080
User-Agent: apifox/1.0.0 （https://www.apifox.cn）
Content-Length: 126
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
# Request Message 请求体
----WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name="param"
post
----WebKitFormBoundary7MA4YWxkTrZu0gW
Get 请求示例
Get 请求没有请求体
# Method URL Version 请求行
GET /httpLearn/getRequest?param=123 HTTP/1.1
# Request Header 请求头
Host: 127.0.0.1:8080
User-Agent: apifox/1.0.0 （https://www.apifox.cn）
GET 与 POST 的区别
GET 与 POST 是我们常用的两种 HTTP Method，二者之间的区别主要包括如下五个方面：
从功能上讲，GET 一般用来从服务器上获取资源，POST 一般用来更新服务器上的资源；
从 REST 服务角度上说，GET 是幂等的，即读取同一个资源，总是得到相同的数据，而 POST 不是幂等的，因为每次请求对资源的改变并不是相同的；
从请求参数形式上看，GET 请求的数据会附在 URL 之后，即将请求数据放置在 HTTP 报文的请求头中，以？分割 URL 和传输数据，参数之间以 & 相连；而 POST 请求会把提交的数据则放置在是 HTTP 请求报文的请求体中。
从安全性上看，POST 的安全性要比 GET 的安全性高，因为 GET 请求提交的数据将明文出现在 URL 上，而且 POST 请求参数则被包装到请求体中，相对更安全。
从请求的大小看，GET 请求的长度受限于浏览器或服务器对 URL 长度的限制，允许发送的数据量比较小，而 POST 请求则是没有大小限制的。
Http 响应报文
HTTP 的响应报文是服务器返回的数据，必须先有请求体再有响应报文。
HTTP 响应报文由：状态行、响应头、响应体组成。
常见 Response Code 分类
1xx（临时响应）：信息，服务器收到请求，需要请求者继续执行操作；
2xx（成功）：操作被成功接收并处理；
3xx（重定向）：需要进一步的操作以完成请求；
4xx（客户端错误）：请求包含语法错误或无法完成请求；
5xx（服务器错误）：服务器在处理请求的过程中发生了错误；
响应示例
# Version Response Code 状态行
HTTP/1.1 200 OK
# Response Header 响应头
Content-Type:text/plain;charset=UTF-8
Content-Length:31
Date:Wed, 19 Jan 2022 11:37:00 GMT
Keep-Alive:timeout=60
Connection:keep-alive
# Response Message 响应体
post request is ok,param = post
一次完整 HTTP 请求所经历的步骤
当我们在 web 浏览器的地址栏中输入：www.baidu.com，然后回车，到底发生了什么？
由域名→ IP 地址 寻找 IP 地址的过程依次经过了浏览器缓存、系统缓存、hosts 文件、路由器缓存、 递归搜索根域名服务器（DNS解析）。
建立 TCP/IP 连接（三次握手具体过程）。
由浏览器发送一个 HTTP 请求。
经过路由器的转发，通过服务器的防火墙，该 HTTP 请求到达了服务器。
服务器处理该 HTTP 请求，返回一个 HTML 文件。
浏览器解析该 HTML 文件，并且显示在浏览器端。
服务器关闭 TCP 连接（四次挥手具体过程）。
Https
HTTP 协议运行在 TCP 之上，明文传输，客户端与服务器端都无法验证对方的身份。Https 是通过 SSL（Secure Socket Layer, 安全套接层 ）或 TLS（Transport Layer Security, 安全层传输协议）的组合使用，加密 HTTP 的通信内容。属于通信加密，即在整个通信线路中加密。
HTTPS 采用共享密钥加密（对称）和公开密钥加密（非对称）两者并用的混合加密机制。若密钥能够实现安全交换，那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比，其处理速度要慢。
HTTP 的不足
窃听风险：通信使用明文（不加密），内容可能会被窃听；
冒充风险：不验证通信方的身份，因此有可能遭遇伪装；
篡改风险：无法证明报文的完整性，所以有可能已遭篡改；
两者区别
端口不同：Http 与 Http 使用不同的连接方式，用的端口也不一样，前者是80，后者是443；
资源消耗：和 Http 通信相比，Https 通信会由于加减密处理消耗更多的 CPU 和内存资源；
开销：Https 通信需要证书，而证书一般需要向认证机构购买；
如果对部署证书有兴趣可以看看：Docker通过Nginx，ACME快速部署证书
HTTPS 工作原理
【1】客户端发起 HTTPS 请求
用户在浏览器里输入一个 https 网址，然后连接到 server 的 443 端口。
【2】服务端的配置
采用 HTTPS 协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请，区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。
这套证书其实就是一对公钥和私钥，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
【3】传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。
【4】客户端解析证书
由客户端的 TLS 来完成，首先会验证公钥是否有效，比如颁发机构，过期时间等等。如果发现异常，则会弹出一个警告框，提示证书存在问题。
如果证书没有问题，那么就生成一个随机值，然后用证书对该随机值进行加密，就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。
【5】传送加密信息
用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
【6】服务端解密信息
服务端用私钥解密后，得到了客户端传过来的随机值（私钥），然后把内容通过该值进行对称加密，所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够厉害，私钥够复杂，数据就够安全。
【7】传输加密后的信息
服务段用私钥加密后的信息，可以在客户端被还原。
【8】客户端解密信息
客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容，整个过程第三方即使监听到了数据，也无法解密信息。
HTTPS 的缺点
HTTPS 协议多次握手，导致页面的加载时间延长近 50%；
HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗；
SSL 涉及到的安全算法会消耗 CPU 资源，对服务器资源消耗较大；
|
