C语言 C/C++ 中的高性能应用程序网络服务器

high performance application webserver in C/C++

提问by Aaron Yodaiken

Is there any high performance (ideally evented and open source) web server in C or C++?

C 或 C++ 中是否有任何高性能（理想情况下事件化和开源）的 Web 服务器？

I'd like to be able to use it in that it calls a method/function in my application with a filled out HTTP Request class/struct, and then I can return a filled out HTTP Response class/struct to it.

我希望能够使用它，因为它使用填充的 HTTP 请求类/结构调用我的应用程序中的方法/函数，然后我可以向它返回一个填充的 HTTP 响应类/结构。

If it isn't open source, I'd need built in support for long-polling connections, keep-alive, etc—otherwise, I think that I can add these things myself.

如果它不是开源的，我需要内置对长轮询连接、保持活动等的支持——否则，我认为我可以自己添加这些东西。

If you don't know of any such servers available, would you recommend writing my own web server to fit the task? It cannotbe file-based, and must be written in high-performance C/C++.

如果您不知道有任何可用的此类服务器，您是否建议编写我自己的 Web 服务器以适应该任务？它不能基于文件，必须用高性能 C/C++ 编写。

---

---

Edit: I'm thinking something like the Ruby Mongrel for C, if that helps.

编辑：如果有帮助的话，我正在考虑类似于 C 的 Ruby Mongrel 之类的东西。

回答by Yaroslav Stavnichiy

I had the very same requirements for my job, so I evaluated a number of solutions: mongoose, libmicrohttpd, libevent. And I also was thinking about writing nginx modules. Here is the summary of my findings:

我对我的工作有非常相同的要求，所以我评估了许多解决方案：猫鼬、libmicrohttpd、libevent。我也在考虑编写 nginx 模块。以下是我的发现总结：

nginx

nginx

nginx project page

nginx 项目页面

I love this server and use it a lot. Its performance and resource usage is much better than that of Apache, which I also still use but plan migrating to nginx.

我喜欢这个服务器并且经常使用它。它的性能和资源使用比Apache好很多，我也在用，但计划迁移到nginx。

• Very good tunable performance. Rich functionality. Portability.
• Module API is not documented and seems to be very verbose. See this nginx hello world moduleas example.
• Nginx does not use threads but uses multiple processes. This makes writing modules harder, need to learn nginx API for shared memory, etc.

• 非常好的可调性能。功能丰富。可移植性。
• 模块 API 没有记录，似乎非常冗长。以这个nginx hello world 模块为例。
• Nginx 不使用线程，而是使用多个进程。这使得编写模块变得更加困难，需要学习用于共享内存的 nginx API 等。

mongoose

猫鼬

mongoose project page

猫鼬项目页面

• All server's code is in single mongoose.c file (about 130K), no dependencies. This is good.
• One thread per connection, so if you need concurrency you've got to configure lots of threads, ie. high RAM usage. Not too good.
• Performance is good, although not exceptional.
• API is simple but you have to compose all response HTTP headers yourself, ie. learn HTTP protocol in detail.

• 所有服务器的代码都在单个 mongoose.c 文件中（大约 130K），没有依赖关系。这很好。
• 每个连接一个线程，所以如果你需要并发，你必须配置很多线程，即。RAM使用率高。不是很好。
• 性能很好，虽然不是例外。
• API 很简单，但您必须自己编写所有响应 HTTP 标头，即。详细学习HTTP协议。

libmicrohttpd

libmicrohttpd

libmicrohttpd project page

libmicrohttpd 项目页面

• Official GNU project.
• Verbose API, seems awkward to me, although much more simple than writing nginx modules.
• Good performance in keep-alive mode (link to my benchmarks below), not so good without keep-alive.

• 官方 GNU 项目。
• Verbose API，对我来说似乎很尴尬，虽然比编写 nginx 模块简单得多。
• 保持活动模式下的良好性能（链接到下面我的基准），如果没有保持活动，则表现不佳。

libevent

自由事件

libevent project page

libevent 项目页面

Libevent library has built-in web server called evhttp.

Libevent 库具有称为 evhttp 的内置 Web 服务器。

