Ошибка подключения к signalr

SignalR sometime throws exception (approximately 4 exceptions/week) «Failed connection handshake».
I think reason could be unstable internet connection on client but I’m not sure (other reason could be wrong configuration or implementation). Has anyone the same problem? And should I solve it when most of the time it is ok?
It is MVC .Net Core app.

Here is log:

{"EventId":{"Id":5,"Name":"HandshakeFailed"},"SourceContext":"Microsoft.AspNetCore.SignalR.HubConnectionContext","TransportConnectionId":"rC64r0HCfzSQCqE7OB5h-A","RequestId":"0HLNJ4TCNIKN8:00000002","RequestPath":"/hub/status","CorrelationId":null,"ConnectionId":"0HLNJ4TCNIKN8"}

I am trying to use SignalR in my .NET CORE 3.1 webapi(server) and angular 10(client) project. API (https://localhost:44305/api) and client angular (https://localhost:44305/user/signup) project shares same domain. This is how I have setup signalR in the server side:

  1. I have created Hub class

    using Microsoft.AspNetCore.SignalR;
    namespace Web.Hubs
    {
        public class ResponseHub : Hub
        {
        }
    }
    
  2. In Startup.cs class, added services.AddSignalR() in the ConfigureService method. And Enabled CORS like :

                services.AddCors(options =>{
                    options.AddPolicy(MyAllowSpecificOrigins,
                    builder =>
                    {
                        builder
                        .WithOrigins(Configuration.GetValue<string>("https://localhost:44305"))
                        .AllowAnyHeader()
                        .AllowAnyMethod()
                        .AllowCredentials();
                    });
                });
    
    

And added following lines in configure method :

 app.UseEndpoints(endpoints =>
            {
               
                endpoints.MapControllerRoute(
                    name: "default",
                    pattern: "{controller}/{action=Index}/{id?}");
                endpoints.MapHub<ResponseHub>("/userdetails/response");
            });

In the client side,

  1. I have installed «@microsoft/signalr»: «^3.1.9» package in the angular project.

  2. created service for the signalR like :

    import { Signalrresponse } from "./signalrresponse";
    import { Router } from "@angular/router";
    import * as signalR from '@microsoft/signalr'; 
    
    @Injectable({
        providedIn: 'root'
    })
    export class SignalRService{
        constructor(private router: Router){}
     public data : Signalrresponse;
     private hubConnection: signalR.HubConnection
        public startConnection = () =>{
            this.hubConnection = new signalR.HubConnectionBuilder()
                                    .withUrl("https://localhost:44305/api/userdetails/response")
                                    .build();
            this.hubConnection
                .start()
                .then(() => console.log("Connection Started"))
                .catch(err => console.log('Error while starting connection: ' + err))
        }
    
        public addTransferChartDataListener = () =>{
            this.hubConnection.on('changestatus',(data)=>{
                console.log("Received data");
                this.data = data;
            })
        }
    }
    
    

I am getting error while trying to establish connection from the client side. Error message : Error: Failed to start the connection: Error: None of the transports supported by the client are supported by the server.
Please help me in fixing this.
Thanks.

I am trying to use SignalR in my .NET CORE 3.1 webapi(server) and angular 10(client) project. API (https://localhost:44305/api) and client angular (https://localhost:44305/user/signup) project shares same domain. This is how I have setup signalR in the server side:

  1. I have created Hub class

    using Microsoft.AspNetCore.SignalR;
    namespace Web.Hubs
    {
        public class ResponseHub : Hub
        {
        }
    }
    
  2. In Startup.cs class, added services.AddSignalR() in the ConfigureService method. And Enabled CORS like :

                services.AddCors(options =>{
                    options.AddPolicy(MyAllowSpecificOrigins,
                    builder =>
                    {
                        builder
                        .WithOrigins(Configuration.GetValue<string>("https://localhost:44305"))
                        .AllowAnyHeader()
                        .AllowAnyMethod()
                        .AllowCredentials();
                    });
                });
    
    

And added following lines in configure method :

 app.UseEndpoints(endpoints =>
            {
               
                endpoints.MapControllerRoute(
                    name: "default",
                    pattern: "{controller}/{action=Index}/{id?}");
                endpoints.MapHub<ResponseHub>("/userdetails/response");
            });

In the client side,

  1. I have installed «@microsoft/signalr»: «^3.1.9» package in the angular project.

  2. created service for the signalR like :

    import { Signalrresponse } from "./signalrresponse";
    import { Router } from "@angular/router";
    import * as signalR from '@microsoft/signalr'; 
    
    @Injectable({
        providedIn: 'root'
    })
    export class SignalRService{
        constructor(private router: Router){}
     public data : Signalrresponse;
     private hubConnection: signalR.HubConnection
        public startConnection = () =>{
            this.hubConnection = new signalR.HubConnectionBuilder()
                                    .withUrl("https://localhost:44305/api/userdetails/response")
                                    .build();
            this.hubConnection
                .start()
                .then(() => console.log("Connection Started"))
                .catch(err => console.log('Error while starting connection: ' + err))
        }
    
        public addTransferChartDataListener = () =>{
            this.hubConnection.on('changestatus',(data)=>{
                console.log("Received data");
                this.data = data;
            })
        }
    }
    
    

I am getting error while trying to establish connection from the client side. Error message : Error: Failed to start the connection: Error: None of the transports supported by the client are supported by the server.
Please help me in fixing this.
Thanks.

У меня есть простой проект клиента чата, работающий с использованием SignalR и MVC, который почти идентичен ASP.Net один (Я просто экспериментирую — код клиента идентичен). Я подключил следующее, чтобы наблюдать за происходящим:

$.connection.hub.stateChanged(function(state){console.log(state)});

Соединения работают нормально, но я заметил, что если я закрываю IIS Express и смотрю консоль в Chrome, я вижу это:

//As you would expect the state goes from connected to connecting
Object {oldState: 1, newState: 2}

//Then it times out after about 30 secs and throws this awesomeness at the console
WebSocket connection to 'ws://localhost:61623/signalr?transport=webSockets&connectionToken=VDF640emz7PFMToC6vxle_5-7QS5dZMszV4SPbQO7EFEmSSsITnwKsZreqfl4MGq8TXitG2xB5F-2ZdHp-2t3shPzN2hemTY1ZmEWlB8NOn5orUVexaSoARk9XjEO5B00&connectionData=%5B%7B%22name%22%3A%22chathub%22%7D%5D&messageId=B%2C7%7CL%2C0%7CM%2C0%7CN%2C0&tid=0' failed: WebSocket is closed before the connection is established. jquery.signalR-1.0.1.js:1117

//Reconnecting to Disconnecting - so why the error above?
Object {oldState: 2, newState: 4} 

//Then radio silence if I start IIS again...

2 вопросы:

Как избежать ошибки при неудачной попытке повторного подключения?

Почему SignalR не пытается подключиться к IIS? У меня сложилось впечатление, что в этом суть технологии…

РЕДАКТИРОВАТЬ: то же самое происходит и в FireFox

title description author ms.service ms.topic ms.date ms.author ms.openlocfilehash ms.sourcegitcommit ms.translationtype ms.contentlocale ms.lasthandoff ms.locfileid

Руководство по устранению неполадок для Службы Azure SignalR

Сведения об устранении распространенных неполадок

yjin81

signalr

conceptual

11/06/2020

yajin1

e26def56fbd03626c3efc660db57012ee1b767ea

ed7376d919a66edcba3566efdee4bc3351c57eda

MT

ru-RU

03/24/2021

105048210

Руководство по устранению неполадок службы Azure SignalR

Это руководство содержит полезные рекомендации по устранению неполадок на основе распространенных проблем, которые пользователи составили и устраняют за последние годы.

Слишком длинный маркер доступа

Возможные ошибки

  • На стороне клиента ERR_CONNECTION_
  • 414 — слишком длинный универсальный код ресурса (URI)
  • 413 (слишком большой объем полезных данных)
  • Длина маркера доступа не должна превышать 4 КБ. 413 — размер запрашиваемой сущности слишком большой

Первопричина

Для HTTP/2 Максимальная длина для одного заголовка равна 4 КБ, поэтому при использовании браузера для доступа к службе Azure произойдет ошибка ERR_CONNECTION_ для этого ограничения.

Для клиентов HTTP/1.1 или C# максимальная длина URI составляет 12 КБ, максимальная длина заголовка — 16 КБ.

При использовании пакета SDK версии 1.0.6 или более поздней /negotiate выдается исключение, 413 Payload Too Large Если созданный маркер доступа больше 4 КБ.

Решение

По умолчанию утверждения из context.User.Claims включаются при создании маркера доступа JWT для АСРС(Zure игнал R s ервице), чтобы утверждения сохранялись и можно было передавать из АСРС в, Hub когда клиент подключается к Hub .

В некоторых случаях context.User.Claims используется для хранения большого количества сведений для сервера приложений, большинство из которых не используются, Hub а другими компонентами.

Созданный маркер доступа передается через сеть, а для соединений WebSocket и SSE маркеры доступа передаются через строки запроса. Поэтому мы рекомендуем передавать на сервер приложений только необходимые утверждения от клиента через АСРС , когда это необходимо.

ClaimsProviderДля настройки утверждений, передаваемых в АСРС внутри маркера доступа, можно настроить.

Для ASP.NET Core:

services.AddSignalR()
        .AddAzureSignalR(options =>
            {
                // pick up necessary claims
                options.ClaimsProvider = context => context.User.Claims.Where(...);
            });

Для ASP.NET:

services.MapAzureSignalR(GetType().FullName, options =>
            {
                // pick up necessary claims
                options.ClaimsProvider = context.Authentication?.User.Claims.Where(...);
            });

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

Требуется TLS 1,2

Возможные ошибки

  • ASP.NET об ошибке «сервер недоступен» #279
  • ASP.NET «Подключение неактивно, данные не могут быть отправлены в службу». #324 об ошибке
  • «Произошла ошибка при выполнении HTTP-запроса к https:// . Эта ошибка может быть вызвана тем, что сертификат сервера неправильно настроен с HTTP.SYS в случае HTTPS. Эта ошибка также может быть вызвана несоответствием привязки безопасности между клиентом и сервером. «

Первопричина

Служба Azure поддерживает только TLS 1.2 в целях безопасности. В .NET Framework возможно, что TLS 1.2 не является протоколом по умолчанию. В результате невозможно успешно установить подключения сервера к АСРС.

Руководство по устранению неполадок

  1. Если эту ошибку можно воспроизвести локально, снимите флажок только мой код и вызывайте все исключения CLR и отлаживать сервер приложений локально, чтобы увидеть, что вызывает исключение.

    • Снять только мой код

      :::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/uncheck-just-my-code.png» alt-text=»Снять Только мой код»:::

    • Выдавать исключения CLR

      :::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/throw-clr-exceptions.png» alt-text=»Выдавать исключения CLR»:::

    • См. исключения, возникающие при отладке кода на стороне сервера приложений:

      :::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/tls-throws.png» alt-text=»Исключение»:::

  2. Для ASP.NET можно также добавить следующий код в, Startup.cs чтобы включить подробную трассировку и просмотреть ошибки из журнала.

    app.MapAzureSignalR(this.GetType().FullName);
    // Make sure this switch is called after MapAzureSignalR
    GlobalHost.TraceManager.Switch.Level = SourceLevels.Information;

Решение

Добавьте в запуск следующий код:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

400 для клиентских запросов возвращен неверный запрос

Первопричина

Проверьте, содержит ли ваш запрос клиента несколько hub строк запроса. hub сохраненный параметр запроса, и 400 выдаст исключение, если служба обнаружит hub в запросе более одного.

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

401 Unauthorized returned for client requests (Возврат ошибки с кодом «401 — не санкционировано» для клиентских запросов)

Первопричина

В настоящее время время жизни маркера JWT по умолчанию — 1 час.

Для ASP.NET Core SignalR, когда он использует тип транспорта WebSocket, это нормально.

Для другого типа транспорта ASP.NET Core SignalR, SSE и длительного опроса, это означает, что по умолчанию подключение может храниться не более 1 часа.

Для ASP.NET SignalR клиент отправляет /ping службе запрос на KeepAlive время от времени, когда /ping происходит сбой, клиент прерывает подключение и никогда не переключается. Это означает, что для ASP.NET SignalR время существования токена по умолчанию делает подключение продолжительностью не более 1 часа для всех типов транспорта.

Решение

В целях безопасности не рекомендуется расширять TTL. Мы рекомендуем добавить логику повторного подключения из клиента, чтобы перезапустить подключение при возникновении такой ошибки 401. Когда клиент перезапускает подключение, он будет согласовываться с сервером приложений для повторного получения маркера JWT и получения обновленного маркера.

Установите здесь , чтобы перезапустить клиентские подключения.

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

404 returned for client requests (Возврат ошибки с кодом 404 для клиентских запросов)

Для постоянного подключения SignalR сначала /negotiate необходимо установить службу Azure SignalR, а затем — реальное подключение к службе Azure SignalR.

Руководство по устранению неполадок

  • Чтобы Просмотреть исходящие запросы на получение запроса от клиента к службе, необходимо выполнить следующие требования.
  • Проверьте URL-адрес запроса при возникновении ошибки 404. Если URL-адрес предназначен для веб-приложения и аналогичен {your_web_app}/hubs/{hubName} , проверьте, имеет ли клиент SkipNegotiation true . При использовании Azure SignalR клиент получает URL-адрес перенаправления при первом согласовании с сервером приложений. Клиент не должен пропускать согласование при использовании Azure SignalR.
  • Еще один 404 может произойти, когда запрос на подключение обрабатывается более 5 секунд после /negotiate вызова. Проверьте метку времени запроса клиента и откройте сообщение о том, что в случае, если запрос к службе имеет слишком много откликов.

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

404 возвращается для запроса на повторное подключение SignalR ASP.NET

Для ASP.NET SignalR при удалении клиентского соединенияон повторно подключается в connectionId течение трех раз, прежде чем остановить подключение. /reconnect может помочь, если подключение отбрасывается из-за временных неполадок сети, которые /reconnect могут успешно восстановить постоянное подключение. В других случаях, например, подключение клиента отбрасывается из-за разрыва соединения с перенаправленным сервером, или служба SignalR имеет некоторые внутренние ошибки, такие как перезапуск экземпляра, отработка отказа или развертывание, поэтому соединение больше не существует, поэтому /reconnect возвращается 404 . Это ожидаемое поведение в /reconnect и после трех раз, когда повторная попытка подключения прекращается. Мы рекомендуем подать логику перезапуска подключения при остановке соединения.

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

429 (слишком много запросов) возвращено для клиентских запросов

Есть два способа.

Число одновременных подключений превышает предел

Для свободных экземпляров ограничение числа одновременных подключений равно 20 для стандартных экземпляров, ограничение числа одновременных подключений на единицу равно 1 K, что означает, что Unit100 допускает одновременные подключения 100-K.

Подключения включают как клиентские, так и серверные соединения. Проверьте , как подсчитываются подключения.

Слишком много запросов на согласование одновременно

Мы рекомендуем установить произвольную задержку перед повторной попыткой подключения, чтобы проверить примеры повторных попыток.

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

500 ошибка при согласовании: служба Azure SignalR еще не подключена, повторите попытку позже.

Первопричина

Эта ошибка возникает при отсутствии подключения сервера к службе SignalR Azure.

Руководство по устранению неполадок

Включите трассировку на стороне сервера, чтобы узнать сведения об ошибке, когда сервер пытается подключиться к службе Azure SignalR.

Включение ведения журнала на стороне сервера для ASP.NET Core SignalR

Ведение журнала на стороне сервера для ASP.NET Core SignalR интегрируется с ILogger журналом на основе ASP.NET Core Framework. Вы можете включить ведение журнала на стороне сервера с помощью ConfigureLogging , выбрав пример использования следующим образом:

.ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConsole();
            logging.AddDebug();
        })

