Máy chủ web nhúng với trình phân tích cú pháp XML tích hợp

Question

Tôi có yêu cầu tích hợp máy chủ web vào một thiết bị được nhúng chạy Linux và đang trong quá trình đánh giá OSS và dịch vụ thương mại.

Yêu cầu hệ thống không đặc biệt chặt chẽ: - Bộ nhớ chạy tối đa 10MB, - Có thể dự phòng 20% ​​+ ARM 300MHz và nhiều hơn nữa trong các cụm, UI sẽ nằm trong jQuery và JSON, hàng trăm trang KB liên kết một chục tệp CSS và JS trong vòng một giây.

Yêu cầu tính năng: - Hỗ trợ HTTPS, - Hơn 10 kết nối đồng thời, - Được kiểm tra tốt trước các cuộc tấn công DOS.

Có thể đánh giá cao trình phân tích cú pháp XML tích hợp để cơ sở triển khai SOAP.

Không phải là người hâm mộ PHP, nhưng không chắc chắn về Javascript phía máy chủ, và không quen thuộc với Lua. Vì vậy, tìm kiếm các đề xuất cho các giải pháp tạo khuôn mẫu, có lẽ là một chồng dựa trên Python.

Đã được xem xét discussions on SO và lists on Wikipedia. Nhận thức được thttpd, Mongoose, Cherokee, Appweb.

Tại thời điểm này, tôi mời chi tiết kỹ thuật đề xuất và thảo luận về các lựa chọn triển khai, dựa trên trải nghiệm đầu tiên trong triển khai chất lượng sản xuất.

Answer 1

Khi nói đến một chồng máy chủ python đơn giản, sự kết hợp mà tôi đã nghe thường xuyên nhất trong cộng đồng để thực hiện nhẹ là CherryPy (để cung cấp máy chủ WSGI luồng-ren) với Werkzeug (để tạo cấu trúc cơ bản của ứng dụng) Cả hai đều rất khác nhau về WSGI mà tốc độ phát triển đáng kể.

Có một số ghi chú khá tốt phác thảo so sánh khuôn khổ python cơ bản (mặc dù không phải trong một môi trường nhúng, nhưng nhấn mạnh vào việc triển khai nhẹ.) at this question, in which Alex "the Machine" Martelli weighed in for these two.

Nếu bạn có khả năng chi phí của dịch viên python (mà tôi giả sử là ok khi bạn bao gồm nó trong danh sách đủ điều kiện của bạn), werkzeug là một cách tuyệt vời để thiết lập một ứng dụng bao gồm các điểm cuối đơn giản. Các câu trả lời có thể được bắt chước nội tuyến để hỗ trợ trong việc xuất các lib UI của bạn (Jquery, v.v.). Có những ví dụ tuyệt vời về tài liệu Werkzeug.

Một trong những tài nguyên tốt nhất mà tôi có thể tìm thấy khi so sánh các máy chủ WSGI (để đáp ứng nhu cầu kết nối đồng thời cao và khả năng sống sót của DOS) tại Nicholas Piel's blog post on the subject, nơi CherryPy xếp hạng là một trong những bang tốt nhất -cho-bạn-buck "tài nguyên để tăng tốc độ khôn ngoan. Máy chủ WSGI trong Cherry đang triển khai sẵn sàng, và điều này có thể được sử dụng như là quá trình máy chủ cung cấp môi trường cho ứng dụng Werkzeug của bạn, do đó bạn không cần phải thực hiện một cái gì đó nặng hơn như Apache với mod_wsgi. Cherry có thể dễ dàng có khả năng trung bình khoảng 2000 r/ps với thời gian đáp ứng tốt dưới một giây trong khi tải trọng vừa phải.

Vì tôi không biết bạn sẽ triển khai loại thiết bị nào, tôi nên đề cập đến cả hai nền tảng này đều được cập nhật thường xuyên, vì vậy cũng nên xem xét xem liệu lý do phân bổ tài nguyên mạng có cập nhật hay không thiết bị không thực tế.

Bằng cách kết hợp mô-đun minidom python (v2.6 +) với định tuyến điểm cuối trong Werkzeug, bạn cũng nên hưởng lợi từ tốc độ phát triển rất tốt. Việc xây dựng một lược đồ url phức tạp rất đơn giản bằng cách sử dụng tính năng Map của Werkzeug và hướng dẫn tại trang tài liệu của họ cung cấp một tóm tắt tuyệt vời về điều này. Giữa hai, nó không phải là quá khó khăn để có được dịch vụ web của bạn và chạy.

Answer 2

