2. HTTP协议与网关基础
2.1 HTTP请求/响应模型
HTTP(HyperText Transfer Protocol)是网关架构的通信基石。网关作为客户端与后端服务之间的中间层,必须深刻理解HTTP请求/响应模型的完整生命周期。一个标准的HTTP事务包含以下阶段:
- 建立连接:客户端(浏览器、移动App、其他服务)与网关建立TCP连接(默认端口80/443)。
- 发送请求:客户端向网关发送HTTP请求报文,包含请求行、请求头、空行和请求体。
- 网关处理:网关解析请求,执行路由、认证、限流、日志等中间件逻辑。
- 转发请求:网关将请求转发至上游后端服务(Upstream)。
- 接收响应:网关接收后端返回的HTTP响应报文。
- 后处理与返回:网关对响应进行加工(如添加安全头、压缩、缓存),最终返回给客户端。
关键认知: 在网关架构中,HTTP请求/响应模型从“端到端”变为“端到网关到端”。网关必须完整处理两个独立的HTTP事务:客户端↔网关、网关↔后端。
2.2 HTTP请求报文结构
| 组成部分 | 示例 | 说明 |
|---|---|---|
| 请求行 | GET /api/users HTTP/1.1 |
方法、URI、协议版本 |
| 请求头 | Host: example.comAuthorization: Bearer <token> |
元数据,包含认证、内容类型、缓存控制等 |
| 空行 | \r\n |
分隔头部与消息体 |
| 请求体 | {"name":"Alice"} |
POST/PUT/PATCH 方法携带的数据 |
2.3 HTTP响应报文结构
| 组成部分 | 示例 | 说明 |
|---|---|---|
| 状态行 | HTTP/1.1 200 OK |
协议版本、状态码、状态描述 |
| 响应头 | Content-Type: application/jsonX-Request-Id: abc123 |
元数据,包含内容类型、缓存策略、自定义头 |
| 空行 | \r\n |
分隔头部与消息体 |
| 响应体 | {"id":1,"name":"Alice"} |
返回的实际数据 |
网关实践: 在Go语言中,
net/http 标准库的 http.Request 和 http.ResponseWriter 分别对应请求解析与响应构建。网关开发中常使用 httputil.ReverseProxy 简化反向代理实现。
2.4 反向代理原理
反向代理(Reverse Proxy)是网关最核心的技术模式。与正向代理(为客户端代理)不同,反向代理代表服务器端接收请求,并将请求分发到内部网络中的后端服务。其核心流程如下:
- 接收请求:反向代理监听公网端口,接收客户端请求。
- 请求解析:解析请求的Host、Path、Headers、Query参数。
- 路由决策:根据路由规则(如路径前缀、域名、Header匹配)选择目标后端。
- 连接复用:维护与后端服务的连接池,减少TCP握手开销。
- 请求转发:将原始请求(或修改后的请求)发送到选定的后端。
- 响应回传:接收后端响应,可选地修改响应头/体,返回给客户端。
// Go 标准库反向代理核心示例
package main
import (
"net/http"
"net/http/httputil"
"net/url"
)
func main() {
target, _ := url.Parse("http://localhost:8080")
proxy := httputil.NewSingleHostReverseProxy(target)
http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
// 可在转发前修改请求
r.Header.Set("X-Forwarded-For", r.RemoteAddr)
proxy.ServeHTTP(w, r)
})
http.ListenAndServe(":9090", nil)
}
安全注意: 反向代理必须验证并清理
X-Forwarded-For、X-Real-IP 等头部,防止IP伪造。同时应限制代理仅转发到内部网络,避免SSRF攻击。
2.5 网关核心职责
现代API网关承担了远超“简单转发”的职责。以下是网关在权限审计与事务边界场景下的核心职责清单:
| 职责领域 | 具体职责 | 权限审计相关性 |
|---|---|---|
| 路由与负载均衡 | 根据请求特征分发到不同后端服务 | 路由规则可绑定权限策略 |
| 身份认证 | 验证JWT、OAuth2 Token、API Key | 认证是审计的前提 |
| 权限授权 | RBAC/ABAC策略执行、角色校验 | 核心审计点:谁、对什么、做什么 |
| 请求审计 | 记录请求/响应日志、操作轨迹 | 审计日志的采集点 |
| 限流与熔断 | 防止滥用、保护后端服务 | 异常流量可能预示攻击 |
| 协议转换 | HTTP ↔ gRPC、HTTP/1.1 ↔ HTTP/2 | 转换过程需保持审计上下文 |
| 响应缓存 | 缓存幂等GET请求的响应 | 缓存命中时仍需记录审计 |
| 安全防护 | SQL注入检测、XSS过滤、CORS策略 | 安全事件应触发审计告警 |
2.6 常见网关模式
根据架构复杂度与业务需求,网关通常采用以下几种模式。本课程重点聚焦反向代理网关与中间件链网关,因为它们最适合嵌入权限审计与事务边界逻辑。
- 反向代理网关:最基础的网关模式,使用
httputil.ReverseProxy或 Nginx 实现。适合简单的路由转发场景,权限逻辑通常通过外部插件或独立服务实现。 - 中间件链网关:将认证、授权、审计、限流等逻辑封装为中间件,按顺序组成处理链。Go 生态中
negroni、alice、chi等库均支持此模式。这是本课程推荐的核心模式。 - API组合网关:将多个微服务的响应聚合成一个响应返回给客户端。适合BFF(Backend For Frontend)场景,但审计粒度需要精细设计。
- 服务网格Sidecar网关:以Sidecar模式部署在Pod内,如Envoy、Linkerd。适合Kubernetes环境,但Go自定义扩展相对复杂。
- 边缘网关:部署在集群入口,处理南北向流量。通常与CDN、WAF配合使用,如Kong、APISIX。
课程选型: 本实战课程采用中间件链网关模式,基于Go标准库
net/http 构建自定义中间件链。该模式在灵活性、可审计性、事务边界控制方面表现最优,且不依赖第三方网关框架。
2.7 网关模式对比
| 模式 | 适用场景 | 权限审计集成难度 | 事务边界支持 | Go实现复杂度 |
|---|---|---|---|---|
| 反向代理网关 | 简单路由转发 | 中(需外部插件) | 低 | 低 |
| 中间件链网关 | 权限审计、限流、日志 | 低(原生支持) | 高 | 中 |
| API组合网关 | BFF、数据聚合 | 高(需跨服务审计) | 中 | 高 |
| 服务网格Sidecar | Kubernetes微服务 | 中(依赖控制面) | 中 | 高 |
| 边缘网关 | 南北向流量入口 | 中(配置驱动) | 低 | 低(配置为主) |
实战建议: 对于权限审计网关与事务边界场景,中间件链网关是最佳选择。它允许你在Go中精确控制每个请求的处理顺序,在认证之后、转发之前插入审计逻辑,并在整个请求生命周期内维护事务上下文。