Django / Comet (Push): Least of all evils?

Question

我已经阅读了有关Django和HTTP Push的所有问题和解答。然而，没有人提供关于如何实现所谓的“彗星”功能的基本“问候世界”的清晰，简洁，从头到尾的解决方案。

第一个问题（1）：在何种程度上，HTTP根本没有（至少到目前为止）没有做到这一点？所有潜在的解决方案是否都是黑客？

2）什么是目前最好的解决方案？

• Orbited?
• Some other Twisted-based solution?
• Tornado?
• node.JS?
• XMPP w/ BOSH?

其他解决方案？

3）nginx push模块如何参与此讨论？

4）以下哪种解决方案需要替换典型的mod_wsgi / nginx（或apache）部署模型？他们为什么需要这个？无论如何，这是一个有利的过渡吗？

5）使用Python中已经存在的解决方案的优势有多重要？

我刚刚在blip.tv上观看了PyCon 2010上的Alex Gaynor的演示，它令人惊叹且内容丰富，但在Django的HTTP Push的当前状态方面并没有特别明确。他说的让我充满信心的一件事是：Orbited在抽象和模拟网络套接字的概念方面做得很好。因此，当WebSockets实际登陆时，我们将是过渡的好地方。

6）HTML5 Websocket与当前解决方案有何不同？Gaynor对从轨道过渡的难易程度的评估是否准确？

django 彗星

Answer 1

如果你需要的只是comet，那么我来看看evserver（http://code.google.com/p/evserver/）。

它“支持鲜为人知的异步WSGI扩展”，并且围绕libevent构建。像魅力一样工作并支持django。实际的处理程序代码有点丑陋，但由于它确实是异步io，因此可以很好地扩展。

我使用过evserver，目前正在迁移到气旋（扭曲的tornado），因为我需要的不止是evserver offsers。我需要真正的双向io（认为socket.io（http://socket.io/）），而evserver可以支持它，我认为重新实现tornado的socket.io更容易在旋风中（我选择旋风而不是tornado，因为旋风是在扭曲的基础上构建的，因此允许使用扭曲（ic zeromq）不能实现的更多传输）Socket.io支持websockets，彗星样式轮询以及更多的相互影响，基于Flash的WebSocket。我认为在大多数实际情况下，websockets +基于flash的websockets足以支持99％（根据adobe flash的渗透率约为99％（http://www.adobe.com/products/player_census/flashplayer/version_penetration.html））的网站访问者数量（仅不使用Flash的用户需要回退到socket.io（减少了性能和资源消耗）的备份传输之一）

请注意，虽然websocket并非http传输，因此将它们置于基于http的代理（例如，http模式下的haproxy）后面，但会断开连接。最好在备用IP或端口上为它们提供服务，以便你可以在TCP模式下代理（例如，在TCP模式下使用haproxy）。

要回答你的问题：（1）如果你不需要双向传输，基于长轮询的解决方案就足够了（它们所做的就是保持连接开放）。当你需要连接为全状态或需要能够发送和接收数据时，事情确实会变得很棘手。对于后一种情况，socket.io会有所帮助。但是，Websocket是针对这种情况而制作的，并且在Flash的支持下，大多数网站的访问者都可以使用它（通过socket.io或独立访问，但是socket.io为那些不想安装Flash的人提供了备份传输的额外好处）

（2）如果你只需要推送，evserver就是你的最佳选择。它在客户端使用与Orbited相同的JavaScript。另外看看socket.io（这也需要一个支持服务器，唯一可用的python是tornado。）

（3）这只是另一种服务器实现。如果我没看错的话，那只是推。通过将HTTP equest从你的应用程序发送到nginx服务器来完成将数据推送到客户端的操作。（然后nginx会注意他们到达客户）。如果你对此感兴趣，请查看mongrel2（http://mongrel2.org/home），它不仅具有用于longpolling的处理程序，还具有用于websockets的处理程序（而不是向mongrel发出http请求，这次你使用zeromq处理程序来将数据发送到Mongrel服务器）（请注意开发人员对Websocket和基于Flash的Websocket缺乏热情。尤其是考虑到Websocket协议可能会发展，在某些时候你可能需要重新编码Mongrel2的Websocket支持自己支持websockets

（4）除evserver以外的所有解决方案都将wsgi替换为其他内容。尽管大多数服务器在此“其他”之上也有一些wsgi支持。无论你选择哪种解决方案，都必须小心，一个cpu密集或其他io阻止请求不会阻止服务器。（你需要多个实例或线程）。

（5）不是很重要。所有解决方案都依赖于某些自定义处理程序，以将数据推送（并在适用时接收）到客户端。我提到的所有解决方案都允许这些处理程序以python编写。如果要使用完全不同的框架（node.js），则必须权衡一下node.js的难易程度（假定它很简单，但这也只是实验性的，我发现很少有库实际上是稳定的）使用现有代码库和可用库的便利性（例如，如果你的应用程序需要博客，那么可以插入很多django博客，而node.js则不需要），也不要对性能统计数据视而不见。除非你计划将笨拙的预定义数据（所有基准测试都执行）推送给客户端，否则你会发现实际的数据处理会增加很多比最糟糕的异步io实现还要更多的开销。（但是，如果你打算拥有多个同时运行的客户端，那么你仍然想使用基于异步io的服务器，线程化并不意味着保持数千个连接处于活动状态）

（6）websocket提供双向通信，长轮询/彗星仅推送数据，但不接受写入。（Socket.io通过使用两个http请求（一个到longpoll，一个发送数据来模拟这种双向支持。它通过两个会话查询字符串中的（会话）id跟踪它们的相互依赖性））。基于Flash的websocket与实际的websocket相似（不同之处在于，它们的实现是在swf中，而不是在浏览器中）。而且websockets协议不遵循http协议；longpolling / comet的东西可以（技术上，websocket客户端将升级请求发送到websocket服务器，升级后的协议不再是http）