Категории средств ведения журнала для Azure SignalR всегда начинаются с Microsoft.Azure.SignalR . Чтобы включить подробные журналы из Azure SignalR, настройте предыдущие префиксы для Debug уровня appsettings.jsв файле, как показано ниже:

{
    "Logging": {
        "LogLevel": {
            ...
            "Microsoft.Azure.SignalR": "Debug",
            ...
        }
    }
}

Включение трассировки на стороне сервера для ASP.NET SignalR

При использовании пакета SDK версии >= 1.0.0 можно включить трассировку, добавив следующую команду в web.config : (Details).

<system.diagnostics>
    <sources>
      <source name="Microsoft.Azure.SignalR" switchName="SignalRSwitch">
        <listeners>
          <add name="ASRS" />
        </listeners>
      </source>
    </sources>
    <!-- Sets the trace verbosity level -->
    <switches>
      <add name="SignalRSwitch" value="Information" />
    </switches>
    <!-- Specifies the trace writer for output -->
    <sharedListeners>
      <add name="ASRS" type="System.Diagnostics.TextWriterTraceListener" initializeData="asrs.log.txt" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

Разрывы соединения с клиентом

Когда клиент подключается к Azure SignalR, постоянное подключение между клиентом и Azure SignalR иногда может быть удалено по разным причинам. В этом разделе описываются некоторые возможности, вызывающие такое удаление подключения, и приводятся некоторые рекомендации по определению основной причины.

