Load Balancer TCP-återställning och tidsgräns för inaktivitet
Du kan använda Standard Load Balancer för att skapa ett mer förutsägbart programbeteende för dina scenarier genom att aktivera TCP-återställning vid inaktivitet för en viss regel. Load Balancer standardbeteendet är att tyst släppa flöden när tidsgränsen för inaktivitet uppnås för ett flöde. Om du aktiverar den här funktionen Load Balancer att skicka dubbelriktade TCP-återställningar (TCP RST-paket) vid tidsgräns för inaktivitet. Detta informerar dina programslutpunkter om att anslutningen har gått ut och inte längre kan användas. Slutpunkter kan omedelbart upprätta en ny anslutning om det behövs.
TCP-återställning
Du ändrar standardbeteendet och aktiverar sändning av TCP-återställningar vid tidsgräns för inaktivitet på inkommande NAT-regler, belastningsutjämningsregler och regler för utgående . När aktiverad per regel Load Balancer en dubbelriktad TCP-återställning (TCP RST-paket) till både klient- och serverslutpunkter vid tidpunkten för tidsgränsen för inaktivitet för alla matchande flöden.
Slutpunkter som tar emot TCP RST-paket stänger motsvarande socket omedelbart. Detta ger ett omedelbart meddelande till slutpunkterna om att anslutningen har släppts och eventuell framtida kommunikation om samma TCP-anslutning misslyckas. Program kan rensa anslutningar när socketen stängs och återupprätta anslutningar efter behov utan att vänta på att TCP-anslutningen till slut tar slut.
I många scenarier kan detta minska behovet av att skicka TCP(eller programlager) keepalives för att uppdatera tidsgränsen för inaktivitet i ett flöde.
Om dina inaktiva varaktigheter överskrider de som tillåts av konfigurationen eller om programmet visar ett oönskat beteende med TCP-återställningar aktiverat kan du fortfarande behöva använda TCP-keepalives (eller programlager-keepalives) för att övervaka TCP-anslutningarnas live. Dessutom kan keepalives också vara användbara när anslutningen proxylagras någonstans i sökvägen, särskilt programlagret keepalives.
Granska noggrant hela scenariot från slutet till slut för att avgöra om du kan dra nytta av att aktivera TCP-återställningar, justera tidsgränsen för inaktivitet och om ytterligare steg kan krävas för att säkerställa önskat programbeteende.
Konfigurerbar tidsgräns för TCP-inaktivitet
Azure Load Balancer har följande tidsgränsintervall för inaktivitet:
- 4 minuter till 100 minuter för regler för utgående trafik
- 4 till 30 minuter för Load Balancer och inkommande NAT-regler
Som standard är det inställt på 4 minuter. Om en inaktivitetsperiod är längre än tidsgränsvärdet finns det ingen garanti för att TCP- eller HTTP-sessionen upprätthålls mellan klienten och molntjänsten.
När anslutningen stängs kan klientprogrammet få följande felmeddelande: "Den underliggande anslutningen stängdes: En anslutning som förväntades vara vid liv stängdes av servern."
En vanlig metod är att använda en TCP-keep-alive. Den här övningen håller anslutningen aktiv under en längre period. Mer information finns i dessa .NET-exempel. Med Keep-Alive aktiverat skickas paket under perioder av inaktivitet på anslutningen. Keep-alive-paket ser till att tidsgränsvärdet för inaktivitet inte nås och att anslutningen upprätthålls under en längre period.
Inställningen fungerar endast för inkommande anslutningar. Om du vill undvika att förlora anslutningen konfigurerar du TCP Keep-Alive med ett intervall som är kortare än tidsgränsinställningen för inaktivitet eller ökar tidsgränsvärdet för inaktivitet. För att stödja dessa scenarier har stöd för en konfigurerbar tidsgräns för inaktivitet lagts till.
TCP keep-alive fungerar för scenarier där batterilivslängd inte är en begränsning. Det rekommenderas inte för mobila program. Genom att använda TCP keep-alive i ett mobilprogram kan enhetens batteri tömmas snabbare.
Begränsningar
- TCP-återställning skickas endast under TCP-anslutningen i etablerat tillstånd.
- TCP-tidsgränsen för inaktivitet påverkar inte belastningsutjämningsregler i UDP-protokollet.
- TCP-återställning stöds inte för ILB HA-portar när en virtuell nätverksinstallation finns i sökvägen. En lösning kan vara att använda utgående regel med TCP-återställning från NVA.