当前位置：首页 > news >正文

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

news 来源：原创 2025/8/23 6:19:51

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

在这里插入图片描述

文章目录

(一)概念梳理
- 1.什么是协议?
- 2.什么是应用层?
- 3. 为什么要进行分层？
（二）HTTP协议
- 2.1 初识HTTP协议
- 2.2HTTP协议的URL
- - 2.2.1域名
  - 2.2.2端口号
  - 2.2.3 web根目录
  - 2.2.4 什么是资源
  - 2.2.5 URL总结
- 2.3 HTTP协议的报文
- - 2.3.1 HTTP请求报文结构
  - - i. 请求行（Request Line）
    - ii. 请求字段（Request Headers）
    - - HTTP请求头中常见的Key-Value字段
    - iii. 空行（Empty Line）
    - iv. 请求正文（Request Body）
  - 2.3.2完整HTTP请求报文示例
  - - 示例1：GET请求（无正文）
    - 示例2：POST请求（含JSON正文）
  - HTTP请求报文各部分的作用总结：
  - HTTP请求报文注意事项：
  - 2.3.3 HTTP响应报文结构
  - - i. 状态行（Status Line）
    - ii. 响应头（Response Headers）
    - iii. 空行（Empty Line）
    - iv. 响应正文（Response Body）
  - 完整HTTP响应报文示例
  - - 示例1：成功响应（HTML页面）
    - 示例2：客户端错误（404 Not Found）
  - 各部分的核心作用总结
  - 关键注意事项

(一)概念梳理

1.什么是协议?

在现实生活中,协议是一种约定,经过多方的同意最终合作完成一件事情。
在网络的中,计算机要帮助用户完成各种工作,包括用户之间的远程通信!
具体来说，协议就是通信双方都认识的结构化的数据类型，比如一个结构体类型，由于双方都事先通知了对方，所以一方可以结构化的向对方发送数据，并且对方也可以把收到的结构化的数据正确的解析出来。
协议一般都有报头和有效载荷，报头是协议规定好的特定位置存储特定结构数据的头部；有效载荷就是将要传输的数据本身。
**举一个形象的例子：**报头和有效载荷的关系其实就像你发的快递的快递单和快递的关系（报头其实就是一个快递单，它记录的这个快递的相关信息，比如发送方是谁，接受方是谁；而有效载荷就是快递的内容）
报头和有效载荷共同构成了一个报文！

2.什么是应用层?

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

OSI的七层分层是非常完善的，它综合考虑了各行各业的，各个厂商在实现的时候按照OSI的七层协议进行。
但是经过实践，人们发现七层协议太过冗余，于是把OSI的七层分层简化为5(或者4)层，形成了如今的网络协议栈。

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

3. 为什么要进行分层？

协议本质上是软件，在设计上的分层是为了更好的进行模块化设计，便于解耦和，设计为层状的结构优势在于：
一层出现问题，可以快速定位，便于快速找到问题所在，同时分层后的软件层之间相互不影响，这也就让软件的维护成本更低。

（二）HTTP协议

2.1 初识HTTP协议

协议看似“高大上”，其实我们每个人都可以定义一个协议，但是由于我们每一个人定义协议时考虑的内容不同，所以有很大的可能定义出来的协议五花八门。
但实际上, 已经有大佬们定义了一些现成的, 又非常好用的应用层协议, 供我们直接参考使用. HTTP(超文本传输协议)就是其中之一。
HTTP（HyperText Transfer Protocol， 超文本传输协议）是一个应用广泛所以至关重要的协议。通过这个“超文本”传输协议我们不仅可以传输文字内容（txt），也可传输图片（gpj），音频（mp3)，甚至是视频（mp4）文件。
此外，HTTP协议是无连接，无状态的协议，即每次请求都需要建立新的链接，且服务器不会保存客户端信息。

2.2HTTP协议的URL

随便打开一个网页，我们就可以看到网址一栏特有的内容：
HTTPS 这个网页使用的是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，以这个目录为根，形成了一颗目录树，这就给用户一种错觉：仿佛在访问服务器的根目录下的资源。
web根目录图解

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）字段及其作用与示例：

字段名称	示例值	作用说明
Host	`Host: www.ddsm.com`	指定请求的目标服务器域名（HTTP/1.1必须字段）。
User-Agent	`User-Agent: Mozilla/5.0 (Windows NT 10.0)`	标识客户端信息（浏览器信息、操作系统信息（包括版本）、硬件设备信息等）。
Accept	`Accept: text/html, application/json`	声明客户端可接收的响应内容类型。
Content-Type	`Content-Type: application/json`	指定请求正文的数据格式（如JSON、表单、文件）。
Content-Length	`Content-Length: 4096`	声明请求正文的字节长度（POST/PUT请求必须）。
Authorization	`Authorization: Beabd125`	携带认证凭证（如Token、Basic Auth）。
Cookie	`Cookie: session_id=xyzabc123`	向服务器发送客户端存储的Cookie。
Connection	`Connection: keep-alive`	控制连接是否保持活跃（`keep-alive`表示长连接，`close`表示短连接）。
Accept-Encoding	`Accept-Encoding: gzip, deflate`	声明客户端支持的压缩算法（如gzip,zip等）。
Referer	`Referer: https://www.google.com`	表示当前请求的来源页面URL（用于防盗链或统计）。
Cache-Control	`Cache-Control: no-cache`	控制缓存行为（如`max-age=3600`、`no-store`）。
Accept-Language	`Accept-Language: en-US, zh-CN`	声明客户端优先接收的语言类型。

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请求报文注意事项：

换行符：HTTP规范要求使用\r\n（CRLF）作为换行符。
Host头：HTTP/1.1中必须包含，用于指定服务器域名。
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"}

各部分的核心作用总结

部分	核心作用
状态行	反馈请求处理结果（成功、失败、重定向等）。
响应头	提供服务器信息、内容类型、缓存控制等元数据。
空行	分隔头部与正文，避免数据混淆。
响应正文	返回客户端请求的实际数据（如HTML、JSON、文件）。

关键注意事项

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

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

未完待续~
转载请注明出处
在这里插入图片描述

文章目录

(一)概念梳理

1.什么是协议?

2.什么是应用层?

3. 为什么要进行分层？

（二）HTTP协议

2.1 初识HTTP协议

2.2HTTP协议的URL

2.2.1域名

2.2.2端口号

2.2.3 web根目录

2.2.4 什么是资源

2.2.5 URL总结

2.3 HTTP协议的报文

2.3.1 HTTP请求报文结构

i. 请求行（Request Line）

ii. 请求字段（Request Headers）

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

iii. 空行（Empty Line）

iv. 请求正文（Request Body）

2.3.2完整HTTP请求报文示例

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

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

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

HTTP请求报文注意事项：

2.3.3 HTTP响应报文结构

i. 状态行（Status Line）

ii. 响应头（Response Headers）

iii. 空行（Empty Line）

iv. 响应正文（Response Body）

完整HTTP响应报文示例

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

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

各部分的核心作用总结

关键注意事项

相关文章：