1.HTTP协议与各种协议之间的关系

HTTP协议与各种协议之间的关系

2.HTTP协议

2.1 基础概念

（1）请求报文

http请求报文

（2）响应报文

http响应报文

2.2 HTTP方法

（1）GET - 获取资源

当前网络请求中，大部分是使用 GET 方法。

（2）HEAD - 获取报文首部

类似GET，但不返回报文实体主体。

作用：确认 URL 的有效性、资源更新的日期时间等。

http响应报文2

（3）POST - 传输实体主体

POST 主要用来传输数据，而 GET 主要用来获取资源。

问题：GET和POST的比较

①作用

GET 用于获取资源，而 POST 用于传输实体主体。

②参数

GET 和 POST 的请求都能使用额外的参数，但是 GET 的参数是以查询字符串出现在 URL 中，而 POST 的参数存储在实体主体中。

GET /test/demo_form.asp?name1=value1&name2=value2 HTTP/1.1

POST /test/demo_form.asp HTTP/1.1

Host: w3schools.com

name1=value1&name2=value2

注意：不能因为 POST 参数存储在实体主体中就认为它的安全性更高，因为照样可以通过一些抓包工具（Fiddler）查看。

因为 URL 只支持 ASCII 码，因此 GET 的参数中如果存在中文等字符就需要先进行编码。例如 中文 会转换为 %E4%B8%AD%E6%96%87，而空格会转换为 %20。

③安全

说明：安全的 HTTP 方法不会改变服务器状态。

GET 方法是安全的，而 POST 却不是，因为 POST 的目的是传送实体主体内容，这个内容可能是用户上传的表单数据，上传成功之后，服务器可能把这个数据存储到数据库中，因此状态也就发生了改变。

安全的方法：GET、HEAD、OPTIONS。

不安全的方法：POST、PUT、DELETE

④幂等性

幂等的含义：同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。

在正确实现的条件下，GET，HEAD，PUT 和 DELETE 等方法都是幂等的，而 POST 方法不是。

GET /pageX HTTP/1.1 是幂等的，连续调用多次，客户端接收到的结果都是一样的：

GET /pageX HTTP/1.1

GET /pageX HTTP/1.1

GET /pageX HTTP/1.1

GET /pageX HTTP/1.1

POST /add_row HTTP/1.1 不是幂等的，如果调用多次，就会增加多行记录：

POST /add_row HTTP/1.1 -> Adds a 1nd row

POST /add_row HTTP/1.1  -> Adds a 2nd row

POST /add_row HTTP/1.1  -> Adds a 3rd row

DELETE /idX/delete HTTP/1.1 是幂等的，即使不同的请求接收到的状态码不一样：

DELETE /idX/delete HTTP/1.1 -> Returns 200 if idX exists

DELETE /idX/delete HTTP/1.1  -> Returns 404 as it just got deleted

DELETE /idX/delete HTTP/1.1  -> Returns 404

⑤可缓存

缓存的条件：

A.请求报文的 HTTP 方法本身是可缓存的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可缓存，POST 在多数情况下不可缓存的。

B.响应报文的状态码是可缓存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。

C.响应报文的 Cache-Control 首部字段没有指定不进行缓存。

⑥XMLHTTPRequest

XMLHttpRequest 是一个 API，它为客户端提供了在客户端和服务器之间传输数据的功能。它提供了一个通过 URL 来获取数据的简单方式，并且不会使整个页面刷新。这使得网页只更新一部分页面而不会打扰到用户。XMLHttpRequest 在 AJAX 中被大量使用。

A. 在使用 XMLHttpRequest 的 POST 方法时，浏览器会先发送 Header 再发送 Data。但并不是所有浏览器会这么做，例如火狐就不会。

B. GET 方法 Header 和 Data 会一起发送。

（4）PUT - 上传文件

PUT /new.html HTTP/1.1

Host: example.com

Content-type: text/html

Content-length: 16

<p>New File</p>

（5）PATCH - 对资源进行部分修改

PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。

PATCH /file.txt HTTP/1.1

Host: www.example.com

Content-Type: application/example

If-Match: "e0023aa4e"

Content-Length: 100

[description of changes]

（6）DELETE - 删除文件

与 PUT 功能相反，并且同样不带验证机制。

DELETE /file.html HTTP/1.1

（7）OPTIONS - 查询支持的方法

查询指定的 URL 能够支持的方法。返回的内容是Allow: GET, POST, HEAD, OPTIONS等。

（8）CONNECT - 要求在与代理服务器通信时建立隧道

使用 SSL（安全套接层）和 TLS（传输层安全）协议时，加密通信内容后，采用网络隧道传输数据。

CONNECT www.example.com:443 HTTP/1.1

connect建立隧道

（9）TRACE - 追踪路径

服务器会将通信路径返回给客户端。发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。