Bạn phải quyết định công nghệ phía máy chủ nào bạn muốn sử dụng trước tiên. Đối với một hệ thống nhúng, bạn có các ràng buộc tài nguyên nghiêm trọng, vì vậy hãy chắc chắn rằng bạn chọn các công nghệ trọng lượng nhẹ cho phù hợp! Có nói rằng Node.js là một công nghệ tuyệt vời (http://nodejs.org/) mà bạn có thể muốn chú ý. Tôi đã nhìn thấy một số triển khai SOAP cho nó là tốt. Ở phía bên kia phát triển dựa trên javascript có thể rất lộn xộn! Bạn có thể thử các giải pháp khác nhau và bắt đầu kiểm tra hành vi chức năng của hệ thống bằng các công cụ như JMeter (http://jmeter.apache.org).

Một số gợi ý: Thiết lập máy chủ http gọn nhẹ (như Cherokee, lighttpd, v.v.) trong hệ thống nhúng của bạn, sau đó thiết lập PHP (PHP cũng có một số công cụ SOAP). Sau đó thay đổi PHP bằng một giải pháp Python hoặc Ruby (như là Mongrel được nhúng, v.v.). Tìm hiểu xem hệ thống của bạn hoạt động như thế nào dưới tải nặng bằng JMeter.

Answer 3

Tôi giả sử rằng mục đích của máy chủ web nhúng của bạn là cung cấp giao diện quản trị cho cấu hình, hoạt động và trạng thái.

Để tiết lộ, công ty chúng tôi xây dựng và triển khai các giao diện web giao diện trên nhiều hệ thống nhúng với thông số tương tự như những gì bạn mô tả dựa trên sản phẩm của chúng tôi, Web. Bạn có thể tìm hiểu thêm về phương pháp của chúng tôi tại http://uweb.workware.net.au/, và bạn có thể đọc một bài báo tôi đã trình bày tại Hội nghị Embedded Linux 2010 tại http://workware.net.au/papers/embedded-scripting.pdf cung cấp một số chi tiết về cách chúng tôi cân bằng kích thước và hiệu suất liên quan đến với việc triển khai nhanh chóng thông qua kịch bản .

Bạn có hai tùy chọn rộng. Đầu tiên là sử dụng một khung công tác như µWeb, hoặc máy chủ Barracuda (đã đề cập ở trên), hoặc một khung nguồn mở chẳng hạn như luci (http://luci.subsignal.org/trac). Thứ hai là để sử dụng máy chủ web có trọng lượng nhẹ như máy chủ bạn đề cập đến ở trên và sau đó xây dựng khung của riêng bạn (có lẽ dựa trên jQuery và JSON). Tùy chọn thứ hai sẽ mất nhiều thời gian hơn và bảo mật là một mối lo ngại khi bạn giải quyết các cuộc tấn công XSS, CRSF và DOS.

Trong mọi trường hợp, tôi đặc biệt khuyên bạn nên tránh xa PHP, Python hoặc Javascript phía máy chủ. Đây là tất cả quá đói cho một nền tảng ARM 300MHz.

Tại sao yêu cầu cho XML và SOAP nếu giao diện người dùng quản trị của bạn sẽ là là jQuery và JSON? Bạn có yêu cầu riêng cho SOAP hỗ trợ không? Nếu vậy, gSOAP có lẽ là một sự lựa chọn hợp lý (đó là một vài năm kể từ khi tôi sử dụng nó lần cuối).

Liên quan đến https và 10+ phiên đồng thời, lưu ý rằng bắt tay SSL ban đầu là tài nguyên đáng kể chuyên sâu và nền tảng được nhúng. Nếu bạn đang thiết lập yêu cầu mới thường xuyên (do các phiên mới hoặc do yêu cầu không được pipelined), nền tảng sẽ gặp khó khăn. Bạn có thể chỉ có thể thiết lập 1-2 kết nối SSL/giây.

Answer 4

Nếu bạn chỉ có 10MB, thì nhiều đề xuất nằm ngoài câu hỏi: nút và ruby ​​sẽ nhanh chóng vượt quá dấu chân này chỉ với một ứng dụng nhỏ. PHP sẽ bắt đầu ở mức tối thiểu khoảng 8MB và có thể nhanh chóng chuyển đến 20 + MB. Chúng tôi đã thấy một trang web với một ứng dụng quản lý PHP 50MB. Chắc chắn không phải là một lựa chọn tốt cho nhúng trừ khi bạn có GB để phụ tùng.

Tôi đã sử dụng Appweb với ESP là khung MVC ngôn ngữ c và Ejscript là Javascript phía máy chủ. Ejscript có trình phân tích cú pháp XML và có thể xử lý yêu cầu SOAP. Appweb bao gồm một trình phân tích cú pháp XML rất cơ bản. Bạn sẽ cần libxml nếu bạn muốn xử lý SOAP mức cao.

Appweb 4 có bảo vệ DOS tốt. Bạn có thể giới hạn số lượng yêu cầu đồng thời từ một máy khách với chỉ thị LimitRequestPerClient. LimitParseTimeout cũng giúp nhanh chóng đóng các yêu cầu DOS không kết thúc tiêu đề của chúng. Hộp cát bảo mật Appweb có rất nhiều chỉ thị để bạn mô tả tải của bạn - điều này giúp cho DOS và các mối đe dọa bảo mật khác.

Lựa chọn khác của bạn sẽ là sử dụng Javascript thuần túy và sử dụng Ejscript có công cụ http của Appweb được tích hợp sẵn trong đó.