当前位置：首页 > news >正文

【计算机基础】网络系列（一）HTTP

news 2025/9/28 5:37:14

网络模型基础

OSI与TCP/IP模型对比

OSI七层参考模型：

应用层、表示层、会话层、传输层、网络层、数据链路层、物理层

TCP/IP四层参考模型：

应用层（HTTP、DNS、FTP等）
传输层（TCP、UDP）
网络层（IP）
网络接口层

应用层协议概览

常见的应用层协议包括：HTTP、HTTPS、DNS、FTP、SMTP等，它们构成了互联网应用的基础通信标准。

HTTP报文结构详解

请求报文组成

请求行：包含请求方法、URL和HTTP版本
请求头部：Host、User-Agent、Content-Type等元数据
空行：分隔头部和主体
请求体：传输的数据内容（如POST请求的参数）

响应报文组成

状态行：HTTP版本、状态码和状态信息
响应头部：Content-Type、Content-Length等元数据
空行：分隔头部和主体
响应体：服务器返回的实际内容

HTTP状态码

状态码类别

1xx：信息性状态码
2xx：成功状态码（如200 OK）
3xx：重定向状态码（301永久重定向，302临时重定向）
4xx：客户端错误（404未找到，405方法不支持）
5xx：服务器错误（500内部错误，502网关错误，503服务不可用）

运维实践：5xx错误排查

500错误：通常表示应用代码问题，需检查服务器日志
503错误：往往由服务器过载引起，需要检查资源使用情况和服务进程状态

HTTP请求方法

GET：请求资源，参数在URL中，可缓存，幂等操作
POST：提交数据，参数在请求体中，非幂等
PUT：更新资源
DELETE：删除资源
HEAD：获取资源元数据

GET与POST关键区别

安全性：GET参数暴露在URL中，POST相对安全
缓存性：GET可被缓存，POST通常不缓存
幂等性：GET是幂等的，POST非幂等
数据长度：GET有长度限制，POST无限制

HTTP/1.1核心技术

请求拆包机制

通过Content-Length头字段明确指示请求正文长度，确保完整传输。同时支持断点续传功能，提升大文件传输体验。

HTTPS安全机制

HTTP与HTTPS核心区别

安全性：HTTPS通过SSL/TLS加密传输数据
端口号：HTTP使用80端口，HTTPS使用443端口
证书要求：HTTPS需要CA颁发的数字证书验证身份

TLS握手过程详解

ClientHello：客户端发送支持协议版本、随机数和密码套件
ServerHello：服务器确认参数并发送证书
密钥交换：客户端生成预主密钥并用服务器公钥加密
完成握手：双方独立计算会话密钥，开始加密通信

防范中间人攻击机制

加密保护：攻击者无法获得服务器私钥，无法解密数据
身份验证：数字证书确保通信对方身份真实性

HTTP版本演进对比

HTTP/1.1 → HTTP/2.0重大改进

二进制协议：提高解析效率
头部压缩：采用HPACK算法减少冗余
多路复用：解决队头阻塞问题

头部压缩

HTTP/2使用HPACK算法，客户端和服务器维护共同的头信息表，通过发送索引号而非完整字段，显著减少带宽占用。

多路复用

允许单个TCP连接上并行传输多个请求/响应，彻底解决HTTP/1.1的队头阻塞问题，减少TCP连接数量，提升效率。

HTTP/2.0的局限性

虽然解决应用层队头阻塞，但底层仍依赖TCP协议，存在传输层队头阻塞问题，这促使了HTTP/3的发展。

HTTP/3.0的革命性变革

基于QUIC协议（运行在UDP之上），从传输层解决队头阻塞，内置TLS加密，显著降低连接建立延迟。

TCP连接中断条件

主动关闭连接
超时重传达到最大次数
空闲超时

HTTP、Socket与TCP关系澄清

TCP：传输层协议，保证可靠连接
HTTP：应用层协议，定义数据格式和规则
Socket：编程接口，连接应用层与传输层

HTTP的无状态特性与状态保持

HTTP无状态本质

HTTP协议本身是无状态的，每个请求相互独立，服务器不保留客户端状态信息。这种设计简化了服务器架构，但无法满足需要状态保持的Web应用需求。

Cookie与Session对比

特性	Cookie	Session
存储位置	客户端浏览器	服务器端
安全性	较低，用户可查看修改	较高，敏感数据在服务器
存储容量	4KB左右，数量有限	理论上无限制
生命周期	可设置持久性或会话级	通常会话级，可设置超时
网络传输	每次请求自动携带	仅传输Session ID

Cookie禁用场景下的解决方案

当用户禁用Cookie时，Session无法正常使用，但可通过URL重写技术作为备选方案：

