简介这是一款面向开发与测试人员的HTTP双端测试工具基于C#实现可同时充当HTTP客户端与服务端用于验证接口正确性、调试请求响应流程以及模拟各类服务器返回行为。客户端侧支持自定义URL、请求方法、请求头与请求体便于覆盖GET、POST、PUT、DELETE等常见场景服务端侧可预设状态码、响应头与响应体模板模拟不同返回情况适合API接口测试、自动化测试与性能压力测试。资源包共48个文件以cs源码、png与jpg界面截图、resx资源文件为主另含sln解决方案、csproj工程文件、xml配置、dll与pdb等编译产物整体约8.65MB目录按UI、Http、Util、Doc等模块划分结构清晰。目前已有314人学习下载适合希望理解HTTP通信机制、快速搭建本地测试环境的开发者参考与二次开发。1. 一个 HTTP 服务端客户端测试工具为什么我劝你别再手搓 curl 脚本上周排查一个线上问题前端说接口返回 502后端说日志里请求根本没到运维说网关配置没问题。三方各执一词最后我打开自己写的那个 HTTP 服务端客户端测试工具一边起本地服务端收请求一边用客户端发过去十秒钟定位到是中间一层代理把 header 吃掉了。这种「既能当客户端发请求、又能当服务端收请求」的工具就是标题里说的东西——它不是 Postman 那种纯客户端也不是 nginx 那种纯服务端而是把两端捏在一个进程里让你能自己跟自己对话。为什么需要它因为日常调试 HTTP 协议相关的问题你经常要同时看「发出去的包长什么样」和「收到的包长什么样」。用 curl 只能看一半用抓包工具又太重。这个工具解决的就是这个夹缝需求验证 http 连接复用 是否生效、检查服务端接口测试 的返回码和 header、模拟客户端和服务端 的异常交互。适合谁后端开发、测试工程师、运维以及任何需要跟 http协议 打交道但不想每次都开 Wireshark 的人。2. 先想清楚客户端和服务端到底该共用哪些代码2.1 为什么不是「写两个独立程序」很多人第一反应是客户端用 requests 写一个服务端用 Flask 写一个分开跑不就行了我一开始也这么干后来发现三个问题。第一两边的 HTTP 解析逻辑不一致客户端认为合法的请求服务端可能因为解析库不同而拒绝你分不清是协议问题还是代码问题。第二调试时要开两个终端、记两个端口、来回切窗口效率极低。第三也是最坑的你没法在一个断点里同时看到请求的原始字节和响应的原始字节。共用代码的核心收益是「协议层统一」。客户端和服务端都基于同一套 HTTP 报文解析和序列化逻辑这样你看到的请求和响应就是同一双眼睛看到的不会出现「客户端觉得发了、服务端觉得没收到」的玄学。常见做法是抽一个http_message模块负责把字节流解析成结构化的 method、path、headers、body反向也能序列化回去。客户端用它构造请求服务端用它解析请求两边对称。2.2 最小可用的协议分层我一般把整个工具分成四层从下往上层级职责关键点传输层TCP socket 读写处理粘包、半包设置超时报文层HTTP 报文解析/序列化区分 header 和 body处理 Content-Length会话层连接管理支持 keep-alive即 http连接复用应用层客户端/服务端逻辑发请求、收请求、路由、响应传输层是最容易翻车的地方。TCP 是流不是消息你recv一次不一定拿到完整的一个 HTTP 请求。必须循环读直到遇到\r\n\r\n拿到 header再根据 Content-Length 或 chunked 编码读 body。这一步没做好后面全是血泪。def recv_http_message(sock): # 先读到 header 结束标记 buf b while b\r\n\r\n not in buf: chunk sock.recv(4096) if not chunk: return None buf chunk header_part, _, rest buf.partition(b\r\n\r\n) headers parse_headers(header_part) # 根据 Content-Length 继续读 body content_length int(headers.get(content-length, 0)) body rest while len(body) content_length: chunk sock.recv(4096) if not chunk: break body chunk return build_message(headers, body[:content_length])这段代码的关键在partition那一步它把已读到的字节按 header 结束符切成两半前半是 header后半可能已经包含了部分 body。很多人在这里直接丢掉rest导致 body 永远读不全。参数上4096是每次 recv 的缓冲区大小太小会增加系统调用次数太大在低延迟场景下会多等。我一般设 8192兼顾吞吐和延迟。3. 客户端怎么发从构造请求到处理响应3.1 构造一个可复现的请求客户端部分的核心是「让你能精确控制发出去的每一个字节」。我一般提供一个RequestBuilder链式设置 method、path、headers、body最后调send()。为什么要链式因为调试时你经常要改一个 header 再发一次链式写起来顺手。class RequestBuilder: def __init__(self, host, port): self.host host self.port port self.method GET self.path / self.headers {} self.body b def set_method(self, method): self.method method.upper() return self def set_header(self, key, value): self.headers[key] value return self def set_body(self, body): if isinstance(body, str): body body.encode(utf-8) self.body body self.headers[Content-Length] str(len(body)) return self def send(self, keep_aliveFalse): conn self.headers.get(Connection, close) raw f{self.method} {self.path} HTTP/1.1\r\n raw fHost: {self.host}:{self.port}\r\n for k, v in self.headers.items(): raw f{k}: {v}\r\n raw \r\n payload raw.encode(utf-8) self.body sock socket.create_connection((self.host, self.port), timeout5) sock.sendall(payload) resp recv_http_message(sock) if not keep_alive: sock.close() return resp逻辑说明set_body里自动补Content-Length这是最容易被忽略的一步。如果你手动设了 body 但忘了 Content-Length服务端会一直等 body直到超时。参数上timeout5是连接超时生产环境调试时我一般设 3 到 10 秒太短会误判慢服务太长会卡住调试节奏。keep_alive参数控制是否复用连接这就是 http连接复用 的开关。3.2 处理响应状态码、header、body 一个都不能少收到响应后别急着只看 body。http状态码大全 里那么多码真正要关注的是 1xx、3xx、4xx、5xx 的边界。我一般把响应拆成三块展示状态行、headers、body。状态行里重点看 reason phrase有些服务端会在这里塞自定义信息。headers 里重点看Content-Length、Transfer-Encoding、Connection这三个决定了 body 怎么读、连接怎么管。def parse_response(raw): header_part, _, body raw.partition(b\r\n\r\n) lines header_part.decode(utf-8, errorsreplace).split(\r\n) status_line lines[0] version, status_code, reason status_line.split( , 2) headers {} for line in lines[1:]: if : in line: k, v line.split(:, 1) headers[k.strip().lower()] v.strip() return { version: version, status: int(status_code), reason: reason, headers: headers, body: body, }这里有个坑split( , 2)只切两次因为 reason phrase 里可能包含空格。如果你用split( )全切reason 就会被拆散。参数上errorsreplace是为了防止服务端返回非 UTF-8 字节时直接抛异常调试工具要能容错。4. 服务端怎么收路由、解析、响应一条龙4.1 起一个能收请求的最小服务端服务端部分的目标是「让你能看到客户端到底发了什么」。我一般用socketserver或直接socket起一个监听收到请求后打印原始字节和解析后的结构然后返回一个可配置的响应。这样你就能在同一个工具里左边发请求、右边看请求。import socketserver class HTTPHandler(socketserver.BaseRequestHandler): def handle(self): msg recv_http_message(self.request) if msg is None: return print( 收到请求 ) print(fMethod: {msg[method]}) print(fPath: {msg[path]}) print(fHeaders: {msg[headers]}) print(fBody: {msg[body]}) # 构造响应 body b{status: ok} resp ( bHTTP/1.1 200 OK\r\n bContent-Type: application/json\r\n bContent-Length: str(len(body)).encode() b\r\n bConnection: close\r\n b\r\n body ) self.request.sendall(resp) if __name__ __main__: with socketserver.TCPServer((0.0.0.0, 8080), HTTPHandler) as server: server.serve_forever()逻辑说明recv_http_message复用了客户端那边的解析逻辑这就是共用的好处。Connection: close表示响应后关闭连接如果你要测试 http连接复用就改成keep-alive并在循环里继续读下一个请求。参数上0.0.0.0监听所有网卡调试时如果只想本机访问改成127.0.0.1更安全。4.2 路由和响应配置让服务端能模拟各种场景真实调试中你需要服务端能返回不同的状态码、不同的 header、不同的 body。我一般加一个简单的路由表用字典映射 path 到响应配置。这样你就能模拟 404、500、重定向、大 body 等各种情况。ROUTES { /ok: {status: 200, body: b{msg: ok}}, /notfound: {status: 404, body: b{msg: not found}}, /error: {status: 500, body: b{msg: internal error}}, /redirect: {status: 302, headers: {Location: /ok}, body: b}, } def build_response(path): route ROUTES.get(path, {status: 404, body: bdefault 404}) status route[status] body route.get(body, b) headers route.get(headers, {}) headers[Content-Length] str(len(body)) headers[Connection] close raw fHTTP/1.1 {status} X\r\n for k, v in headers.items(): raw f{k}: {v}\r\n raw \r\n return raw.encode() body参数说明status是 HTTP 状态码headers里可以塞任意自定义 header用来测试客户端对未知 header 的处理。Location用于重定向测试注意 302 的 body 通常为空但 Content-Length 仍要设为 0。5. 避坑与排查那些让我熬夜的 HTTP 细节5.1 坑一Content-Length 和 Transfer-Encoding 同时出现现象服务端返回的 body 读了一半就卡住或者读到了下一个响应的内容。原因HTTP 规范规定如果同时有Transfer-Encoding: chunked和Content-Length必须忽略 Content-Length按 chunked 解析。很多简易工具只认 Content-Length遇到 chunked 就翻车。解决在解析响应时先检查Transfer-Encoding如果是 chunked走 chunked 解码逻辑逐块读直到遇到 0 长度块。5.2 坑二keep-alive 下连接被服务端单方面关闭现象客户端复用连接发第二个请求时收到Connection reset by peer。原因服务端在第一个响应后设置了Connection: close但客户端没看这个 header继续用旧连接发请求。解决每次收到响应后检查Connectionheader如果是close就主动关闭连接下次请求重新建连。这就是 http连接复用 最容易踩的坑。5.3 坑三header 大小写敏感导致匹配失败现象客户端设了Content-Type: application/json服务端用headers[content-type]取不到。原因HTTP header 名不区分大小写但很多字典实现区分。解决解析时统一转小写存储取值时也转小写。我一般在parse_headers里就做k.lower()。5.4 坑四body 里有二进制字节导致解码异常现象打印请求 body 时抛UnicodeDecodeError。原因body 可能是图片、protobuf 等二进制数据直接decode(utf-8)会炸。解决打印时用repr()或 hex 展示只在确定是文本时才 decode。参数上errorsreplace只能救急不能根治。5.5 坑五超时设置不当导致误判现象本地调试正常连远程服务就超时。原因socket.create_connection的 timeout 同时作用于连接和读写远程网络延迟高时容易触发。解决连接超时和读超时分开设连接用 3 秒读用 10 秒。我一般把这两个参数暴露成命令行选项方便按场景调。6. 进阶用这个工具验证 http连接复用 和异常边界6.1 验证连接复用是否真的生效http连接复用 不是设个 header 就完事你得验证服务端真的复用了同一个 TCP 连接。方法很简单在客户端记录每次请求的本地端口号如果两次请求的本地端口相同说明复用了连接。我一般加一个--verbose选项打印local_port。def send_with_reuse(builder, times3): sock socket.create_connection((builder.host, builder.port), timeout5) for i in range(times): print(f第 {i1} 次请求本地端口: {sock.getsockname()[1]}) raw builder.build_raw() sock.sendall(raw) resp recv_http_message(sock) print(f响应状态: {resp[status]}) if resp[headers].get(connection) close: print(服务端要求关闭连接停止复用) break sock.close()这段代码的关键是sock.getsockname()[1]它返回本地端口。如果三次请求端口一致复用生效如果端口变了说明每次都在新建连接。参数上times3是请求次数一般测 3 次就能看出复用行为。6.2 模拟异常边界超长 header、超大 body、慢响应真实环境里什么都有你的工具得能模拟这些。超长 header 用set_header(X-Long, a * 10000)超大 body 用set_body(bx * 10_000_000)慢响应在服务端time.sleep(5)再返回。这些场景能帮你提前发现客户端的缓冲区溢出、内存暴涨、超时配置等问题。异常场景构造方法观察点超长 header设 10KB 的 header 值服务端是否返回 431超大 body设 10MB 的 body内存占用、发送耗时慢响应服务端 sleep 5 秒客户端读超时是否触发分块传输服务端用 chunked 编码客户端是否正确解码提前关闭服务端发一半就 close客户端是否报错6.3 我踩过的一个后悔药有一次我图省事在服务端解析请求时直接sock.recv(65536)一次读完觉得 64KB 够大了。结果测试一个上传接口时body 有 200KB只读到了前 64KB后面的数据被当成下一个请求解析整个工具行为诡异。后来老老实实按 Content-Length 循环读再也不敢偷懒。这个教训告诉我HTTP 是流协议任何「一次读完」的假设都是定时炸弹。希望帮到你。本文还有配套的精品资源点击获取