[HTTP协议]应用层协议HTTP从入门到深刻理解并落地部署自己的云服务(1)知识基础

**[HTTP协议]应用层协议HTTP从入门到深刻理解并落地部署自己的云服务(1)知识基础

@水墨不写bug**

(一)概念梳理

1.什么是协议?

在现实生活中, 协议 是一种约定,经过多方的同意最终合作完成一件事情。

在网络的中,计算机要帮助用户完成各种工作,包括用户之间的 远程通信 !

具体来说，协议就是通信双方都认识的结构化的数据类型，比如一个 结构体类型 ，由于双方都事先通知了对方，所以一方可以结构化的向对方发送数据，并且对方也可以把收到的结构化的数据正确的解析出来。

协议一般都有报头和有效载荷，报头是协议规定好的特定位置存储特定结构数据的头部；有效载荷就是将要传输的数据本身。

**举一个形象的例子：**报头和有效载荷的关系其实就像你发的快递的快递单和快递的关系（报头其实就是一个快递单，它记录的这个快递的相关信息，比如发送方是谁，接受方是谁；而有效载荷就是快递的内容）

报头和有效载荷共同构成了一个报文！

2.什么是应用层?

说到应用层就不得不提到网络协议栈的分层。 **网络协议栈的5层（4层）协议分层是对OSI的七层模型的简化版本。**

OSI的七层模型：

OSI的七层分层是非常完善的，它综合考虑了各行各业的，各个厂商在实现的时候按照OSI的七层协议进行。

但是经过实践，人们发现七层协议太过冗余，于是把OSI的七层分层 简化为5(或者4)层 ，形成了如今的 网络协议栈 。

网络协议栈的5（4）层分层：

而应用层就是网络协议栈的最上面的一层，因为它最贴近实际应用，因而被称为 引用层 。

3. 为什么要进行分层？

协议本质上是软件，在设计上的分层是为了更好的进行 模块化设计 ，便于 解耦和 ，设计为层状的结构优势在于：

一层出现问题，可以快速定位，便于快速找到问题所在，同时分层后的软件层之间相互不影响，这也就让软件的维护成本更低。

（二）HTTP协议

2.1 初识HTTP协议

协议看似“高大上”，其实我们每个人都可以定义一个协议，但是由于我们每一个人定义协议时考虑的内容不同，所以有很大的可能定义出来的协议五花八门。

但实际上, 已经有大佬们定义了一些现成的, 又非常好用的应用层协议, 供我们直接参考使用. HTTP(超文本传输协议)就是其中之一。

HTTP （ H yper T ext T ransfer P rotocol， 超文本传输协议 ） 是一个应用广泛所以至关重要的协议。通过这个“超文本”传输协议我们不仅可以传输 文字内容（txt） ，也可传输 图片（gpj） ， 音频（mp3) ，甚至是 视频（mp4） 文件。

此外，HTTP协议是 无连接，无状态 的协议，即每次请求都需要建立新的链接，且服务器不会保存客户端信息。

2.2HTTP协议的URL

随便打开一个网页，我们就可以看到网址一栏特有的内容：

这个网页使用的是 HTTPS 协议，但是HTTPS是对HTTP的完善，分析HTTPS的URL和讲解HTTP的URL并不冲突。

2.2.1域名

如图，这一串内容就是 URL ：

其中前面部分被称为域名，域名本质是IP地址，HTTP的接收方会自动把接收到的域名转化为IP地址，这个过程称为 DNS 。

2.2.2端口号

我们知道， 网络通信本质就是进程间的通信 ，只有通过 IP+端口 才能确定两个特定的进程。

HTTP协议由于广为人知，所以其端口号被规定为 80 ，为了方便起见，一般的浏览器会自动在域名后面加上端口号80。

一般而言，协议名称和端口号是强关联的，比如HTTP的知名端口号为80；这意味着：当浏览器发起请求时，会自动拼接端口号80。

2.2.3 web根目录

