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

  • Artykuł

Za pomocą usługa Load Balancer w warstwie Standardowa można utworzyć bardziej przewidywalne zachowanie aplikacji dla Twoich scenariuszy, włączając resetowanie protokołu 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 resetowanie PROTOKOŁU TCP (pakiety TCP RST) w czasie bezczynności, aby poinformować punkty końcowe aplikacji, że upłynął limit czasu połączenia i nie będzie już można ich używać. W razie potrzeby punkty końcowe mogą natychmiast ustanowić nowe połączenie.

Diagram shows default TCP reset behavior of network nodes.

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 dla reguły usługa Load Balancer wysyła dwukierunkowe resetowanie TCP (pakiety TCP RST) do punktów końcowych klienta i serwera w czasie bezczynności dla wszystkich pasujących przepływów.

Punkty końcowe odbierające pakiety TCP RST natychmiast zamykają odpowiednie gniazdo. Zapewnia to natychmiastowe powiadomienie do wydania połączenia punktu końcowego, a każda przyszła komunikacja w tym samym połączeniu TCP zakończy się niepowodzeniem. Aplikacje mogą czyścić połączenia, gdy gniazdo zostanie zamknięte i ponownie opublikuje połączenia zgodnie z potrzebami bez oczekiwania na połączenie TCP, aby ostatecznie upłynął limit czasu.

W przypadku wielu scenariuszy resetowanie protokołu TCP może zmniejszyć konieczność wysyłania utrzymywania ruchu TCP (lub warstwy aplikacji), aby odświeżyć limit czasu bezczynności przepływu.

Jeśli czas bezczynności przekracza limity konfiguracji lub aplikacja pokazuje niepożądane zachowanie z włączonymi resetowaniami PROTOKOŁU TCP, nadal możesz użyć elementów utrzymania tcp lub utrzymania warstwy aplikacji w celu monitorowania aktywności połączeń TCP. Ponadto elementy keepalives mogą również pozostać przydatne w przypadku, gdy połączenie jest proxied gdzieś w ścieżce, szczególnie w przypadku utrzymania 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 ma zakres limitu czasu od 4 minut do 100 minut dla reguł modułu równoważenia obciążenia, reguł ruchu wychodzącego i reguł NAT dla ruchu przychodzą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.

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".

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 wartość limitu czasu bezczynności protokołu TCP z interwałem krótszym niż ustawienie limitu czasu bezczynności lub zwiększ wartość limitu czasu bezczynności. 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ć.

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 translatora adresów sieciowych dla ruchu 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ę, limit czasu bezczynności adresu IP 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 translatora adresów sieciowych zawsze ma pierwszeństwo przed regułami ruchu wychodzącego modułu równoważenia obciążenia (i za pośrednictwem publicznych adresów IP przypisanych bezpośrednio do maszyn wirtualnych), zostanie użyta wartość limitu czasu bezczynności przypisana do bramy translatora adresów sieciowych. (W tych samych wierszach limity czasu bezczynności ruchu wychodzącego zablokowanego publicznego adresu IP w ciągu 4 minut od wszystkich adresów IP przypisanych do bramy translatora adresów sieciowych nie są brane pod uwagę).

Ograniczenia

  • Resetowanie protokołu TCP wysyłane tylko podczas połączenia TCP w stanie ESTABLISHED.
  • 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 wysokiej dostępności modułu równoważenia obciążenia, gdy wirtualne urządzenie sieciowe znajduje się w ścieżce. Obejściem może być użycie reguły ruchu wychodzącego z resetowaniem protokołu TCP z urządzenia WUS.

Następne kroki