Share via

Gids voor het oplossen van veelvoorkomende problemen met Azure SignalR Service

  • Artikel

Dit artikel bevat richtlijnen voor probleemoplossing voor enkele veelvoorkomende problemen die klanten kunnen tegenkomen.

Toegangstoken te lang

Mogelijke fouten

  • Clientzijde ERR_CONNECTION_
  • 414 URI te lang
  • 413 Nettolading te groot
  • Het toegangstoken mag niet langer zijn dan 4K. 413 Aanvraagentiteit te groot

Hoofdoorzaak

Voor HTTP/2 is de maximale lengte voor één header 4 K, dus als u een browser gebruikt voor toegang tot de Azure-service, treedt er een fout ERR_CONNECTION_ op voor deze beperking.

Voor HTTP/1.1- of C#-clients is de maximale URI-lengte 12 K, de maximale headerlengte is 16 K.

Met SDK-versie 1.0.6 of hoger /negotiate wordt het 413 Payload Too Large gegenereerde toegangstoken groter dan 4 K.

Oplossing

Claims uit context.User.Claims worden standaard opgenomen bij het genereren van JWT-toegangstoken naar ASRS (Azure SignalRService), zodat de claims worden bewaard en kunnen worden doorgegeven van ASRS aan het Hub moment dat de client verbinding maakt met de Hub.

In sommige gevallen context.User.Claims worden veel informatie opgeslagen voor app-server, waarvan de meeste niet worden gebruikt door Hubs, maar door andere onderdelen.

Het gegenereerde toegangstoken wordt doorgegeven via het netwerk en voor WebSocket-/SSE-verbindingen worden toegangstokens doorgegeven via queryreeksen. Daarom raden we aan om alleen de benodigde claims van de client via ASRS door te geven aan uw app-server wanneer de Hub nodig heeft.

U kunt ClaimsProvider de claims aanpassen die worden doorgegeven aan ASRS in het toegangstoken.

Voor ASP.NET Core:

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

Voor ASP.NET:

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

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

TLS 1.2 vereist

Mogelijke fouten

  • ASP.NET fout 'Geen server beschikbaar' #279
  • ASP.NET 'De verbinding is niet actief, gegevens kunnen niet naar de service worden verzonden'. fout 324
  • 'Er is een fout opgetreden tijdens het indienen van de HTTP-aanvraag naar https://<API endpoint>. Deze fout kan zijn omdat het servercertificaat niet correct is geconfigureerd met HTTP.SYS in het HTTPS-geval. Deze fout kan ook worden veroorzaakt door een onjuiste overeenkomst van de beveiligingsbinding tussen de client en de server.

Hoofdoorzaak

Azure Service biedt alleen ondersteuning voor TLS1.2 voor beveiligingsproblemen. Met .NET Framework is TLS1.2 mogelijk niet het standaardprotocol. Als gevolg hiervan kunnen de serververbindingen met ASRS niet tot stand worden gebracht.

Guide voor probleemoplossing

  1. Als deze fout lokaal kan worden gereproduceerd, schakelt u Just My Code uit en genereert u alle CLR-uitzonderingen en foutopsporing op de app-server om te zien welke uitzondering wordt gegenereerd.

    • Alleen mijn code uitschakelen

      Uncheck Just My Code

    • CLR-uitzonderingen genereren

      Throw CLR exceptions

    • Bekijk de uitzonderingen die optreden bij het opsporen van fouten in de code aan de serverzijde van de app:

      Exception throws

  2. Voor ASP.NET kunt u ook de volgende code toevoegen om Startup.cs gedetailleerde tracering in te schakelen en de fouten in het logboek te bekijken.

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

Oplossing

Voeg de volgende code toe aan uw opstartproces:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

400 Ongeldige aanvraag geretourneerd voor clientaanvragen

Hoofdoorzaak