Возможные ошибки со стороны клиента

  • The remote party closed the WebSocket connection without completing the close handshake
  • Service timeout. 30.00ms elapsed without receiving a message from service.
  • {"type":7,"error":"Connection closed with an error."}
  • {"type":7,"error":"Internal server error."}

Первопричина

Клиентские подключения могут удаляться при различных обстоятельствах:

  • При Hub вырождении исключений с входящим запросом.
  • Когда соединение с сервером, на которое направляется клиент, удаляется, см. ниже в разделе с подробными сведениями о падении соединения с сервером.
  • При возникновении проблемы с сетевым подключением между клиентом и службой SignalR.
  • Когда служба SignalR имеет некоторые внутренние ошибки, такие как перезапуск экземпляра, отработка отказа, развертывание и т. д.

Руководство по устранению неполадок

  1. Откройте журнал на стороне сервера приложений, чтобы проверить, не произошло ли что-либо непредвиденное
  2. Проверьте журнал событий на стороне сервера приложений, чтобы узнать, не перезапущен ли сервер приложений.
  3. Создайте ошибку, предоставляющую время, и отправьте имя ресурса по адресу

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

Подключение клиента постоянно увеличивается

Это может быть вызвано неправильным использованием клиентского соединения. Если кто-то забыл закрыть или ликвидировать клиент SignalR, соединение остается открытым.

Возможные ошибки в метриках SignalR, которые находятся в разделе «Мониторинг» портал Azure меню ресурсов

Клиентские подключения постоянно наиграют в течение длительного времени в метриках Azure SignalR.

:::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/client-connection-increasing-constantly.jpg» alt-text=»Подключение клиента постоянно растет»:::

Первопричина

Подключение клиента SignalR DisposeAsync никогда не вызывается, подключение остается открытым.

Руководство по устранению неполадок

Проверьте, не закрывается ли клиент SignalR.

Решение

Убедитесь, что подключение закрыто. Вызов метода HubConnection.DisposeAsync() останавливает подключение вручную после его использования.

Пример:

var connection = new HubConnectionBuilder()
    .WithUrl(...)
    .Build();
try
{
    await connection.StartAsync();
    // Do your stuff
    await connection.StopAsync();
}
finally
{
    await connection.DisposeAsync();
}

Распространенное неправильное использование подключения клиента

Пример функции Azure

