【Linux】【网络】应用层协议：HTTP

---

一端发送时构造的数据，在另一端能够正确的进行解析，这种约定，就是 应用层协议 。

程序员自然可以自行定制协议，但有如下非常好的协议设计是可以直接拿来使用的。

一些软件：

• Postman：测试工具
• Fiddler：抓包工具
• Redis：控制维护 Session

---

HTTP 协议

1. URL 统一资源定位符

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 的逆过程。

---

2. HTTP 的协议格式

🎯 HTTP 的 Request 的结构如下：

1. 请求行：

   请求方法 URL 协议版本\r\n
   

请求方法：GET / POST
URL（请求的某种资源，通常以路径的方式存在）
协议版本（指的是客户端版本，eg：http/1.0、http/1.1、http/2.0）

2. 请求报头（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 的字符长度

3. 空行：

   \r\n（区分前半部分后半部分，前半部分就是报头）
   

4. 有效载荷（body）：

   用户提交的参数（这部分可以没有）
   

🎯 HTTP 的 Response 的结构如下：

1. 状态行

   协议版本 状态码 状态码描述\r\n
   

这里的协议版本指的是 服务器版本

状态码 + 状态码描述（eg: 404: Not Foun）

2. 响应报头

相应的常见 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图片格式

3. 空行

4. 有效载荷

   资源：html / css / js、图片、视频、音频....
   

HTTP 怎么识别报头和有效载荷？

• HTTP 读到空行，我们就认为，报头读完了，后面的就是有效载荷。

HTTP 如何进行序列化和反序列化？

• HTTP 的序列化，由于其消息都是按行陈列，把一行一行累加起来变成一个大字符串就是序列化。用户提取消息的时候按照 \r\n 进行分割和结构化，就能完成反序列化。

---

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 方法：

• 可以获取一个静态网页，也可以 通过 URL 的方式提交参数
• 输入到 html 表单中提交的数据，会回显到 URL 上，所以 get 方法不私密
• url 一般会有大小的约束

POST 方法：

• 由 post 请求提交的数据，是 通过正文部分提交参数 的，不会显示出来，故私密性更高
• 但是两个方法都不是安全的
• 正文在理论上可以无限大

---

HTTP 的 状态码

http 的状态码在实际使用上只是一种参考

	类别	原因短语
1XX	Informational (信息性状态码)	接收的请求正在处理
2XX	Success (成功状态码)	请求正常处理完毕
3XX	Redirection (重定向状态码)	需要进行附加操作以完成请求
4XX	Client Error (客户端错误状态码)	服务器无法处理请求
5XX	Server Error (服务器错误状态码)	服务器处理请求出错

3xx 重定向：

• 临时重定向不更改浏览器的任何地址信息
• 永久重定向会更改浏览器的本地书签

location 搭配 3xx 重定向使用，可以告诉客户端接下来要去那里访问

---

HTTP 的常见 Header

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：对众多的资源可以只发一个链接，包含众多请求

Cookie && Session 会话保持功能

关于 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 对话失效，不会对原用户造成影响。