方法（method）
| 方法 | 说明 | 支持的HTTP协议版本 |
| GET | 获取资源 | 1.0 1.1 |
| POST | 传输实体主体 | 1.0 1.1 |
| PUT | 传输文件 | 1.0 1.1 |
| HEAD | 获得报文首部 | 1.0 1.1 |
| DELETE | 删除文件 | 1.0 1.1 |
| OPTION | 询问支持的方法 | 1.0 |
| TRACE | 追踪路径 | 1.0 |
| CONNECT | 要求用隧道协议连接代理 | 1.0 |
| LINK | 建立和资源之间的联系 | 1.0 |
| UNLINE | 断开连接关系 | 1.0 |
上述HTTP请求的初心是为了，表示不同的“语义”
但是在使用的过程中，不一定严格按照上述的标准，比较随意
GET 是最常用的 HTTP 方法 . 常用于获取服务器上的某个资源在浏览器中直接输入 URL, 此时浏览器就会发送出一个 GET 请求另外 , HTML 中的 link, img, script 等标签 , 也会触发 GET 请求GET 请求的特点首行的第一部分为 GETURL 的 query string 可以为空 , 也可以不为空header 部分有若干个键值对结构body 部分为空
POST 方法也是一种常见的方法. 多用于提交用户输入的数据给服务器(例如登陆页面)
通过 HTML 中的 form 标签可以构造 POST 请求 , 或者使用 JavaScript 的 ajax 也可以构造 POST 请求POST 请求的特点首行的第一部分为 POSTURL 的 query string 一般为空 ( 也可以不为空 )header 部分有若干个键值对结构body 部分一般不为空 . body 内的数据格式通过 header 中的 Content - Type 指定 . body 的长度由header 中的 Content - Length 指定
PUT 与 POST 相似，只是具有幂等特性，一般用于更新
DELETE 删除服务器指定资源OPTIONS 返回服务器所支持的请求方法HEAD 类似于 GET ，只不过响应体不返回，只返回响应头TRACE 回显服务器端收到的请求，测试的时候会用到这个CONNECT 预留，暂无使用
在方法中，GET 和 POST 占据了大多数，所以以下就针对这两种方法进行介绍：
GET请求，通常会把要传递给浏览器的数据，加到URL的query string中
POST请求，通常把要传给服务器的数据，加到body中 ——以上都是习惯用法
浏览器显示的网页，是从服务器这边下载过来的，HTML内容可能比较多，通过网络加载消耗的时间比较多
浏览器一般会自带缓存，把之前加载过的数据，保存到本地网盘上
如要传输图片等数据，一般要进行 base64 转码——>针对二进制数据重新编码（转义），确保编码之后的数据就是纯文本数据
GET 和 POST 的错误描述——>
1）GET请求能传递的数据量有上限，POST请求传递的数据量没有上限
该说法是一个“历史遗留”问题
早期版本的浏览器（硬件资源匮乏），针对GET请求的长度做出了限制
实际上，RFC标准文档中并没有明确URL的最大长度
目前浏览器和服务器的实现过程中，URL可以非常长（以至于可以使用URL传递图片等）
2）GET请求传递数据不安全，POST请求传递数据安全
依据是：使用GET请求来实现登录，会把用户名和密码放到URL中，进而显示在浏览器的搜索地址里。相比之下，POST则是把数据放在body里面
——>所谓的安全不是，传递的数据不容易被获取，而是在获取后不容易被破解（加密）
3）GET只能给服务器传输文本数据，POST可以给服务器传输文本数据和二进制数据
1. GET也可以使用body（body是可以直接放二进制数据的）
2. GET也可以把二进制的数据进行 base64 转码，放到URL的query string中
以下是关于GET和POST较为模棱两可的论述：
1）GET请求是幂等的，POST请求不是幂等的
任何情境下，输入相同的内容，输出的是稳定的
GET和POST是否是幂等的取决于代码的实现（RFC标准文档建议GET请求是幂等的）
2）GET请求可以被浏览器缓存，POST不可以缓存
幂等性的延续，如果请求是幂等的，就可以缓存
3）GET请求可以被浏览器收藏夹收藏，POST不能（收藏时可能丢失body）
请求报头（header）
Header中的键值对很多，以下是比较重要的几个：
Host
Content-Length Content-Type
Content-Length body中的数据长度
Content-Type body中的数据格式
请求中有body，才会有这两个属性
通常情况下，GET请求没有body，POST请求有body
body中的格式，可以选择的方式有很多：
请求：
1. json
2. form表单的格式 相当于是把GET的query string给挪到了body中
3. form-data的格式 上传文件时，会涉及到（不一定是form-data，也可能是form表单）
响应：
1. html 构成网页的骨架
2. css 构成网页的样式
3. json
4. js 构成网页的行为
5. 图片
...
TCP涉及到“粘包”问题，HTTP在传输层就是基于TCP
使用同一个TCP连接，传输多个数据包。此时就会使多个HTTP数据包，在TCP接收缓冲区挨在一起。接收方解析时，就需要清除HTTP数据包之间的边界
GET请求没有body，直接使用 空行（分隔符）
POST请求有body，结合 空行 和 Content-Length
后续给服务器提交请求的时候，不同的Content-Type,服务器处理数据的逻辑是不同的
服务器返回数据给浏览器，也需要设置合适的Content-Type，浏览器也会根据不同的Content-Type做出不同的处理
User-Agent（UA）
表示浏览器/操作系统的属性
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko)Chrome/91.0.4472.77 Safari/537.36中 Windows NT 10.0 ; Win64 ; x64 表示操作系统信息AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.77 Safari/537.36 表示浏览器信息
Referer
Cookie
浏览器的数据来自服务器，浏览器的后续操作也是要提交给服务器的
服务器这边管理了一个网站的各种核心数据
程序运行过程中，也会需要一些数据，需要在浏览器储存，在后续请求的过程中可能会发给服务器（这些临时性的数据，存储在浏览器比较好）但是禁止网页直接访问电脑的文件系统——>
于是为保证安全，又能进行保存数据，引入了Cookie（按照硬盘文件的方式进行保存，但是浏览器把操作文件封装了，网页只能往Cookie里储存键值对）——>Cookie 中存储了一个字符串
1）Cookie往往是从服务器返回的数据（可以是页面自己生成的）
2）Cookie存储到浏览器所在的主机的硬盘上，按照域名为维度来存储（每个域名下可以存自己的Cookie，彼此之间互不影响）
3）Cookie是按照键值对的形式组织的（此处的键值对是自定义的）
键值对之间，使用 ; 分割 键和值之间，使用 = 分割
后续再请求这个服务器的时候，会把Cookie中的内容自动带入到请求中，发给服务器。服务器通过Cookie的内容做一些逻辑上的处理
状态码
| 1XX | Informational（信息性状态码） | 接受的请求正在处理 |
| 2XX | Success （成功状态码） | 请求正常处理完毕 |
| 3XX | Redirection （重定向状态码） | 需要进行附加操作以完成请求 |
| 4XX | Client Error （客户端错误 状态码） | 服务器无法处理请求 |
| 5XX | Server Error （服务器错误 状态码） | 服务器处理请求出错 |
3XX 请求中访问的是A的地址，响应返回了一个重定向的报文，告诉你要访问B地址
很多时候网页的跳转就是使用重定向来实现
重定向的响应报文中，会带有Location字段，描述出当前要跳转到哪个字段
404 Not Found 请求中访问的资源，在服务器上不存在
403 Forbidden 访问的资源没有权限