Эта проблема часто возникает, когда кто-то устанавливает клиентское подключение SignalR в методе функции Azure вместо того, чтобы сделать его статическим членом класса функции. Вы можете ожидать, что установлено только одно клиентское подключение, но количество подключений клиентов постоянно увеличивается в метриках, которые находятся в разделе «Мониторинг» в портал Azure меню ресурсов. все эти подключения отменяются только после перезапуска функции Azure или службы Azure SignalR. Это связано с тем, что при каждом запросе функция Azure создает одно клиентское соединение, если подключение клиента в методе функции не будет прервано, клиент будет поддерживать подключения в службе Azure SignalR.

Решение

  • Не забудьте закрыть клиентское подключение, если вы используете SignalR Clients в функции Azure или используете клиент SignalR в качестве одноэлементного.
  • Вместо использования клиентов SignalR в функции Azure вы можете создавать клиенты SignalR в любом месте и использовать привязки функций Azure для службы Azure SignalR для согласования клиента с Azure SignalR. Кроме того, можно использовать привязку для отправки сообщений. Примеры для согласования клиентов и отправки сообщений можно найти здесь. Дополнительные сведения можно найти здесь.
  • При использовании клиентов SignalR в функции Azure может быть улучшена архитектура вашего сценария. Проверьте, правильно ли разрабатывается бессерверная архитектура. Вы можете обращаться к бессерверным приложениям в режиме реального времени с привязками службы SignalR в функциях Azure.

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

Падения подключений к серверу

Когда сервер приложений запускается, в фоновом режиме пакет SDK для Azure начинает инициировать подключения к удаленному серверу Azure SignalR. Как описано в статье внутренние компоненты службы Azure SignalR, Azure SignalR направляет входящие клиентские трафик на эти подключения к серверу. После удаления соединения с сервером все клиентские подключения, которые он обслуживает, будут закрыты.

Поскольку подключения между сервером приложений и службой SignalR являются постоянными подключениями, они могут испытывать проблемы с сетевым подключением. В пакете SDK для сервера мы всегда повторно подключаем стратегию к подключениям к серверу. Рекомендуется также рекомендовать пользователям добавлять логику непрерывного повторного подключения к клиентам с произвольным временем задержки, чтобы избежать массовых одновременных запросов к серверу.

На регулярной основе для службы Azure SignalR предусмотрены новые версии версий, а иногда установка исправлений или обновления операционной системы для всего Azure, а также иногда прерывание от наших зависимых служб. Это может привести к кратковременному прерыванию работы службы, но при условии, что клиент на стороне клиента имеет механизм отключения и повторного подключения, такое влияние минимально, как и на стороне клиента, вызванного отключением и повторному подключению.

В этом разделе описаны несколько возможностей, ведущих к удалению подключения к серверу, и приводятся некоторые рекомендации по определению основной причины.

Возможные ошибки со стороны сервера

  • [Error]Connection "..." to the service was dropped
  • The remote party closed the WebSocket connection without completing the close handshake
  • Service timeout. 30.00ms elapsed without receiving a message from service.

Первопричина

Подключение к службе сервера закрыто АСРС(A Zure игнал****R s ервице).

Для времени ожидания проверки связи это может быть вызвано высокой нагрузкой ЦП или нехватка пула потоков на стороне сервера.

В ASP.NET SignalR была исправлена известная проблема в пакете SDK 1.6.0. Обновите пакет SDK до последней версии.

Нехватка ресурсов пула потоков

Если сервер не используется, это означает, что потоки не работают над обработкой сообщений. Все потоки не отвечают в определенном методе.

Обычно этот сценарий вызывается асинхронно для синхронизации или Task.Result / Task.Wait() в асинхронных методах.

См. ASP.NET Core рекомендации по повышению производительности.

См. Дополнительные сведения о нехватке пула потоков.

Как определить нехватку пула потоков

Проверьте число потоков. Если в это время нет пиковых нагрузок, сделайте следующее:

  • Если вы используете службу приложений Azure, проверьте количество потоков в метриках. Проверьте Max агрегирование:

    :::image type=»content» source=»media/signalr-howto-troubleshoot-guide/metrics-thread-count.png» alt-text=»Снимок экрана: панель «максимальное число потоков» в службе приложений Azure.»:::

  • Если вы используете платформа .NET Framework, вы можете найти метрики в системном мониторе на виртуальной машине сервера.

  • Если вы используете .NET Core в контейнере, см. раздел получение диагностических сведений в контейнерах.

Можно также использовать код для обнаружения недостаточности пула потоков:

public class ThreadPoolStarvationDetector : EventListener
{
    private const int EventIdForThreadPoolWorkerThreadAdjustmentAdjustment = 55;
    private const uint ReasonForStarvation = 6;

    private readonly ILogger<ThreadPoolStarvationDetector> _logger;

    public ThreadPoolStarvationDetector(ILogger<ThreadPoolStarvationDetector> logger)
    {
        _logger = logger;
    }

    protected override void OnEventSourceCreated(EventSource eventSource)
    {
        if (eventSource.Name == "Microsoft-Windows-DotNETRuntime")
        {
            EnableEvents(eventSource, EventLevel.Informational, EventKeywords.All);
        }
    }

    protected override void OnEventWritten(EventWrittenEventArgs eventData)
    {
        // See: https://docs.microsoft.com/en-us/dotnet/framework/performance/thread-pool-etw-events#threadpoolworkerthreadadjustmentadjustment
        if (eventData.EventId == EventIdForThreadPoolWorkerThreadAdjustmentAdjustment &&
            eventData.Payload[3] as uint? == ReasonForStarvation)
        {
            _logger.LogWarning("Thread pool starvation detected!");
        }
    }
}

Добавьте его в службу:

service.AddSingleton<ThreadPoolStarvationDetector>();

Затем проверьте журнал, когда соединение с сервером отключается по истечении времени ожидания проверки связи.

Как найти основную причину нехватка ресурсов пула потоков

Чтобы найти основную причину нехватка ресурсов пула потоков, выполните следующие действия.

  • Выведите дамп памяти, а затем проанализируйте стек вызовов. Дополнительные сведения см. в разделе Получение и анализ дампов памяти.
  • Используйте клрмд для дампа памяти при обнаружении нехватки ресурсов пула потоков. Затем зайдите в журнал стека вызовов.

Руководство по устранению неполадок

  1. Откройте журнал на стороне сервера приложений, чтобы проверить, не выполнялось ли что-либо непредвиденное.
  2. Проверьте журнал событий на стороне сервера приложений, чтобы узнать, не перезапущен ли сервер приложений.
  3. Создайте вопрос. Укажите интервал времени и отправьте имя ресурса по электронной почте.

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

