【网络编程】HTTP(超文本传输协议)详解

🦄个人主页:修修修也

🎏所属专栏:网络编程

⚙️操作环境:Visual Studio 2022

目录

📌HTTP定义

📌HTTP工作原理

1.客户端发起请求:

2.服务器处理请求:

3.客户端处理响应:

📌HTTP关键特性

🎏HTTP请求方法

📖Get(获取资源)

📖Post(提交消息)

📖Put(修改数据)

📖Delect(删除数据)

🎏HTTP中Cookie、Session和Token

📖为什么需要Cookie和Session

📖Cookie

📖Session

📖Session-Cookie的典型场景

📖Token

📖小结

📌HTTP版本演进

🎏HTTP/0.9 [1991年]

🎏HTTP/1.0 [1996年]

🎏HTTP/1.1 [1997年]

🎏HTTP/2.0 [2015年]

🎏HTTP/3.0 [2022年]

📌HTTPS

🎏核心原理

🎏TLS握手过程

结语

📌HTTP定义

HTTP（HyperText Transfer Protocol）是一种应用层协议, 用于在客户端和服务器之间传输超文本(如网页, 图片, 视频等)。具备以下核心特性:

无状态协议: 每次请求独立, 服务器不保存客户端状态(需通过Cookie/Session扩展状态管理)。
请求-响应模型: 客户端发起请求(Request), 服务器返回响应(Response)。
基于TCP/IP: 默认端口80(HTTP)或443(HTTPS), 依赖TCP保证可靠传输。
可扩展性: 通过Header字段自定义元数据, 支持缓存, 认证, 压缩等功能。

📌HTTP工作原理

1.客户端发起请求:

输入URL, 浏览器解析域名并建立TCP连接。
发送HTTP请求报文, 包含方法, 路径, 协议版本, Headers等。

2.服务器处理请求:

解析请求，定位资源，执行后端逻辑（如查询数据库）。
返回HTTP响应报文，包含状态码（如200）、Headers（如Content-Type）、Body（如HTML内容）。

3.客户端处理响应:

浏览器解析响应内容(如渲染HTML), 关闭或复用TCP连接。

📌HTTP关键特性

🎏HTTP请求方法

📖Get(获取资源)

作用：获取指定资源（通常不修改服务器数据）。
特点：
安全：不改变服务器状态。
幂等：多次请求结果相同。
无请求体, 数据通过URL参数传递（如?id=123）。

适用场景: 加载页面内容, 获取静态资源等。

📖Post(提交消息)

作用：向服务器提交数据（通常用于创建资源或触发操作）。
特点：
非安全：可能修改服务器状态。
非幂等：重复提交可能产生不同结果（如重复创建订单）。
有请求体, 数据通过请求体（Body）传输，支持多种格式（JSON、表单等）。

适用场景: 提交表单(如用户注册), 上传文件等。

📖Put(修改数据)

作用：替换或完整更新指定资源。
特点：
非安全：修改服务器状态。
幂等：多次请求效果等同于一次（如重复更新同一资源）。
有请求体, 需提供完整的资源数据。

适用场景: 更新用户全部信息, 替换已有文件等。

📖Delect(删除数据)

作用：删除指定资源。
特点：
非安全：修改服务器状态。
幂等：删除不存在资源仍返回相同结果。

适用场景: 删除数据库记录, 移除服务器上的文件。

🎏HTTP中Cookie、Session和Token

📖为什么需要Cookie和Session

HTTP 是无状态协议，每个请求独立处理，服务器默认不会记录之前的请求信息。这导致以下挑战：

无法跟踪用户身份：用户登录后，服务器不知道后续请求来自同一用户。
无法保存用户操作状态：例如购物车内容、页面偏好设置等无法跨请求保留。
无法实现个性化服务：无法根据用户历史行为动态调整内容（如推荐系统）。

Cookie 和 Session 的共同目标：在无状态的 HTTP 协议上实现有状态的用户会话管理。

