Http协议理论知识

原创于 2025-02-16 18:03:42 发布 · 1.1k 阅读

25 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

前言

阅读本文前请注意最后编辑时间，文章内容可能与目前最新的技术发展情况相去甚远。欢迎各位评论与私信，指出错误或是进行交流等。

注：可上网搜索HTTP协议官方文档，学习该方面的知识。

Http协议介绍

在介绍Http协议之前，首先知道什么叫协议。‌

计算机中的协议是一种规则，用于管理计算机之间的通信‌。协议确保不同厂商的设备、不同的CPU及不同的操作系统能够通过遵循相同的标准进行通信。这些协议定义了数据传输的格式、顺序和错误处理方式，从而使得网络中的设备能够相互理解和交互。

HTTP，全称为超文本传输协议（Hypertxt Transfer Protocol），是一种基于请求与响应模式的，应用广泛的应用层协议，用于在网络中传输超文本内容（如HTML、文本、视频、图片等）。是基于传输层的TCP/IP协议栈实现的，定义了客户端（如浏览器）与服务器之间请求和响应的格式。简单来说就是客户端发送请求到服务器，服务器再接收到请求后处理，返回响应给客户端。

Http协议的特点

无状态性（Stateless）

HTTP 协议是无状态的，这意味着每次请求都是独立的，服务器不会自动保存任何前一次请求的上下文信息。
这种无状态设计简化了服务器的实现，但为了满足需要“记住”用户状态的场景（如登录），可以通过 Cookie 或 Session等机制实现状态管理。

请求-响应模型（Request-Response Model）

HTTP 是基于请求-响应的协议。客户端发送 HTTP 请求 (Request)，服务器处理并返回一个 HTTP 响应 (Response)。
每次交互由以下流程组成：客户端发起请求，服务器解析请求并生成响应，然后将数据返回给客户端。

灵活性（Flexibility）

HTTP 支持传输多种类型的数据，如纯文本（text/html）、图片（image/jpeg）、音频（audio/mp3）、视频（video/mp4）等。
数据类型由响应头中的 Content-Type 字段指定，客户端会根据这个字段解析内容。

无连接性（Connectionless）

HTTP 协议在早期版本中是无连接的，即每次请求完成后，连接就会关闭。
从 HTTP/1.1 开始，加入了 Keep-Alive 机制，使得连接可以被复用，从而提高了效率。

可扩展性（Extensibility）

HTTP 协议支持通过自定义头部字段或扩展功能（如 WebSocket）来满足新的需求。这种设计让 HTTP 能够不断适应互联网的变化。

跨平台性与普适性

HTTP 是与平台无关的协议，几乎所有支持网络通信的设备和编程语言都可以实现 HTTP 客户端或服务器

关于HTTP通信的基础术语

客户端（Client）
发起请求的一端，通常是浏览器、移动端应用或其他工具（如 Postman）。
客户端的主要任务是生成请求报文并解析服务器返回的响应内容。
服务器（Server）
接收并处理请求的一端，通常是 Web 服务器（如 Apache、Nginx、IIS 等）。
服务器负责根据请求生成响应数据并返回给客户端。
请求（Request）
请求报文由客户端构造并发送给服务器，通常包含请求方法（如 GET、POST）、目标 URL 及附加数据（如请求头和请求体）。
响应（Response）
响应报文由服务器生成并返回给客户端，通常包含状态信息（如 200 OK、404 Not Found）及资源数据（如 HTML 页面或 JSON 数据）。

Http协议的工作过程

DNS 解析

用户在浏览器中输入的网址（如 www.example.com）是一个域名。计算机无法直接识别域名，需要通过 DNS（域名系统）解析将域名转换为服务器的 IP 地址。例如：www.example.com → 192.168.1.1。

工作机制：
1.浏览器先查询本地 DNS 缓存中是否有对应的记录。
2.如果没有，向本地 DNS 服务器发起查询，逐级请求权威 DNS 服务器，直到获取到 IP 地址。

建立连接

通过DNS域名解析，获取到了对应的IP地址以及端口号后。客户端通过TCP三次握手与服务器建立连接，确保数据传输的可靠性。

三次握手的过程：
1.客户端发送 SYN 报文，表示希望建立连接。
2.服务器收到后，返回 SYN-ACK 报文，表示同意建立连接。
3.客户端再发送 ACK 报文，确认连接成功。

在 HTTPS 中，还会增加 TLS 握手流程，完成加密通信的密钥协商。

发送 HTTP 请求
连接建立后，客户端向服务器发送 HTTP 请求报文。
服务器处理请求并返回 HTTP 响应

