跨语言 HTTP 解析器?

Cross-language HTTP parser?

我遇到了一个相当奇怪的观察结果。

HTTP 是这个世界上使用最多的协议。不知道统计数据,但肯定至少占互联网总流量的 90%。

每种主要语言都有一个库,用于创建网络服务器并使用网络客户端消耗流量。实际上,每种主要语言都是 C 的后裔 and/or 具有 C 绑定。

但似乎即使两端相遇自然形成了互联网的基础,也没有统一的、广泛使用的 C 中 HTTP 解析器的实现。

http_parser by Ryan Dahl, there is its decendant llhttp by Fedor Indutny(都在 Node.js 中使用),我想每个框架都根据自己的需要实现自己的解析器。

为什么?

我主要担心兼容性问题,关于库支持。例如,HTTP/3 推出但我在项目中使用的库不支持它,或者 Node.js 已被弃用并且不再支持。当然,这些论点听起来很愚蠢,但是这样看:为什么每个人都实现自己的解析器,如果 HTTP 协议规范是明确的并且在一天结束时几乎所有语言都有 C 绑定? 每个人都同意一个代码库并在所有语言中使用它不是更好吗?没有什么可竞争的。 这是一个协议,对每个人都是一样的。

问题是:是否有大多数服务器、http 客户端使用的跨语言解决方案?如果没有,为什么?

几个原因:

  • C 是 20 世纪 70 年代初期的产物,当时的系统往往是单一的,以网络为中心的架构很少见。它主要是为了实现 Unix 操作系统而创建的。而且它对 任何东西 的大部分内容几乎没有语言级别的支持——没有本地网络、图形、声音或其他许多东西。这就是它如此便携的原因——语言定义对底层平台的要求相对较少。维护 C 标准的小组在添加功能方面倾向于保守。

  • HTTP是众多中的一种——telnet、SMTP、NNTP、FTP、SSH等,都是或有在某些时候与 HTTP 一样被广泛使用。 30 年前,一个很好的案例可以使 telnet 或 FTP 支持原生(这也需要原生的 TCP/IP 堆栈)。现在是 HTTP 和 HTTPS,这将需要本机 SSL 实现。

范式(和协议)来来去去,但遗留代码是永恒的。使协议成为语言的一部分会使语言变得更大更难维护。新协议被创建,旧协议失宠或被弃用,导致更多维护问题。每次更新协议时,您都需要更新编译器(或至少更新标准库)。

如果所有这些都与语言本身分开,生活就会更轻松。

至于为什么会有这么多不同的实现...

  • 不同的平台有不同的 API - 在某些时候你必须有一个特定于系统的实现;

  • 不同的人对可用性、能力、可扩展性和安全性有不同的要求。对于个人使用来说可能工作得很好的轻量级实现可能会在负载下崩溃;

  • 有些人可能只是不知道现有的实现并推出了自己的实现;

  • 最后,没有裁判;存在标准,并且存在维护和执行这些标准的团体,但是没有人正式祝福特定的实施。