{"id":21215,"date":"2026-08-31T18:19:53","date_gmt":"2026-08-31T16:19:53","guid":{"rendered":"https:\/\/webhosting.de\/tcp-time-wait-optimierung-webserver-performance-netzwerk\/"},"modified":"2026-08-31T18:19:53","modified_gmt":"2026-08-31T16:19:53","slug":"optymalizacja-stanu-tcp-time-wait-wydajnosc-serwera-www-siec","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/tcp-time-wait-optimierung-webserver-performance-netzwerk\/","title":{"rendered":"Optymalizacja stanu TCP TIME_WAIT na serwerach WWW: praktyczny przewodnik dla administrator\u00f3w"},"content":{"rendered":"<p>Pokazuj\u0119, jak <strong>TCP TIME_WAIT<\/strong> tak, aby na serwerach internetowych du\u017ce obci\u0105\u017cenie kr\u00f3tkotrwa\u0142e nie powodowa\u0142o wyczerpania port\u00f3w, a nowe po\u0142\u0105czenia nawi\u0105zywa\u0142y si\u0119 szybko. Przewodnik praktyczny zawiera jasno okre\u015blone punkty pomiarowe, bezpieczne opcje j\u0105dra, optymalizacj\u0119 gniazd na poziomie aplikacji oraz sztuczki architektoniczne, kt\u00f3re pozwalaj\u0105 zachowa\u0107 stan TIME_WAIT jako u\u017cyteczn\u0105 siatk\u0119 bezpiecze\u0144stwa, a jednocze\u015bnie zwi\u0119kszy\u0107 przepustowo\u015b\u0107.<\/p>\n\n<h2>Punkty centralne<\/h2>\n<p>Poni\u017csze kluczowe aspekty pomagaj\u0105 w skutecznej analizie i optymalizacji stanu TIME_WAIT na serwerach WWW z systemem Linux.<\/p>\n<ul>\n  <li><strong>Zrozumienie<\/strong>: TIME_WAIT chroni integralno\u015b\u0107 danych; celem jest kontrola, a nie wy\u0142\u0105czenie.<\/li>\n  <li><strong>targi<\/strong>: Dok\u0142adne rejestrowanie odsetka TIME_WAIT, obci\u0105\u017cenia port\u00f3w i wska\u017anik\u00f3w ponownego nawi\u0105zywania po\u0142\u0105cze\u0144.<\/li>\n  <li><strong>J\u0105dro<\/strong>: ip_local_port_range, tcp_fin_timeout, tcp_tw_reuse \u2013 nale\u017cy regulowa\u0107 te parametry ostro\u017cnie, w oparciu o pomiary.<\/li>\n  <li><strong>Gniazda<\/strong>: Funkcja Keep-Alive, protoko\u0142y HTTP\/2\/3 oraz pule po\u0142\u0105cze\u0144 ograniczaj\u0105 fluktuacj\u0119 po\u0142\u0105cze\u0144.<\/li>\n  <li><strong>Architektura<\/strong>: Skalowanie, dodatkowe adresy IP\/porty oraz serwery proxy rozk\u0142adaj\u0105 obci\u0105\u017cenie zwi\u0105zane ze stanem TIME_WAIT.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverraum-optimierung-1423.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Prawid\u0142owe zinterpretowanie stanu TIME_WAIT<\/h2>\n\n<p>Wielu administrator\u00f3w widzi tysi\u0105ce po\u0142\u0105cze\u0144 w <strong>TIME_WAIT<\/strong> i mo\u017cna pomy\u015ble\u0107, \u017ce to b\u0142\u0105d, ale jest dok\u0142adnie odwrotnie. Stan ten wstrzymuje usuni\u0119te po\u0142\u0105czenia na kr\u00f3tk\u0105 chwil\u0119, aby p\u00f3\u017aniejsze segmenty nie zak\u0142\u00f3ca\u0142y nowych po\u0142\u0105cze\u0144 i aby wszystkie bajty dotar\u0142y do odbiorcy. Szanuj\u0119 t\u0119 logik\u0119 bezpiecze\u0144stwa, poniewa\u017c zapobiega ona mieszaniu danych i irytuj\u0105cym komunikatom RST. Na serwerach internetowych o du\u017cym nat\u0119\u017ceniu ruchu liczba kr\u00f3tkotrwa\u0142ych gniazd naturalnie ro\u015bnie, co wymaga oceny sytuacji, a nie paniki. Przed rozpocz\u0119ciem optymalizacji kluczowe znaczenie ma ustalenie, czy faktycznie wyst\u0119puje niedob\u00f3r port\u00f3w, przepe\u0142nienie kolejki lub b\u0142\u0119dy u\u017cytkownik\u00f3w.<\/p>\n\n<h2>Rozpoznawanie objaw\u00f3w na serwerach poddanych du\u017cemu obci\u0105\u017ceniu<\/h2>\n\n<p>Najpierw sprawdzam <strong>Port<\/strong>-Komunikaty o b\u0142\u0119dach: \u201eCannot assign requested address\u201c lub \u201eAddress already in use\u201c wskazuj\u0105 na wyczerpanie zasob\u00f3w. Op\u00f3\u017anione uzgodnienia po\u0142\u0105cze\u0144, sporadyczne odrzucenia oraz skoki obci\u0105\u017cenia procesora j\u0105dra w \u015bcie\u017cce sieciowej to kolejne sygna\u0142y ostrzegawcze. Gdy monitorowanie wykazuje niezwykle du\u017c\u0105 liczb\u0119 gniazd w stanie TIME_WAIT, zawsze por\u00f3wnuj\u0119 t\u0119 liczb\u0119 z cz\u0119stotliwo\u015bci\u0105 nawi\u0105zywania nowych po\u0142\u0105cze\u0144 i czasami odpowiedzi. Sam wysoki odsetek gniazd TIME_WAIT jest akceptowalny, o ile wolne porty efemeryczne i tabele gniazd zapewniaj\u0105 wystarczaj\u0105c\u0105 rezerw\u0119. Dopiero konkretne w\u0105skie gard\u0142a sk\u0142aniaj\u0105 mnie do celowej regulacji parametr\u00f3w, zamiast dzia\u0142ania na podstawie przypuszcze\u0144.<\/p>\n\n<h2>Pomiar i ocena: przegl\u0105d stan\u00f3w i port\u00f3w<\/h2>\n\n<p>Bez danych liczbowych niczego nie optymalizuj\u0119, dlatego zaczynam od <strong>ss<\/strong> oraz Netstat, aby zarejestrowa\u0107 rozk\u0142ady stan\u00f3w i trendy. Dodatkowo zagl\u0105dam do katalogu \/proc\/net\/tcp, poniewa\u017c mo\u017cna tam znale\u017a\u0107 szczeg\u00f3\u0142owe informacje na temat port\u00f3w lokalnych i zdalnych oraz ich stan\u00f3w. Na podstawie monitoringu wyodr\u0119bniam liczb\u0119 stan\u00f3w TIME_WAIT na ka\u017cdy host, liczb\u0119 nowych po\u0142\u0105cze\u0144 na sekund\u0119 oraz wska\u017aniki b\u0142\u0119d\u00f3w na minut\u0119. Interesuje mnie stosunek stanu TIME_WAIT do ca\u0142kowitej liczby gniazd oraz obci\u0105\u017cenie port\u00f3w efemerycznych, aby odr\u00f3\u017cni\u0107 rzeczywiste obci\u0105\u017cenie od pozornego. Dopiero gdy te wska\u017aniki potwierdz\u0105 wyst\u0119powanie w\u0105skich garde\u0142, planuj\u0119 konkretne dzia\u0142ania dotycz\u0105ce j\u0105dra i aplikacji.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp_timewait_optimierung_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Optymalizacja j\u0105dra: bezpieczne regulacje z zachowaniem rozs\u0105dku<\/h2>\n\n<p>Zaczynam od <strong>konserwatywny<\/strong> Wprowadzaj zmiany i wdra\u017caj je stopniowo, zawsze w po\u0142\u0105czeniu z pomiarami i opcj\u0105 powrotu do poprzedniego stanu. Zwi\u0119kszenie warto\u015bci parametru `ip_local_port_range` poszerza wyb\u00f3r port\u00f3w \u017ar\u00f3d\u0142owych, co ogranicza kolizje port\u00f3w. Ostro\u017cne zmniejszenie warto\u015bci parametru `tcp_fin_timeout` skraca czas trwania niekt\u00f3rych stan\u00f3w ko\u0144cowych bez ryzyka przedwczesnego przerwania po\u0142\u0105czenia. W konfiguracjach bez NAT parametr tcp_tw_reuse mo\u017ce zauwa\u017calnie zmniejszy\u0107 obci\u0105\u017cenie port\u00f3w, o ile dobrze znam \u015brodowisko, a testy przebiegaj\u0105 bezb\u0142\u0119dnie. Wystarczaj\u0105co wysoka warto\u015b\u0107 parametru tcp_max_tw_buckets pozwala unikn\u0105\u0107 agresywnego odrzucania, musi jednak by\u0107 dostosowana do dost\u0119pnej pojemno\u015bci pami\u0119ci RAM.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Parametry<\/strong><\/th>\n      <th><strong>Cel<\/strong><\/th>\n      <th><strong>Przyk\u0142adowa warto\u015b\u0107<\/strong><\/th>\n      <th><strong>Ryzyko<\/strong><\/th>\n      <th><strong>Mierzona zmienna<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>net.ipv4.ip_local_port_range<\/td>\n      <td>Rozszerzenie puli port\u00f3w efemerycznych<\/td>\n      <td>12000 65535<\/td>\n      <td>Wi\u0119cej otwartych <strong>Porty<\/strong> zu\u017cywaj\u0105 zasoby j\u0105dra<\/td>\n      <td>Wolne porty, b\u0142\u0119dy po\u0142\u0105czenia<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_fin_timeout<\/td>\n      <td>Skr\u00f3cenie czasu trwania faz FIN<\/td>\n      <td>30\u201345 sekund<\/td>\n      <td>Zbyt niskie warto\u015bci sprzyjaj\u0105 poronieniom<\/td>\n      <td>Retransmisje, wska\u017anik RST<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_tw_reuse<\/td>\n      <td>Ponowne wykorzystanie gniazd TIME_WAIT<\/td>\n      <td>1 (selektywnie)<\/td>\n      <td>Ryzykowne w \u015brodowiskach NAT<\/td>\n      <td>Odsetek TIME_WAIT, wska\u017aniki b\u0142\u0119d\u00f3w<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_max_tw_buckets<\/td>\n      <td>Maksymalna liczba gniazd w stanie TIME_WAIT<\/td>\n      <td>Wysoka, odpowiednia warto\u015b\u0107<\/td>\n      <td>Zbyt ma\u0142y rozmiar powoduje zniekszta\u0142cenia<\/td>\n      <td>Zrzuty j\u0105dra, RST<\/td>\n    <\/tr>\n    <tr>\n      <td>przestarza\u0142e opcje (np. tcp_tw_recycle)<\/td>\n      <td>Dawne, problematyczne zachowanie<\/td>\n      <td>Pozostaw wy\u0142\u0105czone<\/td>\n      <td>Zablokowania w NAT i uzasadnione b\u0142\u0119dy po\u0142\u0105czenia<\/td>\n      <td>Cz\u0119ste b\u0142\u0119dy, skargi klient\u00f3w<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Najlepsze praktyki dotycz\u0105ce wprowadzania zmian w stosie sieciowym<\/h2>\n\n<p>W ka\u017cdym kroku zmieniam tylko kilka <strong>Parametry<\/strong>, aby m\u00f3c precyzyjnie przyporz\u0105dkowa\u0107 przyczyny i skutki. Na wst\u0119pie okre\u015blam jasne cele, takie jak brak wyczerpania port\u00f3w, akceptowalne warto\u015bci TIME_WAIT oraz sta\u0142e warto\u015bci op\u00f3\u017anie\u0144. Ka\u017cda zmiana trafia najpierw do system\u00f3w testowych z realistycznymi wzorcami obci\u0105\u017cenia i kontrolowanymi planami przywracania poprzedniego stanu. Podczas wdra\u017cania koreluj\u0119 wska\u017aniki sieciowe i aplikacyjne, poniewa\u017c tylko ich wzajemne oddzia\u0142ywanie odzwierciedla do\u015bwiadczenia u\u017cytkownik\u00f3w. Dopiero gdy wyniki pomiar\u00f3w s\u0105 przekonuj\u0105ce w kilku fazach obci\u0105\u017cenia, na sta\u0142e wprowadzam te ustawienia.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp-time-wait-optimization-guide-4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Optymalizacja gniazd na poziomie aplikacji<\/h2>\n\n<p>Najwi\u0119ksz\u0105 ulg\u0119 cz\u0119sto przynosi mi <strong>Keep-Alive<\/strong> oraz ponowne wykorzystywanie po\u0142\u0105cze\u0144, poniewa\u017c mniejsza liczba nowych po\u0142\u0105cze\u0144 generuje r\u00f3wnie\u017c mniej stan\u00f3w TIME_WAIT. W\u0142\u0105czam funkcj\u0119 HTTP Keep-Alive i wybieram rozs\u0105dne czasy bezczynno\u015bci, tak aby nieliczne, d\u0142ugotrwa\u0142e po\u0142\u0105czenia obs\u0142ugiwa\u0142y wiele \u017c\u0105da\u0144. Tam, gdzie to ma sens, stosuj\u0119 protoko\u0142y HTTP\/2 lub HTTP\/3, aby multipleksowa\u0107 wiele \u017c\u0105da\u0144 za pomoc\u0105 niewielkiej liczby po\u0142\u0105cze\u0144. W przypadku klient\u00f3w backendowych korzystam z pul po\u0142\u0105cze\u0144, kt\u00f3re utrzymuj\u0105 po\u0142\u0105czenia otwarte i starannie je odnawiaj\u0105. Zwi\u0119z\u0142y przegl\u0105d tego tematu mo\u017cna znale\u017a\u0107 w moim odno\u015bniku do <a href=\"https:\/\/webhosting.de\/pl\/http-connection-reuse-keepalive-optymalizacja-serverperf-boost\/\">HTTP Keep-Alive<\/a>, z kt\u00f3rego konsekwentnie korzystam w przypadku us\u0142ug internetowych.<\/p>\n\n<h2>Rozwi\u0105zania architektoniczne \u0142agodz\u0105ce problem TIME_WAIT<\/h2>\n\n<p>Rozk\u0142adam obci\u0105\u017cenie w p\u0142aszczy\u017anie poziomej, aby <strong>TIME_WAIT<\/strong> nie s\u0105 skoncentrowane na jednym ho\u015bcie, a porty zaczynaj\u0105 si\u0119 wyczerpywa\u0107. Wi\u0119ksza liczba adres\u00f3w IP lub dodatkowe porty list zwi\u0119kszaj\u0105 liczb\u0119 mo\u017cliwych kombinacji \u017ar\u00f3d\u0142owych\/docelowych i ograniczaj\u0105 kolizje. Serwery proxy odwrotne umieszczone przed serwerem \u017ar\u00f3d\u0142owym grupuj\u0105 po\u0142\u0105czenia klient\u00f3w i efektywnie komunikuj\u0105 si\u0119 wewn\u0119trznie z serwerami zaplecza w ramach puli. Kluczowe znaczenie maj\u0105 odpowiednio dostosowane warto\u015bci limit\u00f3w czasu, aby serwery proxy, urz\u0105dzenia r\u00f3wnowa\u017c\u0105ce obci\u0105\u017cenie i serwery zaplecza nie przerywa\u0142y po\u0142\u0105cze\u0144 przedwcze\u015bnie. U\u017cytkownicy serwera Apache powinni <a href=\"https:\/\/webhosting.de\/pl\/optymalne-ustawienie-limitu-czasu-keepalive-w-apache-z-naciskiem-na-wydajnosc\/\">Limit czasu Keep-Alive<\/a> dok\u0142adnie dostosowa\u0107 do wzorc\u00f3w ruchu i op\u00f3\u017anie\u0144.<\/p>\n\n<h2>Wyb\u00f3r hostingu i serwera z uwzgl\u0119dnieniem stanu TIME_WAIT<\/h2>\n\n<p>Preferuj\u0119 dostawc\u00f3w, kt\u00f3rzy maj\u0105 aktualne <strong>Linux<\/strong>-J\u0105dro, poniewa\u017c nowoczesne funkcje TCP u\u0142atwiaj\u0105 codzienn\u0105 prac\u0119. Precyzyjna kontrola za pomoc\u0105 parametr\u00f3w sysctl pozwala zaoszcz\u0119dzi\u0107 czas podczas analizy i wdra\u017cania. Zintegrowane monitorowanie stanu sieci i gniazd przyspiesza ocen\u0119 skutk\u00f3w wprowadzonych zmian. W przypadku us\u0142ug charakteryzuj\u0105cych si\u0119 du\u017c\u0105 liczb\u0105 kr\u00f3tkotrwa\u0142ych po\u0142\u0105cze\u0144 warto zainwestowa\u0107 w wydajny sprz\u0119t i sie\u0107, kt\u00f3ra z \u0142atwo\u015bci\u0105 radzi sobie ze szczytami obci\u0105\u017cenia. W ten spos\u00f3b nie tylko wdra\u017cam optymalizacje TIME_WAIT, ale tak\u017ce niezawodnie utrzymuj\u0119 je w prawid\u0142owym stanie podczas pracy.<\/p>\n\n<h2>Praktyczny przewodnik: Serwer API poddany kr\u00f3tkotrwa\u0142emu obci\u0105\u017ceniu<\/h2>\n\n<p>Zaczynam od rundy pomiarowej i rejestruj\u0119 <strong>Nowe po\u0142\u0105czenia<\/strong> na sekund\u0119, odsetek TIME_WAIT oraz wska\u017aniki b\u0142\u0119d\u00f3w. Nast\u0119pnie rozszerzam zakres ip_local_port_range i ostro\u017cnie zmniejszam warto\u015b\u0107 tcp_fin_timeout, obserwuj\u0105c przy tym liczb\u0119 retransmisji. W \u015brodowisku bez NAT w\u0142\u0105czam testowo opcj\u0119 tcp_tw_reuse, dokumentuj\u0119 wyniki i natychmiast reaguj\u0119 na wszelkie nieprawid\u0142owo\u015bci. R\u00f3wnolegle upewniam si\u0119, \u017ce funkcja Keep-Alive jest aktywna, protok\u00f3\u0142 HTTP\/2 dzia\u0142a, a aplikacja prawid\u0142owo wykorzystuje pule po\u0142\u0105cze\u0144. Na koniec sprawdzam trendy dotycz\u0105ce stanu TIME_WAIT w kilku okresach szczytowego obci\u0105\u017cenia, zanim ostatecznie ustal\u0119 ustawienia.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp_timewait_optimierung_5238.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitorowanie i bie\u017c\u0105ca eksploatacja<\/h2>\n\n<p>Dokumentuj\u0119 ka\u017cd\u0105 <strong>Poprawka<\/strong> wraz z warto\u015bci\u0105 pocz\u0105tkow\u0105, celem i zaobserwowanym efektem, abym m\u00f3g\u0142 p\u00f3\u017aniej szybko to zweryfikowa\u0107. Procesy zmian oparte na jasnej strategii przywracania stanu poprzedniego chroni\u0105 przed d\u0142ugotrwa\u0142ymi szkodami w razie b\u0142\u0119dnych decyzji. Opr\u00f3cz TIME_WAIT mierz\u0119 r\u00f3wnie\u017c RTT, retransmisje, przepustowo\u015b\u0107 u\u017cytkow\u0105 (Goodput) oraz wska\u017aniki b\u0142\u0119d\u00f3w, aby uzyska\u0107 pe\u0142ny obraz do\u015bwiadczenia u\u017cytkownika. W przypadku d\u0142ugotrwa\u0142ych po\u0142\u0105cze\u0144 z backendem uwa\u017cam, \u017ce <a href=\"https:\/\/webhosting.de\/pl\/ustawienia-tcp-keepalive-optymalizacja-hostingu-serverboost\/\">TCP Keepalive<\/a> konsekwentnie, aby zlikwidowa\u0107 zb\u0119dne po\u0142\u0105czenia i uwolni\u0107 zasoby. W ten spos\u00f3b wspieram optymalizacj\u0119 na co dzie\u0144, zamiast traktowa\u0107 j\u0105 jako jednorazowe dzia\u0142anie.<\/p>\n\n<h2>Kto obs\u0142uguje stan TIME_WAIT? Zamkni\u0119cie aktywne a pasywne<\/h2>\n<p>Zawsze sprawdzam, kt\u00f3ra strona aktywnie zamyka po\u0142\u0105czenie, poniewa\u017c strona, kt\u00f3ra je aktywnie zamyka, zazwyczaj trafia do <strong>TIME_WAIT<\/strong>. W przypadku klasycznych klient\u00f3w internetowych to cz\u0119sto klient si\u0119 zamyka, przez co serwer rejestruje mniej stan\u00f3w TIME_WAIT \u2013 natomiast w przypadku wywo\u0142a\u0144 backendowych moja aplikacja sama pe\u0142ni rol\u0119 klienta i gromadzi stany TIME_WAIT. Unikam wymuszonego aktywnego zamykania po\u0142\u0105cze\u0144 na serwerze (np. SO_LINGER=0), poniewa\u017c mo\u017ce to powodowa\u0107 sygna\u0142y RST i utrat\u0119 danych. Zamiast tego stawiam na <em>eleganckie zako\u0144czenie<\/em>, rozs\u0105dne limity czasu Keep-Alive oraz, w miar\u0119 mo\u017cliwo\u015bci, pozwalam klientowi na zamkni\u0119cie po\u0142\u0105czenia jako pierwszemu. Nie tylko zmniejsza to liczb\u0119 stan\u00f3w TIME_WAIT na serwerze, ale tak\u017ce ogranicza liczb\u0119 b\u0142\u0119d\u00f3w spowodowanych przedwczesnym przerwaniem po\u0142\u0105czenia. Gdy tworz\u0119 wiele po\u0142\u0105cze\u0144 wychodz\u0105cych (np. z bazami danych, serwerami upstream), dobre ponowne wykorzystanie po\u0142\u0105cze\u0144 przynosi bardziej bezpo\u015brednie efekty ni\u017c jakiekolwiek dostrajanie j\u0105dra.<\/p>\n\n<h2>Prawid\u0142owe wymiarowanie kolejek listowych i kolejek akceptacyjnych<\/h2>\n<p>Dbam o to, by po\u0142\u0105czenia przychodz\u0105ce nie ko\u0144czy\u0142y si\u0119 niepowodzeniem jeszcze przed uruchomieniem aplikacji. W tym celu dostosowuj\u0119 <strong>net.core.somaxconn<\/strong> oraz warto\u015bci zaleg\u0142o\u015bci mojego serwera WWW, aby kolejka Accept nie uleg\u0142a przepe\u0142nieniu. <strong>net.ipv4.tcp_max_syn_backlog<\/strong> Dobieram rozmiar odpowiednio do szczytowej warto\u015bci przychodz\u0105cych \u017c\u0105da\u0144 nawi\u0105zania po\u0142\u0105czenia; zbyt ma\u0142e warto\u015bci powoduj\u0105 utrat\u0119 pakiet\u00f3w ju\u017c w fazie SYN. <strong>tcp_syncookies<\/strong> Utrzymuj\u0119 t\u0119 opcj\u0119 w\u0142\u0105czon\u0105, aby system zachowywa\u0142 stabilno\u015b\u0107 podczas kr\u00f3tkotrwa\u0142ych skok\u00f3w obci\u0105\u017cenia, ale w testach obci\u0105\u017ceniowych sprawdzam, czy nie spowalnia to normalnego ruchu. Je\u015bli korzystam z wielu proces\u00f3w roboczych, ustawiam <strong>SO_REUSEPORT<\/strong>, aby r\u00f3wnomiernie roz\u0142o\u017cy\u0107 obci\u0105\u017cenie mi\u0119dzy rdzeniami procesora i zmniejszy\u0107 konflikt blokad Accept. \u015arodki te nie rozwi\u0105zuj\u0105 problemu niedoboru port\u00f3w, ale zapobiegaj\u0105 b\u0142\u0119dnym interpretacjom, gdy odrzucenia s\u0105 mylnie przypisywane do stanu TIME_WAIT.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/tcp_timewait_optimierung_3492.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>NAT, modu\u0142 r\u00f3wnowa\u017cenia obci\u0105\u017cenia i Conntrack \u2013 co warto mie\u0107 na uwadze<\/h2>\n<p>Dok\u0142adnie rozr\u00f3\u017cniam problemy zwi\u0105zane z serwerem g\u0142\u00f3wnym od problem\u00f3w zwi\u0105zanych z urz\u0105dzeniami brzegowymi. Za serwerem SNAT lub Cloud-NAT mo\u017ce znajdowa\u0107 si\u0119 nie tylko serwer, ale tak\u017ce brama NAT wraz z jej <em>wychodz\u0105ce<\/em> Porty efemeryczne staj\u0105 si\u0119 w\u0105skim gard\u0142em. W takich sytuacjach zmniejszam obci\u0105\u017cenie poprzez dodanie dodatkowych adres\u00f3w IP wyj\u015bciowych, bardziej precyzyjny podzia\u0142 port\u00f3w lub zmniejszenie cz\u0119stotliwo\u015bci ponownego nawi\u0105zywania po\u0142\u0105cze\u0144 za pomoc\u0105 pul. Na urz\u0105dzeniach brzegowych z systemem Linux sprawdzam <strong>nf_conntrack_max<\/strong> oraz limity czasu TCP w Conntrack; zbyt d\u0142ugie utrzymywanie \u015bledzenia bliskiego stanu TIME_WAIT zajmuje pami\u0119\u0107 i mo\u017ce wypiera\u0107 prawid\u0142owe strumienie. Czas wyga\u015bni\u0119cia w Conntracku zmniejszam ostro\u017cnie i zawsze w po\u0142\u0105czeniu z warto\u015bciami aplikacji i j\u0105dra, aby nie odci\u0105\u0107 segment\u00f3w sp\u00f3\u017anionych. Wa\u017cne: <strong>tcp_tw_reuse<\/strong> dzia\u0142a wy\u0142\u0105cznie na po\u0142\u0105czenia wychodz\u0105ce z hosta, a nie na po\u0142\u0105czenia przychodz\u0105ce do nas\u0142uchuj\u0105cego, i ustawia <strong>tcp_timestamps=1<\/strong> Z tego powodu \u015brodowiska NAT testuj\u0119 szczeg\u00f3lnie dok\u0142adnie.<\/p>\n\n<h2>HTTP\/3 i UDP: co si\u0119 zmienia?<\/h2>\n<p>Wraz z wprowadzeniem protoko\u0142u HTTP\/3 transport przechodzi na <strong>QUIC\/UDP<\/strong>, co eliminuje klasyczny stan TCP-TIME_WAIT. Dlatego planuj\u0119 inaczej: zamiast stan\u00f3w TCP obserwuj\u0119 liczb\u0119 gniazd UDP, obci\u0105\u017cenie port\u00f3w efemerycznych oraz wpisy Conntrack dla protoko\u0142u UDP. QUIC zauwa\u017calnie obni\u017ca koszty nawi\u0105zywania po\u0142\u0105cze\u0144 i zmniejsza rotacj\u0119 po\u0142\u0105cze\u0144, wymaga jednak sp\u00f3jnych limit\u00f3w czasu bezczynno\u015bci (idle timeouts) mi\u0119dzy klientem, serwerem proxy a serwerem \u017ar\u00f3d\u0142owym. W \u015brodowiskach mieszanych (H2\/H3) zwracam uwag\u0119 na to, aby polityki Keep-Alive pozostawa\u0142y sp\u00f3jne, tak aby korzy\u015bci wynikaj\u0105ce z multipleksowania nie zosta\u0142y zaprzepaszczone przez zbyt kr\u00f3tkie limity czasu bezczynno\u015bci.<\/p>\n\n<h2>Ograniczenia zasob\u00f3w i ograniczenia systemu operacyjnego<\/h2>\n<p>Na pocz\u0105tek przedstawiam rzetelne <strong>Ograniczenia dotycz\u0105ce deskryptor\u00f3w plik\u00f3w<\/strong> (ulimit nofile, fs.file\u2011max, fs.nr_open), poniewa\u017c zbyt w\u0105skie limity powoduj\u0105 wt\u00f3rne b\u0142\u0119dy, kt\u00f3re TIME_WAIT jedynie maskuje. Limity pami\u0119ci TCP (<strong>net.ipv4.tcp_mem<\/strong>, <strong>tcp_rmem<\/strong>, <strong>tcp_wmem<\/strong>) reguluj\u0119 w taki spos\u00f3b, aby stos nie znalaz\u0142 si\u0119 pod presj\u0105 pami\u0119ci przy du\u017cej liczbie jednoczesnych po\u0142\u0105cze\u0144. Je\u015bli chodzi o wyra\u017anie oddzielone porty us\u0142ugowe, uwa\u017cam, \u017ce <strong>ip_local_reserved_ports<\/strong> aktualnie, aby porty efemeryczne nie kolidowa\u0142y przypadkowo z portami serwera. W testach obci\u0105\u017ceniowych sprawdzam, czy wzrost wielko\u015bci slab\u00f3w (np. dla blok\u00f3w steruj\u0105cych TCP) pozostaje stabilny \u2013 tylko w ten spos\u00f3b oceniam, czy wy\u017csza warto\u015b\u0107 tcp_max_tw_buckets jest rzeczywi\u015bcie wykonalna.<\/p>\n\n<h2>Specyfika kontener\u00f3w i Kubernetes<\/h2>\n<p>W kontenerach uwzgl\u0119dniam fakt, \u017ce zakresy port\u00f3w efemerycznych, ulimits i sysctls na <em>Przestrze\u0144 nazw<\/em> mog\u0105 si\u0119 r\u00f3\u017cni\u0107. Siatki us\u0142ugowe (service meshes) i modu\u0142y sidecar cz\u0119sto podwajaj\u0105 liczb\u0119 po\u0142\u0105cze\u0144 (klient\u2194modu\u0142 sidecar\u2194proxy\u2194backend), a tym samym zwi\u0119kszaj\u0105 ryzyko wyst\u0105pienia stanu TIME_WAIT \u2013 w tym zakresie najwi\u0119ksze korzy\u015bci osi\u0105gam dzi\u0119ki ponownemu wykorzystaniu po\u0142\u0105cze\u0144 i odpowiednio dostosowanym timerom bezczynno\u015bci. NodePorts i SNAT na w\u0119z\u0142ach roboczych dodatkowo obci\u0105\u017caj\u0105 tabele Conntrack; obserwuj\u0119 te warto\u015bci oddzielnie od hosta poda. Pod obci\u0105\u017ceniem rozdzielam ruch wychodz\u0105cy na kilka w\u0119z\u0142\u00f3w lub korzystam z dedykowanych bramek wychodz\u0105cych, aby unikn\u0105\u0107 przeci\u0105\u017cenia port\u00f3w. Wa\u017cne jest, aby pami\u0119ta\u0107: je\u015bli optymalizuj\u0119 pod, sie\u0107 hosta (w tym NAT\/Conntrack) musi by\u0107 do tego dostosowana, w przeciwnym razie tylko przenosz\u0119 problem w inne miejsce.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverraum-optimierung-4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Podr\u0119cznik diagnostyczny i przydatne warto\u015bci orientacyjne<\/h2>\n<p>Aby szybko oceni\u0107 sytuacj\u0119, stosuj\u0119 sta\u0142\u0105 sekwencj\u0119 czynno\u015bci: Po pierwsze <em>ss -s<\/em> oraz <em>ss -tan stan oczekiwania<\/em> co do rz\u0119du wielko\u015bci, po drugie <em>\/proc\/sys\/net\/ipv4\/ip_local_port_range<\/em> sprawdzam i szacuj\u0119 liczb\u0119 wolnych port\u00f3w efemerycznych, a po trzecie \u2013 weryfikuj\u0119 komunikaty o b\u0142\u0119dach i wska\u017aniki RST w logach aplikacji i j\u0105dra. Nast\u0119pnie mierz\u0119 liczb\u0119 nowych po\u0142\u0105cze\u0144 na sekund\u0119 i koreluj\u0119 j\u0105 z op\u00f3\u017anieniami. Jako warto\u015bci orientacyjne akceptuj\u0119 wysoki odsetek TIME_WAIT, o ile: nie dochodzi do wyczerpania port\u00f3w, nie dochodzi do przepe\u0142nienia kolejki Accept, retransmisje pozostaj\u0105 stabilne, a czasy odpowiedzi nie ulegaj\u0105 odchyleniom. Optymalizacj\u0119 uznaj\u0119 za \u201ezako\u0144czon\u0105\u201c dopiero wtedy, gdy te same szczyty obci\u0105\u017cenia s\u0105 powtarzalne przez kilka dni bez \u017cadnych anomalii.<\/p>\n\n<h2>Typowe b\u0142\u0119dy i przeciwwskazania<\/h2>\n\n<p>Unikam masowego wy\u0142\u0105czania <strong>TIME_WAIT<\/strong>, poniewa\u017c nara\u017cam si\u0119 w ten spos\u00f3b na mieszanie danych i sporadyczne b\u0142\u0119dy. \u015alepe skracanie limit\u00f3w czasu powoduje, \u017ce u\u017cytkownicy musz\u0105 znosi\u0107 przerwy w po\u0142\u0105czeniu pod obci\u0105\u017ceniem. Nie ingeruj\u0119 w przestarza\u0142e opcje, takie jak tcp_tw_recycle, poniewa\u017c mog\u0105 one przerywa\u0107 prawid\u0142owe po\u0142\u0105czenia. Samo dostrojenie j\u0105dra bez prac nad aplikacjami i architektur\u0105 przynosi niewielkie korzy\u015bci, je\u015bli powstaje zbyt wiele kr\u00f3tkotrwa\u0142ych po\u0142\u0105cze\u0144. Kto zmienia wszystko naraz, utrudnia sobie rzeteln\u0105 analiz\u0119 przyczyn i wyd\u0142u\u017ca czas poszukiwania b\u0142\u0119d\u00f3w.<\/p>\n\n<h2>Kompaktowe podsumowanie dla administrator\u00f3w<\/h2>\n\n<p>Traktuj\u0119 <strong>TIME_WAIT<\/strong> Jako mechanizm zabezpieczaj\u0105cy najpierw dok\u0142adnie dokonuj\u0119 pomiar\u00f3w, a dopiero potem stopniowo optymalizuj\u0119. Najwi\u0119kszy efekt osi\u0105gam dzi\u0119ki ponownemu wykorzystaniu po\u0142\u0105cze\u0144 za pomoc\u0105 Keep-Alive, HTTP\/2\/3 i pul, w po\u0142\u0105czeniu z ostro\u017cnymi dostosowaniami sysctl. Elementy architektury, takie jak dodatkowe adresy IP, serwery proxy i skalowanie horyzontalne, skutecznie rozk\u0142adaj\u0105 obci\u0105\u017cenie po\u0142\u0105cze\u0144. Bie\u017c\u0105cy monitoring, przejrzysta dokumentacja i jasno okre\u015blone cele zapewniaj\u0105 sta\u0142e op\u00f3\u017anienia i dost\u0119pno\u015b\u0107 port\u00f3w. Dzi\u0119ki temu serwer WWW pozostaje responsywny nawet przy du\u017cym nat\u0119\u017ceniu ruchu, a stan TIME_WAIT dzia\u0142a w spos\u00f3b kontrolowany i przewidywalny.<\/p>","protected":false},"excerpt":{"rendered":"<p>Dowiedz si\u0119, jak bezpiecznie zoptymalizowa\u0107 stan \u201etime_wait\u201d protoko\u0142u TCP na silnie obci\u0105\u017conych serwerach internetowych oraz jak unikn\u0105\u0107 wyczerpania port\u00f3w dzi\u0119ki ukierunkowanej optymalizacji systemu Linux i gniazd.<\/p>","protected":false},"author":1,"featured_media":21208,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[676],"tags":[],"class_list":["post-21215","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-server_vm"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"177","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"TCP TIME_WAIT","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21208","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/21215","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/comments?post=21215"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/21215\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/21208"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=21215"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=21215"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=21215"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}