Советы

  • Как просмотреть исходящий запрос от клиента?
    Возьмем ASP.NET Core один пример (ASP.NET похож):

    • Из браузера:

      Возьмем Chrome в качестве примера. можно использовать F12 , чтобы открыть окно консоли, и перейти на вкладку сеть . Возможно, потребуется обновить страницу с помощью клавиши F5 , чтобы захватить сеть с самого начала.

      :::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/chrome-network.gif» alt-text=»Сеть представления Chrome»:::

    • Из клиента C#:

      Вы можете просматривать локальные веб-трафик с помощью Fiddler. Трафик WebSocket поддерживается с момента Fiddler 4,5.

      :::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/fiddler-view-network-inline.png» alt-text=»Fiddler просмотр сети» lightbox=»./media/signalr-howto-troubleshoot-guide/fiddler-view-network.png»:::

  • Как перезапустить клиентское подключение?

    Ниже приведены примеры кодов , содержащих перезапуск логики подключения с использованием всегда стратегии повторных попыток :

    • Клиент ASP.NET Core C#

    • ASP.NET Core клиент JavaScript

    • Клиент ASP.NET C#

    • Клиент ASP.NET JavaScript

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

Дальнейшие действия

В этом руководство вы узнали, как решать распространенные проблемы. Вы также можете узнать больше об общих методах устранения неполадок.

[!div class=»nextstepaction»]
Устранение проблем с подключением и доставкой сообщений

Всем привет. Разрабатываю SPA приложение на ASP.NET Core Vue.js. Подключил SignalR. Все работает, как ожидалось. Но осталась одна проблема.
После входя в систему со спящего режима через определенное время соединение с SignalR перестает работать.

Ошибки:

Код

Error: Connection disconnected with error 'Error: Error occurred'. net::ERR_CONNECTION_RESET
Error: Failed to complete negotiation with the server
Error: Failed to start the connection
Failed to load resource: net::ERR_NAME_NOT_RESOLVED
Uncaught (in promise) Error
    at new e (vendors~main.js:7)
    at XMLHttpRequest.i.onerror

(Оффтоп) Но так же выдает ошибки и webpack (не связано с SignalR):

Код

Failed to load resource: net::ERR_NAME_NOT_RESOLVED
Failed to load resource: net::ERR_ADDRESS_UNREACHABLE
Failed to load resource: net::ERR_NETWORK_IO_SUSPENDED

Данные ошибки появляются только после входа в систему после спящего режима через определенное время.
Пытался соединяться после разрыва соединения:

Javascript
1
2
3
4
5
hubConnection.disconnected(function() {
   setTimeout(function() {
       hubConnection.start();
   }, 5000);
});

Работает только в случае отсоединения по другим причинам. Но после спящего режима не работает, т.к. он не может соединиться.

Пытался подключаться вручную с помощью метода. Срабатывало.

В чем может быть проблема? Возможно ли настроить соединение работать более стабильно? Или дело не в этом?
Заранее благодарен.

__________________
Помощь в написании контрольных, курсовых и дипломных работ, диссертаций здесь

Всем привет. Может быть я и задаю много вопросов. Пытаюсь подключиться к SignalR Hub с SPA-приложения.

this.hubConnection = new HubConnectionBuilder()
    .withUrl('http://localhost:*****/testhub')
    .configureLogging(LogLevel.Information)
    .build()

Появляется ошибка: Error: Failed to complete negotiation with the server: SyntaxError: Unexpected token < in JSON at position 0

Пробовал так:

this.hubConnection = new HubConnectionBuilder()
    .withUrl('http://localhost:*****/testhub', {
      skipNegotiation: true,
      transport: HttpTransportType.WebSockets
    })
    .configureLogging(LogLevel.Information)
    .build()

Ошибка:

WebSocket connection to ‘ws://localhost:50523/testhub’ failed: Error during WebSocket handshake: Unexpected response code: 200

Использование веб-сокетов в Startup.cs я включил. Пробовал менять версию SignalR в клиентской части, ошибка не исчезает. В многостраничных приложениях все нормально.

В чем может быть проблема?

#asp.net-core #nginx #signalr

Вопрос:

У меня возникли проблемы с подключением к серверу SignalR. Моя первоначальная настройка на nginx была

 
location /notificationHub/ {
    rewrite ^/notificationHub/?(.*) /notificationHub/$1 break;
    proxy_pass http://api_beta_server;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
  }
 

Ответ №1:

Из документации Microsoft ниже приведены минимальные необходимые параметры для включения WebSockets в Nginx

 # add this at the top of ninx config
map $http_connection $connection_upgrade {
    "~*Upgrade" $http_connection;
    default keep-alive;
}

# Configure the SignalR Endpoint inside server setting
location /hubroute {
      # App server url
      proxy_pass http://localhost:5000;

      # Configuration for WebSockets
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection $connection_upgrade;
      proxy_cache off;
      # WebSockets were implemented after http/1.0
      proxy_http_version 1.1;

      # Configuration for ServerSentEvents
      proxy_buffering off;

      # Configuration for LongPolling or if your KeepAliveInterval is longer than 60 seconds
      proxy_read_timeout 100s;

      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
    }
full documentation is on SignalR [documentaion][1]
  [1]: https://docs.microsoft.com/en-us/aspnet/core/signalr/scale?view=aspnetcore-5.0
 
title description author ms.service ms.topic ms.date ms.author ms.openlocfilehash ms.sourcegitcommit ms.translationtype ms.contentlocale ms.lasthandoff ms.locfileid

Руководство по устранению неполадок для Службы Azure SignalR

Сведения об устранении распространенных неполадок

yjin81

signalr

conceptual

11/06/2020

yajin1

e26def56fbd03626c3efc660db57012ee1b767ea

ed7376d919a66edcba3566efdee4bc3351c57eda

MT

ru-RU

03/24/2021

105048210

Руководство по устранению неполадок службы Azure SignalR

Это руководство содержит полезные рекомендации по устранению неполадок на основе распространенных проблем, которые пользователи составили и устраняют за последние годы.

Слишком длинный маркер доступа

Возможные ошибки

  • На стороне клиента ERR_CONNECTION_
  • 414 — слишком длинный универсальный код ресурса (URI)
  • 413 (слишком большой объем полезных данных)
  • Длина маркера доступа не должна превышать 4 КБ. 413 — размер запрашиваемой сущности слишком большой

Первопричина

Для HTTP/2 Максимальная длина для одного заголовка равна 4 КБ, поэтому при использовании браузера для доступа к службе Azure произойдет ошибка ERR_CONNECTION_ для этого ограничения.

Для клиентов HTTP/1.1 или C# максимальная длина URI составляет 12 КБ, максимальная длина заголовка — 16 КБ.