与Linux的根目录不同，每一台web服务器都可以设置一个 web根目录 ，用于存储服务器的资源。

web根目录的名称一般设置为 wwwroot ，以这个目录为根，形成了一颗目录树，这就给用户一种错觉： 仿佛在访问服务器的根目录下的资源。

2.2.4 什么是资源

资源指的是网页，图片，视频，音频等超文本内容，这些资源在被获取之前，存储在服务端。（即Linux的某目录的文件）

2.2.5 URL总结

URL前半部分是 IP和端口 。

URL后半部分（域名和端口号后面部分）是服务端主机上的一个资源的 相对路径 。（ 这个路径标识了服务端机器上的某一资源的唯一性 ）。此外，这个路径不是服务器主机的根目录，而是 web根目录 。

2.3 HTTP协议的报文

在网络传输的时候，HTTP协议的报文有自己的约定好的格式。

HTTP报文是客户端与服务器之间通信的核心载体，主要分为 请求报文 和 响应报文 。

2.3.1 HTTP请求报文结构

以上是 HTTP请求报文 结构的基本格式，接下来我将会分别讲解这个格式的各个部分的内容，以及它们在网络传输中的作用。

i. 请求行（Request Line）

• 格式 ： 请求方法 空格 URI 空格 HTTP版本 换行符

• 作用 ：定义请求的基本操作、目标资源和协议版本。

• 示例 ：

  GET /index.html?name=ddsm HTTP/1.1\r\n

  • 请求方法 ： GET （获取资源）。
  • URI ： /index.html?name=ddsm （请求路径和查询参数）。
  • HTTP版本 ： HTTP/1.1 。

常见请求方法 ：

• GET ：获取资源（无请求正文）。
• POST ：提交数据（有请求正文）。
• PUT ：更新服务器上的资源。
• DELETE ：删除服务器上的资源。

其中，在网络传输中，最重要最常用（ 95%以上 ）的方法就是 GET 和 POST ； 其他的方法都基本上不使用。

ii. 请求字段（Request Headers）

• 格式 ： Key:[空格]Value 换行符 ( key-value键值对 )

• 作用 ：传递附加信息（如客户端信息、内容类型、认证等）。

• 示例 ：

  Host: www.ddsm.com\r\n
  User-Agent: Mozilla/5.0 (Windows NT 10.0)\r\n
  Accept: text/html\r\n
  Content-Type: application/json\r\n
  Content-Length: 28\r\n
  \r\n

  • Host ：目标服务器域名（HTTP/1.1必须）。
  • User-Agent ：客户端信息（浏览器或工具标识），OS信息（包括版本）。
  • Accept ：客户端可接收的响应类型。
  • Content-Type ：请求正文的数据类型（如JSON、表单）。
  • Content-Length ：请求正文的字节长度（POST/PUT需指定）。

HTTP请求头中常见的Key-Value字段

以下是HTTP请求报文中常见的 请求头（Request Headers） 字段及其作用与示例：

iii. 空行（Empty Line）

• 格式 ： 换行符

• 作用 ：分隔请求头和请求正文，表示头部结束。

• 示例 ：

  \r\n

iv. 请求正文（Request Body）

• 格式 ：任意数据（如JSON、表单数据、文件）。

• 作用 ：携带需要提交到服务器的数据。

• 示例 （POST请求）：

  {"username": "john", "password": "123"}

  • 适用场景 ： POST 、 PUT 等需要传输数据的请求方法。

2.3.2完整HTTP请求报文示例

示例1：GET请求（无正文）

GET /search?q=http HTTP/1.1\r\n
Host: www.google.com\r\n
User-Agent: Chrome/120.0\r\n
Accept: text/html\r\n
\r\n

示例2：POST请求（含JSON正文）

POST /api/login HTTP/1.1\r\n
Host: example.com\r\n
Content-Type: application/json\r\n
Content-Length: 28\r\n
\r\n
{"username": "ddsm", "password": "190"}

