Lastbalanserare TCP-återställning och inaktiv tidgräns

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 Balancers standardbeteende är att tyst släppa flöden när tidsgränsen för inaktivt flöde uppnås. Aktivering av TCP-återställning gör att Load Balancer skickar dubbelriktade TCP-återställningspaket (TCP-återställningspaket) vid tidsgränsen för inaktivitet för att informera programslutpunkterna om att anslutningen uppnådde tidsgränsen och inte längre kan användas. Slutpunkter kan omedelbart upprätta en ny anslutning om det behövs.

Diagrammet visar standardbeteendet för TCP-återställning för nätverksnoder.

TCP-återställning

Du ändrar det här standardbeteendet och aktiverar sändning av TCP-återställningar vid inaktiv timeout för inkommande NAT-regler, belastningsutjämningsregler och regler för utgående trafik. När det är aktiverat per regel skickar Load Balancer dubbelriktade TCP-återställningar (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 en omedelbar avisering om slutpunktens anslutningsavslutning och all framtida kommunikation över samma TCP-anslutning kommer att misslyckas. Applikationer kan rensa anslutningar när socketen stängs och återupprätta anslutningar när det behövs utan att behöva vänta på att TCP-anslutningen ska nå tidsgränsen.

I många scenarier kan en TCP-återställning minska behovet av att skicka TCP-keepalives (eller programlager) för att uppdatera tidsgränsen för inaktivitet för ett flöde.

Välj mellan TCP-reset och keepalives

Använd följande kriterier för att avgöra vilken mekanism ditt scenario behöver:

  • Aktivera TCP-återställning när du vill att endpoints omedelbart ska meddelas om att ett inaktivt flöde stängs, så att applikationer kan rensa och återupprätta anslutningar istället för att vänta på sin egen TCP-timeout.
  • Använd TCP keepalives när dina viloperioder överskrider det konfigurerbara inaktiva tidsintervallet, eller när din applikation beter sig oväntat med TCP-återställningar aktiverade. Keepalives rekommenderas inte för mobilapplikationer eftersom de tömmer enhetens batteri snabbare.
  • Använd keepalive-meddelanden på applikationslagret när anslutningen går via en proxy någonstans längs vägen, eftersom en proxy kan avsluta TCP-anslutningen som transportlagrets keepalive-meddelanden förnyar.

Genom att noggrant undersöka hela end-to-end-scenariot kan du avgöra fördelarna med att aktivera TCP-återställningar och justera vilolägestiden. Bestäm sedan om fler steg krävs för att säkerställa önskat applikationsbeteende.

Konfigurerbar tidsgräns för TCP-inaktivitet

Azure Load Balancer Standard har ett timeoutintervall från 4 till 100 minuter för lastbalanseringsregler och inkommande NAT-regler. Utgående regler har ett konfigurerbart intervall på 4 till 120 minuter. Standard är 4 minuter för alla regeltyper. Om en period av inaktivitet är längre än tidsgränsvärdet finns det ingen garanti för att TCP- eller HTTP-sessionen underhålls mellan klienten och molntjänsten. Azure Load Balancer Basic (utgått) hade ett timeoutintervall på upp till 60 minuter.

När anslutningen stängs kan klientprogrammet få följande felmeddelande: "Den underliggande anslutningen stängdes: En anslutning som förväntades hållas vid liv stängdes av servern."

Om TCP-återställningar är aktiverade och det missas av någon anledning, då kommer återställningar att ske för alla efterföljande paket. Om alternativet för TCP-återställning inte är aktiverat ignoreras paketen tyst.

En vanlig metod är att använda en TCP keep-alive. Den här metoden 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 säkerställer att tidsgränsvärdet för inaktivitet inte nås och att anslutningen upprätthålls under en längre period.

TCP keep-alive som beskrivs i detta avsnitt gäller endast inkommande anslutningar. TCP-återställning och konfigurerbar inaktivitetstimeout stöds separat för utgående regler. Om du vill undvika att förlora anslutningen konfigurerar du TCP keep-alive med ett intervall som är mindre än tidsgränsinställningen för inaktivitet eller ökar tidsgränsvärdet för inaktivitet. För att stödja dessa scenarier finns stöd för en konfigurerbar tidsgräns för inaktivitet tillgänglig.

TCP keep-alive fungerar för scenarier där batteritiden inte är en begränsning. Det rekommenderas inte för mobila program. Om du använder en TCP keep-alive i ett mobilprogram kan enhetens batteri tömmas snabbare.

Prioritetsordning

Det är viktigt att ta hänsyn till hur timeoutvärdena för inaktivitet som angetts för olika IP-adresser potentiellt kan interagera.

Inkommande

  • Om det finns en (inkommande) lastbalanserare med ett inaktivt timeout-värde som är annorlunda än tidsgränsen för inaktivitet för klientdels-IP-adressen som den refererar till, prioriteras tidsgränsen för lastbalanserarens ip-inaktiva IP-inaktiva klientdel.
  • Om det finns en inkommande NAT-regel med ett inaktivt timeout-värde som skiljer sig från inaktivitetstidsgränsen för frontend-IP-adressen som den refererar till, prioriteras tidsgränsen för inaktivitet hos lastbalanserarens frontend-IP.

Utgående

  • Om det finns en utgående regel med ett timeoutvärde för inaktivitet som skiljer sig från 4 minuter (vilket är vad den offentliga tidsgränsen för utgående IP-inaktivitet är låst vid) prioriteras tidsgränsen för utgående regelinaktivering.
  • Eftersom en NAT-gateway alltid har företräde framför regler för utgående lastbalanserare (och över offentliga IP-adresser som tilldelats direkt till virtuella datorer) används det timeout-värde för inaktivitet som tilldelats NAT-gatewayen. (På samma sätt beaktas inte den låsta offentliga IP-tidsgränsen för utgående inaktivitet på 4 minuter av ip-adresser som tilldelats NAT GW.)

Begränsningar

Dessa begränsningar gäller för TCP reset och idle timeout på Azure Load Balancer:

  • TCP-återställning skickas endast under en TCP-anslutning i ETABLERAT tillstånd.
  • Tidsgräns för inaktivitet stöds inte för lastbalanseringsregler för UDP.
  • TCP-återställning stöds inte för HA-portregler för intern lastbalanserare när en virtuell nätverksinstallation (NVA) finns i trafikflödet. Använd en regel för utgående trafik med TCP-reset från den virtuella nätverksinstallationen som en tillfällig lösning.
  • TCP-timeout för inaktivitet stöds inte för HA-portregler för intern lastbalanserare när en användardefinierad routningstabell (UDR) dirigerar trafik till den interna lastbalanseraren.

Nästa steg

  • Last updated on