[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（HyperText Transfer Protocol， 超文本传输协议） 是一个应用广泛所以至关重要的协议。通过这个“超文本”传输协议我们不仅可以传输文字内容（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表示服务器错误），并优化前后端交互逻辑。

未完待续~
转载请注明出处