服务器接收到请求后，解析请求报文，根据 URL 定位目标资源，执行相应操作（如读取文件或查询数据库），然后生成 HTTP 响应报文并返回给客户端。

关闭或保持连接

如果启用了 Keep-Alive（HTTP/1.1 默认开启），连接会保持一段时间，供后续请求复用，减少握手延迟。
如果未启用或超时，连接将被关闭。

Http请求报文

在Http协议的工作过程中，客户端会向服务器发送请求报文，让我们来了解下请求报文的组成。

URL

URL（Uniform Resource Locator）统一资源定位符，用于描述网络资源的地址和访问方法。URL 可以理解为我们俗称的 “网址” ，互联网上的每个文件都有一个唯一的 URL，它包含的信息可以指出文件的位置及浏览器应该怎么处理它。

URL 基本格式

协议类型://[凭证信息@]服务器地址[:端口号][/资源路径]文件名[?查询参数][#片段标识符]

URL参数解析

参数	描述	能否省略
协议类型	指定数据传输的方式，常见协议包括 HTTP、HTTPS、FTP 等	可以省略，省略的时候默认是http://
凭证信息	包括用户名和密码，用于授权访问。但是现在的网站进行认证一般不会通过URL进行	可以省略
服务器地址	服务器地址可以是一个IP地址，也可以是一个域名（域名会通过DNS系统解析成一个具体的IP地址），IP地址用来描述一个网络上的具体位置，能用来定位一个具体的主机	可以省略，省略后的地址即为本地连接的IP地址
端口号	一台计算上会运行不同的应用程序。每个程序在访问网络的时候，都会关联上一个或多个端口号，通过端口号就能区分出当前数据包的来源和目的地。	可以被省略，当端口号省略时，浏览器会根据协议类型自动决定使用哪个端口号（如 http 协议默认使用80端口，https 协议默认使用443端口）
资源路径	表示服务器上某个资源路径	可以省略，省略后相当于 /
文件名	表示访问该服务器上的哪个资源（如 html、图片等）	不可省略
查询参数	使用 ? 开头，以键值对的形式传递参数，多个参数用 & 分隔。表示客户端给服务器传递的参数信息	可以省略
片段标识符	使用 # 开头，主要是用来页面跳转，例如跳转到当前页面的某个部分等	可以省略

URL 示例

https://www.example.com:443/api/v1/resource?user=alice&action=view#details
协议：https
服务器地址：www.example.com
端口号：443
资源路径：/api/v1/resource（可将资源路径和文件名合称为资源路径）
查询参数：user=alice&action=view
片段标识符：details

请求方法

HTTP 定义了一系列请求方法，用于描述客户端对资源的操作。

以下表格概述了常用请求方法的功能及其特点：

方法	描述
GET	从服务器获取资源，用于请求数据而不对其进行更改。例如：获取网页、图片等。
POST	向服务器发送数据以创建新资源。常用于提交表单或上传文件，数据包含在请求体中。
PUT	更新或替换服务器上的资源，如果资源不存在则创建。
DELETE	从服务器删除指定资源，使用资源标识符指定要删除的内容。

GET 和 POST 的区别是一个经典的面试题

答题模板：

GET 和 POST 其实没有本质区别，使用 GET 的场景完全可以使用 POST 代替，使用 POST 的场景一样可以使用 GET 代替。但是在具体的使用上，还是存在一些细节的区别

GET 习惯上会把客户端的数据通过查询参数来传输（格式如 ?key=value，数据暴露在地址栏，请求体部分是空的）；POST 习惯上会把客户端的数据通过请求体来传输（适合传输大数据或复杂结构，查询参数部分是空的）。
GET 习惯上用于从服务器获取数据；POST 习惯上是客户端给服务器提交数据。
一般情况，程序员会把 GET 请求的处理，实现成“幂等”的；对于 POST 请求的处理，不要求实现成“幂等”。
GET 请求可以被缓存，可以被浏览器保存到收藏夹中；POST 请求默认不能被缓存，更适合提交动态数据。
GET 请求参数暴露在 URL 中，不适合传输敏感数据。 POST 请求数据包含在请求体中，结合 HTTPS 加密传输更安全。

补充：幂等是什么？

一个 HTTP 方法是幂等的，指的是同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。

关于POST比GET更加安全的误解
网上的错误理解：如果实现登录界面，如果使用GET实现登录，GET习惯上把数据放到查询参数中，此时就能看到浏览器的URL中显示的当前的用户名和密码，所以就不安全了，而POST习惯上会把数据放入请求体中，因此登录就不能直接看到用户名和密码，就会更加安全

