Sdílet prostřednictvím

Průvodce odstraňováním potíží pro běžné problémy se službou Azure SignalR

Tento článek obsahuje pokyny k řešení potíží s některými běžnými problémy, se kterými se zákazníci můžou setkat.

Přístupový token je příliš dlouhý

Možné chyby

  • Na straně klienta ERR_CONNECTION_
  • 414 Příliš dlouhý identifikátor URI
  • 413 Příliš velký objem
  • Přístupový token nesmí být delší než 4K. 413 – Entita požadavku je příliš velká

Původní příčina

U protokolu HTTP/2 je maximální délka jedné hlavičky 4 K, takže pokud pro přístup ke službě Azure používáte prohlížeč, dojde k chybě ERR_CONNECTION_ pro toto omezení.

U klientů HTTP/1.1 nebo C# je maximální délka identifikátoru URI 12 K a maximální délka hlavičky je 16 K.

Od verze SDK 1.0.6 nebo vyšší /negotiate vyvolá 413 Payload Too Large, když je vygenerovaný přístupový token větší než 4 K.

Řešení

Ve výchozím nastavení jsou deklarace identity zahrnuté v context.User.Claims při generování přístupového tokenu JWT do ASRS(Azure SignalRService), aby se zachovaly a mohly být předány z ASRS do Hub, když se klient připojí k Hub.

V některých případech context.User.Claims se používá k ukládání velkého množství informací pro aplikační server, z nichž většina se nepoužívá Hub, ale jinými komponentami.

Vygenerovaný přístupový token se předává přes síť a pro připojení WebSocket/SSE se přístupové tokeny předávají prostřednictvím řetězců dotazů. Jako osvědčený postup doporučujeme předávat pouze nezbytné deklarace identity od klienta prostřednictvím ASRS na aplikační server, když to Hub potřebuje.

Existuje ClaimsProvider pro přizpůsobení nároků, které se předávají službě ASRS v rámci přístupového tokenu.

Pro ASP.NET Core:

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

Pro ASP.NET:

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

Máte problémy nebo zpětnou vazbu k řešení potíží? Dejte nám vědět.

Vyžaduje se protokol TLS 1.2.

Možné chyby

  • ASP.NET chyba "Není k dispozici server" č. 279
  • ASP.NET "Připojení není aktivní, data se nedají odeslat do služby." Chyba č. 324
  • Došlo k chybě při provádění požadavku HTTP na https://<API endpoint>adresu . K této chybě může dojít v případě, že certifikát serveru není správně nakonfigurovaný s HTTP.SYS v případě HTTPS. Možnou příčinou této chyby je neshoda vazby zabezpečení mezi klientem a serverem."

Původní příčina

Služba Azure podporuje pouze protokol TLS1.2 z hlediska zabezpečení. V rozhraní .NET Framework je možné, že protokol TLS1.2 není výchozím protokolem. V důsledku toho není možné úspěšně navázat připojení serveru k ASRS.

Příručka pro řešení problémů

  1. Pokud se tato chyba dá reprodukovat místně, zrušte zaškrtnutí políčka Jen můj kód, vyvolejte všechny výjimky CLR a aplikační server ladit místně, abyste zjistili, jaká výjimka je vyvolána.

    • Zrušit zaškrtnutí políčka Jen můj kód

      Zrušit zaškrtnutí políčka Jen můj kód

    • Vyvolejte výjimky CLR

      Vyvolání výjimek CLR

    • Podívejte se na výjimky vyvolané laděním kódu na straně serveru aplikace:

      Vyvolání výjimek

  2. V případě položek ASP.NET můžete také přidat následující kód Startup.cs pro povolení podrobného sledování a zobrazení chyb z protokolu.

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

Řešení

Do spouštěcího programu přidejte následující kód:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Máte problémy nebo zpětnou vazbu k řešení potíží? Dejte nám vědět.

Chyba 400 Chybný požadavek vrácena pro požadavky klientů

Původní příčina

Zkontrolujte, jestli váš požadavek klienta obsahuje více hub řetězců dotazu. Parametr hub dotazu se zachová a pokud služba zjistí více než jeden hub v dotazu, vrátí chybu 400.

Máte problémy nebo zpětnou vazbu k řešení potíží? Dejte nám vědět.

Klientské požadavky vracejí chybu 401 Neautorizovaný přístup.

Původní příčina

Výchozí hodnota životnosti JWT je v současné době jedna (1) hodina.

Pro ASP.NET Core SignalR je při použití typu přenosu WebSocket v pořádku.

Pro ASP.NET Core jiný typ přenosu, SSE a dlouhé dotazování, výchozí životnost ve výchozím nastavení znamená, že připojení může trvat maximálně jednu hodinu.

