HTTP详解

一、HTTP 概述

HTTP 是一种用于传输超媒体文档（例如 HTML）的应用层协议。它定义了客户端（如浏览器）与服务器之间如何通信，以交换或传输超文本（如HTML 文档）。

HTTP 协议是客户端与服务器之间通信的基础。客户端通过HTTP 协议向服务器发送请求，服务器收到请求后处理并返回响应。HTTP 协议是一个无连接、无状态的协议，即每次请求都需要建立新的连接，且服务器不会保存客户端的状态信息。

全称：超文本传输协议
特点：
- 客户端-服务器模型：由客户端（如浏览器）发起请求，服务器响应。
- 无状态协议：默认情况下，服务器不会保留两次请求之间的任何状态信息。这意味着每次请求都是独立的（后续的 Cookie/Session 技术解决了此问题）。
- 可扩展：通过请求/响应头字段，可以轻松扩展新功能。
- 基于文本（HTTP/1.1）：报文是直观可读的文本格式（HTTP/2 改为二进制帧，但语义不变）。

二、核心工作模型：请求与响应

一次完整的 HTTP 交互称为一个事务，由一次请求和一次响应组成。

1. HTTP 请求

客户端发送给服务器的报文。

plain 复制代码

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

一个请求报文由三部分组成：

请求行：[方法] + [uri] + [版本]

**Header: **请求的属性, 冒号分割的键值对;每组属性之间使用\r\n 分隔;遇到空行表示Header 部分结束

Body: 空行后面的内容都是Body. Body 允许为空字符串. 如果Body 存在, 则在Header 中会有一个Content-Length 属性来标识Body 的长度;

方法

我们日常生活99%用的都是是GET 方法和POST 方法，其他的方法大多服务器都不允许

GET 与 POST 方法概述

GET方法登录时提参，参数在URL

GET方法登录时提参，参数在body

URL

平时我们俗称的"网址" 其实就是说的URL

URL 是统一资源定位符。你可以把它理解为互联网上资源的"地址"或"门牌号"。就像你家的地址能告诉邮差信件该送到哪里一样，URL 告诉你的浏览器去哪里找到并获取你想要的网页、图片、视频或文件。

urlencode 和urldecode

在Web开发中，URL（Uniform Resource Locator）用于定位网络上的资源。URL中只能包含ASCII字符集的一部分字符，且某些字符具有特殊含义（如?用于分隔查询字符串，#用于指定锚点）。当需要在URL中传输非ASCII字符（如中文）或可能被误解为控制字符的符号时，必须对其进行URL编码（也称为百分号编码）。URL解码则是其逆过程，将编码后的字符串还原为原始内容。

一、为什么需要URL编码？

字符限制：URL中允许的字符集有限（通常为字母、数字、以及部分特殊符号-_.~），其他字符（如空格、中文、特殊符号）必须被编码。
避免歧义：某些字符在URL中具有特殊含义（如&分隔参数、=连接键值、#表示书签），若这些字符作为数据的一部分出现，必须转义，以免被解析器误解。
安全性：编码可以防止注入攻击，例如在参数中插入恶意脚本或SQL代码时，编码会将其变为无害形式。
数据传输：HTTP协议本身基于文本，URL编码确保数据在传输过程中不被破坏。

二、URL编码的规则

URL编码采用百分号后跟两位十六进制数的形式表示一个字节。其基本规则：

● 将需要编码的字符转换为对应字符集的字节序列（通常为UTF-8编码）。

● 每个字节用%后跟该字节的两位十六进制表示（字母大写）。

● 例如，字符中的UTF-8编码为E4 B8 AD，则URL编码后为%E4%B8%AD。

哪些字符需要编码？

● 保留字符：在URL中有特殊用途的字符，如! * ' ( ) ; : @ & = + $ , / ? % # [ ]。当它们作为普通数据时，必须编码。

● 不安全字符：包括空格、引号、<>、{}、|、\、^、~（RFC 3986将~列为安全字符，但旧标准可能认为不安全）等。

● 非ASCII字符：所有超过ASCII范围的字符（如中文、日文、俄文等）都需要编码。

● 实际上，根据RFC 3986，只有字母、数字、以及-._~这四个符号可以不经编码直接使用，其他字符均应编码。但实践中，不同实现略有差异。

三、URL解码（urldecode）

