本质上只有get和post请求，其他都是post请求
?key1=value1&key2=value2格式。（不理解没关系，后面会单独说）POST请求的请求体（Body）是用来承载客户端要发送给服务器的数据部分，根据不同的应用场景和内容类型（Content-Type），请求体的内容格式会有所不同。对于上传文件的情况，通常采用multipart/form-data、application/x-www-form-urlencoded、application/json。
multipart/form-data：
这是最常见的文件上传方式，尤其在HTML表单中通过<input type="file">元素选择文件时，默认使用此Content-Type。请求体被划分为多个部分（parts），每个部分包含一个或多个字段及其对应的值，文件字段则包含了文件内容本身。每个部分都有自己的Header描述信息，例如：
--boundary_string
Content-Disposition: form-data; name="field1"
value1
--boundary_string
Content-Disposition: form-data; name="file"; filename="example.txt"
Content-Type: text/plain
... file contents here ...
--boundary_string--
在这个例子中，“boundary_string”是一个由服务器指定或者浏览器自动生成的分隔符，用于区分各个部分。文件字段通过Content-Disposition头部中的filename属性来标识上传文件的名字，并且其内容紧跟在头部后面。
application/x-www-form-urlencoded：
尽管这种Content-Type也能上传少量数据，但不适合大文件或二进制文件的上传，因为这种方式下所有的键值对都会被编码为一串连续的字符序列，例如：
field1=value1&file=encoded_file_contents
对于文件内容，通常是不现实的将其编码成URL安全的形式并作为请求体的一部分。
在实际编程过程中，比如使用Python的requests库、JavaScript的Fetch API或XMLHttpRequest等工具，都需要正确设置Content-Type，并将文件内容以适当的方式添加到请求体中。例如，在requests库中，可以这样上传文件：
import requests
url = 'https://example.com/upload'
files = {'file': ('example.txt', open('path_to_your_file.txt', 'rb'))}
response = requests.post(url, files=files)
这里open('path_to_your_file.txt', 'rb')用来打开文件并以二进制读取模式准备上传，requests库会自动处理请求头和请求体的格式化工作。
在使用multipart/form-data格式上传文件时，除了基本的文件内容传输外，还可以携带其他非文件字段数据。例如，在一个表单中可能同时包含文本输入框和其他控件的数据，整个POST请求体将会包括这些额外信息：
--boundary_string
Content-Disposition: form-data; name="title"
File Title
--boundary_string
Content-Disposition: form-data; name="description"
A brief description of the file
--boundary_string
Content-Disposition: form-data; name="file"; filename="example.txt"
Content-Type: text/plain
... file contents here ...
--boundary_string--
这里的“File Title”和“A brief description of the file”是与文件一同提交的额外字段数据。
在服务器端处理POST请求时，需要能够解析这种多部分格式的请求体来提取出各个字段的值以及文件内容。大多数现代Web框架（如Django、Express.js等）都提供了内置或第三方中间件来方便地处理multipart/form-data类型的文件上传。
另外，对于大文件的上传，还需要考虑以下几点：
总之，POST请求体用于文件上传是一个相对复杂的过程，涉及到了HTTP协议、浏览器行为、服务器端编程等多个环节的协同工作。
除了上述四种常见方法外，还有HEAD、OPTIONS、PATCH等：
application/json、multipart/form-data等。HTTP协议支持多种缓存机制来提高性能和减少网络带宽消耗，主要通过以下几种头部字段实现：
Expires：规定缓存过期时间，到了这个时间点后，缓存不再有效。
Cache-Control：更详细的缓存控制指令集，包括max-age、no-cache、public、private等。
max-age：设置缓存的最大生存时间（秒数）。no-cache：要求验证缓存的有效性，即使有缓存也要与服务器确认。public：指示响应可以被任何中间缓存存储。private：指示响应只能被单个用户浏览器缓存，不能被共享缓存（如CDN）存储。Last-Modified / If-Modified-Since：基于时间戳判断资源是否发生过改动。
ETag / If-None-Match：基于资源实体标签判断资源是否发生过变动。
HTTP缓存机制是Web性能优化中非常重要的一环，它允许浏览器、代理服务器以及其他中间件存储HTTP响应的副本，并在后续请求时使用这些副本来避免不必要的网络延迟。以下是一些核心的HTTP缓存机制以及相关的代码示例：
HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: max-age=3600
Expires: Wed, 01 Jan 2025 00:00:00 GMT
在上述响应头中，Cache-Control: max-age=3600 表示资源在接下来的一个小时内有效；而 Expires 设置了一个未来的时间点，过了这个时间点后，浏览器认为缓存过期。
Cache-Control 是一个更强大的缓存控制策略，它可以设置多种指令如：max-age（相对有效期）、no-cache（需要验证缓存的有效性）、public（可以被任何缓存存储）和 private（只能被单个用户浏览器缓存）等。HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=300, public
Last-Modified 头部提供资源最后修改的时间戳，客户端在下一次请求时带上 If-Modified-Since 头部，询问服务器资源是否自上次访问以来有变化。// 首次请求响应：
HTTP/1.1 200 OK
Last-Modified: Sat, 23 Oct 2021 08:23:45 GMT
// 客户端再次请求时：
GET /resource HTTP/1.1
If-Modified-Since: Sat, 23 Oct 2021 08:23:45 GMT
如果资源未改变，服务器会返回304 Not Modified状态码，并且没有响应体，客户端则从缓存中获取内容。
Last-Modified 类似，客户端会在下次请求时携带 If-None-Match 头部。// 首次请求响应：
HTTP/1.1 200 OK
ETag: "ae3f7e9a"
// 客户端再次请求时：
GET /resource HTTP/1.1
If-None-Match: "ae3f7e9a"
如果ETag匹配，服务器同样会返回304状态码。
在实际编程中，开发者通常不需要直接编写处理这些头部信息的代码，因为现代Web框架或库（如Express.js、axios等）已经内置了对HTTP缓存机制的支持。不过，开发者可以根据业务需求配置响应头，以实现定制化的缓存策略。例如，在Node.js的Express框架中：
const express = require('express');
const app = express();
app.get('/resource', (req, res) => {
// 假设这里的getResource函数从数据库获取数据
const resource = getResource();
// 设置缓存策略
res.setHeader('Cache-Control', 'public, max-age=3600');
res.setHeader('ETag', generateETag(resource)); // 假设有generateETag函数用于生成ETag
res.json(resource);
});
HTTPS（Hypertext Transfer Protocol Secure）是在HTTP协议的基础上加入了SSL/TLS协议，为数据传输提供了安全保证。
通过HTTPS，客户端和服务器之间建立起了一条安全通道，既保证了数据的机密性，又确保了数据的完整性，同时还能够防止中间人攻击。