为什么聊天应用程序必须是异步的？

Question

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

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

Answer 1

与许多其他Web框架一样，Django是围绕从Web客户端接收HTTP请求，处理请求和发送响应的概念构建的。打破这种流动（为了清晰起见简化）：

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

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

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

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

然而，同步方法

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

1. 客户端向您的服务器发送POST个请求，以便向频道发送消息。

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

使用这种方法，您的服务器将比使用异步执行模型来维护持久连接更加困难，但它可以正常工作。

Answer 2

如果您要制作聊天应用，则需要使用websockets。他们会让参与对话的所有客户的更新变得更加轻松，并且会在您的应用中为您提供实时对话。话虽如此，我从未见过在同步框架中使用的websockets。

如果可以制作基于Django的同步聊天应用程序？有太多未解决的问题需要合理的答案。有多少人会使用这个聊天应用？每次谈话有多少人？这款应用需要多长时间？如果你想为你和几个朋友做一些简单的事情，那就做你所知道的。如果您为获得此应用程序而获得报酬，请使用websockets并使用异步框架。

Answer 3

你当然可以开发一个同步聊天应用程序，你不一定需要我们一个异步框架。但这一切都取决于你想要你的应用程序做什么？有多少人会使用该应用程序？是否会有多个用户和多个聊天同时进行？