WTX

一个专注于Web技术的不同传输实现和相关工具的集合。包含4个IETF RFC的实现（RFC6455、RFC7541、RFC7692、RFC9113）、2个正式规范（gRPC、PostgreSQL）和几个其他创新想法。

1. 客户端API框架
2. 数据库客户端
3. 数据库模式管理器
4. gRPC 客户端/服务器
5. HTTP 客户端框架
6. HTTP 服务器框架
7. HTTP2 客户端/服务器
8. 池管理器
9. UI 工具
10. WebSocket 客户端/服务器

具有工作堆分配器的嵌入式设备可以使用此 no_std crate.

性能

在项目中使用了许多通常可以提高性能的事物，以下是一些例子

1. 手动向量化：当算法已知用于处理大量数据时，会进行多次实验来分析如何拆分循环以允许编译器利用x86处理器的SIMD指令。
2. 内存分配：尽可能在实例创建的开始仅进行一次堆分配，另外，优先使用堆内存而不是栈内存。
3. 更少的依赖项：默认情况下不注入任何第三方。换句话说，通过选择Cargo功能，用户可以添加额外的依赖项，从而减少编译时间。例如，您可以通过以下命令查看PostgreSQL客户端所需的仅16个依赖项：cargo tree -e normal --features postgres。

由于内存通常在实例级别上保持，而不是动态创建和删除，因此值得注意，其使用量可能会根据使用情况显著增长。如果适当，尝试使用共享资源池或尝试限制双方之间可以交换的数据量。

高级基准测试

查看wtx-bench以查看各种基准测试，或者随时指出任何误解或错误配置。

主要影响性能的两个因素是所选运行时和预分配的字节数。特别是对于每次握手机会都要创建新实例的服务器，为短生命期或低传输连接预分配大量字节可能会产生负面影响。

低级基准测试

在存储库中标记为#[bench]的任何内容都被视为低级基准测试，因为它们测量非常具体的操作，这些操作通常作为其他部分的基础。

查看https://bencher.dev/perf/wtx以查看不同时间段的全部低级基准测试。

限制

不支持16位内存地址的系统，并期望8个分配的内存块大小的不可靠相加，否则程序将在涉及usize的某些算术操作中溢出，可能导致意外的操作。

例如，在32位系统上，您可以为最多8个元素分配最多2^29字节的内存。这种场景应具有可行性，因为可能触发OOM杀手或通过特定的限制器如ulimit。

可能未来的功能

• 通过HTTP/2流上的WebSocket (https://datatracker.ietf.org/doc/html/rfc8441)。
• cURL绑定
• 通过HTTP/2上的WebTransport (https://datatracker.ietf.org/doc/draft-ietf-webtrans-http2)。
• 静态Web服务器