Resetowanie protokołu TCP i limit czasu bezczynności modułu równoważenia obciążenia

Możesz użyć Standardowego Load Balancera, aby uzyskać bardziej przewidywalne działanie aplikacji dla scenariuszy, włączając reset TCP w stanie bezczynności dla danej reguły. Domyślne zachowanie modułu równoważenia obciążenia polega na dyskretnym usuwaniu przepływów po osiągnięciu limitu czasu bezczynności przepływu. Włączenie resetowania protokołu TCP powoduje, że usługa Load Balancer wysyła dwukierunkowe pakiety resetowania TCP podczas przekroczenia limitu czasu bezczynności, aby poinformować punkty końcowe aplikacji, że połączenie przekroczyło limit czasu i nie jest już do użytku. W razie potrzeby punkty końcowe mogą natychmiast ustanowić nowe połączenie.

Diagram przedstawia domyślne zachowanie resetowania protokołu TCP węzłów sieciowych.

Resetowanie protokołu TCP

To zachowanie domyślne można zmienić i włączyć wysyłanie resetów TCP w przypadku limitu czasu bezczynności dla reguł NAT dla ruchu przychodzącego, reguł równoważenia obciążenia i reguł ruchu wychodzącego. Po włączeniu zgodnie z regułą, usługa Load Balancer wysyła dwukierunkowe resety TCP (pakiety TCP RST) do punktów końcowych klienta i serwera w momencie upływu czasu bezczynności dla wszystkich pasujących przepływów.

Punkty końcowe odbierające pakiety TCP RST natychmiast zamykają odpowiednie gniazdo. Dzięki temu natychmiastowe powiadomienie o zwolnieniu połączenia punktu końcowego, a każda przyszła komunikacja z tym samym połączeniem TCP się nie powiedzie. Aplikacje mogą usuwać połączenia, gdy gniazdo zostanie zamknięte i ponownie ustanawiać połączenia w razie potrzeby bez czekania na wygaśnięcie limitu czasu połączenia TCP.

W wielu scenariuszach resetowanie protokołu TCP może zmniejszyć konieczność wysyłania sygnałów utrzymywania aktywności protokołu TCP (lub warstwy aplikacji) w celu odświeżenia czasu bezczynności połączenia.

Wybierz między resetem TCP a keepalives

Użyj następujących kryteriów, aby zdecydować, jakiego mechanizmu potrzebuje Twój scenariusz:

  • Włącz reset TCP, jeśli chcesz, aby punkty końcowe były natychmiast powiadamiane o zamknięciu bezczynnego przepływu, tak aby aplikacje mogły usuwać takie połączenia i nawiązywać je ponownie, zamiast czekać na upływ własnego limitu czasu TCP.
  • Używaj TCP keepalive , gdy czas bezczynności przekracza konfigurowalny zakres limitu bezczynności lub gdy aplikacja zachowuje się nieoczekiwanie przy włączonych resetach TCP. Keepalive nie są zalecane do aplikacji mobilnych, ponieważ szybciej rozładowują baterię urządzenia.
  • Używaj mechanizmów podtrzymywania połączenia w warstwie aplikacji, gdy połączenie jest obsługiwane przez serwer proxy na którymś etapie trasy, ponieważ serwer proxy może zakończyć połączenie TCP podtrzymywane przez mechanizmy keepalive warstwy transportowej.

Dokładnie analizując cały scenariusz od początku do końca, możesz określić korzyści z włączenia resetowania połączeń TCP i dostosowania limitu czasu bezczynności. Następnie zdecyduj, czy potrzebne są dodatkowe kroki, aby zapewnić pożądane zachowanie aplikacji.

Konfigurowalny limit czasu bezczynności protokołu TCP

Azure Load Balancer Standard ma zakres timeoutu od 4 minut do 100 minut dla reguł load balancera i reguł NAT przychodzących. Reguły wychodzące można konfigurować w zakresie od 4 do 120 minut. Domyślnie obowiązuje 4 minuty dla wszystkich typów reguł. Jeśli okres braku aktywności jest dłuższy niż wartość limitu czasu, nie ma gwarancji, że sesja TCP lub HTTP jest utrzymywana między klientem a usługą w chmurze. Azure Load Balancer Basic (wycofany) miał zakres limitu czasu do 60 minut.

Po zamknięciu połączenia aplikacja kliencka może otrzymać następujący komunikat o błędzie: "Połączenie bazowe zostało zamknięte: Połączenie, które miało być przechowywane, zostało zamknięte przez serwer".

