python – 为什么聊天应用程序必须是异步的?

我需要为我的Web服务实现一个聊天应用程序(用Django Rest api框架编写).在做了一些谷歌搜索后,我发现可用的Django聊天应用程序都已弃用,不再受支持了.我找到的所有DIY(自己动手)解决方案都使用Tornado或Twisted框架.

所以,我的问题是:是否可以制作基于Django的同步聊天应用程序?我需要使用任何异步框架吗?我在后端编程方面经验很少,所以我希望尽可能简单.

解决方法:

与许多其他Web框架一样,Django是围绕从Web客户端接收HTTP请求,处理请求和发送响应的概念构建的.打破这种流动(为简化起见简化):

>远程客户端打开与Django服务器的TCP连接.
>客户端向服务器发送HTTP请求,其中包含路径,某些标头以及可能的正文.
>服务器发送HTTP响应.
>连接已关闭
>服务器返回到等待新连接的状态.

聊天服务器,如果需要在某种程度上是实时的,则需要有所不同:它需要与连接的客户端保持许多同时打开的连接,以便在通道上发布新消息时,相应的客户端会得到相应的通知.

一种现代的实现方式是使用WebSockets.客户端和服务器之间的通信流以HTTP请求开始,如上所述,但是客户端向服务器发送特殊的升级HTTP请求,要求会话切换从简单的请求/响应范例到持久的“全双工”通信模型,客户端和服务器都可以在任何时间向两个方向发送消息.

与多个并发客户端的连接需要持久的事实意味着您不能拥有一个简单的执行模型,其中您的服务器一次只能处理一个请求,这通常发生在您调用同步服务器的情况中. Tornado和Twisted使用多线程进行网络连接的不同模型,因此可以保持多个连接打开并由服务器同时处理,并使聊天服务成为可能.

尽管如此,同步方法

话虽如此,有一些方法可以实现一个非常简单,不可扩展的聊天服务,具有明显的延迟:

>客户端向服务器执行POST请求以向通道发送消息.
>客户端向服务器执行定期GET请求,以向他们订阅的频道请求任何新消息.他们发送这些请求的速率基本上是聊天应用的刷新率.

使用这种方法,您的服务器将比使用异步执行模型来维护持久连接更加困难,但它会起作用.

上一篇:javascript – 验证用户在聊天脚本中的存在


下一篇:android – 如何在我的应用程序中创建这种类型的聊天布局?