大多数基础设施团队不会单独为网络服务器付费。他们为其周围的一切付费：为峰值流量保留的多余计算资源、独立的安全服务、遥测代理、配置自动化，以及维持这些部分一致性所需的工程时间。
这使得网络服务器成为基础设施成本决策。更快的二进制文件有用，但更小、更可控的生产系统才是真正的商业成果。
当吞吐量改变容量计划时才重要
Webship 是在 Rust 中构建的，用于高负载静态交付和跨 HTTP/1.1、HTTP/2 和 HTTP/3 的反向代理在当前经过验证的 Debian 直接服务矩阵中，四个 Webship 工作线程在 h2c 上维持了每秒 1,041,848 个请求的中位数，在 HTTP/3 上维持了每秒 307,727 个加密请求的中位数。
另一个同时期、同主机的比较提供了竞争情况。在那次测试中，Webship 在 h2c 上提供了每秒 1,015,870 个请求，而 Nginx 提供了 192,324 个请求。在 HTTP/3 TLS 上，Webship 提供了每秒 317,138 个请求，而 Envoy 提供了 35,207 个请求。每个已公布的结果都是五个已接受样本的中位数，使用隔离 CPU 集并且零错误正确性门控。
这些测量结果是证据，而不是通用容量。承诺。应用程序行为、响应大小、TLS 配置、缓存命中率、网络条件和上游延迟都会改变结果。相关的问题不是标题数字是否保持不变，而是 Webship 是否让您的工作负载以更少的节点或每个节点更多的余量来实现其服务目标。
请在Webship 基准页面上查看完整的方法论和每个竞争对手的结果。
整合才是经济性真正体现的地方
一个传统边缘可能包括 Web 服务器、反向代理、TLS 终端、缓存、WAF、速率限制器、指标端点以及单独的操作 API。每个组件都可以是优秀，但组合系统会产生更多的配置界面、网络转换、升级、故障模式和发票。
Webship 将静态文件、应用代理、TLS 1.3、HTTP/3、WebTransport、缓存、WAF、DDoS 控制、API Shield、响应安全头、可观测性和运营控制整合到一个可部署的二进制文件中。
对于符合该范围的工作负载，整合不仅可以减少 CPU 需求，还可以减少工程师在事件处理中必须配置、监控、保护和调和的服务数量。Webship 并不声称能取代全球 CDN、上游清洗网络或所有专用安全产品。uct。它为团队提供了一个强大的自托管基线，在需要另一个服务之前。
AI原生应该意味着受控操作
在基础设施中添加聊天界面并不等于操作自动化。一个AI原生的Web服务器需要一个有限的控制面、明确的策略、验证、可审计性和回滚能力。
Webship公开经过身份验证的Model Context Protocol操作，用于读取和验证配置、解释请求策略、比较影子更改、运行流量场景、检查有限诊断、管理缓存条目、检查TLS状态以及应用或回滚已批准的运行时安全更改。
控制监听器是隔离的应远离公共流量路径，并应保持在回环或 TLS 保护下的私有网络以及强大的承载令牌后面。运行时安全补丁可以在不中断流量的情况下应用。监听器、TLS 和身份验证更改仍然需要有意的重启。这一区分使自动化仍然有用，而不会假装每次生产更改都是无风险的。
请参阅 AI 代理快速入门 了解操作模型。
安全属于第一配置
Webship 从安全基线开始：WAF 检查、每客户端 DDoS 控制、机器人挑战、API 端点和内容类型验证、响应安全头以及点文件保护。控制措施在数据平面，而不是添加另一个默认的网络跳点。
内置并不意味着完成。运营者仍然拥有防火墙策略、机密信息、源安全、更新、应用安全和特定工作负载的规则调整的控制权。优势在于首次部署已经有一个一致的地方来执行和检查这些决策。
在自己的流量上建立业务案例
可信的评估应回答四个问题：
- Webship是否在静态、代理、WebSocket 和现代协议路径中保持请求的正确性？
- 在代表性流量下，持续吞吐量、尾延迟、CPU 和内存会发生什么情况？
- 可以在不丢失团队依赖的功能的情况下整合多少边缘组件？
- 操作员和人工智能代理可以在您的安全模型中诊断、验证、更改并回滚策略吗？
在现有边缘旁边运行 Webship，重放类似生产的流量，并保持旧监听器可用于回滚。将测量的可持续吞吐量转换为节点数量模型，然后加上每个剩余组件的运营成本。这样就可以做出可辩护的基础设施决策，而不是基于基准的猜测。
Webship 为希望在承诺之前测试经济性的团队提供了14天的评估路径。从 [文档] 开始n](https://webship.site/docs/1.1.1)，从下载中选择一个签名版本，并将其与您今天使用的系统进行对比。