TCP-reset en inactieve time-out van load balancer

U kunt Standard Load Balancer gebruiken om een beter voorspelbaar toepassingsgedrag voor uw scenario's te maken door TCP Reset in te schakelen voor inactiviteit voor een bepaalde regel. Het standaardgedrag van Load Balancer is om verkeer stilletjes te verwijderen wanneer de inactiviteitstijd van een stroom is bereikt. Als u TCP-reset inschakelt, verzendt Load Balancer bidirectionele TCP-resetpakketten bij een idle-timeout om uw toepassingseindpunten te informeren dat de verbinding is verlopen en niet meer bruikbaar is. Eindpunten kunnen zo nodig onmiddellijk een nieuwe verbinding tot stand brengen.

Diagram toont het standaardgedrag van TCP-reset van netwerkknooppunten.

Opnieuw instellen van TCP

U verandert dit standaardgedrag en schakelt het verzenden van TCP-resets in bij tijdsoverschrijding voor inkomende NAT-regels, load balancing regels en uitgaande regels. Wanneer deze optie per regel is ingeschakeld, verzendt Load Balancer bidirectionele TCP-resets (TCP RST-pakketten) naar zowel client- als servereindpunten op het moment van time-out voor inactiviteit voor alle overeenkomende stromen.

Eindpunten die TCP RST-pakketten ontvangen, sluiten de bijbehorende socket onmiddellijk. Dit biedt een onmiddellijke melding met betrekking tot de beëindiging van de verbinding van het eindpunt, waardoor toekomstige communicatie op dezelfde TCP-verbinding mislukt. Toepassingen kunnen verbindingen opschonen wanneer de socket wordt gesloten en verbindingen opnieuw tot stand worden gebracht als dat nodig is, zonder te wachten op een time-out van de TCP-verbinding.

Voor veel scenario's kan een TCP-reset de noodzaak verminderen om TCP-keepalives (of toepassingslaag) te verzenden om de time-out voor inactiviteit van een stroom te vernieuwen.

Kies tussen TCP-reset en keepalives

Gebruik de volgende criteria om te bepalen welk mechanisme jouw scenario nodig heeft:

  • Schakel TCP-reset in wanneer je eindpunten direct wilt laten melden dat een inactieve flow is gesloten, zodat applicaties kunnen opmaken en verbindingen herstellen in plaats van te wachten op hun eigen TCP-timeout.
  • Gebruik TCP keepalives wanneer je idle-periodes de configureerbare idle-timeout-range overschrijden, of wanneer je applicatie zich onverwacht gedraagt met TCP-resets ingeschakeld. Keepalives worden niet aanbevolen voor mobiele applicaties, omdat ze de batterij van apparaten sneller leegtrekken.
  • Gebruik keepalives op applicatieniveau wanneer de verbinding ergens in de keten via een proxy loopt, omdat een proxy de TCP-verbinding kan beëindigen die door keepalives op transportniveau in stand wordt gehouden.

Door het hele end-to-end scenario zorgvuldig te onderzoeken, kun je de voordelen bepalen van het inschakelen van TCP-resets en het aanpassen van de idle-timeout. Bepaal vervolgens of er meer stappen nodig zijn om het gewenste applicatiegedrag te waarborgen.

Configureerbare time-out voor TCP-inactiviteit

Azure Load Balancer Standard heeft een timeout-interval van 4 minuten tot 100 minuten voor load balancer-regels en inkomende NAT-regels. Uitgaande regels kunnen worden ingesteld van 4 tot 120 minuten. De standaard is 4 minuten voor alle regeltypes. Als een periode van inactiviteit langer is dan de time-outwaarde, is er geen garantie dat de TCP- of HTTP-sessie wordt onderhouden tussen de client en uw cloudservice. Azure Load Balancer Basic (met pensioen) had een timeout-interval tot 60 minuten.

Wanneer de verbinding is gesloten, kan de clienttoepassing het volgende foutbericht ontvangen: 'De onderliggende verbinding is gesloten: een verbinding die naar verwachting actief blijft, is gesloten door de server.'