V případě služby ASP.NET SignalR klient odešle čas od času do služby požadavek "Udržet naživu", když dojde k selhání, klient přeruší připojení a již se nikdy nepřipojí. Pro ASP.NET SignalR výchozí doba života tokenu způsobí, že připojení trvá maximálně jednu hodinu pro všechny typy přenosu.

Řešení

Pokud jde o zabezpečení, rozšíření hodnoty TTL se nepodporuje. Doporučujeme přidat logiku opětovného připojení z klienta, aby se připojení restartovalo, když dojde k takové 401. Když klient restartuje připojení, vyjedná s aplikačním serverem, aby znovu získal JWT a získal obnovený token.

Tady zjistíte, jak restartovat připojení klientů.

Máte problémy nebo zpětnou vazbu k řešení potíží? Dejte nám vědět.

Požadavky klientů vracejí chybu 404 Nenalezeno

V případě trvalého připojení SignalR nejprve /negotiate ke službě Azure SignalR a pak vytvoří skutečné připojení ke službě Azure SignalR.

Příručka pro řešení problémů

  • Následujte jak zobrazit odchozí požadavky, abyste viděli požadavek od klienta na službu.
  • Zkontrolujte adresu URL požadavku, když dojde k chybě 404. Pokud adresa URL cílí na vaši webovou aplikaci a je podobná {your_web_app}/hubs/{hubName}, zkontrolujte, jestli je SkipNegotiation klient true. Klient obdrží adresu URL pro přesměrování, když se poprvé vyjedná s aplikačním serverem. Klient nesmí při použití Azure SignalR přeskočit vyjednávání.
  • Další chyba 404 může nastat, když je žádost o připojení zpracována více než pět (5) sekund po /negotiate zavolání. Pokud má požadavek vůči službě pomalou odezvu, zkontrolujte časové razítko požadavku klienta a nahlaste problém.

Máte problémy nebo zpětnou vazbu k řešení potíží? Dejte nám vědět.

404 vráceno pro žádost o opětovné připojení služby SignalR pro ASP.NET

V případě ASP.NET SignalR, když dojde k vypadnutí klientského připojení, znovu se připojí třikrát s použitím téhož connectionId, než přestane se pokoušet o připojení. /reconnect může pomoct, pokud dojde k přerušení připojení kvůli nestálým problémům se sítí, které /reconnect může úspěšně obnovit trvalé připojení. Za jiných okolností, například když je připojení klienta přerušeno v důsledku ukončení připojení ke směrovanému serveru, nebo pokud služba SignalR má různé vnitřní chyby, jako je restartování instance, převzetí služeb při selhání nebo nasazení. Spojení již neexistuje, proto /reconnect vrátí 404. Jedná se o očekávané chování /reconnect a po třech pokusech se zastaví připojení. Doporučujeme mít logiku restartování připojení, když se připojení zastaví.

Máte problémy nebo zpětnou vazbu k řešení potíží? Dejte nám vědět.

429 (Příliš mnoho požadavků) vráceno pro klientské požadavky.

Existují dva možné případy.

Počet souběžných připojení překračuje limit

V případě bezplatných instancí je limit počtu souběžných připojení 20 Pro standardní instance, limit počtu souběžných připojení na jednotku je 1 K, což znamená, že jednotka 100 umožňuje 100 K souběžných připojení.

Připojení zahrnují připojení klienta i serveru. Tady zkontrolujte, jak se počítá připojení.

Omezené vyjednávání

Pokud je současně vyjednáno příliš mnoho klientů, může dojít k omezení. Limit se vztahuje k počtu jednotek, u kterého mají jednotky s vyšším limitem vyšší počet. Kromě toho navrhujeme mít náhodné zpoždění před opětovným připojením. Podívejte se tady, kde najdete ukázky pokusů o opakování.

Máte problémy nebo zpětnou vazbu k řešení potíží? Dejte nám vědět.

Chyba 500 při vyjednávání: Služba Azure SignalR ještě není připojená, zkuste to prosím znovu později.

Původní příčina

Tato chyba se zobrazí, když není připojené připojení serveru ke službě Azure SignalR.

Příručka pro řešení problémů

Povolte trasování na straně serveru a zjistěte podrobnosti o chybě, když se server pokusí připojit ke službě Azure SignalR.

Povolení protokolování na straně serveru pro ASP.NET Core SignalR

Protokolování na straně serveru pro ASP.NET Core SignalR se integruje s protokolováním založeným na frameworku ASP.NET Core. Protokolování na straně serveru můžete povolit pomocí ConfigureLogging, ukázkové použití jako následuje:

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

Kategorie protokolování pro Azure SignalR vždy začínají Microsoft.Azure.SignalR. Pokud chcete povolit podrobné protokoly z Azure SignalR, nakonfigurujte výše uvedené předpony na úroveň Debug v souboru appsettings.json, vizte následující příklad:

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

