在 4 年前，Istio 让我眼前一亮的特性莫过于应用无关的流量拦截和透明代理。这为低成本进入 Service Mesh 时代大大降低了开发门槛。也是很多公司引入 Istio 的主要原因之一。

故事发生在公元 2022 年的夏天。上帝（化名）在上线流量测试中，发现在未引入 Istio 前正常 HTTP 200 的请求，引入 Istio Gateway 后变为 HTTP 400 了。而出现问题的流量均带有不合 HTTP 规范的 HTTP Header。如冒号前多了个 空格：

注，原文来自 [链接] 。如你看到的转载图片不清，请回到原文。为何要了解 upstream/downstream 事件驱动协作下的 HTTP 反向代理流程逆向工程与云原生现场分析 系列介绍HTTP 反向代理的总流程Downstream Read Request 模块协作Upstream Write Request 模块协作Upstream Read Response 模块协作Downstream Write Response ...

在上一篇 逆向工程与云原生现场分析 Part2 —— eBPF 跟踪 Istio/Envoy 之启动、监听与线程负载均衡 中，介绍了 如何用 bpftrace 去跟踪分析 Envoy Listener 的 socket 监听，和监听是如何分配到 worker 线程的。

在上一篇 逆向工程与云原生现场分析 Part1 —— eBPF 跟踪 Istio/Envoy 之学步 中，介绍了如何入门 bpftrace 跟踪 Envoy。这次我们来次较深度的历险。trace 观察一下 envoy 的启动、worker 线程启动与初始化、socket 监听。

在 200x 年时代，服务端软件架构，组成的复杂度，异构程度相对于云原生，可谓简单很多。那个年代，大多数基础组件，要么由使用企业开发，要么是购买组件服务支持。