Dlaczego krótkie połączenia przeciążają zajęty serwer samoobsługowy?

Krótkie połączenia przeciążają zajęty serwer self-hosted, gdy prace związane z nawiązywaniem i zamykaniem połączeń stają się większe niż użyteczna praca związana z żądaniem. Każda nowa sesja może wymagać uzgodnienia TCP, negocjacji TLS, przydzielenia gniazda, uwierzytelnienia, logowania i sprzątania, nawet jeśli odpowiedź zawiera tylko kilka bajtów.

Długi transfer pliku ponosi te koszty raz, a następnie przesyła znaczne ilości danych. Kontrole stanu, pulpity nawigacyjne, klienci mobilni, zasoby internetowe i źle zarządzane wywołania API mogą tworzyć setki małych sesji, zmuszając serwer do powtarzania stałych kosztów przy jednoczesnym utrzymywaniu stanu z niedawno zamkniętych połączeń.

Główna przyczyna: Każde nowe połączenie powtarza stałą pracę

Połączenie TCP rozpoczyna się od uzgodnienia, zanim dane aplikacji mogą przepływać. HTTPS dodaje negocjację kryptograficzną, a aplikacja może następnie utworzyć sesję, sprawdzić poświadczenia, otworzyć połączenie z bazą danych lub załadować stan użytkownika. Dla małej odpowiedzi te etapy konfiguracji mogą dominować zarówno opóźnienie, jak i czas procesora.

Koszty krótkotrwałych połączeń stają się znaczące, gdy serwer powtarza je z dużą częstotliwością. Widocznym efektem może być rosnące obciążenie i wolniejsze odpowiedzi, mimo że przepustowość sieci pozostaje znacznie poniżej prędkości łącza.

Wielokrotne użycie połączeń zmienia ten stosunek. Kilka żądań może korzystać z jednego ustanowionego transportu i, tam gdzie to możliwe, jednej zaszyfrowanej sesji. Serwer spędza więcej czasu na pracy aplikacji, a mniej na przydzielaniu i zwalnianiu stanu połączenia.

Keep-Alive zmniejsza liczbę uzgodnień, ale wymaga rozsądnych limitów

HTTP keep-alive pozwala na wielokrotne żądania korzystające z jednego połączenia TCP zamiast otwierania nowego połączenia dla każdego obiektu lub wywołania API. Zmniejsza to liczbę podróży w obie strony i zapobiega mnożeniu się powtarzanych konfiguracji podczas ładowania wielu zasobów strony lub pulpitu nawigacyjnego.

Połączenia HTTP keepalive obniżają opóźnienia, ponownie wykorzystując ustanowione transporty. Granicą jest stan bezczynności: zbyt długie timeouty mogą pozostawić wiele nieużywanych gniazd zajmujących pamięć i sloty połączeń, więc ponowne użycie wymaga limitu czasu i liczby żądań dopasowanych do wzorca klienta.

Pulowanie musi istnieć po obu stronach wewnętrznego wywołania usługi. Reverse proxy może ponownie wykorzystywać połączenia klientów, otwierając jednocześnie nowe połączenie upstream dla każdego żądania, przesuwając problem zamiast go usuwać. Sterowniki baz danych i klienci API mogą tworzyć ten sam ukryty rozrost wewnątrz jednej aplikacji self-hosted.

Zamknięte połączenia mogą pozostawiać stan jądra

Zamknięcie sesji TCP nie zawsze natychmiast usuwa jej stan. Punkt końcowy, który aktywnie zamyka połączenie, może zachować wpis TIME_WAIT, aby opóźnione pakiety ze starego połączenia nie zostały pomylone z późniejszym połączeniem używającym tego samego adresu i portu.

Duża populacja TIME_WAIT sygnalizuje zatem częstą rotację połączeń, a nie automatycznie uszkodzony serwer. Przy wysokich wskaźnikach może zużywać pamięć, utrudniać obserwowalność lub wyczerpać efemeryczne porty klienta, zanim stare wpisy wygasną.

Zmiana timerów jądra rzadko jest pierwszym krokiem. Znajdź, który klient lub usługa otwiera połączenia, potwierdź, czy ponowne użycie jest włączone, i sprawdź, czy powtórzenia lub kontrole stanu nie zwiększają tempa. Agresywne zmiany timerów mogą ukryć wzorzec, osłabiając jednocześnie ochronę TCP przed opóźnionymi pakietami.

Automatyzacja może powodować rotację połączeń na pozornie bezczynym serwerze

Serwer domowy może otrzymywać żądania od kontroli stanu kontenerów, agentów monitorujących, kart przeglądarki, widżetów telefonicznych, klientów multimedialnych i reverse proxy, nawet gdy nikt aktywnie go nie używa. Jeśli każde sprawdzenie otwiera nowe zaszyfrowane połączenie, krótki interwał zamienia lekką kontrolę w ciągłą pracę konfiguracyjną.

Pomiary krótkotrwałych połączeń TCP pokazują, jak zautomatyzowani klienci i skrypty mogą preferować powtarzane nowe sesje zamiast utrzymywanych. Na małym serwerze self-hosted to samo zachowanie jest widoczne na mniejszą skalę, ponieważ limity CPU, pamięci i pracowników są mniejsze.

Licząc zaakceptowane połączenia na sekundę, CPU na uzgodnienia, otwarte gniazda, wpisy TIME_WAIT i żądania na połączenie, jeśli tempo połączeń rośnie znacznie szybciej niż liczba żądań, sprawdź pulowanie i zachowanie powtórzeń. Jeśli usługa jest dostępna z internetu, najpierw potwierdź granicę ekspozycji za pomocą sprawdzenia ekspozycji serwera domowego, aby nie pomylić niechcianych skanów z normalnymi klientami.

Najczęściej zadawane pytania

Czy wiele krótkich połączeń zawsze stanowi problem?

Nie. Nowoczesne serwery mogą obsługiwać wiele połączeń, a krótkie sesje mogą być odpowiednie dla rzadkich klientów. Stają się problemem, gdy tempo połączeń zużywa CPU, porty, pracowników lub pamięć szybciej niż serwer może je odzyskać.

Czy HTTP/2 eliminuje przeciążenie połączeń?

HTTP/2 może multipleksować wiele żądań przez mniejszą liczbę połączeń, co zmniejsza rotację. Klienci, proxy i usługi upstream muszą faktycznie negocjować i ponownie używać tego protokołu; wewnętrzne przeskoki mogą nadal korzystać z oddzielnych połączeń HTTP/1.1.

Czy powinienem skrócić timeout TIME_WAIT?

Nie, zanim nie zidentyfikujesz źródła rotacji. TIME_WAIT to normalne zachowanie protokołu. Pulowanie połączeń, trwałe transporty, interwały kontroli i limity powtórzeń zwykle rozwiązują obciążenie bardziej bezpośrednio niż skracanie timerów jądra.