• It is event based, uses libevent for that.
• Easy API. Constructs HTTP headers automatically.
• Officially single-threaded. This is major disadvantage. I've found a hack, which makes several instances of evhttp run simultaneously accepting connections from the same socket. Not sure if it is all safe and robust.
• Performance of single-threaded evhttp is surprisingly poor. Multi-threaded hack works better, but still not good.

• 它是基于事件的，为此使用 libevent。
• 简单的API。自动构造 HTTP 标头。
• 正式单线程。这是主要的缺点。我发现了一个 hack，它使多个 evhttp 实例同时运行，接受来自同一个套接字的连接。不确定它是否安全可靠。
• 单线程 evhttp 的性能出奇的差。多线程 hack 效果更好，但仍然不好。

G-WAN

广域网

G-WAN projectis not open source, but I'd like to say a few words about it.

G-WAN 项目不是开源的，但我想说几句。

• Very good performance, low memory usage, 150 KB executable.
• Very convenient 'servlet' deployment: just copy .c file into csp directory, and running server automatically compiles it. Code modifications also compiled on the fly.
• Simple API. Although constrained in some ways. Rich functionality (json, key-value store, etc.).
• Unstable. I had segfaults on static files. Hangs on some sample scripts. (Experienced on clean install. Never mixed files of different versions).
• Only 32-bit binary(not anymore).

• 非常好的性能，低内存使用，150 KB 可执行文件。
• 非常方便的'servlet'部署：只需将.c文件复制到csp目录中，运行服务器自动编译它。代码修改也可以即时编译。
• 简单的 API。虽然在某些方面受到限制。丰富的功能（json、键值存储等）。
• 不稳定。我在静态文件上有段错误。挂在一些示例脚本上。（有干净安装经验。从不混合不同版本的文件）。
• 只有 32 位二进制（不再）。

So as you can see, none of existing alternatives have fully satisfied me. So I have developed my own server, which is ...

正如你所看到的，现有的替代方案都没有让我完全满意。所以我开发了自己的服务器，这是...

NXWEB

恩智网

NXWEB project page

NXWEB项目页面

Feature highlights:

功能亮点：

• Very good performance; see benchmarks on project page
• Can serve tens of thousands concurrent requests
• Small memory footprint
• Multi-threaded model designed to scale
• Exceptionally light code base
• Simple API
• Decent HTTP protocol handling
• Keep-alive connections
• SSL support (via GNUTLS)
• HTTP proxy (with keep-alive connection pooling)
• Non-blocking sendfile support (with configurable small file memory cache; gzip pre-encoded file serving)
• Modular design for developers
• Can be run as daemon; relaunches itself on error
• Open source

• 非常好的表现；查看项目页面上的基准
• 可以服务数万个并发请求
• 内存占用小
• 可扩展的多线程模型
• 极其轻量级的代码库
• 简单的API
• 体面的 HTTP 协议处理
• 保持活动连接
• SSL 支持（通过 GNUTLS）
• HTTP 代理（具有保持活动连接池）
• 非阻塞发送文件支持（具有可配置的小文件内存缓存；gzip 预编码文件服务）
• 面向开发人员的模块化设计
• 可以作为守护进程运行；出错时重新启动
• 开源

Limitations:

限制：

• Depends on libev library(not anymore)
• Only tested on Linux

• 依赖于 libev 库（不再）
• 仅在 Linux 上测试

回答by Axel Gneiting

I would suggest to write a FastCGI executable that can be used with many high performance web servers (even closed source ones).

我建议编写一个 FastCGI 可执行文件，它可以与许多高性能 Web 服务器（甚至是封闭源代码的服务器）一起使用。

回答by Gabe Rainbow

mongoose: one file. simple and easy to use. not an asycn io but perfect for embedded and particular purposes.

猫鼬：一个文件。简单易用。不是 asycn io，但非常适合嵌入式和特定用途。

gwan. excellent. no crashes. ultra well planned configuration. very smart and easy for c/c++ development in other words, very clean sensible api compared to nginx. provides a thread per core. or whatever you specify. a great choice. largest disadvantage (maybe im lacking in this area): cannot step thru code.