URL解码是编码的逆过程：将形如%XX的序列替换为对应的字符。解码时需注意字符集，通常与编码时使用的字符集一致（如UTF-8）。若编码时采用了其他字符集（如GBK），解码时需使用相同字符集，否则会出现乱码。

四、示例

下面通过一个具体的例子来演示URL编码和解码的过程。

Hello 你好！

这个字符串包含ASCII字符（Hello）、空格、中文（你好）和中文标点（！）。我们将对它进行URL编码，然后再解码回原字符串。

手动编码过程（基于UTF-8）

Hello：都是ASCII字母，无需编码，直接保留。
空格：ASCII码为32（十六进制20），需要编码为 %20（注：在表单类型编码中可能用 +，但URI路径中通常用 %20，这里采用RFC 3986标准）。
你：UTF-8编码为三个字节：E4 BD A0 → 编码为 %E4%BD%A0。
好：UTF-8编码：E5 A5 BD → 编码为 %E5%A5%BD。
！：中文感叹号，UTF-8编码：EF BC 81 → 编码为 %EF%BC%81。
将以上拼接起来，得到URL编码后的字符串：
Hello%20%E4%BD%A0%E5%A5%BD%EF%BC%81
解码过程
解码时，程序扫描到 % 后跟两位十六进制数，就将它们转换回对应的字节，然后按UTF-8解码成字符。上述编码字符串解码后就会还原为原始字符串 Hello 你好！。

一个完整的 URL 分解

让我们以 https://www.example.com:8080/shop/products?id=123\&color=red#details 为例，分解它的各个部分：

协议 / 方案
https://
这部分告诉浏览器用什么"协议"或"规则"来访问资源。最常见的两种是：
http://：超文本传输协议，标准网页传输协议。
https://：安全的 HTTP，数据在传输过程中会被加密，更安全。
其他还有：ftp://（文件传输）、mailto://（电子邮件）等。
主机名 / 域名
www.example.com
这是资源所在服务器的名称。它像一个易于记忆的"公司名称"。它最终会被DNS 系统转换成服务器的 IP 地址（如 93.184.216.34）。
端口
:8080
端口就像是服务器上的一个"门"或"通道"。每个服务运行在一个特定的端口上。HTTP 默认端口是 80，HTTPS 默认端口是 443。当使用默认端口时，URL 中通常省略端口号（如 https://www.example.com 等同于 https://www.example.com:443）。非标准端口（如 8080）才需要显式写出。
路径
/shop/products
这代表了资源在服务器上的具体位置，就像服务器硬盘上的文件夹和文件路径。它指向特定的页面或文件（例如 index.html, /images/logo.png）。
查询字符串 / 参数
?id=123&color=red
以问号 ? 开头，用于向服务器传递额外信息，通常用于搜索、筛选或提交表单。
格式是键=值对。
多个参数之间用 & 连接。
在上例中，服务器可能会根据 id=123 和 color=red 这两个参数来返回特定的产品信息。
片段 / 锚点
#details
以井号 # 开头，它不发送给服务器，只由浏览器处理。
它用于直接跳转到网页内部的某个特定位置（例如一个标题或锚点）。常用于长页面的内部导航。

URL和URI的区别

URL （统一资源定位符）和 URI （统一资源标识符）的核心区别在于：URI 是一个广义的"身份证"，而 URL 是一个具体的"家庭住址"。

简单来说，URL 是 URI 的一种子集。以下是详细的对比和解释：

1. 核心定义区别

URI（Uniform Resource Identifier，统一资源标识符） ：
- 作用是标识一个资源。
- 它只负责通过一个唯一的字符串（如名称、位置或两者的结合）来区分不同的资源，不关心如何找到它。
URL（Uniform Resource Locator，统一资源定位符） ：
- 作用是定位一个资源。
- 它不仅标识了资源，还提供了访问该资源的机制 （协议，如 HTTP、FTP）和具体位置（如网络地址）。

2. 通俗类比

假设我们把"你"看作一个资源：

URI ：相当于你的身份证号。它是唯一的，能准确地标识出"你"这个人。但它本身不告诉你该去哪里找你。
URL ：相当于你现在的家庭住址（例如：北京市朝阳区xx路xx号）。它不仅标识了"你"（通过这个地址找到的就是你），还告诉别人如何找到你。

3. 语法结构对比

通过结构可以更直观地理解：

● URL 的语法（必须包含访问协议）：

协议://域名或IP地址/路径/文件名

例如：https：//www.example.com/index.html