正确理解：安全问题取决于是否进行加密以及加密算法的强度，和把数据信息放到查询参数和请求体中无关，因为通过抓包这两部分的数据，我们都可以看见

关于GET只能传输文本数据的误解
网上的错误理解：GET只能传输文本数据，POST传输文本数据，也可以传输二进制数据

正确理解：GET也可以传输二进制数据，虽然不能直接在查询参数中传输二进制数据，但是可以针对二进制数据进行url编码，转码之后就可以放到URL中；GET还可以将二进制数据放到请求体中

此处补充 url编码(url encode)，URL中的查询参数中的内容是自定义的键值对。在URL中，有些符号是具有特殊含义的，比如：/、:、?、@……，如果在 URL 中的查询参数中也包含了同样的符号，并直接写入，可能就会使浏览器/服务器解析失败，为了解决这样的问题，就需要对内容进行 “转义”，这就是 encode。

如下图所示，在搜索C++时，+这个字符在url中具有特殊含义，因此encode为 %2B

在这里插入图片描述

Http请求报文格式

请求行：指定客户端希望服务器执行的操作。

结构：

方法：如 GET、POST、PUT、DELETE，指示请求的操作类型。
请求 URL：目标资源的路径，包括主机名、端口号（如非默认）、资源路径和查询字符串。
HTTP 版本：指定所使用的 HTTP 协议版本（如 HTTP/1.1、HTTP/2）。
示例：GET /index.html HTTP/1.1

请求头（Request Headers）：提供额外的信息，如客户端信息（User-Agent）、支持的格式（Accept）等。

以key: value的格式书写

请求头中常见的内容有：

Host：目标服务器的地址和端口（地址可以是域名，也可以是IP；端口号可以省略或者手动指定）。
User-Agent：表示浏览器或者操作系统的属性。
Content-Length：请求体的长度，长度单位是字节。
Content-Type：表示请求体的数据格式，以下介绍三种请求中的数据格式

application/x-www-form-urlencoded：这是form表单提交的数据格式，此时请求体的格式就类似于查询参数（是键值对的结构，键值对之间使用&分割，键与值之间使用=进行分割）
multipart/from-data：这是form表单提交的数据格式（需要在from标签上加上 enctyped=“multipart/form-data”），通常用于HTML提交图片或者文件
application/json:此时请求体数据为json格式，json格式就是源自js的对象格式，用一个{}包含，里面有多个键值对，键值对之间使用逗号进行分割，键和值之间使用冒号分隔

空行

请求头和请求体之间的分隔符，表示请求头部分结束。

请求体（Request Body，非必需）

携带发送给服务器的数据（如表单、JSON 数据等）。

例如，打开百度，需要向百度的服务器发送一个GET请求来获取页面，用抓包软件抓到了这个HTTP请求数据包，如下

在这里插入图片描述

第一行为请求行，请求方法为GET，URL为https://www.baidu.com/，HTTP协议版本为1.1。

随后的内容则是请求头，以key: value的格式书写。

在请求头的最后一行之后有一个空行，由于该请求没有请求体内容，所以就以空行结束。

Http响应报文

服务器接收到请求后，解析请求报文，根据 URL定位目标资源，执行相应操作（如读取文件或查询数据库），然后生成 HTTP 响应报文并返回给客户端。

状态码

HTTP 状态码是服务器用于表示请求处理结果的三位数字代码。状态码分为五大类，每类代表不同的处理结果。

状态码分类

分类	描述
1XX	服务器收到请求，需请求者继续操作
2XX	成功：请求被成功处理
3XX	重定向：需进一步操作以完成请求
4XX	客户端错误：请求包含语法错误或无法完成
5XX	服务器错误：服务器在处理请求时发生错误

常见状态码

状态码	描述	详细说明
200	OK	请求成功，通常用于 GET 或 POST 请求
201	Created	资源已成功创建（用于 POST 或 PUT）
204	No Content	请求成功，无返回内容
301	Moved Permanently	资源永久重定向到新 URL
302	Found	资源暂时重定向到新 URL
403	Forbidden	服务器拒绝执行请求
404	Not Found	请求的资源不存在
503	Service Unavailable	服务器超载或维护中，暂时不可用

Http响应报文格式

状态行（Status Line）

表明响应结果的状态信息。

结构：

HTTP 版本：与请求的版本匹配。
状态码：三位数字，表示请求的处理结果（如 200 表示成功，404 表示资源未找到）。
状态信息：状态码的描述。
示例：HTTP/1.1 200 OK

响应头（Response Headers）