Controleer of uw clientaanvraag meerdere hub queryreeksen heeft. hub is een bewaarde queryparameter en 400 genereert als de service meer dan één hub in de query detecteert.

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

401 - Niet gemachtigd geretourneerd voor clientaanvragen

Hoofdoorzaak

Momenteel is de standaardwaarde van de levensduur van het JWT-token één (1) uur.

Voor ASP.NET Core SignalR is het goed wanneer het webSocket-transporttype gebruikt.

Voor ASP.NET Core SignalR's andere transporttype, SSE en lange polling, betekent de standaardlevensduur standaard dat de verbinding maximaal één uur kan blijven bestaan.

Voor ASP.NET SignalR verzendt de client van tijd tot tijd een /ping 'keep alive'-aanvraag naar de service, wanneer de /ping fout optreedt, wordt de verbinding afgebroken en wordt nooit opnieuw verbinding gemaakt. Voor ASP.NET SignalR duurt de standaardtokenlevensduur de verbinding maximaal één uur voor alle transporttypen.

Oplossing

Voor beveiligingsproblemen wordt het uitbreiden van TTL niet aangemoedigd. We raden u aan opnieuw verbindingslogica van de client toe te voegen om de verbinding opnieuw op te starten wanneer dergelijke 401 plaatsvindt. Wanneer de client de verbinding opnieuw start, onderhandelt deze met de app-server om het JWT-token opnieuw op te halen en een vernieuwd token op te halen.

Kijk hier hoe u clientverbindingen opnieuw start.

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

404 geretourneerd voor clientaanvragen

Voor een permanente SignalR-verbinding wordt eerst /negotiate de Azure SignalR-service gebruikt en wordt vervolgens de echte verbinding met de Azure SignalR-service tot stand gebracht.

Guide voor probleemoplossing

  • Volg hoe u uitgaande aanvragen kunt weergeven om de aanvraag van de client naar de service op te halen.
  • Controleer de URL van de aanvraag wanneer 404 plaatsvindt. Als de URL gericht is op uw web-app en vergelijkbaar is met {your_web_app}/hubs/{hubName}, controleert u of de client SkipNegotiation is true. De client ontvangt een omleidings-URL wanneer deze voor het eerst onderhandelt met de app-server. De client mag de onderhandeling niet overslaan bij het gebruik van Azure SignalR.
  • Een andere 404 kan optreden wanneer de verbindingsaanvraag meer dan vijf (5) seconden na /negotiate het aangeroepen wordt verwerkt. Controleer de tijdstempel van de clientaanvraag en open een probleem voor ons als de aanvraag voor de service een traag antwoord heeft.

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

404 geretourneerd voor ASP.NET herverbindingsaanvraag van SignalR

Voor ASP.NET SignalR, wanneer de clientverbinding afneemt, wordt deze drie keer opnieuw verbonden met hetzelfde connectionId voordat de verbinding wordt gestopt. /reconnect kan helpen als de verbinding wordt verbroken vanwege onregelmatige netwerkproblemen waarmee /reconnect de permanente verbinding kan worden hersteld. Onder andere omstandigheden wordt de clientverbinding verbroken omdat de gerouteerde serververbinding is verbroken, of signalR-service heeft een aantal interne fouten, zoals het opnieuw opstarten/failover/implementeren van het exemplaar, de verbinding bestaat niet meer, dus /reconnect retourneert 404. Dit is het verwachte gedrag voor /reconnect en na drie keer opnieuw proberen de verbinding te stoppen. We raden u aan om logica voor het opnieuw opstarten van de verbinding te gebruiken wanneer de verbinding stopt.

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

429 (Te veel aanvragen) geretourneerd voor clientaanvragen

Er zijn twee mogelijke situaties.

Het aantal gelijktijdige verbindingen overschrijdt de limiet

Voor gratis exemplaren is de limiet voor het aantal gelijktijdige verbindingen 20 Voor standaardexemplarenis de limiet voor gelijktijdige verbindingen per eenheid 1 K, wat betekent dat Unit100 gelijktijdige verbindingen van 100 K toestaat.

