Przejdź do treści 
Serwer WWW Keep Alive często decyduje o czasie oczekiwania lub szybkości: źle skonfigurowany spowalnia działanie, a prawidłowo dostrojony zauważalnie przyspiesza każde zapytanie. Pokażę konkretnie, jak ja Keep-Alive Skonfiguruj, które przedziały czasowe są skuteczne i dlaczego zbyt długie otwarte TCP-Połączenia Koszt usługi.
Punkty centralne
- mechanizm: Otwarte połączenia TCP oszczędzają uzgodnienia i zmniejszają opóźnienia.
- wartości podstawowe: KeepAliveTimeout, MaxKeepAliveRequests i aktywację wybierać w sposób celowy.
- Obciążenie serwera: Prawidłowo dostrojone okna czasowe zmniejszają zapotrzebowanie na moc procesora i pamięć RAM.
- Praktyka: Konsekwentnie uwzględniać zachowanie przeglądarki i łańcuchy odwrotnych serwerów proxy.
- Kontrola: Mierzyć, dopasowywać, ponownie mierzyć – aż do osiągnięcia idealnego punktu.
Co oferuje Keep Alive
Zamiast rozpoczynać każde zapytanie nowym handshake'iem, Keep-Alive utrzymuje TCP-Połączenie pozostaje otwarte i obsługuje kilka żądań jednocześnie. W scenariuszu obejmującym 50 żądań na sekundę od trzech klientów liczba pakietów spada drastycznie: z około 9000 do około 540 pakietów na minutę, ponieważ powstaje mniej połączeń i odbywa się mniej uzgodnień. Skraca to czas oczekiwania i oszczędza cykle serwera, co ma bezpośredni wpływ na Czas załadunku i przepustowości. W testach czas ten zmniejsza się o połowę, z około 1190 ms do około 588 ms, czyli o dobre 50 procent, o ile pozostała część łańcucha nie jest ograniczona. Dlatego zawsze umieszczam Keep-Alive na początku konfiguracji i sprawdzam rzeczywiste opóźnienia w ruchu na żywo.
Właściwe wskaźniki
Zacznę od trzech parametrów, które zawsze mają wpływ: aktywacja, liczba żądań na połączenie i przedział czasowy do zamknięcia Połączenie. Aktywacja decyduje o tym, czy ponowne wykorzystanie w ogóle ma miejsce; maksymalna liczba zapytań kontroluje, jak długo połączenie pozostaje otwarte; limit czasu równoważy oszczędność i szybkość reakcji. Zbyt długi czas blokuje sloty i marnuje pamięć RAM, ponieważ nieaktywne gniazda pozostają nieaktywne i brakuje pracowników. Zbyt krótki czas niweluje korzyści, ponieważ serwer zbyt wcześnie się rozłącza i musi ponownie uruchomić się. Trzymam się oszczędnych ustawień domyślnych i zwiększam je tylko wtedy, gdy pomiary potwierdzają rzeczywiste czasy oczekiwania w stanie bezczynności.
HTTP/1.1 a HTTP/2/3: klasyfikacja
Keep-Alive działa dla każdego połączenia TCP. W przypadku HTTP/1.1 wiele żądań dzieli między sobą jedno łącze, a w przypadku HTTP/2 wiele żądań dzieli między sobą wiele łączy. Strumienie multipleksowane przez jedno połączenie, HTTP/3 wykorzystuje QUIC zamiast TCP. Uważam, że: krótki limit czasu pozostaje sensowny również w przypadku HTTP/2, ponieważ strumienie bezczynne nie są bezpłatne – połączenie nadal zajmuje zasoby, zwłaszcza w przypadku TLS. Nginx ma własne okno bezczynności dla HTTP/2; dbam o to, aby globalne wartości Keep-Alive i wartości graniczne specyficzne dla HTTP/2 były do siebie dopasowane i nie były zbyt wysokie. Ważne: Nginx komunikuje się obecnie tylko z klientem HTTP/2; z backendem komunikuje się HTTP/1.1-Połączenia otwarte. Upstream-Keepalive pozostaje zatem obowiązkowe, aby zachować zalety end-to-end. W przypadku HTTP/3 obowiązują podobne zasady: nawet jeśli QUIC lepiej maskuje straty, długo otwarty, niewykorzystywany kanał kosztuje pamięć i deskryptory plików. Dlatego moje podejście pozostaje konserwatywne: krótkie okna bezczynności, jasne limity i raczej czyste ponowne połączenie niż niekończące się utrzymywanie.
Pragmatyczne spojrzenie na obciążenie TLS
TLS jeszcze bardziej zwiększa oszczędności dzięki funkcji Keep-Alive, ponieważ uzgodnienia są droższe niż czyste struktury TCP. Dzięki TLS 1.3 i wznowieniu sesji obciążenie zmniejsza się, ale w sumie każde uniknięte nowe połączenie jest korzystne. W praktyce sprawdzam trzy kwestie: po pierwsze, czy serwer prawidłowo wykorzystuje wznowienie sesji (bilety nie tracą ważności zbyt wcześnie). Po drugie, czy silne szyfry i nowoczesne protokoły są aktywne, bez niepotrzebnego zmuszania starych klientów. Po trzecie, czy wykorzystanie procesora pozostaje stabilne przy wysokiej równoległości. Nawet przy wznowieniu krótkie, stabilne okna czasu keep-alive pozwalają uniknąć dodatkowych szczytów obciążenia procesora, ponieważ rozpoczyna się mniej negocjacji. Jednocześnie zbyt długie okna nie uniemożliwiają uzgodnień, ale przenoszą obciążenie do stanu bezczynności – jest to droższa opcja.
Apache: zalecane ustawienia
W Apache włączam KeepAlive na On, ustaw MaxKeepAliveRequests na 300–500 i wybierz przedział czasowy wynoszący zazwyczaj 2–3 sekundy. Wartość 0 dla maksymalnej liczby żądań wydaje się kusząca, ale nieograniczona liczba rzadko ma sens, ponieważ połączenia trwają wtedy zbyt długo. kleić. W przypadku aplikacji o dużym natężeniu ruchu z stabilnymi klientami testuję 5–10 sekund; w przypadku szczytów z wieloma krótkimi wizytami zmniejszam czas do 1–2 sekund. Ważne jest, aby najpierw skrócić limit czasu, a następnie dokładniej dostosować liczbę żądań, aby sloty nie były blokowane przez bezczynność. Jeśli nie masz dostępu do głównej konfiguracji, możesz kontrolować zachowanie połączenia dla każdego katalogu za pomocą mod_headers, o ile hostingodawca udostępnił tę opcję.
Nginx: sensowne dostrajanie
W Nginx funkcja Keep-Alive jest domyślnie aktywna, dlatego zwracam szczególną uwagę na limit czasu, wyjątki przeglądarki i liczbę połączeń. Za pomocą keepalive_timeout ustalam liczbę sekund, które stopniowo dostosowuję od 1 do 5 sekund w zależności od wzorca ruchu; w przypadku wielu wywołań API sensowne może być również 10 sekund. Za pomocą keepalive_disable wykluczam problematyczne stare klienty, aby nie powodowały nieprawidłowości. Sesje . W przypadku odwrotnych serwerów proxy do upstreamów dodatkowo ustawiam upstream keepalive, aby Nginx ponownie wykorzystywał połączenia z backendem i zajmował tam mniej pracowników. W ten sposób utrzymuję spójność ścieżki od początku do końca i zapobiegam niepożądanym Rozstania w środku przepływu żądań.
Odwrotny serwer proxy i przekazywanie nagłówków
W konfiguracjach wielopoziomowych potrzebuję spójnego Strategia, który poprawnie przekazuje nagłówki HTTP/1.1 i nie nadpisuje przypadkowo wartości połączenia. Nginx powinien komunikować się z backendem w protokole HTTP/1.1 i wyraźnie tolerować Keep-Alive, podczas gdy Apache wykorzystuje odpowiednie okna czasowe. Krytyczne są konfiguracje, które wymuszają Connection: close lub zakłócają ścieżki aktualizacji, ponieważ wtedy rzekoma korzyść znika. W Apache mogę kontrolować za pomocą mod_headers dla każdej lokalizacji, czy połączenia pozostają otwarte i jakie dodatkowe informacje są ustawiane. Wszystkie węzły muszą mieć ten sam cel, w przeciwnym razie jeden z nich spowoduje skuteczność hamowania, których właściwie chciałem uniknąć.
CDN, Load Balancer i konfiguracje chmury
Jeśli przed nim znajduje się CDN lub moduł równoważenia obciążenia, większość połączeń klientów trafia właśnie tam. Źródło korzysta wtedy przede wszystkim z trwałych, nielicznych połączeń między brzegiem a źródłem. Zwracam uwagę, aby moduł równoważenia również pracował z krótkimi oknami bezczynności i aby aktywowana była funkcja łączenia połączeń z zapleczem. W środowiskach kontenerowych i chmurowych liczy się również przepływ drenażowy: przed aktualizacją typu rolling wysyłam węzeł do Odsączanie-status, szybko zamykam otwarte połączenia (czas oczekiwania nie jest zbyt długi) i dopiero wtedy uruchamiam zamiennik. W ten sposób unikam przerwanych żądań i pozostałych połączeń zombie. Sticky Sessions (np. za pomocą plików cookie) mogą rozdzielać pule połączeń; tam, gdzie to możliwe, stawiam na low-state. Backendy lub zewnętrzne magazyny sesji, aby ponowne wykorzystanie działało równomiernie.
Szybkość hostingu w praktyce
Wiele środowisk współdzielonych wyłącza funkcję Keep-Alive, aby w krótkim czasie Automaty do gry oszczędzać, ale strony stają się powolne i tracą interaktywność. Dlatego też na wczesnym etapie sprawdzam za pomocą testów czasu ładowania, czy serwer pozwala na ponowne wykorzystanie i jak wyglądają fazy połączenia na wykresie wodospadowym. Jeśli narzędzie wykrywa długie bloki handshake między wieloma małymi zasobami, zazwyczaj brakuje ponownego wykorzystania lub limit czasu kończy się zbyt wcześnie. W dalszym dopracowywaniu ustawień pomaga mi uporządkowany przewodnik, taki jak ten kompaktowy Optymalizacja Keep-Alive, aby móc wykonywać kolejne czynności w sposób uporządkowany. W ten sposób unikam zgadywania i osiągam zauważalne rezultaty za pomocą kilku prostych kroków. impuls w przedniej części.
Limity czasu, ograniczenia i zachowanie przeglądarki
Nowoczesne przeglądarki otwierają wiele równoległych Połączenia, często sześć, i szybko wyczerpują w ten sposób pojemność Keep-Alive. MaxKeepAliveRequests wynoszące 300 wystarcza w praktyce dla wielu jednoczesnych odwiedzających, o ile limit czasu nie jest niepotrzebnie wysoki. Jeśli ustawię okno na trzy sekundy, sloty pozostaną dostępne, a serwer nada priorytet aktywnym klientom zamiast bezczynności. Dopiero gdy żądania regularnie się urywają lub ponowne wykorzystanie nie działa, zwiększam limit w umiarkowanych krokach. Strony z wieloma strumieniami HTTP/2 wymagają osobnego rozpatrzenia, szczegóły podsumowuje Multipleksowanie HTTP/2 bardzo kompaktowo, aby móc uporządkować wykorzystanie kanałów i funkcję Keep-Alive.
| Parametry | Dyrektywa Apache | Dyrektywa Nginx | wartość orientacyjna | Wskazówka |
|---|---|---|---|---|
| Aktywacja | KeepAlive Włączone | domyślnie aktywne | zawsze aktywować | Bez ponownego wykorzystania wzrasta Nad głową. |
| Limit czasu | KeepAliveTimeout | keepalive_timeout | 2–5 s | Krótszy w przypadku wielu krótkich wywołań, dłuższy w przypadku Interfejsy API. |
| Liczba/Conn | MaxKeepAliveRequests | keepalive_requests | 300–500 | Ograniczone wykorzystanie zasobów na Klient. |
| Wyjątki przeglądarki | - | keepalive_disable | selektywny | Wyłącz dla bardzo starych Klienci. |
| w górę rzeki | ProxyKeepAlive | upstream keepalive | aktywny | Zapewnia ponowne wykorzystanie kierunku Backend. |
Ograniczenia systemu operacyjnego i gniazda
Na poziomie systemu operacyjnego rzeczywistą wydajność ograniczają deskryptory plików i parametry gniazda. Sprawdzam ulimit -n, ograniczenia procesów i systemu oraz konfigurację serwera WWW (np. worker_connections w Nginx). Funkcja Keep-Alive zmniejsza liczbę nowych połączeń, ale wydłuża czas, przez jaki deskryptory pozostają zajęte. W okresach dużego natężenia ruchu może wystąpić presja TIME_WAIT, gdy połączenia zamykają się bardzo szybko – w tym przypadku pomocne jest przede wszystkim czyste ponowne wykorzystanie zamiast agresywnych hacków jądra. Dokonuję wyraźnego rozróżnienia między HTTP-Keep-Alive (protokół aplikacji) oraz sondy TCP Keepalive jądra: te ostatnie są czystymi pakietami sygnałów życia, których nie należy mylić z otwartym oknem HTTP. Zmieniam domyślne ustawienia jądra tylko za pomocą punktu pomiarowego i skupiam się przede wszystkim na samym serwerze WWW: krótkie, ale skuteczne limity czasu bezczynności, ograniczona liczba żądań na połączenie i rozsądne rezerwy pracowników.
Bezpieczeństwo: Slowloris & Co. łagodzą sytuację
Zbyt hojne wartości Keep-Alive zachęcają do nadużyć. Dlatego ograniczam nie tylko czasy bezczynności, ale także limity czasu odczytu i treści. W Nginx korzystam z client_header_timeout i client_body_timeout; w Apache ustawiam odpowiednie moduły z twardymi limitami odczytu, aby żadne powolne żądania nie blokowały pracowników. Limity rozmiaru nagłówków i treści żądań dodatkowo zapobiegają nadmiernemu obciążeniu pamięci. W połączeniu z umiarkowanymi oknami Keep-Alive zmniejszam ryzyko, że niewielka liczba klientów zajmie wiele gniazd. Ważna jest kolejność: najpierw prawidłowe limity czasu, następnie ukierunkowane limity, a na końcu reguły związane z szybkością lub adresem IP. Tylko w ten sposób prawdziwi użytkownicy pozostają szybcy, a profile ataków nie przynoszą efektu.
Monitorowanie i testy obciążeniowe
Po każdej zmianie mierzę efekt za pomocą narzędzi takich jak ab, wrk lub k6 i sprawdzam 95. percentyl Opóźnienia. Najpierw zmniejszam limit czasu w wyraźnych krokach i obserwuję, czy wzrasta liczba limitów czasu lub przerwanych połączeń; następnie dostosowuję liczbę zapytań na połączenie. Równolegle oceniam otwarte gniazda, obciążenie pracowników i zapotrzebowanie na pamięć, aby wyeliminować bezczynność we właściwym miejscu. W przypadku powtarzających się czasów oczekiwania warto przyjrzeć się kolejkom w backendzie, hasło Kolejkowanie serwerów i dystrybucja żądań. Kto pracuje z punktami pomiarowymi, wcześnie rozpoznaje wąskie gardła i oszczędza sobie długiego czasu. Rozwiązywanie problemów.
Praktyka logowania i metryki
Chcę sprawdzić, czy połączenia są rzeczywiście ponownie wykorzystywane. W Nginx rozszerzam format logu o licznik połączeń i czasy; wartości pokazują mi, czy klienci wysyłają wiele żądań na każde połączenie, czy też zamykają je po jednym lub dwóch trafieniach. Podobnie postępuję w przypadku Apache, aby wyświetlić liczbę żądań na każde połączenie. W ten sposób identyfikuję wzorce, które bardziej korzystają z limitu czasu lub limitu żądań.
# Nginx: przykład rozszerzonego formatu dziennika log_format main_ext '$remote_addr $request ' 'conn=$connection reqs=$connection_requests ' 'rt=$request_time uct=$upstream_connect_time';
access_log /var/log/nginx/access.log main_ext;
# Apache: LogFormat z połączeniem i czasem trwania LogFormat "%h %r conn:%{c}L reqs:%{REQUESTS_PER_CONN}n time:%D" keepalive CustomLog logs/access_log keepalive
W monitorowaniu interesują mnie przede wszystkim opóźnienia P95/P99, aktywne połączenia, rozkład żądań/połączeń i błędy (rosnące 408/499). Jeśli wzrosną one przy mniejszym oknie Keep-Alive, zmniejszam nieco prędkość; jeśli obciążenie pozostaje na stałym poziomie, a opóźnienie jest lepsze, oznacza to, że znalazłem idealny punkt.
Wdrażanie i restartowanie
Reloady i aktualizacje są kompatybilne z Keep-Alive, jeśli odpowiednio je zaplanuję. W Nginx stawiam na płynne reloady i pozwalam pracownikom kontrolować połączenia zamiast ich gwałtownie przerywać. Krótkie czasy oczekiwania pomagają szybciej zwolnić starych pracowników. W Apache używam wdzięczny-Uruchom ponownie i obserwuj równolegle mod_status lub strony statusu, aby nie utracić oczekujących żądań. Przed większymi wdrożeniami tymczasowo zmniejszam okno Keep-Alive, aby szybciej opróżnić system, a po sprawdzeniu stabilności przywracam je do wartości docelowej. Ważne: dokumentuj zmiany i porównuj je z profilami obciążenia, aby nie pozostały niezauważone powolne regresja wkradać się.
Częste błędy i środki zaradcze
Zbyt długie okna czasowe powodują brak aktywności Połączenia otwarte i przenoszą problem do wąskich gardeł pracowników, co wyraźnie spowalnia nowych odwiedzających. Nieograniczona liczba zapytań na połączenie wygląda elegancko, ale w końcu wzrasta obciążenie na gniazdo, a szczyty obciążenia wymykają się spod kontroli. Bardzo krótkie okna poniżej sekundy powodują ciągłe odświeżanie przeglądarki, co zwiększa liczbę uścisków dłoni i sprawia, że interfejs użytkownika działa nierówno. W łańcuchach proxy często brakuje spójności: jedno ogniwo używa HTTP/1.0 lub ustawia Connection: close, co blokuje ponowne wykorzystanie. Dlatego pracuję w następującej kolejności: sprawdzam aktywację, dostosowuję limity czasu w małych krokach, dostosowuję liczbę żądań na połączenie i zwiększam ją tylko wtedy, gdy pomiary wskazują rzeczywisty Korzyści pokaz.
Lista kontrolna do szybkiej realizacji
Najpierw aktywuję Keep-Alive i zapisuję aktualne Wartości, aby móc w każdej chwili cofnąć się. Następnie ustawiam limit czasu na trzy sekundy, ponownie ładuję konfigurację i sprawdzam otwarte połączenia, obciążenie i wodospady w interfejsie użytkownika. Jeśli pojawia się wiele krótkich wizyt, zmniejszam limit do dwóch sekund; jeśli pojawia się wiele długich zapytań API, zwiększam limit do pięciu do dziesięciu sekund. Następnie ustawiam MaxKeepAliveRequests na 300–500 i obserwuję, czy sloty pozostają wolne, czy też silni klienci długoterminowi zajmują je zbyt długo. Po każdym kroku ponownie dokonuję pomiarów, dokumentuję skutki i zachowuję najlepsze Połączenie stały.
Krótki bilans
Prawidłowo skonfigurowana funkcja Keep-Alive pozwala zaoszczędzić na uzgodnieniach, zmniejsza opóźnienia i zapewnia serwerowi więcej możliwości. Powietrze na żądanie. Dzięki krótkim, ale nie zbyt krótkim oknom czasowym i umiarkowanej liczbie żądań na połączenie host działa zauważalnie płynniej. Stawiam na niewielkie zmiany z jasnymi punktami pomiarowymi, zamiast ślepo dążyć do wartości maksymalnych. Kto konsekwentnie dostosowuje hosting, odwrotny serwer proxy i backend do ponownego wykorzystania, zyskuje szybką interakcję bez niepotrzebnego angażowania zasobów. Ostatecznie liczy się pomiar: tylko prawdziwe wskaźniki pokazują, czy tuning przyniósł oczekiwane rezultaty. Efekt przynosi.