Povolení trasování na straně serveru pro ASP.NET SignalR

Při použití verze >sady SDK = 1.0.0můžete povolit trasování přidáním následujícího příkazu: web.config(Podrobnosti)

<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>

Máte problémy nebo zpětnou vazbu k řešení potíží? Dejte nám vědět.

Dojde k výpadku připojení klienta

Když je klient připojený k Azure SignalR, trvalé připojení mezi klientem a Službou Azure SignalR může někdy z různých důvodů klesat. Tato část popisuje několik možností, které způsobují takové výpadky připojení, a obsahuje některé pokyny k identifikaci původní příčiny.

Možné chyby na straně klienta

  • 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."}

Původní příčina

Klientská připojení můžou za různých okolností klesat:

  • Pokud Hub vyvolá výjimky při příchozím požadavku
  • Když se připojení k serveru, na které klient směroval, zahodí, podrobnosti o ukončení připojení k serveru najdete v následující části.
  • Když dojde k problému s připojením k síti mezi klientem a službou SignalR Service
  • Pokud má služba SignalR několik vnitřních chyb, jako je restartování instance, převzetí služeb při selhání, nasazení atd.

Příručka pro řešení problémů

  1. Otevřete protokol na straně serveru aplikace a zjistěte, jestli se nestalo něco neobvyklého.
  2. Zkontrolujte protokol událostí na straně serveru aplikace a zjistěte, jestli se aplikační server restartoval.
  3. Vytvořte problém, který nám poskytne časový rámec, a pošlete nám e-mailem název prostředku.

Máte problémy nebo zpětnou vazbu k řešení potíží? Dejte nám vědět.

Připojení klienta se neustále zvyšuje.

Nesprávné použití připojení klienta to může způsobit. Pokud někdo zapomene zastavit nebo odstranit klienta SignalR, připojení zůstane otevřené.

Možné chyby zobrazené v metrikách služby SignalR v části Monitorování v nabídce prostředků webu Azure Portal

Klientská připojení se v metrikách Azure SignalR neustále zvyšuje po dlouhou dobu.

Neustále se zvyšuje připojení klienta.

Původní příčina

Připojení DisposeAsync klienta SignalR se nikdy nevolá a připojení zůstane otevřené.

Příručka pro řešení problémů

Zkontrolujte, jestli se klient SignalR nikdy nezavře .

Řešení

Zkontrolujte, jestli připojení zavřete. Manuálně volejte HubConnection.DisposeAsync(), abyste po použití zastavili připojení.

Příklad:

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

Běžné nesprávné využití připojení klienta

Příklad funkce Azure Functions

K tomuto problému často dochází, když někdo vytvoří připojení klienta SignalR v metodě funkce Azure místo toho, aby se jedná o statického člena ve třídě funkce. Můžete očekávat, že bude navázáno pouze jedno připojení klienta, ale místo toho se počet připojení klienta neustále zvyšuje v metrikách. Všechna tato připojení se přeruší až po restartování služby Azure Function nebo služby Azure SignalR. K tomuto chování dochází, protože funkce Azure Vytvoří pro každý požadavek jedno připojení klienta a pokud v metodě funkce nezastavíte připojení klienta, klient udržuje připojení aktivní ke službě Azure SignalR.

Řešení

  • Nezapomeňte zavřít připojení klienta, pokud ve funkci Azure používáte klienty SignalR nebo pokud používáte SignalR klienta jako singleton.
  • Místo použití klientů SignalR ve funkci Azure můžete vytvářet klienty SignalR na libovolném místě a pomocí vazeb Azure Functions pro službu Azure SignalR vyjednat připojení klienta k Azure SignalR. K odesílání zpráv můžete také využít vazbu. Ukázky pro vyjednávání klientů a odesílání zpráv najdete tady. Další informace najdete tady.
  • Pokud ve funkci Azure používáte klienty SignalR, může být pro váš scénář lepší architektura. Zkontrolujte, jestli navrhujete správnou bezserverovou architekturu. Můžete se podívat na aplikace v reálném čase se službou Azure SignalR a Azure Functions.

Máte problémy nebo zpětnou vazbu k řešení potíží? Dejte nám vědět.

Spadne připojení k serveru

Když se aplikační server spustí, na pozadí se sada Azure SDK začne inicializovat připojení serveru ke vzdálené službě Azure SignalR. Jak je popsáno v interních informacích služby Azure SignalR, Azure SignalR směruje příchozí klientské přenosy na tato připojení k serveru. Když dojde k vyřazení připojení k serveru, zavře všechna klientská připojení, která obsluhovala.

