Load Balancer resetování TCP a časového limitu nečinnosti

  • Článek
  • 2 min ke čtení

Pomocí funkce Standard Load Balancer předvídatelnější chování aplikace pro vaše scénáře tím, že pro dané pravidlo povolíte resetování protokolu TCP při nečinnosti. Load Balancer výchozím chováním je tiché vyhovění toků při dosažení časového limitu nečinnosti toku. Povolení této funkce způsobí, Load Balancer při časovém limitu nečinnosti odesílat obousměrná resetování protokolu TCP (paket TCP RST). Tím se koncové body aplikace informují o tom, že připojení nemá časový limit a že už není použitelné. Koncové body mohou v případě potřeby okamžitě vytvořit nové připojení.

Load Balancer resetování protokolu TCP

Resetování protokolu TCP

Toto výchozí chování změníte a povolíte odesílání resetování protokolu TCP při časovém limitu nečinnosti u příchozích pravidel NAT, pravidel vyrovnávání zatížení a odchozích pravidel. Pokud je povoleno podle pravidla, Load Balancer odešle obousměrné resetování protokolu TCP (pakety TCP RST) do koncových bodů klienta i serveru v době časového limitu nečinnosti pro všechny odpovídající toky.

Koncové body přijímající pakety TCP RST okamžitě zavře odpovídající soket. Koncovým bodům se okamžitě zobrazí oznámení o tom, že došlo k vydání připojení, a jakákoli budoucí komunikace na stejném připojení TCP selže. Aplikace mohou vyprázdnit připojení, když se soket zavře, a podle potřeby znovu navázat připojení, aniž by musely čekat na ukončení časového limitu připojení TCP.

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

Pokud doba nečinnosti překročí dobu nečinnosti povolenou konfigurací nebo pokud se v aplikaci zobrazí nežádoucí chování při povoleném resetování protokolu TCP, stále možná budete muset k monitorování aktivity připojení TCP použít nastavení TCP keepalives (neboli keepalives aplikační vrstvy). Funkce keepalives navíc může zůstat užitečná i v případě, že se připojení nachází někde v cestě, zejména v aplikační vrstvě keepalives.

Pečlivě prozkoumejte celý scénář od konce a rozhodněte se, jestli vám povolení resetování protokolu TCP, úprava časového limitu nečinnosti a případné další kroky k zajištění požadovaného chování aplikace umožní.

Konfigurovatelný časový limit nečinnosti TCP

Azure Load Balancer má následující časový limit nečinnosti:

  • 4 až 100 minut pro odchozí pravidla
  • 4 až 30 minut pro Load Balancer a příchozí pravidla NAT

Ve výchozím nastavení je nastavená na 4 minuty. Pokud je doba nečinnosti delší než hodnota časového limitu, není zaručeno, že se mezi klientem a cloudovou službou zachová relace PROTOKOLU TCP nebo HTTP.

Když se připojení zavře, klientská aplikace se může zobrazit následující chybová zpráva: Základní připojení se zavřelo: Server uzavřel připojení, u kterých se očekávalo, že bude zachováno.

Běžným postupem je použití funkce tcp keep-alive. Tímto postupem se připojení udržuje aktivní po delší dobu. Další informace najdete v těchto příkladech rozhraní .NET. Pokud je funkce keep-alive povolená, pakety se posílají během období nečinnosti na připojení. Udržování paketů zajistí, že se nedosáhnou hodnoty časového limitu nečinnosti a že připojení se udržuje po dlouhou dobu.

Nastavení funguje jenom pro příchozí připojení. Abyste se vyhnuli ztrátě připojení, nakonfigurujte udržování protokolu TCP s nastavením časového limitu nečinnosti menším než interval, který je menší, nebo zvyšte hodnotu časového limitu nečinnosti. Pro podporu těchto scénářů byla přidána podpora konfigurovatelného časového limitu nečinnosti.

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

Omezení

  • Resetování protokolu TCP se odesílá jenom během připojení TCP ve stavu ESTABLISHED.
  • Časový limit nečinnosti protokolu TCP nemá vliv na pravidla vyrovnávání zatížení v protokolu UDP.
  • Porty S HA s ILB nepodporují resetování protokolu TCP, 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