需要实时嵌入式 http 服务器库
在查看了几个可用的 http 服务器库之后，我还没有找到我正在寻找的东西，并且确信我不能成为第一个有这组要求的人。
我需要一个提供“管道化”API 的库。管道技术用于描述一种 HTTP 功能，其中可以一次通过 TCP 链路发送多个 HTTP 请求，而无需等待响应。我希望库 API 具有类似的功能，让我的应用程序可以接收所有这些请求，而无需发送响应（我会响应，但希望能够一次处理多个请求，以减少内部延迟的影响）。
因此，Web 服务器库需要支持以下流程
1) HTTP 客户端传输 http 请求 1
2) HTTP 客户端传输 http 请求 2 ...
3) Web 服务器库接收请求 1 并将其传递给 My Web Server 应用程序
4) My Web 服务器应用程序接收请求 1 并将其分派到我的系统
5) Web 服务器接收请求 2 并将其传递到我的 Web 服务器应用程序
6) 我的 Web 服务器应用程序接收请求 2 并将其分派到我的系统
7) 我的 Web 服务器应用程序接收响应从我的系统请求 1 并将其传递给 Web 服务器
8) Web 服务器将 HTTP 响应 1 传输到 HTTP 客户端
9) 我的 Web 服务器应用程序从我的系统接收对请求 2 的响应，并且 将其传递给 Web 服务器
10) Web 服务器将 HTTP 响应 2 传输给 HTTP 客户端
希望这说明了我的要求。有 需要认识的两个关键点。对 Web 服务器库的响应是 异步，并且可能有多个 HTTP 请求传递到“我的网站” 服务器应用程序响应出色。
附加要求可
- 嵌入到现有的“C”应用程序
- 中我不需要 Apache 等中提供的所有功能
- 。需要每秒支持数千个请求
- 允许对请求进行异步响应；它们的响应延迟很小，并且考虑到所需的请求吞吐量，同步架构不适合我。
- 支持持久 TCP 连接
- 支持与 Server-Push Comet 连接一起使用
- 开源 / GPL
- 支持 HTTPS
- 可跨 Linux、Windows 移植；最好更多。
我将非常感谢任何建议
最好的问候
Having looked at several available http server libraries I have not yet found what I am looking for and am sure I can't be the first to have this set of requirements.
I need a library which presents an API which is 'pipelined'. Pipelining is used to describe an HTTP feature where multiple HTTP requests can be sent across a TCP link at a time without waiting for a response. I want a similar feature on the library API where my application can receive all of those request without having to send a response (I will respond but want the ability to process multiple requests at a time to reduce the impact of internal latency).
So the web server library will need to support the following flow
1) HTTP Client transmits http request 1
2) HTTP Client transmits http request 2 ...
3) Web Server Library receives request 1 and passes it to My Web Server App
4) My Web Server App receives request 1 and dispatches it to My System
5) Web Server receives request 2 and passes it to My Web Server App
6) My Web Server App receives request 2 and dispatches it to My System
7) My Web Server App receives response to request 1 from My System and passes it to Web Server
8) Web Server transmits HTTP response 1 to HTTP Client
9) My Web Server App receives response to request 2 from My System and
passes it to Web Server
10) Web Server transmits HTTP response 2 to HTTP Client
Hopefully this illustrates my requirement. There are
two key points to recognise. Responses to the Web Server Library are
asynchronous and there may be several HTTP requests passed to My Web
Server App with responses outstanding.
Additional requirements are
- Embeddable into an existing 'C' application
- Small footprint; I don't need all the functionality available in Apache etc.
- Efficient; will need to support thousands of requests a second
- Allows asynchronous responses to requests; their is a small latency to responses and given the required request throughput a synchronous architecture is not going to work for me.
- Support persistent TCP connections
- Support use with Server-Push Comet connections
- Open Source / GPL
- support for HTTPS
- Portable across linux, windows; preferably more.
I will be very grateful for any recommendation
Best Regards
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
您可以尝试 libmicrohttp。
You could try libmicrohttp.
使用洋葱，卢克。这是一个轻量级且易于使用的 C 语言 HTTP 服务器库。
Use the Onion, Luke. This is lightweight and easy to use HTTP server library in C.
为了便于将来参考，满足您的要求，请查看 libasyncd
我是贡献者之一。
它是用 C 编写的。
非常紧凑。
它是基于 libevent 的框架。能处理的还不止这些。
它是异步的。还支持流水线。
当然，keep-alive。
这取决于您如何编写逻辑。
BSD 许可下的
是的。它通过 openssl 支持 https。
目前是可移植的，但不是 Windows，但它可以移植到 Windows。
For future reference, that meets your requirement, take a look at libasyncd
I'm one of contributors.
It's written in C.
Very compact.
It's libevent based framework. Can handle more than that.
It's asynchronous. Also support pipelining.
Sure, keep-alive.
It's up to how you code your logic.
under BSD license
Yes. it supports https with openssl.
Portable but not windows at this moment but it's portable to windows.
您想要的是支持 HTTP 管道 的东西。如果您还不熟悉该页面，则应该熟悉该页面。
是的，请使用 libmicrohttp。它支持 SSL 等，并且可以在 Unix 和 Windows 上工作。
然而，克里斯托弗的评论是正确的。如果每个响应都有一个启动时间，那么您将不会通过管道获得太多好处。然而，如果您对第一个请求的响应时间很长，您可能会赢得一些东西。
另一方面，如果每个响应都有一个启动时间，那么不使用管道，而是为每个对象创建一个新请求，您可能会获得很多好处。然后每个请求都可以有自己的线程，从而并行吸收启动成本。在最佳情况下，所有响应将“立即”发送。 libmicrohttp 在其
MHD_USE_THREAD_PER_CONNECTION线程模型中支持这种操作模式。What you want is something that supports HTTP pipelining. You should make yourself familiar with that page if you are not already.
Yes, go for libmicrohttp. It has support for SSL etc and work in both Unix and Windows.
However, Christopher is right on the spot in his comment. If you have a startup time for each response, you are not going to gain much by pipelining. However, if you only have a significant response time to the first request, you may win something.
On the other hand, if each response has a startup time, you may gain a lot by not using pipelining, but create a new request for each object. Then each request can have its own thread, sucking up the startup costs in parallel. All responses will then be sent "at once" in the optimum case. libmicrohttp supports this mode of operation in its
MHD_USE_THREAD_PER_CONNECTIONthread model.跟进之前的评论和更新...
您没有说您将拥有多少个并发连接，而只是说“TCP 链接”。
如果它是单个连接，那么您将使用前面提到的 HTTP 管道；因此，您只需要少数线程（而不是数千个）来处理管道头部的请求。
所以你不需要为每个请求都有一个线程；每个连接只有一小部分工作人员。
到目前为止，您是否已完成任何测试或实施来表明您是否确实存在管道连接的响应延迟问题？
如果您的嵌入式设备功能强大，足以应对每秒数千个请求，包括进行 TLS 设置、加密和解密，我会担心在此级别上过早进行优化。
Following up on previous comments and updates...
You don't say how many concurrent connections you'll have but just "a TCP link".
If it's a single connection, then you'll be using HTTP pipelining as previously mentioned; so you would only need a handful of threads — rather than thousands — to process the requests at the head of the pipeline.
So you wouldn't need to have a thread for every request; just a small pool of workers for each connection.
Have you done any testing or implementation so far to show whether you actually do have problems with response latency for pipelined connections?
If your embedded device is powerful enough to cope with thousands of requests per second, including doing TLS setup, encryption and decryption, I would worry about premature optimisation at this level.
霍华德，
您看过 lighthttpd 吗？它满足您的所有要求，除了它不是明确的嵌入式网络服务器。但它是开源的，将其编译到您的应用程序中应该不会太难。然后，您可以编写自定义插件来处理您的请求。
Howard,
Have you taken a look at lighthttpd? It meets all of your requirements except it isn't explicitly an embedded webserver. But it is open source and compiling it in to your application shouldn't be too hard. You can then write a custom plugin to handle your requests.
不敢相信没有人提到 nginx。我已经阅读了大部分源代码，它非常模块化。您可能很快就能获得所需的部件。
Can't believe no one has mentioned nginx. I've read large portions of the source-code and it is extremely modular. You could probably get the parts you need working pretty quickly.
uIP 或 lwip 可以为您工作。我个人使用uIP。它适用于少量客户端和并发连接（或者如您所说的“管道”）。然而，根据我的阅读，它的可扩展性或提供内容的速度不如 lwip 那样快。我选择了 uIP 的简单性和小尺寸，而不是 lwip 的强大功能，因为我的应用程序通常只有 1 个用户。
我发现随着并发连接的增加，uIP 相当有限。不过，我确信这是我的 MAC 接收缓冲区的限制，而不是 uIP 本身的限制。我认为 lwip 以某种方式使用更多的内存来解决这个问题。我只是没有足够的以太网 RAM 来支持大量传入的请求数据包。也就是说，我可以在 56mhz 处理器上进行后台 ajax 轮询，延迟约为 15ms。
http://www.sics.se/~adam/software.html
我实际上已经通过多种方式修改了 uIP。添加 DHCP 服务器并支持文件上传的分段 POST 是最重要的事情。）如果您有任何问题，请告诉我。
uIP or lwip could work for you. I personally use uIP. It's good for a small number of clients and concurrent connections (or as you call it, "pipelining"). However, it's not as scalable or as fast at serving up content as lwip from what I've read. I went with simplicity and small size of uIP instead of the power of lwip, as my app usually only has 1 user.
I've found uIP pretty limited as the concurrent connections increase. However, I'm sure that's a limitation of my MAC receive buffers available and not uIP itself. I think lwip uses significantly more memory in some way to get around this. I just don't have enough ethernet RAM to support a ton of request packets coming in. That said, I can do background ajax polling with about a 15ms latency on a 56mhz processor.
http://www.sics.se/~adam/software.html
I've actually modified uIP in several ways. Adding a DHCP server and supporting multipart POST for file uploads are the big things.) Let me know if you have any questions.