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

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 tiše vyřadit datové toky při dosažení časového limitu nečinnosti. Povolení resetování TCP způsobí, že Load Balancer po vypršení časového limitu nečinnosti odešle obousměrné TCP reset pakety, aby informoval koncové body vaší aplikace, že připojení vypršelo a už není použitelné. Koncové body můžou v případě potřeby okamžitě navázat nové připojení.

Resetování protokolu TCP

Toto výchozí chování změníte a povolíte odesílání TCP resetů při nečinném vypršení časového limitu u NAT pravidel, 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 uvolnění připojení koncového bodu a jakákoli budoucí komunikace na stejném TCP připojení bude selhávat. Aplikace můžou uvolnit připojení, když se soket uzavře, a znovu je navázat podle potřeby, aniž by čekaly na vypršení časového limitu připojení TCP.

Ve mnoha scénářích může reset TCP snížit potřebu odesílání udržovacích signálů TCP (nebo aplikační vrstvy) k obnovení časového limitu nečinnosti spojení.

Pokud doba nečinnosti překračuje limity konfigurace nebo aplikace vykazuje nežádoucí chování při aktivovaném resetování TCP, můžete stále potřebovat použít monitorovací signály TCP nebo signály udržování aktivity na úrovni aplikace, abyste mohli nadále sledovat aktivitu připojení TCP. Keepalive signály mohou také zůstat užitečné, když je připojení umístěno na trase, zejména keepalive signály aplikační vrstvy.

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 Standard má časový limit od 4 do 100 minut pro pravidla vyrovnávání zatížení, odchozí pravidla 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. Azure Load Balancer Basic má až 60minutový časový limit.

Po zavření připojení může klientská aplikace obdržet následující chybovou zprávu: "Základní připojení bylo uzavřeno: Připojení, u kterého se očekávalo, že zůstane aktivní, bylo uzavřeno serverem."

Pokud je povolené resetování protokolu TCP a z nějakého důvodu se zmešká, resetuje se pro všechny následné pakety. Pokud možnost resetování PROTOKOLU TCP není povolená, pakety se bezobslužně zahodí.

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 Keep-Alive jsou pakety odesílány, když je připojení nečinné. Keep-alive pakety zajišťují, že nedojde k dosažení hodnoty časového limitu nečinnosti a připojení je udržováno 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í funkce keep-alive protokolu TCP v mobilní aplikaci může rychleji vybít baterii zařízení.

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 doby nečinnosti, která se liší od 4 minut (na kterou je zamčený časový limit nečinnosti odchozí komunikace veřejné IP adresy), má přednost časový limit 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. (Ve stejném duchu, vypršení časového limitu 4 minut pro nečinnost odchozích veřejných IP adres přiřazených k bráně NAT GW není bráno v úvahu.)

Omezení

• Resetování PROTOKOLU TCP se odesílá pouze během připojení TCP ve stavu NAVÁZÁNO.
• Pro pravidla vyrovnávání zatížení UDP se nepodporuje časový limit nečinnosti.
• Resetování protokolu TCP se nepodporuje u portů s vysokou dostupností 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 TCP ze síťového virtuálního zařízení.
• Vypršení časového limitu nečinnosti protokolu TCP není podporováno u portů s vysokou dostupností interního nástroje pro vyrovnávání zatížení (ILB), když se k přesměrování provozu do interního nástroje pro vyrovnávání zatížení používá trasa definovaná uživatelem (UDR).

Další kroky

• Přečtěte si o Standardním vyrovnávání zatížení.
• Přečtěte si informace o odchozích pravidlech.
• Konfigurace protokolu TCP RST při vypršení časového limitu nečinnosti