De verbindingen omvatten zowel client- als serververbindingen. controleer hier hoe verbindingen worden geteld.

Te veel onderhandelingsaanvragen tegelijk

We raden u aan een willekeurige vertraging te hebben voordat u opnieuw verbinding maakt. Controleer hier op voorbeelden voor opnieuw proberen.

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

500 Fout bij onderhandelen: Azure SignalR Service is nog niet verbonden. Probeer het later opnieuw

Hoofdoorzaak

Deze fout wordt gerapporteerd wanneer er geen serververbinding is met Azure SignalR Service verbonden.

Guide voor probleemoplossing

Schakel tracering aan de serverzijde in om de foutdetails te achterhalen wanneer de server verbinding probeert te maken met Azure SignalR Service.

Logboekregistratie aan de serverzijde inschakelen voor ASP.NET Core SignalR

Logboekregistratie aan de serverzijde voor ASP.NET Core SignalR kan worden geïntegreerd met de ILogger logboekregistratie op basis van het ASP.NET Core-framework. U kunt logboekregistratie aan de serverzijde als volgt inschakelen met behulp van ConfigureLoggingeen voorbeeldgebruik:

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

Logboekregistratiecategorieën voor Azure SignalR beginnen altijd met Microsoft.Azure.SignalR. Als u gedetailleerde logboeken van Azure SignalR wilt inschakelen, configureert u de voorgaande voorvoegsels die Debug u in uw bestand appsettings.json wilt e-mailen, zoals hieronder:

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

Traceringen aan de serverzijde inschakelen voor ASP.NET SignalR

Wanneer u SDK-versie >= 1.0.0gebruikt, kunt u traceringen inschakelen door het volgende toe te voegen aan 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>

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

Clientverbinding daalt

Wanneer de client is verbonden met De Azure SignalR, kan de permanente verbinding tussen de client en Azure SignalR soms om verschillende redenen afnemen. In deze sectie worden verschillende mogelijkheden beschreven die een dergelijke verbinding veroorzaken en vindt u enkele richtlijnen voor het identificeren van de hoofdoorzaak.

Mogelijke fouten aan de clientzijde

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

Hoofdoorzaak

Clientverbindingen kunnen onder verschillende omstandigheden afnemen:

  • Wanneer Hub uitzonderingen worden veroorzaakt met de binnenkomende aanvraag
  • Wanneer de serververbinding, waarnaar de client is gerouteerd, afneemt, raadpleegt u de onderstaande sectie voor meer informatie over serververbindingen
  • Wanneer er een netwerkverbindingsprobleem optreedt tussen client en SignalR Service
  • Wanneer SignalR Service enkele interne fouten heeft, zoals opnieuw opstarten van exemplaren, failover, implementatie, enzovoort

Guide voor probleemoplossing

  1. Open het logboek aan de serverzijde van de app om te zien of er iets abnormaal is gebeurd
  2. Controleer het gebeurtenislogboek aan de serverzijde van de app om te zien of de app-server opnieuw is opgestart
  3. Maak een probleem aan ons door het tijdsbestek op te geven en stuur de resourcenaam per e-mail naar ons

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

Clientverbinding neemt voortdurend toe

Dit kan worden veroorzaakt door onjuist gebruik van de clientverbinding. Als iemand vergeet de SignalR-client te stoppen/verwijderen, blijft de verbinding geopend.

Mogelijke fouten in de metrische gegevens van SignalR die zich in de sectie Bewaking van het resourcemenu van Azure Portal bevindt

Clientverbindingen stijgen voortdurend voor langere tijd in de metrische gegevens van Azure SignalR.

Client connection increasing constantly

Hoofdoorzaak

SignalR-clientverbinding wordt DisposeAsync nooit aangeroepen, de verbinding blijft open.