在所有链接和表单中手动附加Session ID参数
缺点：安全性低，实现复杂，现代应用通常要求启用Cookie

Session集群优化方案

为解决Session带来的服务器压力，常见优化策略：

水平扩展：采用共享存储方案

Redis集群（主流方案，高性能）
数据库存储（适合小型应用）
Zookeeper（强一致性场景）

资源优化：

设置合理超时时间
减少Session数据量
客户端存储非敏感信息

Redis Session集群

工作流程：
1. 所有Web服务器将Session数据序列化存入Redis集群
2. 负载均衡器将请求分发到任意服务器
3. 服务器通过Session ID从Redis获取统一会话数据

技术要点：
- 采用哨兵模式保证高可用性
- 设置TTL自动过期机制
- 使用MsgPack等高效序列化协议

客户端存储方案对比

LocalStorage与Cookie差异

维度	Cookie	LocalStorage
生命周期	可设置过期时间	永久存储，手动删除
存储容量	几KB	几MB
网络传输	每次请求自动发送	仅本地存储
安全性	较低，易被窃取	相对安全

Cookie适用场景：跨域访问、会话管理、设置过期时间

LocalStorage适用场景：大数据存储、永久缓存、同域页面共享

JWT令牌

JWT由三部分组成，使用点号分隔：

Header.Payload.Signature

头部(Header)：令牌类型和签名算法
载荷(Payload)：用户声明信息（用户ID、角色等）
签名(Signature)：验证令牌完整性和真实性

JWT与传统Session对比优势

分布式友好：无需共享Session存储，适合微服务架构
扩展性强：任何服务器都可独立验证令牌
跨域支持：天然支持跨域身份验证

安全性机制

数字签名确保令牌完整性
只有持有正确密钥的服务器才能验证
比传统Cookie更安全的身份验证方式

JWT在集群部署中的应用价值

集群部署挑战：多服务器间Session同步复杂
JWT解决方案：令牌包含完整身份信息，每台服务器可独立验证，实现无状态水平扩展

JWT实践中的挑战与解决方案

令牌撤销问题

挑战：JWT签发后无法主动失效
解决方案：

短有效期+刷新令牌：

访问令牌短期有效（15-60分钟）
刷新令牌长期有效，服务器端可撤销
退出登录时吊销刷新令牌

令牌黑名单机制：

维护失效令牌黑名单（Redis）
每次验证检查黑名单状态
牺牲部分无状态性换取控制力

数据一致性维护

问题：Payload信息过期导致客户端服务端数据不一致
最佳实践：

避免在JWT中存储频繁变更的数据
重要信息变更时主动触发令牌刷新
客户端检测到数据过期主动重新认证

JWT安全防护策略

令牌泄露应对：

及时标记失效令牌、主动刷新令牌机制、黑名单管理可疑令牌。

前端存储方案对比：

存储方式	优点	缺点	适用场景
LocalStorage	容量大，不随请求发送	XSS风险高	非敏感数据
SessionStorage	标签页级隔离	刷新需重新认证	临时会话
HttpOnly Cookie	防XSS，HTTPS安全	容量小，CSRF风险	高安全要求

单点登录(SSO)实现方案

关联服务自动登录技术

集中式Session存储：

所有服务共享持久化Session存储
优点：架构清晰
缺点：单点故障风险，工程量大

JWT无状态方案：

令牌包含完整身份信息
服务间无需Session同步
适合微服务架构

现代通信协议

HTTP与RPC的互补关系

HTTP：对外标准化服务，浏览器兼容
RPC：内部微服务通信，高性能调用
典型组合：对外HTTP API，内部gRPC通信

WebSocket实时通信优势

全双工通信：支持服务器主动推送
适用场景：实时聊天、在线游戏、高频双向通信
与HTTP对比：HTTP半双工，WebSocket全双工

DNS

DNS层次结构

根DNS服务器(.) → 顶级域服务器(.com) → 权威DNS服务器(server.com)

DNS查询过程

本地缓存查询：检查浏览器和系统缓存
本地DNS服务器：ISP提供的解析服务
递归查询链：根服务器→顶级域→权威服务器
结果缓存：各级服务器缓存结果提高效率

DNS协议技术细节

主要协议：UDP（快速响应，头部小）
TCP备用：数据超512字节或需要可靠传输时
端口号：53

Nginx负载均衡策略

常用算法对比

算法	原理	适用场景
轮询	依次分配请求	简单均衡
加权轮询	按权重分配	服务器性能不均
IP哈希	同一IP固定服务器	会话保持
URL哈希	相同URL固定服务器	缓存优化
最短响应时间	响应快的优先	性能优化