关。优秀。没有崩溃。超精心规划的配置。换言之，与 Nginx 相比，C/C++ 开发非常智能且易于使用。每个内核提供一个线程。或您指定的任何内容。一个不错的选择。最大的缺点（也许我在这方面缺乏）：无法通过代码。

libevent: single thread is not a disadvantage on a single core machine. afterall its point is an async i/o. does have multithreads for other cores.

libevent：单线程在单核机器上不是劣势。毕竟它的重点是异步 I/O。确实有其他内核的多线程。

nginx: no personal experience. gaining serious ground on a-patchy server. (terribly confusing api)

nginx：没有个人经验。在不完整的服务器上取得了重要的进展。（非常令人困惑的api）

boost asio: a c++ library for asynchio (asio). awesome. needs a friendly higher-level api for simpletons like myself. and others who come from php, java, javascript, node.js and other web languages.

boost asio：asynchio (asio) 的 C++ 库。惊人的。对于像我这样的傻瓜，需要一个友好的高级 api。以及其他来自 php、java、javascript、node.js 和其他网络语言的人。

python bottle: awesome 1 file lib (framework/system) that makes it easy to build python web apps. has/is a built in httpd server, like libevent and node.js

python 瓶子：很棒的 1 文件库（框架/系统），可以轻松构建 python web 应用程序。有/是一个内置的 httpd 服务器，比如 libevent 和 node.js

node.js: javascript asyncio server. an excellent selection. unfortunately, have to program in javascript that does become tedious. while there is something to be said for getting the job done; there is also something to be said for enjoying yourself during the process. hopefully no ones comes up with node.php

node.js：javascript 异步服务器。一个很好的选择。不幸的是，必须在 javascript 中编程，这确实变得乏味。而为了完成工作有话要说；在这个过程中也有一些话要说让自己享受。希望没有人提出 node.php

回答by symcbean

I'm going to suggest the same thing as Axel Gneiting - but have provided an answer with my reasons for taking this approach:

我将提出与 Axel Gneiting 相同的建议 - 但已经提供了我采用这种方法的原因的答案：

1) HTTP is not trivial as a protocol - writing your own server or amending an off-the-shelf solution is a very complex task - a lot more complex than using the available APIs for implementing a separate processing engine

1) HTTP 作为一种协议并非微不足道 - 编写自己的服务器或修改现成的解决方案是一项非常复杂的任务 - 比使用可用的 API 来实现单独的处理引擎复杂得多

2) Using (an unmodified) mainstream webserver should provide you with more functionality than you require (so you've got growing room).

2）使用（未经修改的）主流网络服务器应该为您提供比您需要的更多的功能（因此您有成长的空间）。

3) Using (an unmodified) mainstream webserver will usually mean that it has been far more extensively tested and documented than a homebrew system.

3）使用（未经修改的）主流网络服务器通常意味着它比自制系统经过了更广泛的测试和记录。

4) .. and its more likely to be secure and stable.

4) .. 并且它更有可能是安全和稳定的。

5) Using fastCGI you can use all sorts of languages to develop your back-end processing in - including C++ and C. There are standard toolkitsavailable to facilitate this.

5) 使用fastCGI，您可以使用各种语言来开发您的后端处理——包括C++ 和C。有标准工具包可用于促进这一点。

6) alternatively many webservers provide support for running interpreter engines in-process (e.g. mod_php, mod_perl). I'd advise against running your own native code as a module though.

6) 或者，许多网络服务器支持在进程中运行解释器引擎（例如 mod_php、mod_perl）。不过，我建议不要将自己的本机代码作为模块运行。

It cannot be file-based.

它不能是基于文件的。

Eh? What does that mean?

诶？这意味着什么？

回答by pcting

I'm an avid nginxuser; nginx is written in C; nginx seems like it could work for you. If you want the very best speed out of nginx, I would make a nginx module. Here are 3rd party moduleswhich you can examine to get an idea of what it requires.

我是一个狂热的nginx用户；nginx是用C写的；nginx 似乎可以为您工作。如果您想要 nginx 的最佳速度，我会制作一个 nginx 模块。以下是第 3 方模块，您可以检查这些模块以了解它需要什么。

As for the long polling requirement, you might want to have a look at the http push modules.

至于长轮询要求，您可能需要查看 http 推送模块。