因此我们有一个与大量第三方服务器通信的Django后端服务器。这些第三方服务器都使用套接字连接进行通信，而不是HTTP。每个用户对我们服务的请求都将通过许多可能的第三方服务器之一进行通信（通过套接字）。每个第三方服务器可能需要1-20秒才能响应，但通常大约需要1-5秒。当然，当用户访问我们的网页以请求其中一个第三方服务时，我们希望尽快响应我们的用户，即不要阻止我们的服务器等待响应。当第三方服务器响应时，我们希望将响应推送回用户的浏览器。
当然这是一个常见问题。但关键是我们将每5秒左右向我们的Web服务器发出请求（例如在我们的网页中使用JavaScript / AJAX）。据我所知，如果我们能够为响应创建一个websocket连接并使其保持打开状态，和/或如果我们的请求持续时间很长（例如> 30秒），那么websockets将是一个很好的方法来推动服务器推送。但是，由于各种原因我们无法做到这一点，因此我们需要在每个请求中建立一个新的websocket连接。在我看来，如果我们每隔5秒打开一个websocket，整个过程，配置websocket以匹配正确的第三方服务连接，发送命令，将该命令代理到正确的第三方服务，得到响应，代理到正确的websocket，然后将响应发送回浏览器，然后在5秒后再次执行此操作，这真的比仅仅进行基本的短轮询更好吗？我们的简短轮询方法是使用基本的AJAX调用来发送请求，然后将成功返回给浏览器。后端将代理正确的第三方服务，当结果进入时，它会将这些结果保存到MYSQL表中。我们的AJAX只会每隔一两秒发送一个轮询命令（可能带有退避，例如1,1,2,4,6,10，...秒），直到收到响应或发生超时。对此的实现肯定会更简单，并且几乎可以保证工作。在绝大多数情况下，我们会发出“每5秒一次”命令，并在第一次或第二次轮询尝试后得到回复。如果我们使用websockets，它将需要一个连接尝试加上一个或两个套接字写命令来正确配置后端代理以使用正确的后端服务，然后我们得到响应，套接字将关闭，我们必须5秒后再做一遍。
在这种情况下，短期投票工作不会很好，可能会更好吗？
答案 0 :(得分：0)
如果您只是为每个请求设置一个新的webSocket连接，那么使用webSocket比使用http请求更有开销。
每个webSocket连接都以http请求/响应开始，只是为了让webSocket初始化，然后你想发送更多的数据包 - 这比仅仅是一个http请求/响应更多来回。
这里真正的节省是解决您认为需要为每个请求创建新的webSocket连接的任何问题。这很可能是可以解决的。然后，您创建一个webSocket连接，只发送消息以发送请求和返回响应，这肯定比http轮询更有效。
要真正获得比http更高效的功能，您可以完全停止从客户端进行轮询。所以，而不是客户说'＃34;你有什么新东西吗？＆＃34;每隔5秒，客户端就会建立一个webSocket连接，指示服务器要通知它的内容，服务器然后做任何需要进行的轮询，并且只要有任何它认为客户想要的内容，它就会发送它无需等待轮询间隔即可访问客户端。客户端更快地获取数据（它不必等待下一个轮询间隔），没有空的轮询请求/响应，因此服务器使用和带宽使用都更好。