При использовании пакета SDK версии 1.0.6 или более поздней /negotiate выдается исключение, 413 Payload Too Large Если созданный маркер доступа больше 4 КБ.

Решение

По умолчанию утверждения из context.User.Claims включаются при создании маркера доступа JWT для АСРС(Zure игнал R s ервице), чтобы утверждения сохранялись и можно было передавать из АСРС в, Hub когда клиент подключается к Hub .

В некоторых случаях context.User.Claims используется для хранения большого количества сведений для сервера приложений, большинство из которых не используются, Hub а другими компонентами.

Созданный маркер доступа передается через сеть, а для соединений WebSocket и SSE маркеры доступа передаются через строки запроса. Поэтому мы рекомендуем передавать на сервер приложений только необходимые утверждения от клиента через АСРС , когда это необходимо.

ClaimsProviderДля настройки утверждений, передаваемых в АСРС внутри маркера доступа, можно настроить.

Для ASP.NET Core:

services.AddSignalR()
        .AddAzureSignalR(options =>
            {
                // pick up necessary claims
                options.ClaimsProvider = context => context.User.Claims.Where(...);
            });

Для ASP.NET:

services.MapAzureSignalR(GetType().FullName, options =>
            {
                // pick up necessary claims
                options.ClaimsProvider = context.Authentication?.User.Claims.Where(...);
            });

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

Требуется TLS 1,2

Возможные ошибки

  • ASP.NET об ошибке «сервер недоступен» #279
  • ASP.NET «Подключение неактивно, данные не могут быть отправлены в службу». #324 об ошибке
  • «Произошла ошибка при выполнении HTTP-запроса к https:// . Эта ошибка может быть вызвана тем, что сертификат сервера неправильно настроен с HTTP.SYS в случае HTTPS. Эта ошибка также может быть вызвана несоответствием привязки безопасности между клиентом и сервером. «

Первопричина

Служба Azure поддерживает только TLS 1.2 в целях безопасности. В .NET Framework возможно, что TLS 1.2 не является протоколом по умолчанию. В результате невозможно успешно установить подключения сервера к АСРС.

Руководство по устранению неполадок

  1. Если эту ошибку можно воспроизвести локально, снимите флажок только мой код и вызывайте все исключения CLR и отлаживать сервер приложений локально, чтобы увидеть, что вызывает исключение.

    • Снять только мой код

      :::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/uncheck-just-my-code.png» alt-text=»Снять Только мой код»:::

    • Выдавать исключения CLR

      :::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/throw-clr-exceptions.png» alt-text=»Выдавать исключения CLR»:::

    • См. исключения, возникающие при отладке кода на стороне сервера приложений:

      :::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/tls-throws.png» alt-text=»Исключение»:::

  2. Для ASP.NET можно также добавить следующий код в, Startup.cs чтобы включить подробную трассировку и просмотреть ошибки из журнала.

    app.MapAzureSignalR(this.GetType().FullName);
    // Make sure this switch is called after MapAzureSignalR
    GlobalHost.TraceManager.Switch.Level = SourceLevels.Information;

Решение

Добавьте в запуск следующий код:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

400 для клиентских запросов возвращен неверный запрос

Первопричина

Проверьте, содержит ли ваш запрос клиента несколько hub строк запроса. hub сохраненный параметр запроса, и 400 выдаст исключение, если служба обнаружит hub в запросе более одного.

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

401 Unauthorized returned for client requests (Возврат ошибки с кодом «401 — не санкционировано» для клиентских запросов)

Первопричина

В настоящее время время жизни маркера JWT по умолчанию — 1 час.

Для ASP.NET Core SignalR, когда он использует тип транспорта WebSocket, это нормально.

Для другого типа транспорта ASP.NET Core SignalR, SSE и длительного опроса, это означает, что по умолчанию подключение может храниться не более 1 часа.

Для ASP.NET SignalR клиент отправляет /ping службе запрос на KeepAlive время от времени, когда /ping происходит сбой, клиент прерывает подключение и никогда не переключается. Это означает, что для ASP.NET SignalR время существования токена по умолчанию делает подключение продолжительностью не более 1 часа для всех типов транспорта.

Решение

В целях безопасности не рекомендуется расширять TTL. Мы рекомендуем добавить логику повторного подключения из клиента, чтобы перезапустить подключение при возникновении такой ошибки 401. Когда клиент перезапускает подключение, он будет согласовываться с сервером приложений для повторного получения маркера JWT и получения обновленного маркера.

Установите здесь , чтобы перезапустить клиентские подключения.

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

404 returned for client requests (Возврат ошибки с кодом 404 для клиентских запросов)

Для постоянного подключения SignalR сначала /negotiate необходимо установить службу Azure SignalR, а затем — реальное подключение к службе Azure SignalR.

Руководство по устранению неполадок

  • Чтобы Просмотреть исходящие запросы на получение запроса от клиента к службе, необходимо выполнить следующие требования.
  • Проверьте URL-адрес запроса при возникновении ошибки 404. Если URL-адрес предназначен для веб-приложения и аналогичен {your_web_app}/hubs/{hubName} , проверьте, имеет ли клиент SkipNegotiation true . При использовании Azure SignalR клиент получает URL-адрес перенаправления при первом согласовании с сервером приложений. Клиент не должен пропускать согласование при использовании Azure SignalR.
  • Еще один 404 может произойти, когда запрос на подключение обрабатывается более 5 секунд после /negotiate вызова. Проверьте метку времени запроса клиента и откройте сообщение о том, что в случае, если запрос к службе имеет слишком много откликов.

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

404 возвращается для запроса на повторное подключение SignalR ASP.NET

Для ASP.NET SignalR при удалении клиентского соединенияон повторно подключается в connectionId течение трех раз, прежде чем остановить подключение. /reconnect может помочь, если подключение отбрасывается из-за временных неполадок сети, которые /reconnect могут успешно восстановить постоянное подключение. В других случаях, например, подключение клиента отбрасывается из-за разрыва соединения с перенаправленным сервером, или служба SignalR имеет некоторые внутренние ошибки, такие как перезапуск экземпляра, отработка отказа или развертывание, поэтому соединение больше не существует, поэтому /reconnect возвращается 404 . Это ожидаемое поведение в /reconnect и после трех раз, когда повторная попытка подключения прекращается. Мы рекомендуем подать логику перезапуска подключения при остановке соединения.

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

429 (слишком много запросов) возвращено для клиентских запросов

Есть два способа.

Число одновременных подключений превышает предел

Для свободных экземпляров ограничение числа одновременных подключений равно 20 для стандартных экземпляров, ограничение числа одновременных подключений на единицу равно 1 K, что означает, что Unit100 допускает одновременные подключения 100-K.