● URI 的语法（可以是单纯的名称，也可以是完整的 URL）：

文件的主文件名或协议://域名或IP地址/路径/文件名

例如：index.html 或 https：//www.example.com/index.html

4. 具体例子分析

假设我们有一个网页资源：https：//example.com/path/file.html

● https：//example.com/path/file.html 既是一个 URL，也是一个 URI。

○ 它是 URL：因为它包含了协议（https：//）和主机名（example.com），指明了如何访问以及去哪里找。

○ 它也是 URI：因为它唯一地标识了这个网页资源。

● /path/file.html 或 file.html 只能被称为 URI，不能被称为 URL。

○ 因为它缺少了访问协议和主机信息，虽然能标识这是网站上的某个文件（相对于根路径），但无法直接定位到网络上的具体位置。

总结

URL 一定是 URI ，但 URI 不一定是 URL。

在现代互联网开发中，当我们需要访问网页或接口时，使用的绝大多数都是 URL；而当我们在后端代码中进行资源映射、路由匹配时，操作的往往是 URI 的部分路径。

2. HTTP 响应

服务器返回给客户端的报文。

plain 复制代码

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 1234

<!DOCTYPE html>
<html>...</html>

一个响应报文由三部分组成：

状态行：[版本号] + [状态码] + [状态码解释]

**Header: **请求的属性, 冒号分割的键值对;每组属性之间使用\r\n 分隔;遇到空行表示Header 部分结束

**Body: **空行后面的内容都是Body. Body 允许为空字符串. 如果Body 存在, 则在Header 中会有一个Content-Length 属性来标识Body 的长度; 如果服务器返回了一个html 页面, 那么html 页面内容就是在body 中.

状态码

最常见的状态码, 比如200(OK), 404(Not Found), 403(Forbidden), 302(Redirect, 重定向), 504(Bad Gateway)

重定向

在 Linux 网络编程和服务器管理中，重定向是 HTTP 协议中一个非常重要的概念。它指的是服务器通过返回特定的3xx状态码，来通知客户端（如浏览器或 curl 命令）需要执行额外操作才能完成请求，通常是跳转到另一个 URL 。

下面详细梳理 Linux 环境下常见的重定向状态码。

HTTP 重定向状态码以 3 开头，它们都包含一个 Location 响应头，用来指明新的目标地址。根据行为不同，主要分为永久重定向和临时重定向。

HTTP头部字段（HTTP Headers）是HTTP协议中用于传递额外信息的关键部分，它们在客户端和服务器之间交换元数据。根据用途，常见的HTTP Header可以分为四大类：通用头 、请求头 、响应头 和实体头。以下是常见及重要的HTTP头部字段及其作用。

一、通用头（General Headers）

同时适用于请求和响应，但与传输数据无关。

关于connection 报头

HTTP 中的Connection 字段是HTTP 报文头的一部分，它主要用于控制和管理客户端与服务器之间的连接状态

核心作用

• 管理持久连接：Connection 字段还用于管理持久连接（也称为长连接）。持久连接允许客户端和服务器在请求/响应完成后不立即关闭TCP 连接，以便在同一个连接上发送多个请求和接收多个响应。

持久连接（长连接）

• HTTP/1.1：在HTTP/1.1 协议中，默认使用持久连接。当客户端和服务器都不明确指定关闭连接时，连接将保持打开状态，以便后续的请求和响应可以复用同一个连接。

• HTTP/1.0：在HTTP/1.0 协议中，默认连接是非持久的。如果希望在HTTP/1.0上实现持久连接，需要在请求头中显式设置Connection: keep-alive。

语法格式

• **Connection: keep-alive：**表示希望保持连接以复用TCP 连接。

• Connection: close：表示请求/响应完成后，应该关闭TCP 连接。

二、请求头（Request Headers）

客户端向服务器发送请求时使用的头部，说明客户端的能力或偏好。

三、响应头（Response Headers）

服务器返回给客户端的头部，包含关于响应的额外信息。

四、实体头（Entity Headers）

描述消息体内容的元数据，既可用于请求也可用于响应（通常指有Body的消息）。

注意事项

● 大小写：HTTP头部字段名不区分大小写，但惯例使用首字母大写（如Content-Type）。

● 重复：某些头部可以出现多次（如Set-Cookie），但多数应合并为一个逗号分隔的列表。

● 安全：避免在头部中泄露敏感信息（如服务器版本、内部IP等）。

