Resetování a vypršení časového limitu nečinnosti služby Load Balancer TCP

  • Článek

Službu Standard Load Balancer můžete použít k vytvoření předvídatelnějšího chování aplikace pro vaše scénáře povolením resetování protokolu TCP v nečinnosti pro dané pravidlo. Výchozím chováním Load Balanceru je tiché vyřaďte toky při dosažení časového limitu nečinnosti toku. Povolení resetování protokolu TCP způsobí, že Load Balancer odešle obousměrné resetování protokolu TCP (pakety TCP RST) na vypršení časového limitu nečinnosti, aby informoval koncové body aplikace o vypršení časového limitu připojení a už není použitelné. Koncové body můžou v případě potřeby okamžitě navázat nové připojení.

Diagram shows default TCP reset behavior of network nodes.

Resetování protokolu TCP

Toto výchozí chování změníte a povolíte odesílání resetů PROTOKOLU TCP při vypršení časového limitu nečinnosti u příchozích pravidel překladu adres (NAT), pravidel vyrovnávání zatížení a odchozích pravidel. Pokud je pro každé pravidlo povoleno, Nástroj pro vyrovnávání zatížení odesílá obousměrné resetování protokolu TCP (pakety TCP RST) do koncových bodů klienta i serveru v době nečinnosti pro všechny odpovídající toky.

Koncové body, které přijímají pakety TCP RST, okamžitě zavře odpovídající soket. Tím se okamžitě zobrazí oznámení o vydání připojení koncového bodu a jakákoli budoucí komunikace na stejném připojení TCP selže. Aplikace můžou vyprázdnit připojení, když se soket zavře a podle potřeby znovu připojí, aniž by čekaly na vypršení časového limitu připojení TCP.

V mnoha scénářích může resetování protokolu TCP snížit potřebu odesílání protokolu TCP (nebo aplikační vrstvy) kvůli aktualizaci časového limitu nečinnosti toku.

Pokud doba nečinnosti překračuje limity konfigurace nebo u vaší aplikace dochází k nežádoucímu chování s povolenými resety protokolu TCP, můžete stále potřebovat použít protokol TCP keepalives nebo udržování aplikační vrstvy, abyste mohli monitorovat dostupnost připojení TCP. Keepalives také může zůstat užitečný pro, pokud je připojení někam v cestě, zejména vrstvy aplikace keepalives.

Pečlivě prozkoumáním celého koncového scénáře můžete určit výhody povolení resetování protokolu TCP a úpravou časového limitu nečinnosti. Pak se rozhodnete, jestli je potřeba provést další kroky k zajištění požadovaného chování aplikace.

Konfigurovatelný časový limit nečinnosti protokolu TCP

Azure Load Balancer má 4 minuty až 100minutový časový limit pro pravidla Load Balanceru, pravidla odchozích přenosů a příchozí pravidla NAT. Výchozí hodnota je 4 minuty. Pokud je doba nečinnosti delší než hodnota časového limitu, není zaručeno, že se mezi klientem a cloudovou službou udržuje relace TCP nebo HTTP.

Po zavření připojení může klientská aplikace obdržet následující chybovou zprávu: "Podkladové připojení bylo uzavřeno: Připojení, u kterého se očekávalo, že je server zavřený."

Běžným postupem je použití protokolu TCP s udržováním naživu. Tento postup udržuje připojení aktivní po delší dobu. Další informace najdete v těchto příkladech .NET. S povoleným udržováním se pakety odesílají během období nečinnosti připojení. Udržování paketů zajišťuje, že hodnota časového limitu nečinnosti není dosažená a připojení se udržuje po dlouhou dobu.

Nastavení funguje jenom pro příchozí připojení. Pokud se chcete vyhnout ztrátě připojení, nakonfigurujte tcp keep-alive s intervalem kratším než nastavení časového limitu nečinnosti nebo zvyšte hodnotu časového limitu nečinnosti. Pro podporu těchto scénářů je k dispozici podpora konfigurovatelného časového limitu nečinnosti.

Tcp keep-alive funguje ve scénářích, kdy životnost baterie není omezením. Nedoporučuje se pro mobilní aplikace. Použití protokolu TCP v mobilní aplikaci může vyprázdnit baterii zařízení rychleji.

Pořadí priorit

Je důležité vzít v úvahu, jak můžou hodnoty časového limitu nečinnosti nastavené pro různé IP adresy potenciálně interagovat.

Příchozí

  • Pokud existuje pravidlo nástroje pro vyrovnávání zatížení (příchozí) s hodnotou časového limitu nečinnosti nastavenou jinak než časový limit nečinnosti front-endové IP adresy, na kterou odkazuje, má přednost vypršení časového limitu nečinnosti front-endu ip adresy nástroje pro vyrovnávání zatížení.
  • Pokud existuje příchozí pravidlo NAT s hodnotou časového limitu nečinnosti nastavenou jinak než časový limit nečinnosti front-endové IP adresy, na kterou odkazuje, má přednost vypršení časového limitu nečinnosti front-endu IP adresy nástroje pro vyrovnávání zatížení.

Odchozí

  • Pokud existuje pravidlo odchozích přenosů s hodnotou časového limitu nečinnosti, která se liší od 4 minut (což je hodnota, na které je uzamčený časový limit odchozího nečinnosti veřejné IP adresy), má přednost vypršení časového limitu nečinnosti odchozího pravidla.
  • Vzhledem k tomu, že služba NAT Gateway bude mít vždy přednost před odchozími pravidly nástroje pro vyrovnávání zatížení (a přes veřejné IP adresy přiřazené přímo k virtuálním počítačům), použije se hodnota časového limitu nečinnosti přiřazená bráně NAT. (Na stejných řádcích se neuplatní vypršení časového limitu odchozích veřejných IP adres odchozích IP adres za 4 minuty všech IP adres přiřazených k bráně pro překlad adres (NAT GW).)

Omezení

  • Resetování PROTOKOLU TCP se odeslalo pouze během připojení TCP ve stavu NAVAZOVÁNÍ.
  • Časový limit nečinnosti protokolu TCP nemá vliv na pravidla vyrovnávání zatížení v protokolu UDP.
  • Resetování protokolu TCP není podporováno pro porty vysoké dostupnosti interního nástroje pro vyrovnávání zatížení, pokud je v cestě síťové virtuální zařízení. Alternativním řešením může být použití odchozího pravidla s resetováním PROTOKOLU TCP ze síťového virtuálního zařízení.

Další kroky