带有集成 XML 解析器的嵌入式 Web 服务器
我需要将 Web 服务器集成到运行 Linux 的嵌入式设备中，并且正在评估 OSS 和商业产品。
系统要求不是特别严格： - 运行内存集高达 10MB， - 可以突发 300MHz ARM 的 20% 以上，甚至更多， - UI 将采用 jQuery 和 JSON，因此希望提供数百 KB 页面链接不到一秒就能处理十几个 CSS 和 JS 文件。
功能要求： - HTTPS 支持， - 10+ 并发连接， - 经过良好的 DOS 攻击测试。
非常感谢有一个集成的 XML 解析器作为 SOAP 实现的基础。
不喜欢 PHP，但也不了解服务器端 Javascript，也不熟悉 Lua。因此正在寻找模板解决方案的建议，也许是基于 Python 的堆栈。
已经查看了关于SO的讨论和维基百科上的列表。我了解 thttpd、Mongoose, 切诺基，Appweb。
此时，我邀请基于生产质量部署的第一手经验提出详细的技术建议和实施选择的讨论。
I have a requirement to integrate a web server into an embedded device running Linux and am in the process of evaluating OSS and commercial offerings.
System requirements at not particularly tight: - Memory running set of up to 10MB, - Can spare 20%+ of a 300MHz ARM and more in bursts, - UI will be in jQuery and JSON, so would like to feed several hundred KB pages linking a dozen CSS and JS files in well under a second.
Feature requirements: - HTTPS support, - A 10+ concurrent connections, - Well-tested against DOS attacks.
Would much appreciate an integrated XML parser to base a SOAP implementation on.
Not a fan of PHP, but not certain about server-side Javascript either, and unfamiliar with Lua. So looking for suggestions for templating solutions, perhaps a Python-based stack.
Already reviewed discussions on SO and lists on Wikipedia. Am aware of thttpd, Mongoose, Cherokee, Appweb.
At this point I invite detailed technical suggestions and discussion of implementation choices, based on first-hand experince in production quality deployment.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
当谈到简单的 python 服务器堆栈时，我在社区中最常听到的轻量级实现组合是 CherryPy （提供线程池 WSGI 服务器）和 Werkzeug （创建 WSGI 的基本结构） app）两者对 WSGI 的看法略有不同，从而大大加快了开发时间。
有一些很好的注释概述了基本的 python 框架比较（尽管不是在嵌入式环境中，但重点是轻量级部署。）在这个问题上，Alex“机器”Martelli 权衡了这两个问题。
如果您能负担得起 python 解释器的开销（我认为这是可以的，因为您将其包含在您的合格列表），werkzeug 是设置由简单端点组成的应用程序的绝佳方法。响应可以内联 mimetype 来帮助输出 UI 库（Jquery 等）。 Werkzeug 文档中有一些很棒的示例。
我能够找到的关于比较 WSGI 服务器（以满足您对高并发连接和 DOS 生存能力的需求）的最佳资源之一可以在 Nicholas Piel 关于该主题的博客文章，其中 CherryPy 被列为最佳“物超所值”资源之一速度方面。 Cherry 中的 WSGI 服务器已准备好部署，并且可以用作为 Werkzeug 应用程序提供环境的服务器进程，因此您不需要使用 mod_wsgi 实现 Apache 等更重的东西。 Cherry 能够轻松达到平均 2000 r/ps 左右，在中等负载下响应时间远低于一秒。
由于我不知道您将在哪种设备上部署它，所以我当然应该提到这两个平台都会定期更新，因此如果出于某种原因分配网络资源来更新设备不切实际，也应该考虑这一点。
通过将 python 的
minidom模块 (v2.6+) 与 Werkzeug 中的端点路由相结合，您还应该受益于非常好的开发速度。使用 Werkzeug 的Map功能构建复杂的 url 架构非常简单，其文档页面上的教程对此提供了精彩的概述。在两者之间，启动并运行您的 Web 服务应该不会太困难。When it comes to a simple python server stack, the combination I've heard most often from within the community for lightweight implementation is CherryPy (to provide the thread-pooled WSGI server) with Werkzeug (to create the basic structure of the app) Both are very slightly different takes on WSGI that speed development time considerably.
There some pretty good notes outlining basic python framework comparisons (albeit not in an embedded environment, but the emphasis was on lightweight deployments.) at this question, in which Alex "the Machine" Martelli weighed in for these two.
If you can afford the overhead of the python interpreter (which I am assuming is ok as you included it in your eligible list), werkzeug is an excellent way to setup an app that consists of simple endpoints. Responses can be mimetyped inline to aid in outputing your UI libs (Jquery, etc). There are awesome examples on the Werkzeug docs.
One of the best resources I've been able to find on comparing WSGI servers (to satisfy your need for high concurrent connections and DOS survivability) can be found at Nicholas Piel's blog post on the subject, where CherryPy ranks in as one of the best "bang-for-your-buck" resources to speed-wise. The WSGI server in Cherry is deployment ready, and this can be used as the server process providing the environ to your Werkzeug app so you don't need to implement something heavier like Apache with mod_wsgi. Cherry is easily capable of an average around 2000 r/ps with response times well under a second while under moderate load.
Since I don't know what kind of device you will be deploying this on, I should mention of course that both of these platforms are regularly updated, so this too should be considered if for whatever reason allocating network resources to update the device is impractical.
By combining python's
minidommodule (v2.6+) with the endpoint routing in Werkzeug, you should also benefit from very good development speed. Constructing a complex url schema is simple using Werkzeug'sMapfeature, and the tutorial at their documentation page gives an awesome rundown on this. Between the two, it shouldn't be too difficult to get your web service up and running.我认为您的嵌入式网络服务器的目的是提供
用于配置、操作和状态的管理界面。
特此披露，我们公司构建并部署了管理网络
许多嵌入式系统上的接口与您的规格相似
基于我们的产品 Web 进行描述。您可以了解更多关于我们的信息
方法http://uweb.workware.net.au/，你可以阅读一篇论文
我在 2010 年嵌入式 Linux 会议上发表过演讲
在 http://workware.net.au/papers/embedded-scripting.pdf 其中提供
我们如何平衡大小和性能问题的一些细节
通过脚本快速部署。
您有两个广泛的选择。第一种是使用 µWeb 等框架，或者
Barracuda服务器（上面提到的），或者一个开源框架
例如 luci (http://luci.subsignal.org/trac)。第二个是
使用轻量级网络服务器，例如您提到的那些
上面然后构建自己的框架（大概是基于jQuery
和 JSON）。第二种选择将花费更长的时间
当您处理 XSS、CRSF 和 DOS 攻击时，安全性是一个问题。
无论如何，我强烈建议你远离 PHP、Python 或
服务器端 JavaScript。这些对于资源来说都太消耗了
300MHz ARM 平台。
如果您的管理 UI 需要，为什么需要 XML 和 SOAP
是 jQuery 和 JSON？您对 SOAP 有单独的要求吗
支持？如果是这样，gSOAP 可能是一个合理的选择（它已经被
距离我上次使用它已有几年了）。
关于 https 和 10+ 并发会话，请注意初始 SSL 握手
在嵌入式平台上是资源密集型的。如果你是
频繁建立新请求（或者因为新会话，或者因为
请求没有被管道化），平台将会陷入困境。你或许只能
每秒建立 1-2 个 SSL 连接。
I presume that the purpose of your embedded web server is to provide
an administrative interface for configuration, operations and status.
For disclosure, our company builds and deploys administrative web
interfaces on many embedded systems with specs similar to what you
describe based on our product, Web. You can find out more about our
approach at http://uweb.workware.net.au/, and you can read a paper
I presented at the Embedded Linux Conference 2010
at http://workware.net.au/papers/embedded-scripting.pdf which provides
some detail of how we balance the size and performance concerns
with rapid deployment through scripting.
You have two broad options. The first is to use a framework such as µWeb, or
Barracuda server (mentioned above), or a an open source framework
such as luci (http://luci.subsignal.org/trac). The second is
to use a light-weight web server such as those you mention
above and then build your own framework (presumably based on jQuery
and JSON). The second option will take significantly longer and
security is a concern as you address XSS, CRSF and DOS attacks.
In any event, I strongly suggest you stay away from PHP, Python or
server-side Javascript. These are all too resource hungry for a
300MHz ARM platform.
Why the requirement for XML and SOAP if your admin UI is going to
be jQuery and JSON? Do you have a separate requirement for SOAP
support? If so, gSOAP is probably a reasonable choice (it's been
a few years since I last used it).
Regarding https and 10+ concurrent sessions, note that the initial SSL handshake
is significantly resource intensive on and embedded platform. If you are
establishing new requests frequently (either because of new sessions, or because
requests aren't pipelined), the platform will struggle. You can probably only
establish 1-2 SSL connections/second.
如果您只有 10MB，那么许多建议都是不可能的：只有一个小型应用程序，node 和 ruby 就会很快超过这个占用空间。 PHP 的起始大小至少约为 8MB，并且可以快速达到 20+MB。我们见过一个网站有一个 50MB 的 PHP 管理应用程序。对于嵌入式来说绝对不是一个好的选择，除非你有足够的 GB 空间。
我将 Appweb 与 ESP（一种 C 语言 MVC 框架）和 Ejscript（服务器端 Javascript）一起使用。 Ejscript 具有 XML 解析器，可以处理 SOAP 需求。 Appweb 包含一个非常基本的 XML 解析器。如果您想要高级 SOAP 处理，您将需要 libxml。
Appweb 4 具有良好的 DOS 保护。您可以使用 LimitRequestPerClient 指令限制来自单个客户端的并发请求数。 LimitParseTimeout 还有助于快速关闭未结束标头的 DOS 请求。 Appweb 安全沙箱有很多指令供您描述负载特征 - 这有助于防御 DOS 和其他安全威胁。
您的另一个选择是使用纯 Javascript 并使用内置了 Appweb http 引擎的 Ejscript。
If you have only 10MB, then many of the suggestions are out of the question: node and ruby will quickly exceed this footprint with only a small application. PHP will start at about 8MB minimum and can quickly go to 20+MB. We've seen one site with a 50MB PHP management app. Definitely not a good choice for embedded unless you have GB to spare.
I've used Appweb with ESP which is a c-language MVC framework and Ejscript which is server-side Javascript. Ejscript has XML parser and can handle the SOAP requirement. Appweb includes a very basic XML parser. You will need libxml if you want high level SOAP handling.
Appweb 4 has good DOS protections. You can limit the number of simultaneous requests from a single client with the LimitRequestPerClient directive. The LimitParseTimeout also helps to quickly close DOS requests that don't conclude their headers. The Appweb security sandbox has lots of directives for you to characterize your load - this helps for DOS and other security threats.
Your other choice would be to go pure Javascript and use Ejscript which has the Appweb http engine built into it.
您必须决定首先使用哪种服务器端技术。对于嵌入式系统，您有严格的资源限制，因此请确保相应地选择轻量级技术！话虽如此，Node.js 是一项伟大的技术 (http://nodejs.org/)，您可能会愿意付费注意力。我也见过一些 SOAP 实现。另一方面，基于 javascript 的开发可能会非常混乱！您可以尝试不同的解决方案，并开始使用 JMeter (http://jmeter.apache.org）。
一些建议： 在嵌入式系统中设置一个轻量级 http 服务器（如 Cherokee、lighttpd 等），然后设置 PHP（PHP 也有一些 SOAP 工具）。稍后使用 Python 或 Ruby 解决方案更改 PHP（例如嵌入式 Mongrel 等）。使用 JMeter 了解系统在重负载下的行为。
You have to decide which server side technologies that you'd use first. For an embedded system, you have severe resource constraints, so make sure you select the light weight technologies accordingly! Having said that Node.js is a great technology (http://nodejs.org/) that you may want to pay attention. I've seen some SOAP implementations for it as well. On the other side javascript based development could be very messy! You can try different solutions and start testing your system's functional behavior using tools like JMeter (http://jmeter.apache.org).
Some of the suggestions: Set up a lightweight http server (like Cherokee, lighttpd, etc) in your embedded system, then set up PHP (PHP has also some SOAP tools as well). Later change PHP with a Python or Ruby solution (like embedded Mongrel, etc). Find out how your system behaves under heavy load using JMeter.