背景

最近，因为大语言模型，Agent智能体等各种各样的AI技术的发展，OpenAPI 3.0（Swagge）迎来了流行热潮，变成连接AI应用与外部工具能力的关键桥梁。

如使用Dify这类AI开发平台，通过解析OpenAPI规范，实现了“零代码”集成自定义工具的能力，只需要给出一份OpenAPI定义文件，就能自动识别出接口地址、请求方法、参数类型、返回格式等重要的信息，最终形成生成可被AI调用的工具。

本次教程将使用Wireshark对这一交互流程进行完整的抓包分析。从客户端（Dify）发起获取openapi.json的HTTP请求开始，一步步拆解 TCP三次握手、HTTP请求与响应、数据分段传输，直至连接释放的全过程。

操作

导入Schema

可以正常拿到json规范

看下抓包：

可见获取schema是一个完整TCP握手与分手。

86，87，88包为TCP三次握手

95，96，97，99包为TCP四次分手过程。

其中业务包为：

89到93号包，看下89号包：

可见发送了http的get请求。

91号包可知

这个是个TCP segement，可见被分段了，另外一段在93号包，点击也能发现。

92号包是对其中的ACK答复，另外一个是94号包，整理成表格如下：

包号	方向	关键信息	作用解析
89	客户端→服务端	GET /openapi.json	HTTP 请求（已被 TCP 封装，序号 Seq=1，长度 280 字节）
91	服务端→客户端	[PSH, ACK] Len=166，[TCP segment of a reassembled PDU]	服务端发送 HTTP 响应的第一个 TCP 分段，序号 Seq=1，携带 166 字节数据
92	客户端→服务端	[ACK] Ack=167	客户端对91 号包的确认：收到了 Seq=1~166 的所有数据，下一个期望收到的序号是 167
93	服务端→客户端	HTTP/1.1 200 OK	服务端发送 HTTP 响应的后续分段（含剩余数据），序号从 167 开始，和 91 号的分段拼接成完整响应
94	客户端→服务端	[ACK] Ack=754	客户端对 **93 号包（完整响应数据）** 的确认：收到了 Seq=1~753 的所有数据

也可以直接查看HTTP追踪流

可见完整的过程：

完成整个交互后，dify就知道了可用工具

总结

OpenAPI协议和SOAP很像。OpenAPI 3.0 本质上就是一个用 JSON 写的 “API 说明书”，和 SOAP 的 WSDL 功能类似，都是给客户端看 “接口怎么用” 的契约文件，只是格式和风格更现代了。