3. 请求生命周期：从客户端到服务端的完整路径、Sidecar拦截与转发机制、协议支持（HTTP/gRPC/TCP）
理解 Istio 服务网格中的请求生命周期，是进行延迟诊断与性能调优的基础。一个请求从客户端发出到被服务端处理，中间经历了复杂的网络路径和 Sidecar 代理的多次拦截与转发。本章将拆解这一完整路径，深入分析 Sidecar 的透明拦截机制，并梳理 Istio 对不同协议（HTTP/gRPC/TCP）的支持差异。
3.1 请求完整路径：从客户端到服务端
在 Istio 网格中，一个典型的请求会经历以下 7 个关键阶段。每个阶段都可能成为延迟的瓶颈点。
关键路径速览： 客户端 → 客户端 Sidecar (inbound) → 客户端 Sidecar (outbound) → 网络 → 服务端 Sidecar (inbound) → 服务端进程 → 服务端 Sidecar (outbound) → 响应返回。
3.2 Sidecar 拦截与转发机制
Sidecar 代理（Envoy）的透明拦截是 Istio 的核心能力。它通过 iptables 规则将进出 Pod 的流量全部重定向到 Envoy 的监听端口，从而实现无侵入式的流量管理。
3.2.1 iptables 透明劫持原理
当 Sidecar 被注入到 Pod 时，Init 容器会配置以下核心 iptables 规则：
| 链 (Chain) | 规则描述 | 目标端口 |
|---|---|---|
| OUTPUT | 拦截 Pod 内进程发出的出站流量（目标非 localhost） | 重定向到 Envoy 的 15001 端口 |
| PREROUTING | 拦截进入 Pod 网络命名空间的入站流量 | 重定向到 Envoy 的 15006 端口 |
| INPUT | 允许 Envoy 自身流量绕过劫持 | 直接放行 |
诊断提示： 如果发现请求延迟异常，可以进入 Sidecar 容器执行
iptables -t nat -L -n -v 检查规则计数。如果某个链的 pkts 计数远低于预期，说明流量可能未被正确劫持，导致 Sidecar 未参与请求处理。
3.2.2 Envoy 内部转发流程
Envoy 接收到被劫持的流量后，会经历以下内部处理管线：
3.3 协议支持：HTTP/gRPC/TCP
Istio 对不同协议的支持深度不同，这直接影响延迟诊断的维度。下表总结了三种核心协议在 Istio 中的行为差异：
| 特性 | HTTP/1.1 & HTTP/2 | gRPC | TCP (原始) |
|---|---|---|---|
| 协议识别 | 自动检测（基于端口或 ALPN） | 自动检测（基于 HTTP/2 + Content-Type） | 需显式声明（ServerFirst/ClientFirst） |
| 7层路由 | 支持（Header、URI、Method） | 支持（基于 gRPC Service/Method） | 不支持（仅 4 层路由） |
| 重试策略 | 支持（可配置重试次数、超时） | 支持（需注意幂等性） | 不支持 |
| 故障注入 | 支持（延迟、中断） | 支持（延迟、中断） | 仅支持中断 |
| 遥测指标 | 丰富（请求数、延迟、大小、状态码） | 丰富（同 HTTP，含 gRPC 状态码） | 有限（字节数、连接数、延迟） |
| 延迟诊断粒度 | 精细（可追踪到单个请求的每个阶段） | 精细（支持 Streaming 场景） | 粗粒度（仅连接级） |
3.3.1 HTTP 协议：最丰富的可观测性
对于 HTTP 流量，Envoy 可以解析请求头、URI、状态码，并生成详细的访问日志和指标。延迟诊断时可以依赖 envoy_cluster_upstream_rq_time 等指标，按百分位（P50/P95/P99）分析。
# 查看 HTTP 请求延迟分布（PromQL 示例）
histogram_quantile(0.99, sum(rate(istio_request_duration_milliseconds_bucket{reporter="destination",destination_service="reviews.default.svc.cluster.local"}[1m])) by (le))
3.3.2 gRPC 协议：长连接与 Streaming 挑战
gRPC 基于 HTTP/2，使用长连接。延迟诊断时需注意：
- 连接复用：多个 gRPC 调用共享一个 TCP 连接，单个连接的延迟抖动会影响所有复用请求。
- Streaming 场景：延迟指标通常以“消息”为单位，而非“请求”。需要关注
istio_request_messages_total和istio_response_messages_total。 - gRPC 状态码：
Unavailable或DeadlineExceeded通常指向网络或 Sidecar 处理超时。
常见陷阱： 在 gRPC 场景下，如果客户端设置了较短的
deadline，而 Sidecar 的 mTLS 握手时间较长（例如首次连接），可能导致大量 DeadlineExceeded 错误。此时应检查 PILOT_SIDECAR 的证书预热时间。
3.3.3 TCP 协议：黑盒模式
对于原始 TCP 流量（如 Redis、MySQL 协议），Istio 只能提供连接级的可观测性。延迟诊断主要依赖：
- 连接建立延迟：
istio_tcp_connections_opened_total和istio_tcp_connections_closed_total。 - 吞吐量：
istio_tcp_sent_bytes_total和istio_tcp_received_bytes_total。 - 连接持续时间：通过访问日志中的
duration字段推断。
由于无法解析应用层协议，TCP 流量的延迟瓶颈定位通常需要结合服务端和客户端的应用日志进行交叉分析。