Vzhledem k tomu, že připojení mezi aplikačním serverem a službou SignalR Service jsou trvalá připojení, můžou nastat problémy s připojením k síti. V sadě Server SDK máme strategii Vždy znovu připojit pro připojení k serveru. Jsme pro, aby uživatelé jako osvědčený postup přidali do klientů logiku průběžného opětovného připojování s náhodným zpožděním, aby se zabránilo masivním současným požadavkům na server.

Pravidelně existují nové verze pro službu Azure SignalR a někdy i opravy nebo upgrady pro Celou Azure nebo občas přerušení závislých služeb. Tyto události můžou způsobit krátkou dobu přerušení služeb, ale pokud má klientská strana mechanismus odpojení nebo opětovného připojení, je účinek minimální, stejně jako jakékoli přerušení připojení na straně klienta.

Tato část popisuje několik možností, které vedou k poklesu připojení k serveru, a obsahuje některé pokyny k identifikaci původní příčiny.

Možné chyby na straně serveru

  • [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.

Původní příčina

Připojení serveru se službou je ukončeno službou ASRS (AzureSignalRService).

Vysoké využití procesoru nebo vyčerpání fondu vláken na straně serveru může způsobit vypršení časového limitu příkazu ping.

Pro ASP.NET SignalR byl ve verzi SDK 1.6.0 opraven známý problém. Upgradujte sadu SDK na nejnovější verzi.

Vyhladovění fondu vláken

Pokud váš server hladověl, znamená to, že na zpracování zpráv nefungují žádná vlákna. Žádné vlákno nereaguje v jisté metodě.

V asynchronních metodách obvykle async nad sync nebo Task.Result/Task.Wait() způsobuje tento scénář.

Podívejte se na osvědčené postupy pro výkon v ASP.NET Core.

Přečtěte si více o vyčerpání fondu vláken.

Jak zjistit hladovění fondu vláken

Zkontrolujte počet vláken. Pokud v té době nejsou žádné špičky, proveďte tyto kroky:

  • Pokud používáte službu Aplikace Azure Service, zkontrolujte počet vláken v metrikách. Max Zkontrolujte agregaci:

    Snímek obrazovky s podoknem Maximální počet vláken ve službě Aplikace Azure Service

  • Pokud používáte rozhraní .NET Framework, najdete metriky v monitorování výkonu na virtuálním počítači serveru.

  • Pokud v kontejneru používáte .NET Core, přečtěte si téma Shromažďování diagnostiky v kontejnerech.

K detekci hladovění fondu vláken můžete použít také kód:

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!");
        }
    }
}

Přidejte ho do služby:

service.AddSingleton<ThreadPoolStarvationDetector>();

Potom zkontrolujte protokol, když se server odpojil kvůli vypršení časového limitu příkazu ping.

Jak najít původní příčinu vyčerpání vlákenního fondu

Zjištění hlavní příčiny vyčerpání fondu vláken:

  • Vypněte paměť a pak analyzujte zásobník volání. Další informace naleznete v tématu Shromažďování a analýza výpisů paměti.
  • Příkaz clrmd slouží k výpisu paměti při zjištění hladovění fondu vláken. Pak zaznamenejte zásobník volání.

Příručka pro řešení problémů

  1. Otevřete serverový protokol aplikace a podívejte se, jestli se něco neobvyklého neproběhlo.
  2. Zkontrolujte protokol událostí na straně serveru aplikace a zjistěte, jestli se aplikační server restartoval.
  3. Vytvořte problém. Zadejte časový rámec a pošlete nám e-mailem název prostředku.

Máte problémy nebo zpětnou vazbu k řešení potíží? Dejte nám vědět.

Tipy

Jak zobrazit odchozí požadavek od klienta?

Jako příklad si vezměte ASP.NET Core (podobně je tomu u ASP.NET):

  • V prohlížeči: Jako příklad můžete použít F12 k otevření okna konzoly a přepnutí na kartu Síť . Možná budete muset aktualizovat stránku pomocí klávesy F5 , aby se síť zachytála od začátku.

    Síť zobrazení chromu

  • Z klienta jazyka C#:

    Místní webové přenosy můžete zobrazit pomocí Fiddleru. Přenosy protokolu WebSocket jsou podporované od verze Fiddler 4.5.

    Fiddler View Network

Jak restartovat připojení klienta?

Tady jsou ukázkové kódy obsahující logiku restartování připojení se strategií ALWAYS RETRY :

Máte problémy nebo zpětnou vazbu k řešení potíží? Dejte nám vědět.

Další kroky

V této příručce jste se dozvěděli, jak řešit běžné problémy. Můžete se také dozvědět více obecných metod řešení potíží.

Řešení potíží s připojením a doručováním zpráv

  • Last updated on