● 自定义：可以使用X-前缀添加自定义头部（例如X-Custom-Header），但如今推荐使用标准头部或注册新的头部。

附录

HTTP 历史及版本核心技术与时代背景

HTTP（Hypertext Transfer Protocol，超文本传输协议）作为互联网中浏览器和服务器间通信的基石，经历了从简单到复杂、从单一到多样的发展过程。以下将按照时间顺序，介绍HTTP 的主要版本、核心技术及其对应的时代背景。

HTTP/0.9

核心技术：

• 仅支持GET 请求方法。

• 仅支持纯文本传输，主要是HTML 格式。

• 无请求和响应头信息。

时代背景：

• 1991 年，HTTP/0.9 版本作为HTTP 协议的最初版本，用于传输基本的超文本HTML 内容。

• 当时的互联网还处于起步阶段，网页内容相对简单，主要以文本为主。

HTTP/1.0

核心技术：

• 引入POST 和HEAD 请求方法。

• 请求和响应头信息，支持多种数据格式（MIME）。

• 支持缓存（cache）。

• 状态码（status code）、多字符集支持等。

时代背景：

• 1996 年，随着互联网的快速发展，网页内容逐渐丰富，HTTP/1.0 版本应运而生。

• 为了满足日益增长的网络应用需求，HTTP/1.0 增加了更多的功能和灵活性。

• 然而，HTTP/1.0 的工作方式是每次TCP 连接只能发送一个请求，性能上存在一定局限。

HTTP/1.1

核心技术：

• 引入持久连接（persistent connection），支持管道化（pipelining）。

• 允许在单个TCP 连接上进行多个请求和响应，提高了性能。

• 引入分块传输编码（chunked transfer encoding）。

• 支持Host 头，允许在一个IP 地址上部署多个Web 站点。

时代背景：

• 1999 年，随着网页加载的外部资源越来越多，HTTP/1.0 的性能问题愈发突出。

• HTTP/1.1 通过引入持久连接和管道化等技术，有效提高了数据传输效率。

• 同时，互联网应用开始呈现出多元化、复杂化的趋势，HTTP/1.1 的出现满足了这些需求。

HTTP/2.0

核心技术：

• 多路复用（multiplexing），一个TCP 连接允许多个HTTP 请求。

• 二进制帧格式（binary framing），优化数据传输。

• 头部压缩（header compression），减少传输开销。

• 服务器推送（server push），提前发送资源到客户端。

时代背景：

• 2015 年，随着移动互联网的兴起和云计算技术的发展，网络应用对性能的要求越来越高。

• HTTP/2.0 通过多路复用、二进制帧格式等技术，显著提高了数据传输效率和网络性能。

• 同时，HTTP/2.0 还支持加密传输（HTTPS），提高了数据传输的安全性。

HTTP/3.0

核心技术：

• 使用QUIC 协议替代TCP 协议，基于UDP 构建的多路复用传输协议。

• 减少了TCP 三次握手及TLS 握手时间，提高了连接建立速度。

• 解决了TCP 中的线头阻塞问题，提高了数据传输效率。

时代背景：

• 2022 年，随着5G、物联网等技术的快速发展，网络应用对实时性、可靠性的要求越来越高。

• HTTP/3.0 通过使用QUIC 协议，提高了连接建立速度和数据传输效率，满足了这些需求。

• 同时，HTTP/3.0 还支持加密传输（HTTPS），保证了数据传输的安全性。

一、HTTP 概述

二、核心工作模型：请求与响应

1. HTTP 请求

方法

URL

urlencode 和urldecode

一、为什么需要URL编码？

二、URL编码的规则

三、URL解码（urldecode）

四、示例

一个完整的 URL 分解

URL和URI的区别

1. 核心定义区别

2. 通俗类比

3. 语法结构对比

4. 具体例子分析

总结

2. HTTP 响应

状态码

重定向

3、HTTP常见Header

一、通用头（General Headers）

关于connection 报头

二、请求头（Request Headers）

三、响应头（Response Headers）

四、实体头（Entity Headers）

注意事项

附录

HTTP 历史及版本核心技术与时代背景

HTTP/0.9

核心技术：

时代背景：

HTTP/1.0

核心技术：

时代背景：

HTTP/1.1

核心技术：

时代背景：

HTTP/2.0

核心技术：

时代背景：

HTTP/3.0

核心技术：

时代背景：