Guide voor probleemoplossing

Controleer of de SignalR-client nooit wordt gesloten.

Oplossing

Controleer of u verbinding sluit. Roep handmatig HubConnection.DisposeAsync() aan om de verbinding te stoppen nadat u deze hebt gebruikt.

Bijvoorbeeld:

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

Veelvoorkomend onjuist gebruik van clientverbindingen

Azure Function-voorbeeld

Dit probleem treedt vaak op wanneer iemand een SignalR-clientverbinding tot stand brengt in een Azure Function-methode in plaats van het een statisch lid te maken in de functieklasse. U kunt verwachten dat er slechts één clientverbinding tot stand is gebracht, maar in plaats daarvan ziet u dat het aantal clientverbindingen voortdurend toeneemt in metrische gegevens. Al deze verbindingen worden pas uitgevoerd nadat de Azure-functie of Azure SignalR-service opnieuw is opgestart. Dit gedrag komt doordat Azure Function voor elke aanvraag één clientverbinding maakt en als u de clientverbinding niet stopt in de functiemethode, houdt de client de verbindingen actief met de Azure SignalR-service.

Oplossing

  • Vergeet niet om de clientverbinding te sluiten als u SignalR-clients in de Azure-functie gebruikt of SignalR-client als een singleton gebruikt.
  • In plaats van SignalR-clients te gebruiken in de Azure-functie, kunt u overal anders SignalR-clients maken en Azure Functions-bindingen voor Azure SignalR Service gebruiken om te onderhandelen over de client naar Azure SignalR. En u kunt ook de binding gebruiken om berichten te verzenden. Voorbeelden voor het onderhandelen over de client en het verzenden van berichten vindt u hier. Meer informatie vindt u hier.
  • Wanneer u SignalR-clients in De Azure-functie gebruikt, is er mogelijk een betere architectuur voor uw scenario. Controleer of u een juiste serverloze architectuur ontwerpt. U kunt verwijzen naar serverloze toepassingen in realtime met de SignalR Service-bindingen in Azure Functions.

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

Serververbinding daalt

Wanneer de app-server wordt gestart, begint de Azure SDK op de achtergrond serververbindingen met de externe Azure SignalR te initiëren. Zoals beschreven in Internals of Azure SignalR Service, routeert Azure SignalR binnenkomend clientverkeer naar deze serververbindingen. Zodra een serververbinding is verbroken, worden ook alle clientverbindingen gesloten.

Omdat de verbindingen tussen de app-server en SignalR Service permanente verbindingen zijn, kunnen ze netwerkverbindingsproblemen ondervinden. In de Server SDK hebben we een Always Reconnect-strategie met serververbindingen. Als best practice raden we gebruikers ook aan om continue herconnectielogica toe te voegen aan de clients met een willekeurige vertragingstijd om enorme gelijktijdige aanvragen naar de server te voorkomen.

Regelmatig zijn er nieuwe versiereleases voor de Azure SignalR-service en soms worden er patches of upgrades voor de hele Azure-toepassing uitgevoerd of worden er af en toe onderbrekingen van onze afhankelijke services uitgevoerd. Deze gebeurtenissen kunnen een korte periode van serviceonderbreking veroorzaken, maar zolang de clientzijde een mechanisme voor verbinding verbreken/opnieuw verbinden heeft, is het effect minimaal, net als elke clientzijde veroorzaakt dat de verbinding opnieuw tot stand is gebracht.

In deze sectie worden verschillende mogelijkheden beschreven die leiden tot het verwijderen van serververbindingen en vindt u enkele richtlijnen voor het identificeren van de hoofdoorzaak.

Mogelijke fouten die aan de serverzijde worden gezien

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

Hoofdoorzaak

Serverserviceverbinding wordt gesloten door ASRS (Azure SignalRService).

Voor pingtime-out kan dit worden veroorzaakt door een hoog CPU-gebruik of een threadpool aan de serverzijde.

