我已经阅读了关于Django和HTTP Push的所有问题和答案.然而,没有一个提供关于如何实现所谓"彗星"功能的基本"hello world"的清晰,简洁,开端到终端的解决方案.
第一个问题(1):HTTP在多大程度上没有(至少到目前为止)为此做出的问题？所有潜在的解决方案基本上都是黑客吗？
2)目前最好的解决方案是什么？
其他解决方案？
3)nginx推送模块如何参与此讨论？
4)这些解决方案中哪一个需要替换典型的mod_wsgi/nginx(或apache)部署模型？他们为什么要这个？在任何情况下这都是有利的转变吗？
5)使用已经在Python中的解决方案的优势有多重要？
来自PyCon 2010的Alex Gaynor的演讲,我刚刚在blip.tv上观看过,它非常精彩且内容丰富,但对Django中HTTP Push的当前状态并不十分具体.他说的一件事给了我一些信心:Orbited在抽象和模拟网络套接字的概念方面做得很好.因此,当WebSockets实际着陆时,我们将处于转型的好地方.
6)HTML5 Websockets与当前解决方案有何不同？Gaynor对从Orbited过渡的难易程度的评估是否准确？
Ali*_*uip 24
如果你需要的只是彗星,我会看看evserver(http://code.google.com/p/evserver/).
它"支持[鲜]已知的异步WSGI扩展",并围绕libevent构建.像魅力一样工作,支持django.实际的处理程序代码有点难看,但它很好地扩展,因为它确实是异步io.
我已经使用了evserver而且我正在转向旋风(扭曲的龙卷风),因为我需要比evserver更多的东西.我需要真正的双向io(想想socket.io(http://socket.io/)),虽然evserver可以支持它,但我认为重新实现龙卷风的socket.io更容易在旋风中(我选择旋风而不是龙卷风,因为旋风是建立在扭曲的,因此允许更多的传输没有在扭曲(ic zeromq)实现)Socket.io支持websockets,彗星风格轮询,以及更多的交互,基于闪存的websockets.我认为在大多数实际情况下,websockets +基于flash的websockets足以支持99%(根据adobe flash的渗透率约为99%(http://www.adobe.com/products/player_census/flashplayer/version_penetration.html))一个网站访问者(只有不使用flash的人需要回退到socket.io中的一个(较少的性能和资源占用)备份传输)
请注意,虽然websockets不是http传输,因此将它们置于基于http的代理之后(例如,http模式下的haproxy)会破坏连接.更好地在备用IP或端口上为它们提供服务,以便您可以在tcp模式下进行代理(例如,在tcp模式下使用haproxy).
回答你的问题:(1)如果你不需要双向传输基于longpolling的解决方案已经足够好了(他们所做的就是保持连接打开).当你需要你的连接是有状态的,或者你需要能够发送和接收数据时,事情确实会变得很糟糕.在后一种情况下socket.io有帮助.然而,websockets是为这种情况而制作的,并且在大多数网站访问者可以使用flash的支持(通过socket.io或独立,但socket.io为那些不想安装闪存的人提供备份传输的附加好处)
(2)如果你需要的只是推,evserver是你最好的选择.它使用与客户端相同的javascripts作为轨道.另外看看socket.io(这也需要一个支持服务器,唯一可用的python是龙卷风.)
(3)它只是另一个服务器实现.如果我正确阅读它只是推动.通过将http equest从您的应用程序发送到nginx服务器来完成将数据推送到客户端.(nginx然后小心他们到达客户端).如果您对此感兴趣,请查看mongrel2(http://mongrel2.org/home)它不仅具有用于longpolling的处理程序,还用于websockets.(而不是向mongrel发出http请求,这次你使用zeromq处理程序来获取数据到你的mongrel服务器)(请注意开发人员对websockets和基于flash的websockets缺乏热情.特别是考虑到websocket协议趋于发展你可能,在某些时候,需要自己重新编码mongrel2的websocket支持支持websockets)
(4)除evserver之外的所有解决方案都用其他东西替换wsgi.虽然大多数服务器也有一些wsgi支持ontop"其他".无论您选择何种解决方案,请注意一个cpu密集或其他阻止请求不会阻止服务器.(您需要多个实例或线程).
(5)不是很重要.所有解决方案都依赖于一些自定义处理程序来将数据推送(如果适用,接收)到客户端.我提到的所有解决方案都允许这些处理程序用python编写.如果你想使用一个完全不同的框架(node.js),那么你必须权衡node.js的易用性(它被认为是简单的,但它也是实验性的,我发现很少有库实际上是稳定的)使用现有代码库和可用库的便利性(例如,如果你的应用程序需要博客,你可以插入大量的django博客,但node.js没有)也不要盯着自己对性能统计数据视而不见.除非你打算将愚蠢的预定义数据(所有基准测试所做的)推送到客户端,否则你会发现数据的实际处理增加了很多比最差的异步io实现更多的开销.(但是如果您计划同时拥有多个客户端,那么您仍然希望使用基于async io的服务器,线程并不意味着要保持数千个连接存活)
(6)websockets提供双向通信,长轮询/ comet只推送数据但不接受写入.(Socket.io通过使用两个http请求模拟这种双向支持,一个用于longpoll,一个用于发送数据.它通过(会话)id跟踪它们的相互依赖性,这是两个请求查询字符串的一部分).基于闪存的websockets类似于真正的websockets(不同之处在于它们的实现是在swf中,而不是你的浏览器).还对的WebSockets协议不遵循HTTP协议; longpolling/comet stuff(技术上websocket客户端向websocket服务器发送升级请求,升级后的协议不再是http)
支持带有django-websocket的 WebSockets ,但遗憾的是它有很多问题需要它才能正常工作; 这是该页面的引用:
免责声明(使用django-websocket时应该知道的)
大发声明 -就在此刻它在技术上不以任何方式使用的WebSocket与WSGI可能.这是一个已知问题,但由于在编写WSGI标准时做出的一些设计决策,无法以干净的方式解决这个问题.此时Websockets等内容并不存在,也无法预测.
...
但不仅WSGI是限制因素.Django本身是围绕一个简单的请求响应场景设计的,没有考虑Websockets.这也意味着现在不可能为django提供标准的符合websocket实现.然而,它以一种不那么漂亮的方式工作.所以请注意,使用django-websocket时,tcp套接字可能会受到折磨.
所以目前,WSGI:没有去; Django:即使使用django-websockets也几乎没有任何进展; 另见作者原始公告中的评论:
我不能说这看起来是个好主意.你正在以一种需要线程的方式进行长期连接.django-websocket需要线程设置,如果你有进程(因为你只有太多的进程),它将无法工作,但是线程也不能同时扩展到很多连接,所以它只是虚假的安全.你需要一个用于长期存在的异步平台,我通过在Django中运行我的应用程序,在Node.js中运行我的彗星和websocket来实现这一点.
就个人而言,如果尝试使用WebSockets(我希望是明年),我会首先尝试Twisted和Cyclone的组合.它们旨在应对WebSockets,并且可以很好地扩展.如果您正确编写代码以删除对Django的不必要的依赖,那么您应该能够在基于Twisted的系统中使用大部分代码.与使用Node.js或Comet或其他语言的任何系统相比,这是一个非常明显的优势.你也可以做一个简单的推动
最后,你还可以决定它太难了并使用外部服务来提供推送支持.那就变成了向他们的服务器发送一个简单的JSON请求,而不是担心如何建立连接以及并发将如何工作以及类似的事情.当然,您需要为此付费(虽然目前在Beta版本中可能是免费的),但您无需担心实施细节; 尽管如此,你不会拥有WebSockets的全部功能 - 只需推动支持.
我不敢相信自从我问这个问题以来已经过去六年多了。
与 Django 异步（以及相关的网络流量，例如 websockets）一直是我们社区中许多人的渴望。在过去的几年里，我一直致力于解决这个问题。
hendrix 是一个在 Twisted 上运行的 WSGI/ASGI 容器。这是一个主要由 5 名爱好者推动的项目，并得到了一些有远见的组织的帮助和资助。如今有数十家（但不是数百家）公司在生产这种产品。
我将让您阅读文档以了解为什么它是解决此问题的最佳解决方案，但有一些简单的亮点：
请参阅我在 Django-NYC（在 Buzzfeed 办公室）所做的演讲，了解更多关于为什么我认为这是这个问题的最佳答案的信息。