📖Cookie

Cookie解决客户端状态存储, 主要解决用户偏好（如语言、主题）或临时数据（如未登录时的购物车）需长期或短期保存的问题。
解决方案: Cookie 将数据存储在客户端（浏览器），每次请求自动携带。
Cookie解决服务器需要识别同一用户的多次请求的问题。
解决方案: Cookie 存储 Session ID，作为用户身份的唯一标识。

📖Session

Session解决用户的敏感信息（如登录凭证、权限角色）不能暴露在客户端的问题。
解决方案:Session 数据存储在服务器（内存、数据库或缓存如 Redis），仅通过 Cookie 传递安全的 Session ID。
Session解决Cookie 有大小限制（约 4KB），无法存储复杂数据的问题。
解决方案: Session 在服务端存储用户完整数据（如购物车商品列表、多步骤表单填写内容）。
Session解决客户端数据易被篡改（如用户伪造身份提升权限）的问题。
解决方案: Session ID 通过 HttpOnly 和 Secure Cookie 传输，防止 XSS 和中间人攻击。服务端验证 Session ID 合法性，绑定 IP 或设备指纹防止盗用。

下面介绍一下用户登录时Cookie和Session的协同工作场景

1.登录请求(http请求信息):
POST /login HTTP/1.1
Content-Type: application/json{"username": "alice", "password": "123456"}
2.服务器验证：生成 Session 数据并返回 Session ID 到 Cookie。
HTTP/1.1 200 OK
Set-Cookie: session_id=xyz789; HttpOnly; Secure; Path=/
3.后续请求：浏览器自动携带 Session ID，服务器查询 Session 数据识别用户。
GET /dashboard HTTP/1.1
Cookie: session_id=xyz789

📖Token

由于服务器可能会有繁忙需要将部分用户转移给别的服务器分担压力的情况, 那保存在A服务器的Session_id就要一起转交给B服务器, 否则用户发新的请求就还需要重新登陆验证, 这样非常麻烦, 如果把Session_id都统一存放在数据库里呢, 又怕数据库过载不安全, 于是为了解决这个问题, 又引入了新的解决方案, 就是Token。

Token（令牌）是一种用于身份验证和授权的凭证，通常由服务器生成并返回给客户端。客户端在后续请求中携带 Token，供服务器验证身份。

核心特点：

无状态：服务器无需存储 Token，验证基于签名或加密。
自包含：Token 可携带用户信息（如用户ID、权限）。
跨域友好：适合前后端分离、微服务架构。

常见类型：

JWT（JSON Web Token）：标准化、自包含的 Token 格式。
OAuth Token：用于第三方授权（如使用微信登录）。
Access Token/Refresh Token：短效令牌与长效刷新令牌组合。

📖小结

Session是诞生并保存在服务器里的, 由服务器主导一切, 而Cookie则是一种数据载体, 把Session放入Cookie中送到客户端那边, Cookie跟随每个HTTP请求发送出去, 以便服务器识别用户身份。

Token是诞生在服务器, 但是保存在浏览器这边的, 由客户端主导一切, 可以放在Cookie或者Storage里面, 持有Token就像持有"令牌"一样可以允许访问服务器。

📌HTTP版本演进

🎏HTTP/0.9 [1991年]

特点：

极简设计：仅支持 GET 方法，无请求头（Header）和状态码。
纯文本传输：直接返回 HTML 内容，无图片、CSS 等资源支持。

局限：

无错误处理，无法扩展。

🎏HTTP/1.0 [1996年]

核心改进：
引入请求头/响应头：支持元数据（如 Content-Type、User-Agent）。
状态码：如 200 OK、404 Not Found。
多方法支持：新增 POST、HEAD 方法。
版本标识：请求中需声明 HTTP/1.0。

问题：
短连接：每个请求需新建 TCP 连接（三次握手开销大）。
无 Host 头：无法支持虚拟主机（单 IP 多域名）。

