Udostępnij za pośrednictwem

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.

Jeśli czas bezczynności przekracza limity konfiguracji lub aplikacja wykazuje niepożądane zachowanie z włączonymi resetowaniami TCP, nadal możesz potrzebować użyć mechanizmów keepalive TCP lub keepalive na warstwie aplikacji, aby monitorować aktywność połączeń TCP. Ponadto, sygnały podtrzymujące (keepalives) mogą również pozostać przydatne, gdy połączenie jest przekazywane przez serwer proxy na jakimś odcinku ścieżki, szczególnie w przypadku sygnałów podtrzymujących warstwy aplikacji.

Uważnie sprawdzając cały scenariusz końcowy, możesz określić korzyści wynikające z włączania resetowania protokołu TCP i dostosowywania limitu czasu bezczynności. Następnie decydujesz, czy można wykonać więcej kroków w celu zapewnienia odpowiedniego zachowania aplikacji.

Konfigurowalny limit czasu bezczynności protokołu TCP

Usługa Azure Load Balancer Standard ma zakres czasu od 4 do 100 minut dla reguł równoważenia obciążenia, reguł NAT dla ruchu przychodzącego i reguł ruchu wychodzącego. Wartość domyślna to 4 minuty. 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. Usługa Azure Load Balancer w warstwie Podstawowa ma maksymalny limit czasu wynoszący 30 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.

To ustawienie działa tylko dla połączeń przychodzących. 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

  • Resetowanie protokołu TCP wysyłane tylko podczas połączenia TCP w stanie USTANOWIONYM.
  • Limit czasu bezczynności protokołu TCP nie ma wpływu na reguły równoważenia obciążenia w protokole UDP.
  • Resetowanie protokołu TCP nie jest obsługiwane w przypadku portów HA wewnętrznego modułu równoważenia obciążenia, gdy na ścieżce znajduje się wirtualne urządzenie sieciowe. Obejściem może być użycie reguły ruchu wychodzącego z resetowaniem protokołu TCP z wirtualnego urządzenia sieciowego.
  • Limit czasu bezczynności protokołu TCP nie jest obsługiwany dla portów wysokiej dostępności wewnętrznego modułu równoważenia obciążenia (ILB), gdy trasa zdefiniowana przez użytkownika (UDR) jest używana do przekazywania ruchu do wewnętrznego modułu równoważenia obciążenia.

Dalsze kroki