SignalR长轮询反复调用/negotiate和/hub POST，偶尔在Azure上返回404

Question

我们已经在运行在Azure ()上的SignalR核心5.0Web项目上启用了ASP.NET。我们的SignalR客户端是一个使用@microsoft/signalr NPM包(Version5.0.11)的瘦客户机。

我们在/api/hub/notification有一个枢纽。

对于我们的大多数客户来说，所有的事情都能像预期的那样工作，web套接字连接已经建立，我们可以从客户机到服务器调用方法，反之亦然。

对于我们的几个客户端，我们在短时间内看到了大量对POST /api/hub/notification/negotiate和POST /api/hub/notification的请求(每个客户端每分钟有多个请求)。由于我们看到了POST /api/hub/notification请求，这些客户端似乎转而使用长轮询而不是使用web套接字。

我们怀疑受影响的客户端可能会坐在代理或防火墙后面，这会禁止web套接字，因此连接一开始就会切换到长轮询。

下面的屏幕截图显示了在短时间内对单个用户的集线器端点的请求。列表很长，因为这个模式重复，只要用户已经打开我们的网站。我们看到两件奇怪的事情：

1. 客户端每15秒重复调用/negotiate两次。
2. 对POST /notification?id=<connectionId>的调用只需15秒，下面具有相同连接ID的调用将返回一个404响应。然后重复该模式，并再次调用/negotiate。

​

​

出于测试目的，我们只在客户端启用了长轮询。这也适用于我们的预期。不幸的是，我们目前无法访问出现这种行为的浏览器或用户的网络，因此我们很难重现这个问题。

一些更多的注释：

1. 我们目前只有一个Web应用程序实例在运行。
2. 我们使用Redis背板在未来的扩展场景。
3. ARR关联cookie被启用，Azure Web应用程序中的Web套接字也被启用。
4. Web实例不存在CPU使用率高或内存使用率高的问题。
5. 除了添加Redis背板外，我们没有更改任何SignalR选项。我们只使用services.AddSignalR().AddStackExchangeRedis(...)和endpoints.MapHub<NotificationHub>("/api/hub/notification")。
6. 该网站运行在HTTPS上。

• 是什么原因导致这些对/negotiate的重复调用和来自集线器端点的404返回？
• 如何在不访问发生此问题的客户端的情况下进一步调试该问题？

更新

我们现在为@microsoft/signalr包实现了一个自定义记录器，我们在configureLogger()重载中使用它。这个记录器登录到我们的Application中，它允许我们跟踪那些发生问题的客户机的客户端日志。

下面的屏幕截图显示了单个客户端日志条目的简短片段。

​

​

我们看到WebSocket连接失败(未能启动传输"WebSockets“.)并使用回退传输ServerSentEvents。我们看到成功连接了HttpConnection的日志，但是在选择ServerSentEvents传输后整整15秒后，发送握手请求失败，服务器服务器返回握手错误:握手被取消。在此之后，会发生更多相应的错误，并关闭连接。之后，连接再次建立，一切都从新开始，15秒之后会出现一个新的手工共享错误，依此类推。

为什么客户端发送握手请求要花这么长时间？似乎是问题所在，因为这对服务器来说太长了，服务器由于超时而取消了连接。

我们仍然认为这可能与客户端的网络(代理、防火墙等)有关。

费德勒

我们使用Fiddler来阻止WebSockets进行测试。正如预期的那样，回退机制启动并使用ServerSentEvents作为传输。与我们从问题中看到的日志相反，握手请求是立即发送的，而不是15秒后发送的。然后一切都如预期的那样运作。

​

​

Answer 1

您应该检查您在项目中使用的、免费的还是标准的定价层。

您应该更改Standard Tier中的连接字符串。如果您仍然使用免费层，有一些限制。

官方文件：Azure SignalR服务限制