关于 HTTP 的响应报头，其格式与请求报头的格式基本一致，比如 Content-Type，Content-Length 等属性的含义也与请求报头中的含义一致，只不过关于 Content-Type，HTTP 响应报头中的常见取值与 HTTP 请求报头中的场景取值有所差别，响应中的 Content-Type 常见取值如下：

text/html：响应体数据格式是 HTML；
text/css：响应体数据格式是 CSS；
application/javascript：响应体数据格式是 JavaScript；
application/json：响应体数据格式是 JSON。

空行
响应头和响应体之间的分隔符，表示响应头部分结束。
响应体（Response Body）
包含返回的数据内容，如 HTML 页面、JSON 数据、图片等。

HTTP响应报文示例

HTTP/1.1 200 OK  
Content-Type: text/html  
Content-Length: 1024  
Server: Apache/2.4.41 (Ubuntu)  

（空行，表示结束响应头）
<html>
  <head><title>Example</title></head>
  <body>Welcome to the Lingbou blog!</body>
</html>

第一行为状态码，HTTP协议版本1.1，状态码200 描述OK。
随后是响应头，在响应头之后的空行，表示响应头部分结束。最后是响应体的内容，返回的是一个HTML的信息。

了解了HTTP请求和响应之后，对Http协议的工作过程举例说明，再次巩固一下。

假设用户访问 https://www.example.com/login，以下是每个步骤的具体表现：

DNS 解析
域名 www.example.com 解析为 IP 地址 192.0.2.1。
TCP 连接
客户端与 192.0.2.1 建立 TCP 连接，三次握手完成。
客户端发送 HTTP GET 请求：

 GET /login HTTP/1.1  
 Host: www.example.com  
 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/96.0  
 Accept: text/html

服务器返回 HTTP 响应：

 HTTP/1.1 200 OK  
 Content-Type: text/html  
 Content-Length: 1024  
 
 <html>
   <head><title>Login</title></head>
   <body>Welcome to the Lingbou blog.</body>
 </html>

页面显示

浏览器解析 HTML 代码，并向服务器请求页面中的附加资源（如 CSS 文件、图片）。最终显示完整的页面

传统风格与RESTful风格

传统风格与RESTful风格对比-CSDN博客

HTTP的版本

HTTP 协议在不断迭代中发展，主要版本包括：

HTTP/1.0

引入基本的请求-响应模型。
每次请求都会新建一个连接，请求结束后关闭连接，效率较低。

HTTP/1.1

默认支持持久连接（Keep-Alive），提升了性能。
引入了管线化（Pipelining），允许客户端在等待响应的同时发送多个请求（虽然实际应用较少）。

HTTP/2.0

基于二进制帧传输数据，替代了传统的文本格式。
支持多路复用（Multiplexing），在单个连接上同时传输多个请求和响应，避免了 HTTP/1.x 的“队头阻塞”问题。
引入了服务器推送（Server Push），允许服务器主动向客户端发送资源，减少延迟。

HTTP/3.0

基于 QUIC 协议（使用 UDP），进一步提升传输效率和可靠性。
解决了 TCP 的一些固有问题，如握手延迟和连接迁移问题。

在这里插入图片描述

抓包工具

想要获取 HTTP 协议的报文格式，我们就需要借助抓包工具，抓包工具本质上是一个 “代理程序” 它可以获取到网络上传输的数据并显示出来，从而给我们提供一些参考。

方式一：通过 F12 打开浏览器的开发者工具，点击 Network 标签页，然后刷新页面就行。显示的每一条记录都是一次 HTTP 请求/响应
具体使用操作可自行查阅资料。
方式二（推荐）：抓包工具，这里以 Fiddler 为例，它能够直接读取你电脑上网卡的信息，网卡上有什么数据流动，它都能感知到并且显示出来。

打开 Fiddler，然后打开你要访问的网站，访问该网站的 HTTP 请求和响应就会显示在 Fiddler 上

注意：直接安装的 Fiddler 是无法抓取 HTTPS 的请求的，需要进行配置。关于工具的具体使用操作，请自行查阅资料。
在这里插入图片描述

HTTPS（HyperText Transfer Protocol Secure）

HTTPS 的主要功能

加密
HTTPS 通过加密算法保护数据在传输过程中的隐私性，防止被第三方窃听：

对称加密：通信双方使用相同的密钥对数据加密和解密，速度快但密钥需要安全传递。
非对称加密：服务器提供公钥，客户端用公钥加密数据，服务器用私钥解密数据，用于解决密钥分发问题。
实际通信中，两种加密方式配合使用：非对称加密用于密钥交换，对称加密用于数据传输。

