应用层Http协议（1）
在互联网世界中，HTTP（H yperT ext T ransfer Protocol，超文本传输协议）是一个至关重要的协议。它定义了客户端（如浏览器）与服务器之间如何通信，以交换或传输超文本（如 HTML 文档）。
HTTP 协议是客户端与服务器之间通信的基础。客户端通过 HTTP 协议向服务器发送请求，服务器收到请求后处理并返回响应。HTTP 协议是一个无连接、无状态的协议，即每次请求都需要建立新的连接，且服务器不会保存客户端的状态信息。
URL认识
平时我们俗称的 "网址" 其实就是说的 URL
https://news.qq.com/rain/a/20250808A01IJR00
拿这个举例子：
https:获取资源采用的协议
news.qq.com ：域名
域名相当于IP地址，那么为什么不直接用IP地址
核心区别
| 特性 | 域名（如 example.com） |
IP地址（如 192.0.2.1） |
|---|---|---|
| 可读性 | 人类易记（google.com） |
数字组合难记忆（142.250.190.46） |
| 稳定性 | 可保持不变，后台IP可更换 | 直接绑定服务器，变更需手动更新 |
| 灵活性 | 支持负载均衡、CDN、多服务器托管 | 固定指向单一服务器 |
| 安全性 | 可启用HTTPS证书（依赖域名） | 证书难以绑定到纯IP |
后面是要访问的资源路径 ，本质也是socket通信
什么是资源？
资源：视频，网页，图片，。。。
人的上网行为有两种：从远端拿资源；将资源进行上传
http角度："资源"就是文件，文件在LINUX指定路径下
http[s]:port 域名：IP地址（具有唯一性）
路径：目标路径上特定的文件
成熟协议都是有特定的端口号：https:443 http:80
encode，decode编码
像 / ? : 等这样的字符, 已经被 url 当做特殊意义理解了. 因此这些字符不能随意出现.
比如, 某个参数中需要带有这些特殊字符, 就必须先对特殊字符进行转义.
转义的规则如下:
将需要转码的字符转为 16 进制，然后从右到左，取 4 位(不足 4 位直接处理)，每 2 位做一位，前面加上%，编码成%XY 格式
例如
在这里插入图片描述
"+" 被转义成了 "%2B"
urldecode 就是 urlencode 的逆过程;
HTTP协议版本差异
HTTP协议自1991年诞生以来经历了多个版本的演进，每个版本都带来了显著的改进。以下是各主要版本的核心差异和技术特点：
- HTTP/0.9 (1991)
原始版本，极度简单：
- 只有GET方法
- 无HTTP头、状态码或错误处理
- 响应只能是HTML格式
http
GET /index.html
<HTML>...</HTML>- HTTP/1.0 (1996)
正式标准化，引入关键特性：
- 新增HEAD/POST方法
- 引入HTTP头（Header）概念
- 状态码（如200/404）
- 支持Content-Type（可传输非HTML内容）
http
GET /index.html HTTP/1.0
User-Agent: Mozilla/4.0
HTTP/1.0 200 OK
Content-Type: text/html
Content-Length: 1234
<html>...</html>- HTTP/1.1 (1997)
现代Web基础，主要改进：
| 特性 | 说明 |
|---|---|
| 持久连接 | 默认Connection: keep-alive |
| 管道化(Pipelining) | 支持请求批量发送（但存在队头阻塞） |
| 分块传输编码 | Transfer-Encoding: chunked |
| 缓存控制 | Cache-Control头 |
| 主机头 | 支持虚拟主机（Host头） |
示例改进：
http
GET /index.html HTTP/1.1
Host: www.example.com
Connection: keep-alive
User-Agent: Mozilla/5.0- HTTP/2 (2015)
革命性升级，基于Google SPDY：
| 特性 | 优势 |
|---|---|
| 二进制协议 | 替代文本协议，解析更高效 |
| 多路复用 | 解决队头阻塞，单连接并行传输 |
| 头部压缩(HPACK) | 减少冗余头部传输 |
| 服务器推送 | 主动推送关联资源 |
| 流优先级 | 智能资源调度 |
技术实现：
流1: GET / 流2: GET /css 流3: GET /js 推送/css 客户端 服务器
- HTTP/3 (2022)
基于QUIC协议，解决TCP限制：
| 特性 | 突破 |
|---|---|
| UDP传输 | 避免TCP队头阻塞 |
| 0-RTT连接 | 加速重复访问 |
| 改进的多路复用 | 单个丢包不影响其他流 |
| 内建加密 | 默认TLS 1.3 |
| 连接迁移 | IP变更不影响连接（如WiFi切4G） |
性能对比：
bash
# 网络延迟100ms、丢包率2%环境下：
HTTP/1.1: 加载时间 4.3s
HTTP/2: 加载时间 3.1s
HTTP/3: 加载时间 1.8s关键差异总结
| 版本 | 传输层 | 核心优势 | 主要缺陷 |
|---|---|---|---|
| 1.0 | TCP | 基础标准化 | 每个资源需要独立TCP连接 |
| 1.1 | TCP | 持久连接、管道化 | 队头阻塞、头部冗余 |
| 2 | TCP | 多路复用、头部压缩 | TCP层队头阻塞 |
| 3 | QUIC | 0-RTT、无队头阻塞、连接迁移 | 中间设备支持度仍在提升 |
协议选择建议
- 传统系统：HTTP/1.1（兼容性最好）
- 现代Web应用：HTTP/2（主流支持，85%+浏览器覆盖率）
- 移动端/高延迟场景：HTTP/3（逐步普及，Cloudflare等已支持）
Nginx配置示例：
nginx
# 同时支持HTTP/1.1和HTTP/2
listen 443 ssl http2;
# 启用HTTP/3（需Nginx 1.25+）
listen 443 quic reuseport;
add_header Alt-Svc 'h3=":443"';各版本HTTP协议在保持向后兼容的同时不断优化性能，理解这些差异有助于开发者针对不同场景做出最佳技术选型。
HTTP协议格式
• 首行: [版本号] + [状态码] + [状态码解释]
• Header: 请求的属性, 冒号分割的键值对;每组属性之间使用\r\n 分隔;遇到空行表示 Header 部分结束
• Body: 空行后面的内容都是 Body. Body 允许为空字符串. 如果 Body 存在, 则在Header 中会有一个 Content-Length 属性来标识 Body 的长度; 如果服务器返回了一个 html 页面, 那么 html 页面内容就是在 body 中.