5

在查看了几个可用的 http 服务器库后，我还没有找到我正在寻找的东西，并且我确信我不能成为第一个拥有这组要求的人。

我需要一个提供“流水线”API 的库。流水线用于描述一种 HTTP 功能，其中可以一次通过 TCP 链接发送多个 HTTP 请求，而无需等待响应。我希望库 API 上有一个类似的功能，我的应用程序可以接收所有这些请求而无需发送响应（我会响应，但希望能够一次处理多个请求以减少内部延迟的影响）。

所以网络服务器库需要支持以下流程

1) HTTP Client 传输 http 请求 1

2) HTTP 客户端传输 http 请求 2 ...

3) Web Server Library 接收请求 1 并将其传递给 My Web Server App

4) 我的 Web 服务器应用程序接收到请求 1 并将其分派到我的系统

5) Web Server 收到请求 2 并将其传递给 My Web Server App

6) 我的 Web 服务器应用程序接收请求 2 并将其分派到我的系统

7) 我的 Web 服务器应用程序从我的系统接收到对请求 1 的响应并将其传递给 Web 服务器

8) Web Server 向 HTTP Client 发送 HTTP 响应 1

9) My Web Server App 从 My System 接收到对请求 2 的响应并将其传递给 Web Server

10) Web Server 向 HTTP Client 发送 HTTP 响应 2

希望这能说明我的要求。有两个关键点需要识别。对 Web 服务器库的响应是异步的，并且可能有多个 HTTP 请求传递到我的 Web 服务器应用程序，但响应未完成。

额外的要求是

  1. 可嵌入到现有的“C”应用程序中
  2. 占地面积小；我不需要 Apache 等提供的所有功能。
  3. 高效的; 需要每秒支持数千个请求
  4. 允许异步响应请求；它们对响应的延迟很小，并且考虑到所需的请求吞吐量，同步架构对我不起作用。
  5. 支持持久的 TCP 连接
  6. 支持与 Server-Push Comet 连接一起使用
  7. 开源/GPL
  8. 支持 HTTPS
  9. 可跨linux、windows移植；最好更多。

我将非常感谢任何建议

此致

4

8 回答 8

4

你可以试试libmicrohttp。

于 2010-02-09T17:33:31.017 回答
4

为了将来参考，满足您的要求，看看libasyncd 我是贡献者之一。

可嵌入到现有的“C”应用程序中

它是用 C 编写的。

占地面积小；我不需要 Apache 等提供的所有功能。

非常紧凑。

高效的; 需要每秒支持数千个请求

它是基于 libevent 的框架。能处理的还不止这些。

允许异步响应请求；

它是异步的。还支持流水线。

支持持久的 TCP 连接

没错，保命。

支持与 Server-Push Comet 连接一起使用

这取决于你如何编码你的逻辑。

开源/GPL

在 BSD 许可下

支持 HTTPS

是的。它支持带有openssl的https。

可跨linux、windows移植；最好更多。

便携式但目前不是 Windows，但它可以移植到 Windows。

于 2014-04-12T18:42:29.480 回答
4

使用洋葱，卢克。这是 C 语言中轻量级且易于使用的 HTTP 服务器库。

于 2013-05-04T18:52:46.953 回答
1

您想要的是支持HTTP 流水线的东西。如果您还不熟悉该页面，您应该熟悉该页面。

是的，去libmicrohttp。它支持 SSL 等，可在 Unix 和 Windows 中工作。

然而，克里斯托弗在他的评论中是正确的。如果您对每个响应都有启动时间，那么通过流水线处理您不会获得太多收益。但是，如果您对第一个请求只有很长的响应时间，您可能会赢得一些东西。

另一方面，如果每个响应都有一个启动时间，那么不使用流水线可能会收获很多，而是为每个对象创建一个新请求。然后每个请求都可以有自己的线程，并行吸收启动成本。在最佳情况下，所有响应将“立即”发送。libmicrohttpMHD_USE_THREAD_PER_CONNECTION在其线程模型中支持这种操作模式。

于 2010-02-10T11:56:29.393 回答
0

霍华德，

你看过lighthttpd吗？它满足您的所有要求，但它不是明确的嵌入式网络服务器。但它是开源的，将其编译到您的应用程序中应该不会太难。然后，您可以编写一个自定义插件来处理您的请求。

于 2010-02-19T00:24:53.303 回答
0

跟进之前的评论和更新...

你没有说你会有多少并发连接，而​​只是“一个 TCP 链接”。
如果是单个连接，那么您将使用前面提到的 HTTP 流水线；因此，您只需要少数线程（而不是数千个）来处理管道头部的请求。

所以你不需要为每个请求都有一个线程；每个连接只有一小部分工作人员。

到目前为止，您是否进行过任何测试或实施，以表明您是否确实存在流水线连接的响应延迟问题？
如果你的嵌入式设备足够强大，可以每秒处理数千个请求，包括进行 TLS 设置、加密和解密，我会担心这个级别的过早优化。

于 2010-02-12T14:37:04.047 回答
0

不敢相信没有人提到过nginx。我已经阅读了大部分源代码，它非常模块化。您可能会很快得到您需要的零件。

于 2010-02-19T10:10:07.597 回答
0

uIP 或 lwip 可以为您工作。我个人使用uIP。它适用于少量客户端和并发连接（或者您称之为“流水线”）。但是，它在提供内容方面不如我读过的 lwip 那样可扩展或快速。我选择了 uIP 的简单性和小尺寸，而不是 lwip 的强大功能，因为我的应用程序通常只有 1 个用户。

随着并发连接的增加，我发现 uIP 非常有限。但是，我确信这是我的 MAC 接收缓冲区可用而不是 uIP 本身的限制。我认为 lwip 在某种程度上使用了更多的内存来解决这个问题。我只是没有足够的以太网 RAM 来支持大量的请求数据包进来。也就是说，我可以在 56mhz 处理器上以大约 15ms 的延迟进行后台 ajax 轮询。

http://www.sics.se/~adam/software.html

我实际上已经以多种方式修改了 uIP。添加 DHCP 服务器并支持文件上传的多部分 POST 是一件大事。）如果您有任何问题，请告诉我。

于 2010-05-12T18:50:53.910 回答