注意：通常不会使用 TRACE，并且它容易受到 XST 攻击（跨站追踪）。

1.3 HTTP状态码

服务器返回的 响应报文 中第一行为状态行：状态码 + 原因短语。

http状态码表

（1）1XX

100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。

（2）2XX 成功

200 OK

204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。

206 Partial Content ：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。

（3）3XX 重定向

301 Moved Permanently ：永久性重定向

302 Found ：临时性重定向

303 See Other ：类似 302 ，但是 303 明确要求客户端应该采用 GET 方法获取资源。

注意：虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法，但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。

304 Not Modified ：如果请求报文首部包含一些条件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码。

307 Temporary Redirect ：临时重定向，类似302，但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。

（4）4XX 客户端错误

400 Bad Request ：请求报文中存在语法错误。

401 Unauthorized ：表示发送的请求需要包含认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。

403 Forbidden ：请求被拒绝。

404 Not Found

（5）5XX 服务端错误

500 Internal Server Error ：服务器正在执行请求时发生错误。

503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

2.4 HTTP首部

2.5 具体应用

2.6 web页面请求过程

3.HTTPS协议

3.1 加密

（1）对称密钥加密

对称密钥加密，加密和解密使用同一密钥。

优点：运算速度快；

缺点：无法安全地将密钥传输给通信方。

对称密钥加密

（2）非对称密钥加密

非对称密钥加密，又称公开密钥加密，加密和解密使用不同的密钥，即采用公钥加密、私钥解密。

非对称密钥加密

优点：可以更安全地将公开密钥传输给通信发送方；

缺点：运算速度慢。

（3）HTTPS 采用的加密方式

HTTPS采用混合加密的方式，结合非对称加密安全的优势、对称加密效率高的优势。虽然对称密钥加密方式的传输效率更高，但无法安全地将密钥 Secret Key 传给客户端，而非对称密钥加密方式可以保证传输的安全性，因此可以利用非对称密钥加密方式将 Secret Key 传输给客户端。

HTTPS 认证流程如下：

① 客户端向服务端发起 HTTPS 请求，服务端向客户端发送非对称加密的公钥 public key；

② 客户端接收到 public key 后，利用 public key 向 对称加密的密钥 session key 进行加密，并发送该 session key 到服务端；

③ 服务端接收到 session key 后，利用 非对称加密的公钥 private key 对 session key 进行解密。服务端采用该 session key 对数据data进行加密，服务端发送data到客户端；

④  客户端利用 session key 对 data 进行解密。

https认证流程

3.2 CA 认证

使用 证书 来对通信方进行认证。数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。

服务端签名：服务端的工作人员向 CA 机构申请公钥。CA 机构判明申请者的身份后，对申请的公钥（非对称加密的公钥 public key）进行数字签名，并将该公钥放入CA证书后绑定在一起。

客户端认证：服务器会把 CA 证书发送给客户端。客户端本地验证该 CA 证书。如果验证通过，可以获取 CA 证书里面的公钥（非对称加密的公钥 public key）。

CA证书签名和认证

问题1：客户端本地如何验证证书呢？

证书本身就已经告诉客户端怎么验证证书的真伪，也就是证书上写着如何根据证书上的方法自己生成一个证书编号，如果生成的证书编号与证书上的证书编号相同，那么证明这个证书是正确的。同时，为避免证书编号本身又被调包，所以使用第三方机构的私钥进行加密。

问题2：使用 CA 证书后，HTTPS 认证流程是怎么样的？

如上（3）HTTPS 认证流程基本一致，区别是客户端向 HTTPS 请求，服务端向客户端发送的是 CA 证书，而不是直接发送非对称加密的公钥 public key。

① 客户端向服务端发起 HTTPS 请求，服务端向客户端发送CA 证书（内部包含非对称加密的公钥 public key）；

② 客户端接收到 CA 证书后，本地进行 CA 证书验证。如果通过验证，可以获取到里面的非对称加密的公钥 public key，利用 public key 向 对称加密的密钥 session key 进行加密，并发送该 session key 到服务端；

③ 服务端接收到 session key 后，利用非对称加密的公钥 private key 对 session key 进行解密。服务端采用该 session key 对数据data进行加密，服务端发送data到客户端；

④  客户端利用 session key 对 data 进行解密。

参考：https://www.sohu.com/a/320031789_371153

3.3 完整性保护

SSL 提供报文摘要来进行完整性保护。

HTTPS 的报文摘要是安全，因为有加密和认证。

说明：HTTP 也提供了 MD5 报文摘要功能，但不是安全的。例如报文内容被篡改之后，同时重新计算 MD5 的值，通信接收方是无法意识到发生了篡改。

3.4 缺点

①效率低，因为需要进行加密解密等过程；

②费用高，因为需要支付证书授权的高额费用；