Als TCP-resets zijn ingeschakeld en ze om welke reden dan ook worden gemist, worden de resets toegepast op de volgende pakketten. Als de TCP-resetoptie niet is ingeschakeld, worden pakketten stilletjes laten vallen.

Een veelvoorkomende procedure is het gebruik van een TCP-keep-alive. Deze procedure houdt de verbinding gedurende een langere periode actief. Zie deze .NET-voorbeelden voor meer informatie. Als keep alive is ingeschakeld, worden pakketten verzonden tijdens perioden van inactiviteit op de verbinding. Keep-alive-pakketten zorgen ervoor dat de time-outwaarde voor inactiviteit niet wordt bereikt en dat de verbinding gedurende een lange periode wordt onderhouden.

De TCP-keep-alive die in deze sectie wordt beschreven, geldt alleen voor inkomende verbindingen. TCP-reset en een configureerbare idle-time-out worden afzonderlijk ondersteund voor uitgaande regels. Om te voorkomen dat de verbinding verloren gaat, configureert u de TCP-keep-alive met een interval dat kleiner is dan de time-outinstelling voor inactiviteit of verhoogt u de time-outwaarde voor inactiviteit. Ter ondersteuning van deze scenario's is ondersteuning beschikbaar voor een configureerbare time-out voor inactiviteit.

TCP keep-alive werkt voor scenario's waarbij de levensduur van de batterij geen beperking is. Het wordt niet aanbevolen voor mobiele toepassingen. Als u een TCP-keep-alive gebruikt in een mobiele toepassing, kan de batterij van het apparaat sneller leegmaken.

Volgorde van prioriteit

Het is belangrijk om rekening te houden met de manier waarop de time-outwaarden voor inactiviteit voor verschillende IP-adressen mogelijk kunnen communiceren.

Inkomend

  • Als er een (inkomende) load balancer-regel is met een niet-actieve time-outwaarde die anders is ingesteld dan de time-out voor inactiviteit van het front-end-IP-adres waarnaar wordt verwezen, heeft de time-out voor inactiviteit van de load balancer prioriteit.
  • Als er een binnenkomende NAT-regel is met een niet-actieve time-outwaarde die anders is ingesteld dan de time-out voor inactiviteit van het front-end-IP-adres waarnaar wordt verwezen, heeft de time-out van de front-end-IP van de load balancer prioriteit.

Uitgaand

  • Als er een uitgaande regel is met een idle-time-outwaarde anders dan 4 minuten (de tijdslimiet voor inactiviteit van uitgaand verkeer via openbaar IP is vergrendeld op 4 minuten), heeft de idle-time-out van de uitgaande regel voorrang.
  • Omdat een NAT gateway altijd voorrang heeft boven uitgaande load balancer-regels en over openbare IP-adressen die direct aan VM's zijn toegewezen, zal de aan de NAT gateway toegewezen time-outwaarde voor inactiviteit worden gebruikt. (Langs dezelfde lijnen worden de vastgestelde time-outs van 4 minuten voor uitgaande openbare IP-adressen van IP's die zijn toegewezen aan de NAT GW niet in overweging genomen.)

Beperkingen

Deze beperkingen gelden voor TCP reset en idle timeout op Azure Load Balancer:

  • TCP-reset wordt alleen verzonden tijdens een TCP-verbinding in GEVESTIGDE toestand.
  • Idle timeout wordt niet ondersteund voor UDP-regels voor taakverdeling.
  • TCP-reset wordt niet ondersteund voor HA-poortregels van interne load balancers wanneer zich een virtuele netwerkappliance (NVA) in het pad bevindt. Gebruik als tijdelijke oplossing een uitgaande regel met TCP-reset vanuit het virtuele netwerkapparaat.
  • TCP idle timeout wordt niet ondersteund voor interne load balancer HA-poortregels wanneer een door de gebruiker gedefinieerde route (UDR) verkeer doorstuurt naar de interne load balancer.

Volgende stappen

  • Last updated on