Voor ASP.NET SignalR is een bekend probleem opgelost in SDK 1.6.0. Upgrade uw SDK naar de nieuwste versie.

Verhongering van threadpool

Als uw server verhongeert, betekent dit dat er geen threads aan berichtverwerking werken. Alle threads reageren niet in een bepaalde methode.

Normaal gesproken wordt dit scenario veroorzaakt door asynchroon synchroniseren of door Task.Result/Task.Wait() in asynchrone methoden.

Zie ASP.NET Best practices voor coreprestaties.

Meer informatie over de starvatie van threadpools.

Starvation van threadpools detecteren

Controleer het aantal threads. Als er op dat moment geen pieken zijn, voert u de volgende stappen uit:

  • Als u Azure-app Service gebruikt, controleert u het aantal threads in metrische gegevens. Controleer de Max aggregatie:

    Screenshot of the Max thread count pane in Azure App Service.

  • Als u .NET Framework gebruikt, kunt u metrische gegevens vinden in de prestatiemeter op uw server-VM.

  • Als u .NET Core in een container gebruikt, raadpleegt u Diagnostische gegevens verzamelen in containers.

U kunt ook code gebruiken om de starvatie van threadgroepen te detecteren:

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://learn.microsoft.com/dotnet/framework/performance/thread-pool-etw-events#threadpoolworkerthreadadjustmentadjustment
        if (eventData.EventId == EventIdForThreadPoolWorkerThreadAdjustmentAdjustment &&
            eventData.Payload[2] as uint? == ReasonForStarvation)
        {
            _logger.LogWarning("Thread pool starvation detected!");
        }
    }
}

Voeg deze toe aan uw service:

service.AddSingleton<ThreadPoolStarvationDetector>();

Controleer vervolgens uw logboek wanneer de verbinding met de server is verbroken door een pingtime-out.

De hoofdoorzaak van starvatie van threadpools vinden

De hoofdoorzaak van de starvatie van threadpools vinden:

  • Dump het geheugen en analyseer vervolgens de aanroepstack. Zie Geheugendumps verzamelen en analyseren voor meer informatie.
  • Gebruik clrmd om het geheugen te dumpen wanneer de starvatie van threadpools wordt gedetecteerd. Registreer vervolgens de aanroepstack.

Guide voor probleemoplossing

  1. Open het logboek aan de serverzijde van de app om te zien of er iets abnormaal is gebeurd.
  2. Controleer het gebeurtenislogboek aan de serverzijde van de app om te zien of de app-server opnieuw is opgestart.
  3. Maak een probleem. Geef het tijdsbestek op en stuur de resourcenaam naar ons.

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

Tips

Hoe kan ik de uitgaande aanvraag van de client bekijken?

Neem ASP.NET Core bijvoorbeeld (ASP.NET is vergelijkbaar):

  • Vanuit de browser: Neem Chrome als voorbeeld, u kunt F12 gebruiken om het consolevenster te openen en over te schakelen naar het tabblad Netwerk. Mogelijk moet u de pagina vernieuwen met F5 om het netwerk vanaf het begin vast te leggen.

    Chrome View Network

  • Vanaf C#-client:

    U kunt lokale webverkeer weergeven met Fiddler. WebSocket-verkeer wordt ondersteund sinds Fiddler 4.5.

    Fiddler View Network

Hoe start u de clientverbinding opnieuw op?

Hier volgen de voorbeeldcodes die verbindingslogica opnieuw opstarten met de STRATEGIE ALWAYS RETRY :

Hebt u problemen of feedback over de probleemoplossing? Laat het ons weten.

Volgende stappen

In deze handleiding hebt u geleerd hoe u de veelvoorkomende problemen kunt afhandelen. U kunt ook meer algemene methoden voor probleemoplossing leren.

Connectiviteits- en berichtbezorgingsproblemen oplossen