Show HN：Nano-web – 一款为服务 SPA 而设计的低延迟单二进制 Web 服务器

原文 ↗ Hacker News 讨论 ↗

现有的极简服务器与对比

  • 评论者列出了许多单二进制或很小的静态服务器：redbean、h2o、Caddy、BusyBox httpd、thttpd、Lwan、gatling、filed、各种小型 Go 和 Crystal 服务器、基于 node 的 serve，以及一些临时工具。
  • 有人认为，使用 C/汇编实现可以把二进制压到约 500KB 以下，把 Docker 镜像压到 200KB 以下，而 nano‑web 的镜像约为 18MB。
  • 也有人指出，“极简”更多指减少攻击面和功能，而不只是二进制大小；极致的小并不总是必要的。

SPA 路由与 HTTP 状态码

  • 一个主要讨论线程在争论 SPA 路由：未知路径应该返回带 HTTP 200 的 index.html，还是保留正确的 404/40x 语义。
  • 一方认为：对于客户端路由器（React Router 等），服务器无法知道哪些路由有效；始终返回 200 + index 是实用且常见的做法，尤其适用于静态托管（例如 S3）。
  • 另一方认为：对不存在的资源返回 200 会破坏 Web 预期、SEO、链接预览、浏览器历史和安全工具；服务器和工具应支持正确的 404，同时仍由 SPA 渲染错误内容。
  • 讨论中提到的变通方案：基于前缀的处理、与服务器共享路由定义、基于 hash 的路由（/#...），或者使用 SSG/SSR 框架（Astro、Next、Hugo、Rails、Phoenix）。

CloudFront/S3 对 SPA 的行为

  • 有人回忆 CloudFront 过去在没有 Lambda@Edge 的情况下，历史上不会把 /dir 映射到 /dir/index.html；也有人说现在可以了，或者取决于 S3 website 端点和具体配置。
  • 一种常见模式是为 SPA 设置 404 回退页（index.html），这样每个深层链接都会返回 404 状态，但仍会渲染 SPA；这对某些私有/内部应用可以接受，但对公开站点则有问题。

延迟、缓存与性能

  • nano‑web 的内存缓存（包括预先 gzip/brotli 压缩的资源）被宣传为可降低延迟和 CPU 开销。
  • 批评者认为，OS 页缓存加上 sendfile 已经能提供接近最优的性能；差异通常只有微秒级，而网络延迟更大。
  • 有人指出 TLS/HTTP/3 卸载和 CDN 往往主导延迟；在 CDN 后面，静态服务器的选择通常几乎无关紧要。

Unikernels、部署与生态

  • 一个显著特点是它与 Nanos unikernel 的集成，同时也支持 Docker。
  • 一些人对 unikernels 作为类似 PaaS 的原语很感兴趣，希望看到更多真实世界中的使用来验证其收益；大家普遍认为工具链不错，但文档还需要改进。
  • 也有人询问 Nanos 在生产环境中的采用情况；线程中没有提供具体的大规模生产案例。