HTTP¶
HTTP/1.0 是无状态协议。 HTTP/1.1 和 HTTP/2 是有状态协议。 HTTP/1.x/2.0 都是基于 TCP 的。 HTTP/3 是基于 QUIC 协议的，而 QUIC 协议是基于 UDP 协议的。UDP 是无连接的，无状态的协议，因此 HTTP/3 也是无状态协议。 https://zhuanlan.zhihu.com/p/45173862
1 HTTP（HyperText-Transfer-Protocol）¶
1.1 HTTP 协议格式¶
HTTP 的请求和响应的消息协议是一样的，分为三个部分，起始行、消息头 和 消息体。这三个部分以 CRLF 作为分隔符。最后一个消息头有两个 CRLF，用来表示消息头部的结束。
1. HTTP 请求的起始行称为请求行，形如 GET /index.html HTTP/1.1
2. HTTP 响应的起始行称为状态行，形如 200 ok
3. 消息头部有很多键值对组成，多个键值对之间使用 CRLF 作为分隔符，也可以完全没有键值对。形如 Content-Encoding: gzip
4. 消息体是一个字符串，字符串的长度是由消息头部的 Content-Length 键指定的。
客户端报文示例:
GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
服务端响应报文示例:
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
GET、HEAD请求没有消息体，POST、PUT请求有消息体
1.2 http 状态码¶
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 200 | OK | 请求成功。一般用于 GET 与 POST 请求 |
| 301 | Moved Permanently | 永久性重定向。请求的资源已被永久的移动到新 URI，返回信息会包括新的 URI，浏览器会自动定向到新 URI。今后任何新的请求都应使用新的 URI 代替 |
| 302 | Found | 临时性重定向。与 301 类似。但资源只是临时被移动。客户端应继续使用原有 URI |
| 304 | Not Modified | 极少人知道这个错误，因为大部分后端开发者的前端 Javascript 开发经验都严重不足。当你用 Chrome 打开一个经常访问的网站，看看 Network 传输的静态资源就可以看到很多 304 状态码。它表示该资源被浏览器缓存了不需要重新请求服务器。 |
| 400 | Bad Request | 用于参数验证，少了一个参数或者参数类型错误之类的。 |
| 401 | Unauthorized | 权限不足，这个很好理解，就是资源存在但是不让你访问。 |
| 403 | Forbidden | 资源禁止访问，如果你的 IP 列为黑名单了，就会发生这种错误。 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置 " 您所请求的资源无法找到 " 的个性页面。也可以在服务器拒绝请求且不想说明理由时使用 |
| 500 | Internal Server Errorv | 服务器内部错误，无法完成请求，也可能是 web 应用存在 bug 或某些临时故障 |
| 502 | Bad Gateway | 后端服务挂掉或者压力过大的时候， Nginx 接到的请求无法及时传递给后端的服务进行处理，这个时候就会出现 502 错误。这个也非常常见，知乎豆瓣网站经常开小差的时候发生的错误就是这个。 |
参考 https://juejin.cn/post/6844904202863394830
1.3 HTTP 请求方法¶
1.3.1 GET¶
- GET 是最常用的方法。通常用于请求服务器发送某个资源
1.3.2 HEAD¶
类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头
1.3.3 POST¶
POST 方法起初是用来向服务器输入数据的。实际上，通常会用它来支持 HTML 的表单。表单中填好的数据通常会被送给服务器，然后由服务器将其发送到它要去的地方 (比如，送到一个服务器网关程序中，然后由这个程序对其进行处理)。
1.3.4 PUT¶
从客户端向服务器传送的数据取代指定的文档的内容。与 GET 从服务器读取文档相反，PUT 方法会向服务器写入文档。有些发布系统允许用户创建 Web 页面，并用 PUT 直接将其安装到 Web 服务器上去。
2 HTTP1.1¶
https://zhuanlan.zhihu.com/p/51185862
3 HTTP2.0¶
HTTP/2.0 是 HTTP 协议的第二个版本，它的主要目标是改进传输性能，实现低延迟和高吞吐量。 HTTP/2.0 的特点有： - HTTP/2.0 使用二进制协议，而不是文本协议。 - HTTP/2.0 支持多路复用，可以同时发送多个请求和响应。 - HTTP/2.0 使用头部压缩技术，可以减少网络带宽的使用。 - HTTP/2.0 支持服务器推送，可以在客户端请求之前向客户端推送资源。
4 HTTP3.0¶
- HTTP/3.0 使用 QUIC 协议作为传输层协议，而不是 TCP。
- HTTP/3.0 使用了基于 UDP 的 QUIC 协议，可以减少网络延迟和提高网络吞吐量。
- HTTP/3.0 支持多路复用，可以同时发送多个请求和响应。
- HTTP/3.0 支持 0-RTT 连接，可以在客户端和服务器之间建立更快的连接。
5 HTTPS¶
HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer），可以理解为 HTTP+SSL/TLS，即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL，用于安全的 HTTP 数据传输。
6 HTTP 各版本对比¶
6.1 HTTP1.1 和 HTTP1.0 对比¶
- 连接方式：HTTP1.0 默认使用短连接，每次请求都需要建立新的 TCP 连接，连接不能复用；而 HTTP1.1 支持持久连接 和请求的流水线处理，在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少建立和关闭 TCP 连接的消耗和延迟，提高效率。
- 缓存处理：HTTP1.0 主要使用 header 里的 If-Modified-Since、Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag、If-Unmodified-Since、If-Match、If-None-Match 等更多可供选择的缓存头来控制缓存策略。
- 错误处理：HTTP1.0 只有响应码，没有状态码；而 HTTP1.1 则引入了状态码，使得错误处理更加规范化。
- Host 头处理：HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此请求消息中的 URL 并没有传递主机名（hostname），但随着虚拟主机技术的发展，使得一台物理服务器可以承载多个主机名和多个网站，这时就需要在 HTTP 请求头中提供 Host 字段来明确指出请求的对象是哪个主机名。
- 其他特点：HTTP1.1 还支持分块传输编码、支持断点续传、支持管道化处理等。
6.2 HTTP2.0 对比 HTTP1.1¶
- 二进制分帧：HTTP2.0 采用二进制格式传输数据，而非 HTTP1.x 的文本格式，这样可以更加高效地解析和传输数据。
- 多路复用：HTTP2.0 支持多路复用，即在一个 TCP 连接上可以同时传输多个请求和响应，避免了 HTTP1.x 中的队头阻塞问题，提高了并发性能。
- 首部压缩：HTTP2.0 使用 HPACK 算法对首部进行压缩，减少了首部大小，降低了网络延迟。
- 服务器推送：HTTP2.0 支持服务器推送，即服务器可以在客户端请求之前将客户端需要的资源推送给客户端，提高了性能。
- 其他特点：HTTP2.0 还支持流量控制、优先级设置、服务器端推送等。
6.3 HTTP3.0 对比 TTP2.0¶
- 传输协议：HTTP3.0 使用 QUIC 协议作为传输协议，而 HTTP2.0 使用 TCP 协议。
- 二进制分帧：HTTP3.0 采用二进制格式传输数据，与 HTTP2.0 相同。
- 多路复用：HTTP3.0 支持多路复用，与 HTTP2.0 相同。
- 首部压缩：HTTP3.0 使用 QPACK 算法对首部进行压缩，与 HTTP2.0 相同。
- 服务器推送：HTTP3.0 支持服务器推送，与 HTTP2.0 相同。
- 其他特点：HTTP3.0 还支持零 RTT 连接、连接迁移、拥塞控制等。
7 Session、Cookie、Token¶
Session、Cookie、Token 都是用于身份验证的技术，但它们之间有一些区别。 - Cookie 是存储在客户端的文本文件，其中包含有关用户的信息。当用户访问网站时，服务器会读取 cookie 并使用其中的信息来识别用户。由于 cookie 存储在客户端，因此它们可以在多个页面之间共享，并且可以在浏览器关闭后保留。 - Session 是存储在服务器上的数据结构，用于存储有关用户的信息。当用户访问网站时，服务器会创建一个新的 session，并将其与该用户相关联。服务器会将 session ID 发送到客户端，客户端将其存储在 cookie 中。在每个请求中，客户端都会将 session ID 发送回服务器以进行身份验证。 - Token 是一种无状态的身份验证机制，它不需要存储在服务器上。它通常是一个字符串，由服务器生成并发送给客户端。客户端将 token 存储在本地，并在每个请求中将其发送回服务器以进行身份验证。
这些技术都有自己的优缺点，具体使用哪种技术取决于应用程序的需求和安全性要求。如果需要在 多个页面之间共享数据，则应使用 cookie。如果 需要更高的安全性，则应使用 session。
8 X-Forwarded-For¶
X-Forwarded-For 是一个 HTTP 扩展头部，最开始是由 Squid 这个缓存代理软件引入，用来表示 HTTP 请求端真实 IP。如今它已经成为事实上的标准，被各大 HTTP 代理、负载均衡等转发服务广泛使用，并被写入 RFC 7239（Forwarded HTTP Extension）标准之中。