Подключения включают как клиентские, так и серверные соединения. Проверьте , как подсчитываются подключения.

Слишком много запросов на согласование одновременно

Мы рекомендуем установить произвольную задержку перед повторной попыткой подключения, чтобы проверить примеры повторных попыток.

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

500 ошибка при согласовании: служба Azure SignalR еще не подключена, повторите попытку позже.

Первопричина

Эта ошибка возникает при отсутствии подключения сервера к службе SignalR Azure.

Руководство по устранению неполадок

Включите трассировку на стороне сервера, чтобы узнать сведения об ошибке, когда сервер пытается подключиться к службе Azure SignalR.

Включение ведения журнала на стороне сервера для ASP.NET Core SignalR

Ведение журнала на стороне сервера для ASP.NET Core SignalR интегрируется с ILogger журналом на основе ASP.NET Core Framework. Вы можете включить ведение журнала на стороне сервера с помощью ConfigureLogging , выбрав пример использования следующим образом:

.ConfigureLogging((hostingContext, logging) =>
        {
            logging.AddConsole();
            logging.AddDebug();
        })

Категории средств ведения журнала для Azure SignalR всегда начинаются с Microsoft.Azure.SignalR . Чтобы включить подробные журналы из Azure SignalR, настройте предыдущие префиксы для Debug уровня appsettings.jsв файле, как показано ниже:

{
    "Logging": {
        "LogLevel": {
            ...
            "Microsoft.Azure.SignalR": "Debug",
            ...
        }
    }
}

Включение трассировки на стороне сервера для ASP.NET SignalR

При использовании пакета SDK версии >= 1.0.0 можно включить трассировку, добавив следующую команду в web.config : (Details).

<system.diagnostics>
    <sources>
      <source name="Microsoft.Azure.SignalR" switchName="SignalRSwitch">
        <listeners>
          <add name="ASRS" />
        </listeners>
      </source>
    </sources>
    <!-- Sets the trace verbosity level -->
    <switches>
      <add name="SignalRSwitch" value="Information" />
    </switches>
    <!-- Specifies the trace writer for output -->
    <sharedListeners>
      <add name="ASRS" type="System.Diagnostics.TextWriterTraceListener" initializeData="asrs.log.txt" />
    </sharedListeners>
    <trace autoflush="true" />
  </system.diagnostics>

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

Разрывы соединения с клиентом

Когда клиент подключается к Azure SignalR, постоянное подключение между клиентом и Azure SignalR иногда может быть удалено по разным причинам. В этом разделе описываются некоторые возможности, вызывающие такое удаление подключения, и приводятся некоторые рекомендации по определению основной причины.

Возможные ошибки со стороны клиента

  • The remote party closed the WebSocket connection without completing the close handshake
  • Service timeout. 30.00ms elapsed without receiving a message from service.
  • {"type":7,"error":"Connection closed with an error."}
  • {"type":7,"error":"Internal server error."}

Первопричина

Клиентские подключения могут удаляться при различных обстоятельствах:

  • При Hub вырождении исключений с входящим запросом.
  • Когда соединение с сервером, на которое направляется клиент, удаляется, см. ниже в разделе с подробными сведениями о падении соединения с сервером.
  • При возникновении проблемы с сетевым подключением между клиентом и службой SignalR.
  • Когда служба SignalR имеет некоторые внутренние ошибки, такие как перезапуск экземпляра, отработка отказа, развертывание и т. д.

Руководство по устранению неполадок

  1. Откройте журнал на стороне сервера приложений, чтобы проверить, не произошло ли что-либо непредвиденное
  2. Проверьте журнал событий на стороне сервера приложений, чтобы узнать, не перезапущен ли сервер приложений.
  3. Создайте ошибку, предоставляющую время, и отправьте имя ресурса по адресу

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

Подключение клиента постоянно увеличивается

Это может быть вызвано неправильным использованием клиентского соединения. Если кто-то забыл закрыть или ликвидировать клиент SignalR, соединение остается открытым.

Возможные ошибки в метриках SignalR, которые находятся в разделе «Мониторинг» портал Azure меню ресурсов

Клиентские подключения постоянно наиграют в течение длительного времени в метриках Azure SignalR.

:::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/client-connection-increasing-constantly.jpg» alt-text=»Подключение клиента постоянно растет»:::

Первопричина

Подключение клиента SignalR DisposeAsync никогда не вызывается, подключение остается открытым.

Руководство по устранению неполадок

Проверьте, не закрывается ли клиент SignalR.

Решение

Убедитесь, что подключение закрыто. Вызов метода HubConnection.DisposeAsync() останавливает подключение вручную после его использования.

Пример:

var connection = new HubConnectionBuilder()
    .WithUrl(...)
    .Build();
try
{
    await connection.StartAsync();
    // Do your stuff
    await connection.StopAsync();
}
finally
{
    await connection.DisposeAsync();
}

Распространенное неправильное использование подключения клиента

Пример функции Azure

Эта проблема часто возникает, когда кто-то устанавливает клиентское подключение SignalR в методе функции Azure вместо того, чтобы сделать его статическим членом класса функции. Вы можете ожидать, что установлено только одно клиентское подключение, но количество подключений клиентов постоянно увеличивается в метриках, которые находятся в разделе «Мониторинг» в портал Azure меню ресурсов. все эти подключения отменяются только после перезапуска функции Azure или службы Azure SignalR. Это связано с тем, что при каждом запросе функция Azure создает одно клиентское соединение, если подключение клиента в методе функции не будет прервано, клиент будет поддерживать подключения в службе Azure SignalR.

Решение

  • Не забудьте закрыть клиентское подключение, если вы используете SignalR Clients в функции Azure или используете клиент SignalR в качестве одноэлементного.
  • Вместо использования клиентов SignalR в функции Azure вы можете создавать клиенты SignalR в любом месте и использовать привязки функций Azure для службы Azure SignalR для согласования клиента с Azure SignalR. Кроме того, можно использовать привязку для отправки сообщений. Примеры для согласования клиентов и отправки сообщений можно найти здесь. Дополнительные сведения можно найти здесь.
  • При использовании клиентов SignalR в функции Azure может быть улучшена архитектура вашего сценария. Проверьте, правильно ли разрабатывается бессерверная архитектура. Вы можете обращаться к бессерверным приложениям в режиме реального времени с привязками службы SignalR в функциях Azure.

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

Падения подключений к серверу

Когда сервер приложений запускается, в фоновом режиме пакет SDK для Azure начинает инициировать подключения к удаленному серверу Azure SignalR. Как описано в статье внутренние компоненты службы Azure SignalR, Azure SignalR направляет входящие клиентские трафик на эти подключения к серверу. После удаления соединения с сервером все клиентские подключения, которые он обслуживает, будут закрыты.

