# 本次更新说明

本次更新距离上次发布已经过去约半个月，期间累计接近 400 次提交。更新规模较大，重点不只是增加页面或修复显示问题，而是对底层架构、数据处理方式和持久化方式做了一轮完整调整。

本轮更新确立了新的三层数据储存架构：流（Flow）、事务（Transaction，相当于 Surge 的请求 Request 或 Clash 的连接 Connection）与应用模型。流（Flow）负责描述网络连接与传输过程，事务（Transaction）负责记录从流量中识别、拼接并还原出的请求/响应，而应用模型则用于保存那些需要长期复用、或者脱离单个流与单个事务后依然有价值的数据。

同时，本次更新完全分离了数据库读写与数据处理线程。数据处理过程不再直接被数据库操作拖慢，运行期数据会通过管理器、写入队列与节流保存机制持续写回。实测在当前设计下，请求记录模式可以长期保持开启：系统会持续嗅探、识别、拼接并保存每一个请求，包括 UDP 流量中的请求/响应。

应用模型是这次架构调整中比较重要的一层。它用于保存需要长期存在、或者未来处理流式数据时可能需要跨事务引用的数据。目前 HTTP 应用模型会保存捕获到的 HTTP 请求与响应对数据，效果上接近 Surge 的捕获流量；DNS 应用模型会保存每个“服务器 + 请求”组合下不重复的响应，用作本机 DNS 缓存。

未来如果继续实现 WebSocket、HTTP/3 这类更长生命周期的代理转发，应用模型也可以继续承担上下文数据的保存工作。比如某些脚本修改、协议处理或流式数据分析，可能依赖当前事务之前已经出现、但并不属于当前事务本身的数据，这类数据就适合由应用模型承载。

目前应用代理（App Proxy）不会按端口提前排除未知应用层协议，而是会对所有暂时无法识别的应用层（AppLayer）数据包持续进行分析、分类、规则匹配与保存。即使在 App Proxy Provider 约 15 MB 的内存限制下，当前实现也已经能够稳定运行。