WTX

一个专注于网络技术的不同传输实现和相关工具的集合。包含 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服务器