Поскольку подключения между сервером приложений и службой SignalR являются постоянными подключениями, они могут испытывать проблемы с сетевым подключением. В пакете SDK для сервера мы всегда повторно подключаем стратегию к подключениям к серверу. Рекомендуется также рекомендовать пользователям добавлять логику непрерывного повторного подключения к клиентам с произвольным временем задержки, чтобы избежать массовых одновременных запросов к серверу.

На регулярной основе для службы Azure SignalR предусмотрены новые версии версий, а иногда установка исправлений или обновления операционной системы для всего Azure, а также иногда прерывание от наших зависимых служб. Это может привести к кратковременному прерыванию работы службы, но при условии, что клиент на стороне клиента имеет механизм отключения и повторного подключения, такое влияние минимально, как и на стороне клиента, вызванного отключением и повторному подключению.

В этом разделе описаны несколько возможностей, ведущих к удалению подключения к серверу, и приводятся некоторые рекомендации по определению основной причины.

Возможные ошибки со стороны сервера

  • [Error]Connection "..." to the service was dropped
  • The remote party closed the WebSocket connection without completing the close handshake
  • Service timeout. 30.00ms elapsed without receiving a message from service.

Первопричина

Подключение к службе сервера закрыто АСРС(A Zure игнал****R s ервице).

Для времени ожидания проверки связи это может быть вызвано высокой нагрузкой ЦП или нехватка пула потоков на стороне сервера.

В ASP.NET SignalR была исправлена известная проблема в пакете SDK 1.6.0. Обновите пакет SDK до последней версии.

Нехватка ресурсов пула потоков

Если сервер не используется, это означает, что потоки не работают над обработкой сообщений. Все потоки не отвечают в определенном методе.

Обычно этот сценарий вызывается асинхронно для синхронизации или Task.Result / Task.Wait() в асинхронных методах.

См. ASP.NET Core рекомендации по повышению производительности.

См. Дополнительные сведения о нехватке пула потоков.

Как определить нехватку пула потоков

Проверьте число потоков. Если в это время нет пиковых нагрузок, сделайте следующее:

  • Если вы используете службу приложений Azure, проверьте количество потоков в метриках. Проверьте Max агрегирование:

    :::image type=»content» source=»media/signalr-howto-troubleshoot-guide/metrics-thread-count.png» alt-text=»Снимок экрана: панель «максимальное число потоков» в службе приложений Azure.»:::

  • Если вы используете платформа .NET Framework, вы можете найти метрики в системном мониторе на виртуальной машине сервера.

  • Если вы используете .NET Core в контейнере, см. раздел получение диагностических сведений в контейнерах.

Можно также использовать код для обнаружения недостаточности пула потоков:

public class ThreadPoolStarvationDetector : EventListener
{
    private const int EventIdForThreadPoolWorkerThreadAdjustmentAdjustment = 55;
    private const uint ReasonForStarvation = 6;

    private readonly ILogger<ThreadPoolStarvationDetector> _logger;

    public ThreadPoolStarvationDetector(ILogger<ThreadPoolStarvationDetector> logger)
    {
        _logger = logger;
    }

    protected override void OnEventSourceCreated(EventSource eventSource)
    {
        if (eventSource.Name == "Microsoft-Windows-DotNETRuntime")
        {
            EnableEvents(eventSource, EventLevel.Informational, EventKeywords.All);
        }
    }

    protected override void OnEventWritten(EventWrittenEventArgs eventData)
    {
        // See: https://docs.microsoft.com/en-us/dotnet/framework/performance/thread-pool-etw-events#threadpoolworkerthreadadjustmentadjustment
        if (eventData.EventId == EventIdForThreadPoolWorkerThreadAdjustmentAdjustment &&
            eventData.Payload[3] as uint? == ReasonForStarvation)
        {
            _logger.LogWarning("Thread pool starvation detected!");
        }
    }
}

Добавьте его в службу:

service.AddSingleton<ThreadPoolStarvationDetector>();

Затем проверьте журнал, когда соединение с сервером отключается по истечении времени ожидания проверки связи.

Как найти основную причину нехватка ресурсов пула потоков

Чтобы найти основную причину нехватка ресурсов пула потоков, выполните следующие действия.

  • Выведите дамп памяти, а затем проанализируйте стек вызовов. Дополнительные сведения см. в разделе Получение и анализ дампов памяти.
  • Используйте клрмд для дампа памяти при обнаружении нехватки ресурсов пула потоков. Затем зайдите в журнал стека вызовов.

Руководство по устранению неполадок

  1. Откройте журнал на стороне сервера приложений, чтобы проверить, не выполнялось ли что-либо непредвиденное.
  2. Проверьте журнал событий на стороне сервера приложений, чтобы узнать, не перезапущен ли сервер приложений.
  3. Создайте вопрос. Укажите интервал времени и отправьте имя ресурса по электронной почте.

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

Советы

  • Как просмотреть исходящий запрос от клиента?
    Возьмем ASP.NET Core один пример (ASP.NET похож):

    • Из браузера:

      Возьмем Chrome в качестве примера. можно использовать F12 , чтобы открыть окно консоли, и перейти на вкладку сеть . Возможно, потребуется обновить страницу с помощью клавиши F5 , чтобы захватить сеть с самого начала.

      :::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/chrome-network.gif» alt-text=»Сеть представления Chrome»:::

    • Из клиента C#:

      Вы можете просматривать локальные веб-трафик с помощью Fiddler. Трафик WebSocket поддерживается с момента Fiddler 4,5.

      :::image type=»content» source=»./media/signalr-howto-troubleshoot-guide/fiddler-view-network-inline.png» alt-text=»Fiddler просмотр сети» lightbox=»./media/signalr-howto-troubleshoot-guide/fiddler-view-network.png»:::

  • Как перезапустить клиентское подключение?

    Ниже приведены примеры кодов , содержащих перезапуск логики подключения с использованием всегда стратегии повторных попыток :

    • Клиент ASP.NET Core C#

    • ASP.NET Core клиент JavaScript

    • Клиент ASP.NET C#

    • Клиент ASP.NET JavaScript

Возникли проблемы или отзывы об устранении неполадок? Сообщите нам об этом.

Дальнейшие действия

В этом руководство вы узнали, как решать распространенные проблемы. Вы также можете узнать больше об общих методах устранения неполадок.

[!div class=»nextstepaction»]
Устранение проблем с подключением и доставкой сообщений

  • Ошибка подключения к psn
  • Ошибка подключения к openid провайдеру 1c
  • Ошибка подключения к my kaspersky как убрать
  • Ошибка подключения к ksc
  • Ошибка подключения к dss код ошибки 12030