为啥 websocket-rails 需要作为独立服务器启动以支持基于非事件机的 Web 服务器？

Posted 2023-02-16

【中文标题】为啥 websocket-rails 需要作为独立服务器启动以支持基于非事件机的 Web 服务器？

【英文标题】：why websocket-rails need to started as a standalone server to support non-eventmachine based web servers?为什么 websocket-rails 需要作为独立服务器启动以支持基于非事件机的 Web 服务器？

【发布时间】：2016-10-20 03:13:59

【问题描述】：

来自 websocket-rails wiki，当我们使用 Phusion Passenger 或 Unicorn 时，websocket-rails 需要作为独立服务器启动，但我发现 faye-rails 不需要这样做。他们有什么区别？

【参考方案1】：

区别在于用于“劫持”或控制套接字的API。

这两种解决方案都将原始套接字从原始服务器中取出并独立于服务器进行处理...但是，websocket-rails 使用基于 EventMachine 的 API，而 Faye 检查不同的支持选项，例如 hijack API .

因此，当使用非基于 EventMachine 的服务器时，websocket-rails 无法将套接字从服务器中取出，而是运行一个单独的服务器，只处理 Websocket 连接。

其他方法包括根据the proposed Websocket Rack Specification draft 对websocket 协议的服务器端支持，该协议由Iodine 实现（免责声明，这是我的项目）。其他平台（即 Puma）也在努力支持该规范。

这种方法将套接字的控制权留给原始服务器，允许原始服务器处理所有协议细节。它通常允许更好的资源处理，因为套接字处理是统一的，并且资源使用通常得到更好的优化。此外，通过这种方法，可以避免代码重复，并且内存占用通常更小。

这种新规范和方法的另一个好处是，编写体面的服务器的人通常更了解网络和服务器编程问题（例如慢速客户端 DoS 攻击问题等），从而允许更健壮和安全的 Websocket 实现。

附言

如果可能，我会避免websocket-rails，ActionCable 可能会有更好的 Rails 集成，并且意外的套接字劫持可能会破坏中间件，导致奇怪的错误（在某一时刻hijack 会导致奇怪的数据库连接池问题，而连接不是返回池中）。

祝你好运！