测试网络【免费下载链接】toxiproxy:alarm_clock: :fire: A TCP proxy to simulate network and system conditions for chaos and resiliency testing项目地址https://gitcode.com/gh_mirrors/to/toxiproxy点击查看免费下载Toxiproxy 是一款面向混沌与韧性测试的 TCP 代理其核心扩展点在于Toxic毒药——一段附着在代理链路上、可以改写数据流向与内容的小插件。本指南以仓库 _examples/toxics 中的两个完整示例为主线带你从零实现一个自定义 Toxic先用DebugToxic把经过代理的字节流以十六进制打印出来再通过HttpToxic拦截并改写 HTTP 响应头。读完本文你将掌握Toxic接口、ToxicStub管道模型、stream包的读写抽象以及自定义服务端组装方式能够直接在自己的项目中编写、注册并验证新的 Toxic。一、示例概览为什么需要自定义 ToxicToxiproxy 内置了latency、bandwidth、timeout、reset_peer、limit_data等常用故障注入 Toxic见 toxics 目录但真实场景中的故障形态往往是业务特有的可能需要在特定协议字段上做篡改、按业务规则丢弃数据、或者把原始流量打印出来用于调试。此时就需要自定义 Toxic。仓库在 _examples/toxics 中提供了两个可直接go run的示例debug_toxic.go实现debugToxic将经过代理的数据以十六进制hex格式打印到日志http_toxic.go实现httpToxic解析经过代理的 HTTP 响应并改写其中的响应头。两者都是独立可运行的完整程序——它们不依赖官方toxiproxy-server二进制而是自己组装一个 Toxiproxy 服务端监听0.0.0.0:8484再通过toxiproxy-cli把自定义 Toxic 挂到代理上。这正体现了 CREATING_TOXICS.md 所说的设计哲学用toxics.Register注册自定义类型拷贝 cmd/server/server.go 组装自己的二进制即可在不 fork 整个项目的前提下扩展 Toxic。二、自定义 Toxic 的核心接口与运行机制在深入两个示例之前先理解自定义 Toxic 的运行模型。定义在 toxics/toxic.go 中的核心接口只有一个type Toxic interface { // Defines how packets flow through a ToxicStub. // Pipe() blocks until the link is closed or interrupted. Pipe(*ToxicStub) }Pipe()函数定义了数据如何流经 Toxic它阻塞运行直到链路关闭或被中断。传入的ToxicStub结构体同样定义于 toxics/toxic.go承载了该 Toxic 在每条连接上的全部上下文type ToxicStub struct { Input -chan *stream.StreamChunk // 输入通道 Output chan- *stream.StreamChunk // 输出通道 State interface{} // 每条连接独立的有状态数据 Interrupt chan struct{} // 中断通道用于暂停/替换 Toxic }Toxic 以**管道pipeline**方式串联Client - ToxicStub - Upstream多个 Toxic 可以通过 channel 链在一起。通道里流动的不是裸字节而是stream.StreamChunk定义见 stream/io_chan.gotype StreamChunk struct { Data []byte Timestamp time.Time // 代理从客户端/服务端收到该数据的时刻 }带上时间戳的原因在于latency这类 Toxic 需要知道一段数据已在代理中等待了多久。你可以把StreamChunk理解为「网络包」级别的抽象。注册自定义 Toxic 则通过全局注册表完成toxics/toxic.go 中的Register/New/Count内置 Toxic 也在各自文件的init()中注册例如 toxics/noop.go 里的Register(noop, new(NoopToxic))。自定义 Toxic 的注册方式完全一致见下文示例的main()。与官方服务端的差异官方toxiproxy-servercmd/server/server.go默认把 HTTP API 监听在localhost:8474并且只包含内置 Toxic。示例程序则使用server.Listen(0.0.0.0:8484)启动 API因此后续toxiproxy-cli命令都需要通过--host http://localhost:8484显式指定端点这正是原文档中每条 CLI 命令都带--host的原因。三、DebugToxic把经过代理的字节流打印成十六进制3.1 完整复现步骤按 _examples/toxics/README.md 的流程依次执行第一步运行自定义 toxiproxy 服务端内含 DebugToxic$ go run debug_toxic.go第二步在另一个终端启动一个真实的 Redis 服务作为上游$ redis-server第三步通过 CLI 创建代理并挂上debugToxic$ toxiproxy-cli --host http://localhost:8484 create -l :16379 -u localhost:6379 redis $ toxiproxy-cli --host http://localhost:8484 toxic add --type debug redis这里create的三个参数含义分别是-l :16379为代理监听端口-u localhost:6379为上游地址redis为代理名。第四步通过代理访问 Redis触发流量$ redis-cli -p 16379 keys *等价写法redis-cli -p 16379 keys *亦可。此时回到运行go run debug_toxic.go的终端自定义 Toxiproxy 会把keys命令的请求字节和响应字节以十六进制格式打印出来。3.2 源码级原理剖析完整的DebugToxic实现在 _examples/toxics/debug_toxic.go其核心是Pipe()中的主循环func (t *DebugToxic) Pipe(stub *toxics.ToxicStub) { buf : make([]byte, 32*1024) writer : stream.NewChanWriter(stub.Output) reader : stream.NewChanReader(stub.Input) reader.SetInterrupt(stub.Interrupt) for { n, err : reader.Read(buf) log.Printf(-- [DebugToxic] Processed %d bytes\n, n) if err stream.ErrInterrupted { writer.Write(buf[:n]) return } else if err io.EOF { stub.Close() return } t.PrintHex(buf[:n]) writer.Write(buf[:n]) } }这里用到的是 stream/io_chan.go 提供的两个适配器stream.NewChanReader(stub.Input)把-chan *StreamChunk包装成标准io.Readerstream.NewChanWriter(stub.Output)把chan- *StreamChunk包装成io.WriteCloserreader.SetInterrupt(stub.Interrupt)让阻塞中的Read可以被中断通道唤醒。循环的三种退出/分支情况对应着 Toxic 必须遵守的中断协议这也是 CREATING_TOXICS.md 反复强调的要点stream.ErrInterruptedToxic 被 API 更新或移除时InterruptToxic()见 toxics/toxic.go会向Interrupt通道发送信号。此时 Toxic 应把尚未写出的在途数据buf[:n]写完再返回绝不能丢弃任何已从Input读出的字节否则流会缺字节而损坏io.EOF上游关闭代表数据流结束应调用stub.Close()关闭输出通道并返回正常路径打印十六进制后原样writer.Write(buf[:n])转发实现只看不碰的透明调试。十六进制打印本身由PrintHex完成_examples/toxics/debug_toxic.go按每行 4 组、每组 8 字节的排版输出% x格式。注意其边界处理——当剩余字节不足 8 时按实际长度截断避免越界打印。关于 Toxic 被中断时的行为可以对照 toxics/latency.go 中LatencyToxic的做法它在select中同时监听stub.Interrupt和time.After收到中断时同样先把数据stub.Output - c再返回即不把任何数据丢在地上是自定义 Toxic 的一条黄金准则。四、HttpToxic拦截并改写 HTTP 响应头4.1 完整复现步骤第一步运行自定义 toxiproxy 服务端内含 HttpToxic$ go run http_toxic.go第二步创建代理并挂上httpToxic上游指向example.com:80$ toxiproxy-cli --host http://localhost:8484 create -l :18080 -u example.com:80 example $ toxiproxy-cli --host http://localhost:8484 toxic add --type http example第三步通过代理发起请求并观察响应$ curl -v localhost:18080/hello预期输出中会出现关键两行... HTTP/1.1 404 Not Found Location: https://github.com/Shopify/toxiproxy即请求经代理转发到example.com后返回了 404 状态码而Location响应头已被自定义 Toxic 改写为 Toxiproxy 项目地址——这正是 HttpToxic 注入生效的直接证据。4.2 源码级原理剖析完整实现见 _examples/toxics/http_toxic.go。与 DebugToxic 不同HttpToxic 需要把字节流按 HTTP 协议解析再改写因此借助了 Go 标准库的net/httpfunc (t *HttpToxic) Pipe(stub *toxics.ToxicStub) { buffer : bytes.NewBuffer(make([]byte, 0, 32*1024)) writer : stream.NewChanWriter(stub.Output) reader : stream.NewChanReader(stub.Input) reader.SetInterrupt(stub.Interrupt) for { tee : io.TeeReader(reader, buffer) resp, err : http.ReadResponse(bufio.NewReader(tee), nil) if err stream.ErrInterrupted { buffer.WriteTo(writer) return } else if err io.EOF { stub.Close() return } if err ! nil { buffer.WriteTo(writer) } else { t.ModifyResponse(resp) resp.Write(writer) } buffer.Reset() } }实现的关键技巧io.TeeReader旁路缓存TeeReader(reader, buffer)在读取的同时把所有字节镜像写入buffer。一旦http.ReadResponse解析失败例如上游返回的并不是完整 HTTP 响应、或中途被中断就把buffer里已缓存的原始字节原样WriteTo(writer)保证数据不丢http.ReadResponse流式解析从bufio.NewReader(tee)中读出一个完整*http.Response对象。注意这里的 reader 是io.Reader接口由 ChanReader 实现因此天然兼容标准库的解析逻辑——这体现了 stream 包把 channel 抽象成io.Reader/io.Writer的设计价值任何能操作io.Reader的 Go 代码都能直接处理流经 Toxic 的数据改写与回写解析成功则调用自定义的ModifyResponsefunc (t *HttpToxic) ModifyResponse(resp *http.Response) { resp.Header.Set(Location, https://github.com/Shopify/toxiproxy) }随后resp.Write(writer)把被改写的HTTP 响应重新序列化并写回输出通道buffer.Reset()清空旁路缓存进入下一轮循环。值得说明的是HttpToxic 只在一个方向上解析 HTTP响应方向且依赖上游以标准 HTTP/1.x 文本格式返回。若你的代理场景需要双向解析或 HTTP/2需要在此基础上扩展但这并不影响它作为在 TCP 流上做协议级篡改的范本价值——CREATING_TOXICS.md 明确指出该示例正是使用 stream 包配合 Go http 包的完整范例。五、让自定义 Toxic 更专业配置、缓冲与状态两个示例足以让你跑通自定义 Toxic 全流程若要写出可复用的生产级 ToxicCREATING_TOXICS.md 还给出了三个进阶机制其实现均可对照仓库源码5.1 通过 JSON 字段暴露配置Toxic 结构体中的公开字段会被 API 自动 JSON 编解码因此天然成为 CLI/HTTP 可配置的参数。参照 toxics/latency.gotype LatencyToxic struct { // Times in milliseconds Latency int64 json:latency Jitter int64 json:jitter }这样toxiproxy-cli toxic add --type latency --attribute latency1000即可在运行时注入参数。注意结构体字段不应在Pipe()中被写入——每个连接都有独立的 Toxic 实例且 API 更新时会替换实例需要跨连接保存状态时应使用下面的 StatefulToxic或退而求其次使用 Pipe 顶部的局部变量局部变量在中断期间也无法持久化但至少不会跨连接串扰。5.2 用 BufferedToxic 避免阻塞整个管道默认情况下 Toxic 无缓冲stub.Output的写入会阻塞直到对端或其他 Toxic 取走数据。由于 Toxic 是链式串联的不读Input会连带阻塞其他 Toxic 与上游写入。若希望 Toxic 具备缓冲实现BufferedToxic接口即可见 toxics/toxic.go 与 toxics/latency.gofunc (t *LatencyToxic) GetBufferSize() int { return 1024 }返回值的单位是StreamChunk个数而单个 chunk 通常为 1 字节到 32KB 不等规划内存时要心中有数。toxics.New()toxics/toxic.go会在创建 Toxic 时读取该值并写入ToxicWrapper.BufferSize。5.3 用 StatefulToxic 保存每条连接的状态如果 Toxic 需要按连接累积数据例如统计已传输字节数实现StatefulToxic接口的NewState()即可见 toxics/toxic.go。参照 toxics/limit_data.gofunc (t *LimitDataToxic) NewState() interface{} { return new(LimitDataToxicState) }状态对象会存放在ToxicStub.State上在Pipe()中取出使用state : stub.State.(*LimitDataToxicState)LimitDataToxic正是这样一边转发一边累计state.bytesTransmitted达到Bytes限额后stub.Close()截断连接的。5.4 中断协议自查清单无论实现哪种进阶特性编写Pipe()时都应自查依据 CREATING_TOXICS.md 与 toxics/toxic.go 的InterruptToxic所有阻塞操作含sleep是否都可被stub.Interrupt中断收到中断后是否把在途数据全部写回stub.Output再返回读到nilchunk /io.EOF时是否调用stub.Close()并返回是否有数据被吞掉导致流损坏满足这些约束自定义 Toxic 才能与 Toxiproxy 的更新/移除 Toxic 时安全切换机制InterruptToxic会等待运行中的 Toxic 退出见 toxics/toxic.go正确配合。六、从示例走向你自己的二进制两个示例的main()展示了组装自定义服务端的完整模板func main() { toxics.Register(debug, new(DebugToxic)) logger : zerolog.New(os.Stderr).With().Caller().Timestamp().Logger() metrics : toxiproxy.NewMetricsContainer(prometheus.NewRegistry()) server : toxiproxy.NewServer(metrics, logger) server.Listen(0.0.0.0:8484) }要点拆解toxics.Register(debug, new(DebugToxic))把类型名debug与 Toxic 工厂注册进全局注册表。内置 Toxic 各自在init()中注册如 toxics/limit_data.go 的Register(limit_data, ...)而示例选择在main()里注册效果等价toxiproxy.NewServer(metrics, logger)创建 API 服务器HTTP 端点实现在 api.go包含/proxies、/proxies/{proxy}/toxics等完整 REST 路由之后toxiproxy-cli的所有命令都是对这些端点的封装server.Listen(0.0.0.0:8484)监听地址相比官方默认端口8474见 cmd/server/server.go 的-port参数示例固定使用8484因此 CLI 需要--host http://localhost:8484。要把自定义 Toxic 投入实际使用CREATING_TOXICS.md 建议的做法是拷贝 cmd/server/server.go 到自己的项目保留其-host、-port、-config、-seed、-runtime-metrics、-proxy-metrics等启动参数在main()中注册自己的 Toxic 后编译成独立二进制。这样你既拥有完整的 Toxiproxy 能力代理管理、内置 Toxic、配置热加载、Prometheus 指标又能注入业务专属的故障类型无需 fork 整个仓库。若你编写的 Toxic 具有通用价值还可以按 CREATING_TOXICS.md 的建议通过 Pull Request 回馈社区。结语从DebugToxic的透明旁观到HttpToxic的协议级篡改本文完整还原了 _examples/toxics/README.md 的两条实操链路并下沉到Toxic接口、ToxicStub中断协议、StreamChunk时间戳、ChanReader/ChanWriter的io.Reader抽象以及BufferedToxic、StatefulToxic等进阶机制。掌握这些你便能在混沌测试中随心所欲地制造专属故障——无论是打印 Redis 协议流量用于排障还是篡改 HTTP 响应验证客户端容错自定义 Toxic 都是把 Toxiproxy 从拿来即用的工具箱升级为可编程的混沌平台的关键一步。赞分享测试网络【免费下载链接】toxiproxy:alarm_clock: :fire: A TCP proxy to simulate network and system conditions for chaos and resiliency testing项目地址https://gitcode.com/gh_mirrors/to/toxiproxy点击查看免费下载相关推荐PayloadsAllTheThings 之 CRLF 注入HTTP 响应拆分实战指南从响应头注入到会话固定、XSS 与开放重定向PayloadsAllTheThings 之 CRLF 注入HTTP 响应拆分实战指南从响应头注入到会话固定、XSS 与开放重定向 CRLF 注入Car网络安全应用安全渗透测试ESP-IDF中HTTP服务器自定义响应头字段的实现方法ESP IDF中HTTP服务器自定义响应头字段的实现方法 在ESP IDF开发框架中HTTP服务器模块提供了强大的功能来构建嵌入式Web服务。本文将详细介绍如物联网嵌入式Flink自定义函数终极指南从入门到实战应用Flink自定义函数终极指南从入门到实战应用 Apache Flink作为业界领先的流处理框架其强大的自定义函数功能为复杂数据处理提供了无限可能。无论是简单示例工程大数据创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考