Jeśli resetowanie protokołu TCP jest włączone i zostanie pominięte z jakiegokolwiek powodu, reset następuje dla kolejnych pakietów. Jeśli opcja resetowania protokołu TCP nie jest włączona, pakiety są porzucane w trybie dyskretnym.

Powszechną praktyką jest użycie protokołu TCP keep-alive. Ta praktyka utrzymuje aktywne połączenie przez dłuższy czas. Aby uzyskać więcej informacji, zobacz te przykłady platformy .NET. Po włączeniu zachowania aktywności pakiety są wysyłane w okresach braku aktywności w połączeniu. Pakiety o zachowaniu aktywności zapewniają, że wartość limitu czasu bezczynności nie zostanie osiągnięta i połączenie jest utrzymywane przez długi czas.

Mechanizm TCP keep-alive opisany w tej sekcji dotyczy wyłącznie połączeń przychodzących. Resetowanie połączeń TCP i konfigurowalny limit czasu bezczynności są obsługiwane niezależnie dla reguł ruchu wychodzącego. Aby uniknąć utraty połączenia, skonfiguruj monitorowanie aktywności TCP (keep-alive) z interwałem krótszym niż ustawienie limitu czasu bezczynności lub zwiększ tę wartość. Aby obsługiwać te scenariusze, dostępna jest obsługa konfigurowalnego limitu czasu bezczynności.

Tcp keep-alive działa w scenariuszach, w których żywotność baterii nie jest ograniczeniem. Nie jest to zalecane w przypadku aplikacji mobilnych. Korzystanie z protokołu TCP keep-alive w aplikacji mobilnej może przyspieszyć opróżnianie baterii urządzenia.

Kolejność pierwszeństwa

Ważne jest, aby wziąć pod uwagę, w jaki sposób wartości limitu czasu bezczynności ustawione dla różnych adresów IP mogą potencjalnie współdziałać.

Transport przychodzący

  • Jeśli istnieje reguła modułu równoważenia obciążenia (przychodzącego) z wartością limitu czasu bezczynności ustawioną inaczej niż limit czasu bezczynności adresu IP frontonu, do których odwołuje się, pierwszeństwo ma limit czasu bezczynności adresu IP frontonu.
  • Jeśli istnieje reguła NAT dla ruchu przychodzącego z wartością limitu czasu bezczynności ustawioną inaczej niż limit czasu bezczynności adresu IP frontonu modułu równoważenia obciążenia, na który się odwołuje, to limit czasu bezczynności frontonu modułu równoważenia obciążenia ma pierwszeństwo.

Wychodzący

  • Jeśli istnieje reguła ruchu wychodzącego z wartością limitu czasu bezczynności inną niż 4 minuty (co oznacza, że limit czasu bezczynności dla ruchu wychodzącego publicznego adresu IP jest zablokowany), limit czasu bezczynności reguły ruchu wychodzącego ma pierwszeństwo.
  • Ponieważ brama NAT zawsze ma pierwszeństwo przed regułami ruchu wychodzącego w modułach równoważenia obciążenia (oraz przed publicznymi adresami IP przypisanymi bezpośrednio do maszyn wirtualnych), zostanie użyta wartość limitu czasu bezczynności przypisana do bramy NAT. Podobnie, limity czasu bezczynności dla ustalonego publicznego adresu IP o czasie 4 minut dowolnych adresów przypisanych do bramy NAT nie są brane pod uwagę.

Ograniczenia

Te ograniczenia dotyczą resetu TCP i limitu bezczynności w Azure Load Balancer:

  • Reset TCP jest wysyłany tylko podczas połączenia TCP w stanie USTANOWIONYM.
  • Limit czasu bezczynności nie jest obsługiwany w przypadku reguł równoważenia obciążenia UDP.
  • Resetowanie połączeń TCP nie jest obsługiwane w regułach portów wysokiej dostępności (HA) wewnętrznego modułu równoważenia obciążenia, gdy na ścieżce znajduje się wirtualne urządzenie sieciowe (NVA). Jako obejście użyj reguły wychodzącej z resetem TCP z wirtualnego urządzenia sieciowego.
  • Limit czasu bezczynności TCP nie jest obsługiwany w regułach portów HA wewnętrznego modułu równoważenia obciążenia, gdy trasa zdefiniowana przez użytkownika (UDR) przekazuje ruch do wewnętrznego modułu równoważenia obciążenia.

Dalsze kroki

  • Last updated on