一端发送时构造的数据，在另一端能够正确的进行解析，这种约定，就是 应用层协议 。
程序员自然可以自行定制协议，但有如下非常好的协议设计是可以直接拿来使用的。
一些软件：
URL (Uniform Resource Locator) 是我们常说的网址、超链接，通过他可以确定网站上唯一的某一份资源，下面分析一个网址结构：
https://blog.csdn.net/m0_67470729?spm=1000.2115.3001.5343
————————-------------————————————-———————————————————————
1 2 3 4 5
1. 协议（对应的是 端口号，成熟的协议都与其端口号一一对应，比如 http 是 80，https 是 443）
2. 服务器地址（IP）
3. 访问的资源（为首的 / 叫做 ”web 根目录“）
4. 问号分隔符（后面跟的都是参数，参数是 key = value 形式的，多个参数由 & 连接）
5. 查询的内容（会交给访问资源进行处理）
urlencode ：像 / ? : 等这样的字符，已经被url当做特殊意义理解了。
比如，某个参数中需要带有这些特殊字符，就必须先对特殊字符进行转义，转义的规则如下：
将需要转码的字符转为16进制，然后从右到左，取4位(不足4位直接处理)，每2位做一位，前面加上%，编码成%XY格式
urldecode 是 urlencode 的逆过程。
🎯 HTTP 的 Request 的结构如下：
请求行：
请求方法 URL 协议版本\r\n
请求方法：GET / POST
URL（请求的某种资源，通常以路径的方式存在）
协议版本（指的是客户端版本，eg：http/1.0、http/1.1、http/2.0）
请求报头（Header）：
key: Value\r\n
key: Value\r\n
key: Value\r\n
...
请求的 key 常见信息如下
Host: 告知服务器，所请求的是哪个主机 IP 和 端口号
Connection: 长短链接
Cache-Control: 缓存机制
Upgrade-Insecure-Requests: http 的升级或更新
User-Agent: 这次请求的客户端的操作系统和浏览器版本信息
referer: 当前页面是从哪个页面跳转过来的
Accept-Encoding: 客户端自己所能接受的编码或压缩类型
Accept-Language: 客户端自己所能接受的编码符号
Content-Length: body 的字符长度
空行：
\r\n（区分前半部分后半部分，前半部分就是报头）
有效载荷（body）：
用户提交的参数（这部分可以没有）
🎯 HTTP 的 Response 的结构如下：
状态行
协议版本 状态码 状态码描述\r\n
这里的协议版本指的是 服务器版本
状态码 + 状态码描述（eg: 404: Not Foun）
相应的常见 key：
Content-Length: body 的字符长度
Content-Type: body 的种类
location: 搭配 3xx 状态码使用，告诉客户端接下来去哪里访问
Cookie: 用于在客户存储少量信息，通常会用于实现会话（session）的功能
test/hmtl：HTML格式text/plain ：纯文本格式text/xml ： XML格式image/gif ：gif图片格式image/jpeg ：jpg图片格式image/png：png图片格式空行
有效载荷
资源：html / css / js、图片、视频、音频....
HTTP 怎么识别报头和有效载荷？
HTTP 如何进行序列化和反序列化？
| 方法 | 说明 | 支持的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 |
| OPTIONS | 询问支持的方法 | 1.1 |
| TRACE | 追踪路径 | 1.1 |
| CONNECT | 要求用隧道协议连接代理 | 1.1 |
| LINK | 建立和资源之间的联系 | 1.0 |
| UNLINE | 断开连接关系 | 1.0 |
GET 方法：
POST 方法：
http 的状态码在实际使用上只是一种参考
| 类别 | 原因短语 | |
|---|---|---|
| 1XX | Informational (信息性状态码) | 接收的请求正在处理 |
| 2XX | Success (成功状态码) | 请求正常处理完毕 |
| 3XX | Redirection (重定向状态码) | 需要进行附加操作以完成请求 |
| 4XX | Client Error (客户端错误状态码) | 服务器无法处理请求 |
| 5XX | Server Error (服务器错误状态码) | 服务器处理请求出错 |
3xx 重定向：
location 搭配 3xx 重定向使用，可以告诉客户端接下来要去那里访问
Host: 告知服务器，所请求的是哪个主机 IP 和 端口号
Connection: 长短链接
Cache-Control: 缓存机制
Upgrade-Insecure-Requests: http 的升级或更新
User-Agent: 这次请求的客户端的操作系统和浏览器版本信息
referer: 当前页面是从哪个页面跳转过来的
Accept-Encoding: 客户端自己所能接受的编码或压缩类型
Accept-Language: 客户端自己所能接受的编码符号
Content-Length: body 的字符长度
Content-Length: body 的字符长度
Content-Type: body 的种类
location: 搭配 3xx 状态码使用，告诉客户端接下来去哪里访问
Cookie: 用于在客户存储少量信息，通常会用于实现会话（session）的功能
长链接 keep-alive：对众多的资源可以只发一个链接，包含众多请求
关于 http 的会话保持功能，因为 http 本身是无状态的，主要功能是实现超文本传输，而 Cookie 是 http 提供的功能，配合 session 会话可以实现将 用户是否在线的状态持续的记录下来！
Cookie：
在最初的功能设计中只有 cookie，当客户端在要求下输入账号密码后服务器予以认证通过，同时通过一个 Set-Cookie 功能将用户上述的私人信息通过 response 响应，将 cookie 信息在客户端本地进行文件级保存。后续的 http request 会将保存的 cookie 信息携带上，服务器自动对其进行认证，不需要用户手动操作。这样的设计，当电脑遭到黑客攻击，保存的 cookie 信息也全盘被读走，即使账号被检测出异常，服务器也无法对其进行处理（即使处理也会对原用户造成影响），于是发展出了新的功能设计。
Cookie && Session：
这样的处理模式，在服务器对客户端的账户密码认证通过后，不是直接吧信息 Set-Cookie，而是形成一个 session 对象，用当前用户的基本信息填充，每个session 会配上一个唯一的 session id，在 Set-Cookie 放置给客户端保存的是这个 session id。后续客户端再进行 request 时，服务器会识别 session id 予以其认证。当电脑遭到黑客攻击时，拿到的只是 session id，账号如果被服务器检测出异常，只需要使其 session 对话失效，不会对原用户造成影响。