数据完整性
通过消息摘要算法（如 SHA-256）生成哈希值，验证数据是否在传输过程中被篡改。如果数据被篡改，哈希值校验不匹配，通信会被终止。
身份验证
HTTPS 使用数字证书来验证服务器的身份。

数字证书由权威证书颁发机构（CA）签发，包含服务器的公钥和域名信息。
浏览器通过验证证书的合法性（如是否由可信 CA 签发、证书是否过期）确保通信目标是预期的服务器，防止中间人攻击。

HTTPS 的工作原理

HTTPS 使用 SSL/TLS 协议，主要分为两个阶段：握手阶段和数据传输阶段。

握手阶段
客户端与服务器协商通信方式和加密方式的过程：

1.客户端向服务器发送请求，包含支持的加密算法列表和随机数（用于生成密钥）。

2.服务器返回自己的数字证书（包含公钥）和一个随机数。

3.客户端验证证书的合法性（CA 签名、域名匹配、有效期等）。
如果验证通过，客户端生成一个新的随机数并使用服务器的公钥加密后发送给服务器。

4.服务器用私钥解密随机数，三组随机数生成会话密钥，用于后续对称加密。

数据传输阶段
握手完成后，客户端和服务器使用对称加密的会话密钥加密数据进行通信，确保数据高效传输和安全性。

HTTP 与 HTTPS 的对比

HTTPS 是 HTTP 的安全版本，通过 SSL/TLS 协议对数据进行加密，保护传输数据的保密性、完整性和身份真实性。它是现代互联网通信安全的核心技术。

在这里插入图片描述

HTTP 的通信是明文的，数据在传输过程中容易被截获或篡改，而 HTTPS（HTTP Secure）是基于 HTTP 协议的一种安全协议，通过加入 SSL/TLS 加密层确保数据安全性。

主要区别如下：

特性	HTTP	HTTPS
安全性	数据明文传输，易被窃听或篡改	加密传输，防止窃听、篡改和中间人攻击
端口号	默认端口为 80	默认端口为 443
加密机制	无	通过 SSL/TLS 加密
性能	较快，但不安全	略慢（需要加解密），但更安全
身份验证	无验证机制，可能遭遇中间人攻击	通过数字证书验证服务器身份
适用场景	静态内容传输、不涉及隐私和敏感数据	涉及敏感数据（登录、支付、隐私数据）

HTTPS 的缺点

性能开销：

加解密过程需要更多计算资源，增加了服务器和客户端的 CPU 和内存消耗。
特别是在高并发场景下，性能影响更明显。
TLS 1.3 版本优化了握手过程，性能影响已显著降低。

证书成本：

获取权威 CA 签发的证书需要支付费用。
不过免费 CA（如 Let’s Encrypt）为许多小型网站提供免费证书。

部署复杂性：

HTTPS 需要正确配置服务器、证书和加密协议。
还需定期更新证书以保持其有效性。

如何实现 HTTPS

获取数字证书

申请证书：
通过权威 CA（如 DigiCert、Let’s Encrypt）申请 SSL/TLS 证书。
配置域名和服务器：确保域名与服务器 IP 映射正确，方便证书申请验证。

配置服务器

在服务器（如 Apache、Nginx）启用 SSL/TLS 模块。
加载证书文件并指定私钥路径。
强制使用 TLS 1.2 或 TLS 1.3，并禁用旧的、不安全的协议版本（如 SSL、TLS 1.0 和 1.1）。

重定向 HTTP 到 HTTPS

配置 301 永久重定向规则，将所有 HTTP 请求跳转到 HTTPS。

测试 HTTPS

使用工具（如 SSL Labs）测试 HTTPS 配置，确保证书有效性和安全性。

HTTPS 的常见问题

证书无效：
可能因为证书过期、域名与证书不匹配或使用了不被信任的 CA 签发的证书。
解决：检查证书有效性，使用可信 CA 签发的证书。
混合内容警告：
HTTPS 页面中加载了非 HTTPS 的资源（如图片、脚本）。
解决：确保页面所有资源均通过 HTTPS 加载。
性能影响：
在高并发场景下，加密计算会增加服务器开销。
解决：启用 HTTP/2 和 TLS 1.3，使用 CDN 缓解服务器压力。

参考目录

https://blog.csdn.net/2302_80127404/article/details/144143108
https://blog.csdn.net/Stromboli/article/details/143442593
https://blog.csdn.net/weixin_51367845/article/details/123313047
https://blog.csdn.net/zhyhgx/article/details/143134408
https://blog.csdn.net/loss_rose777/article/details/132919997
https://blog.csdn.net/HKJ_numb1/article/details/144170752

标签