HTTP请求报文各部分的作用总结：

HTTP请求报文注意事项：

1. 换行符 ：HTTP规范要求使用 \r\n （CRLF）作为换行符。
2. Host头 ：HTTP/1.1中必须包含，用于指定服务器域名。
3. Content-Length ：正文长度必须与实际数据一致，否则可能引发错误。

2.3.3 HTTP响应报文结构

HTTP响应报文是服务器对客户端请求的回复，主要包含 状态行、响应头、空行和响应正文 。

i. 状态行（Status Line）

• 格式 ： HTTP版本 空格 状态码 空格 状态码描述 换行符

• 作用 ：告知客户端请求的处理结果（成功、重定向、客户端错误或服务器错误）。

• 示例 ：

  HTTP/1.1 200 OK\r\n

  • HTTP版本 ： HTTP/1.1 （服务器使用的协议版本）。
  • 状态码 ： 200 （表示请求成功）。
  • 状态码描述 ： OK （人类可读的简短描述）。

状态码分类 ：

• 1xx ：信息性状态码（如 101 Switching Protocols ）。
• 2xx ：成功状态码（如 200 OK 、 201 Created ）。
• 3xx ：重定向状态码（如 301 Moved Permanently 、 302 Found ）。
• 4xx ：客户端错误（如 404 Not Found 、 400 Bad Request ）。
• 5xx ：服务器错误（如 500 Internal Server Error 、 503 Service Unavailable ）。

但是一般而言，这些状态码并不会被服务器严格遵守。

ii. 响应头（Response Headers）

• 格式 ： Key: Value 换行符

• 作用 ：提供响应的元数据（如内容类型、服务器信息、缓存策略等）。

• 示例 ：

  Server: nginx/1.18.0\r\n
  Date: Mon, 01 Jan 2024 12:00:00 GMT\r\n
  Content-Type: text/html\r\n
  Content-Length: 127\r\n
  Set-Cookie: session_id=abc123; Path=/\r\n
  \r\n

  • Server ：服务器软件信息（如Nginx、Apache）。
  • Content-Type ：响应正文的数据类型（如 text/html 、 application/json ）。
  • Content-Length ：响应正文的字节长度。
  • Set-Cookie ：向客户端设置Cookie。

iii. 空行（Empty Line）

• 格式 ： 换行符

• 作用 ：分隔响应头和响应正文，表示头部结束。

• 示例 ：

  \r\n

iv. 响应正文（Response Body）

• 格式 ：任意数据（如HTML页面、JSON数据、文件）。

• 作用 ：包含服务器返回的实际内容。

• 示例 （HTML响应）：

  <!DOCTYPE html>
  <html>
    <body>Hello, World!</body>
  </html>

完整HTTP响应报文示例

示例1：成功响应（HTML页面）

HTTP/1.1 200 OK\r\n
Server: Apache/2.4.41\r\n
Date: Mon, 01 Jan 2024 12:00:00 GMT\r\n
Content-Type: text/html\r\n
Content-Length: 127\r\n
\r\n
<!DOCTYPE html>
<html>
  <body>Welcome to Example.com</body>
</html>

示例2：客户端错误（404 Not Found）

HTTP/1.1 404 Not Found\r\n
Server: nginx/1.18.0\r\n
Content-Type: application/json\r\n
Content-Length: 35\r\n
\r\n
{"error": "Resource not found"}

各部分的核心作用总结

关键注意事项

1. 状态码是固定的 ：状态码描述（如 OK ）可能因服务器而异，但状态码（如 200 ）是标准化的。
2. Content-Type必须准确 ：若响应是JSON但声明为 text/html ，客户端可能解析失败。
3. Content-Length一致性 ：需与正文实际字节数一致，否则可能截断数据或读取错误。

通过分析响应报文，可以快速定位问题（如 4xx 表示客户端错误， 5xx 表示服务器错误），并优化前后端交互逻辑。

**未完待续~

转载请注明出处**