🎏HTTP/1.1 [1997年]

里程碑改进：
持久连接（Keep-Alive）：默认复用 TCP 连接，通过 Connection: keep-alive 管理。
管道化（Pipelining）：允许连续发送多个请求（但响应必须按序返回，存在队头阻塞）。
Host 头：支持单服务器托管多域名。
缓存控制：引入 Cache-Control、ETag 等头字段。
分块传输：通过 Transfer-Encoding: chunked 支持流式传输。

遗留问题：
队头阻塞（Head-of-Line Blocking）：管道化未完全解决请求/响应队列阻塞。
头部冗余：重复头部字段（如 Cookie）浪费带宽。

🎏HTTP/2.0 [2015年]

核心优化：
二进制分帧（Binary Framing）：将数据拆分为更小的二进制帧，提升传输效率。
多路复用（Multiplexing）：单连接并行处理多个请求/响应，彻底解决队头阻塞。
头部压缩（HPACK）：减少头部大小（如静态表、动态表编码）。
服务器推送（Server Push）：主动推送客户端可能需要的资源（如 CSS/JS 文件）。
流优先级：允许客户端指定资源加载优先级。

示例：
一个 TCP 连接同时传输 HTML、CSS、图片，无需等待前序请求完成。

局限：
TCP 层队头阻塞：若单个 TCP 包丢失，所有流需等待重传。

🎏HTTP/3.0 [2022年]

革命性变革：
基于 QUIC 协议：弃用 TCP，改用 UDP 实现可靠传输，内置加密（TLS 1.3）。
解决 TCP 队头阻塞：每个流独立传输，丢包仅影响单个流。
0-RTT 连接：首次连接即可发送数据（复用之前会话的加密信息）。
连接迁移：网络切换（如 Wi-Fi → 4G）时无需重建连接。

优势场景：
高延迟网络（如卫星通信）、移动网络（频繁切换基站）。

挑战：
运营商对 UDP 的支持策略可能影响普及。

📌HTTPS

HTTPS（HyperText Transfer Protocol Secure）是 HTTP 的安全版本，通过在 HTTP 和 TCP 层之间引入 SSL/TLS 加密层，解决 HTTP 明文传输的安全隐患，保护数据隐私和完整性。默认端口: 443。

🎏核心原理

加密通信

混合加密机制：
非对称加密：用于密钥交换（如 RSA、ECDHE），确保初始握手安全。
对称加密：用于数据传输（如 AES、ChaCha20），提高加密效率。

示例：客户端生成临时密钥（Pre-Master Secret），用服务器公钥加密后传输，双方基于此生成对称加密密钥。

身份验证

数字证书：由受信任的证书颁发机构（CA）签发，包含服务器公钥和域名信息。
验证流程：
客户端验证证书是否过期、域名匹配、签发机构可信。
检查证书链是否完整（根证书 → 中间证书 → 服务器证书）。

数据完整性

MAC（消息认证码） 或 HMAC：防止数据在传输中被篡改。
TLS 记录协议：对每个数据块计算哈希值，接收方验证一致性。

🎏TLS握手过程

一次完整的 HTTPS 连接需经历以下步骤（以 TLS 1.3 为例）：

Client Hello
客户端发送支持的 TLS 版本、加密套件列表、随机数（Client Random）。

Server Hello
服务器选择加密套件，发送随机数（Server Random）、证书、公钥。
TLS 1.3 优化：省略不必要的协商步骤（如密钥交换参数）。

密钥交换
客户端生成 Pre-Master Secret，用服务器公钥加密后发送。
双方基于 Client Random、Server Random 和 Pre-Master Secret 生成会话密钥。

完成握手
双方发送加密的 Finished 消息，确认握手成功，后续数据均加密传输。

握手耗时优化：

Session Resumption：复用之前会话的密钥（通过 Session ID 或 Session Ticket）。
0-RTT（TLS 1.3）：首次连接即可发送加密数据，降低延迟。