{"id":18881,"date":"2026-04-09T18:20:39","date_gmt":"2026-04-09T16:20:39","guid":{"rendered":"https:\/\/webhosting.de\/http-connection-reuse-keepalive-optimierung-serverperf-boost\/"},"modified":"2026-04-09T18:20:39","modified_gmt":"2026-04-09T16:20:39","slug":"http-connection-reuse-keepalive-optymalizacja-serverperf-boost","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/http-connection-reuse-keepalive-optimierung-serverperf-boost\/","title":{"rendered":"Ponowne wykorzystanie po\u0142\u0105cze\u0144 HTTP i optymalizacja po\u0142\u0105cze\u0144 keep-alive: zwi\u0119kszenie wydajno\u015bci serwera WWW"},"content":{"rendered":"<p>Pokazuj\u0119, jak <strong>Ponowne wykorzystanie po\u0142\u0105czenia HTTP<\/strong> i ustrukturyzowane dostrajanie keep-alive zmniejszaj\u0105 narzut zwi\u0105zany z u\u015bciskiem d\u0142oni TCP i TLS, dzi\u0119ki czemu strony reaguj\u0105 szybciej, a serwery musz\u0105 robi\u0107 mniej. Dzi\u0119ki odpowiednim limitom czasu, limitom i funkcjom protoko\u0142u zmniejszam <strong>Op\u00f3\u017anienie<\/strong>, Wyg\u0142adzenie szczyt\u00f3w obci\u0105\u017cenia i znaczne zwi\u0119kszenie przepustowo\u015bci.<\/p>\n\n<h2>Punkty centralne<\/h2>\n\n<ul>\n  <li><strong>Keep-Alive<\/strong> zmniejsza liczb\u0119 u\u015bcisk\u00f3w d\u0142oni i skraca <strong>Czasy \u0142adowania<\/strong>.<\/li>\n  <li><strong>Limity czasu<\/strong> i utrzymywa\u0107 limity <strong>Zasoby<\/strong> skuteczny.<\/li>\n  <li><strong>HTTP\/2<\/strong> i HTTP\/3 <strong>Ponowne u\u017cycie<\/strong> poprzez multipleksowanie.<\/li>\n  <li><strong>\u0141\u0105czenie klient\u00f3w<\/strong> obni\u017ca backend<strong>Op\u00f3\u017anienie<\/strong>.<\/li>\n  <li><strong>Monitoring<\/strong> sprawia, \u017ce tuning jest udany <strong>wymierny<\/strong>.<\/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\/04\/http-server-optimierung-9347.png\" alt=\"Wydajna optymalizacja HTTP w serwerowni\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Co oznacza ponowne u\u017cycie po\u0142\u0105czenia HTTP?<\/h2>\n\n<p>U\u017cywam <strong>Ponowne u\u017cycie po\u0142\u0105czenia<\/strong>, wysy\u0142anie wielu \u017c\u0105da\u0144 HTTP za po\u015brednictwem jednego po\u0142\u0105czenia TCP, a tym samym unikanie kosztownych ponownych po\u0142\u0105cze\u0144. Ka\u017cde nowe po\u0142\u0105czenie kosztuje trzy pakiety TCP plus ewentualny u\u015bcisk d\u0142oni TLS, co oszcz\u0119dza czas i pieni\u0105dze. <strong>CPU<\/strong> je. Je\u015bli linia pozostaje otwarta, kolejne \u017c\u0105dania dzia\u0142aj\u0105 na tym samym gnie\u017adzie i oszcz\u0119dzaj\u0105 podr\u00f3\u017cy w obie strony. Witryny z wieloma ma\u0142ymi zasobami, takimi jak CSS, JS i obrazy, odnosz\u0105 szczeg\u00f3lne korzy\u015bci, poniewa\u017c czas oczekiwania na obiekt jest skr\u00f3cony. W HTTP\/1.1 nag\u0142\u00f3wek \u201cConnection: keep-alive\u201d sygnalizuje ponowne u\u017cycie, co zauwa\u017calnie zmniejsza op\u00f3\u017anienia i stabilizuje przepustowo\u015b\u0107.<\/p>\n\n<h2>Dlaczego Keep-Alive poprawia wydajno\u015b\u0107 serwera WWW<\/h2>\n\n<p>Polegam na <strong>Keep-Alive<\/strong>-tuning, poniewa\u017c zmniejsza narzuty w j\u0105drze i TLS, umo\u017cliwiaj\u0105c przej\u015bcie wi\u0119kszej ilo\u015bci \u0142adunku na sekund\u0119 przez lini\u0119. W testach efektywna przepustowo\u015b\u0107 cz\u0119sto wzrasta nawet o 50 procent, poniewa\u017c u\u015bciski d\u0142oni s\u0105 eliminowane, a przepustowo\u015b\u0107 \u0142\u0105cza wzrasta. <strong>CPU<\/strong> wykonuje mniej prze\u0142\u0105cze\u0144 kontekstu. Jednocze\u015bnie strony reaguj\u0105 szybciej, poniewa\u017c przegl\u0105darki mog\u0105 szybko prze\u0142adowywa\u0107 dodatkowe obiekty. Kr\u00f3tkie timeouty zapobiegaj\u0105 zajmowaniu pami\u0119ci RAM przez bezczynne po\u0142\u0105czenia, a limity dla keepalive_requests zapewniaj\u0105 stabilno\u015b\u0107. W ten spos\u00f3b utrzymuj\u0119 liczb\u0119 aktywnych gniazd w zielonej strefie i unikam w\u0105skich garde\u0142 przy szczytowym obci\u0105\u017ceniu.<\/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\/04\/http-opt-meeting-1045.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Konfiguracja po stronie serwera: Nginx, Apache i serwery proxy<\/h2>\n\n<p>W\u0142o\u017cy\u0142em <strong>Nginx<\/strong> tak, aby czasy oczekiwania by\u0142y wystarczaj\u0105co kr\u00f3tkie, aby zaoszcz\u0119dzi\u0107 pami\u0119\u0107 RAM, ale wystarczaj\u0105co d\u0142ugie, aby przegl\u0105darki mog\u0142y pobiera\u0107 kilka obiekt\u00f3w po kolei. W przypadku typowych stron internetowych dobrze radz\u0119 sobie z 60-120 sekundami bezczynno\u015bci i 50-200 \u017c\u0105daniami na po\u0142\u0105czenie, kt\u00f3re por\u00f3wnuj\u0119 z rzeczywistymi wzorcami ruchu. Przyk\u0142ad pokazuje, jak zaczynam, a nast\u0119pnie dostrajam. Przez link <a href=\"https:\/\/webhosting.de\/pl\/konfiguracja-wydajnosci-serwera-http-keepalive-timeout\/\">Konfiguracja czasu oczekiwania na po\u0142\u0105czenie<\/a> Zag\u0142\u0119biam si\u0119 w szczeg\u00f3\u0142y, takie jak otwarte deskryptory plik\u00f3w i kolejki akceptacji. W przypadku odwrotnych serwer\u00f3w proxy aktywuj\u0119 proxy_http_version 1.1, dzi\u0119ki czemu keep-alive jest przekazywane czysto, a backendy korzystaj\u0105 z ponownego u\u017cycia.<\/p>\n\n<pre><code># Nginx (frontend \/ reverse proxy)\nkeepalive_timeout 65s;\nkeepalive_requests 100;\n\n# Proxy to upstream\nproxy_http_version 1.1;\nproxy_set_header Connection \"\";\n\n# Apache (przyk\u0142ad)\nKeepAlive On\nMaxKeepAliveRequests 100\nKeepAliveTimeout 5\n<\/code><\/pre>\n\n<h2>TLS, HTTP\/2 i HTTP\/3: protoko\u0142y, kt\u00f3re wzmacniaj\u0105 ponowne u\u017cycie<\/h2>\n\n<p>\u0141\u0105cz\u0119 <strong>Keep-Alive<\/strong> z TLS 1.3, wznawianiem sesji i zszywaniem OCSP, dzi\u0119ki czemu po\u0142\u0105czenia s\u0105 dost\u0119pne szybciej. W HTTP\/2 \u0142\u0105cz\u0119 wiele strumieni w jedno po\u0142\u0105czenie, co eliminuje op\u00f3\u017anienia na poziomie aplikacji. Efekt zwi\u0119ksza si\u0119 wraz z <strong>Multipleksowanie<\/strong>, poniewa\u017c przegl\u0105darki \u017c\u0105daj\u0105 zasob\u00f3w r\u00f3wnolegle bez konieczno\u015bci tworzenia nowych gniazd. Aby uzyska\u0107 dobrze uzasadnion\u0105 kategoryzacj\u0119, zapoznaj si\u0119 z <a href=\"https:\/\/webhosting.de\/pl\/http2-multipleksowanie-vs-http11-wydajnosc-tlo-optymalizacja\/\">Multipleksowanie HTTP\/2<\/a>, kt\u00f3ry wyra\u017anie pokazuje r\u00f3\u017cnice w stosunku do HTTP\/1.1. HTTP\/3 z QUIC zapewnia r\u00f3wnie\u017c start 0-RTT dla \u017c\u0105da\u0144 idempotentnych i reaguje zauwa\u017calnie szybciej w przypadku utraty pakiet\u00f3w.<\/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\/04\/http-connection-reuse-8542.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Optymalizacja po stronie klienta: Node.js i Python<\/h2>\n\n<p>Aktywuj\u0119 <strong>Keep-Alive<\/strong> r\u00f3wnie\u017c w kliencie, dzi\u0119ki czemu wywo\u0142ania API i backendu wymagaj\u0105 mniej konfiguracji po\u0142\u0105czenia. W Node.js u\u017cywam https.agent z pul\u0105 po\u0142\u0105cze\u0144, kt\u00f3ra zmniejsza op\u00f3\u017anienia i przyspiesza czas do pierwszego bajtu. Python z requests.Session() robi to samo w prosty spos\u00f3b, czyni\u0105c us\u0142ugi bardziej stabilnymi. Utrzymuje to kr\u00f3tkie \u015bcie\u017cki transportowe i oszcz\u0119dza podr\u00f3\u017ce w obie strony. Skutkuje to bardziej sp\u00f3jnymi czasami odpowiedzi i wymiernie ni\u017cszym kosztem. <strong>Obci\u0105\u017cenie serwera<\/strong>.<\/p>\n\n<pre><code>\/\/ Node.js\nconst https = require('https');\nconst httpsAgent = new https.Agent({\n  keepAlive: true,\n  keepAliveMsecs: 60000,\n  maxSockets: 50\n});\n\n\/\/ U\u017cycie: fetch \/ axios \/ natywny https z httpsAgent\n\n# Python\nimport requests\nsession = requests.Session() # Reuse &amp; Pooling\nr = session.get('https:\/\/api.example.com\/data') # mniej u\u015bcisk\u00f3w d\u0142oni\n<\/code><\/pre>\n\n<h2>Typowe warto\u015bci i ich wp\u0142yw<\/h2>\n\n<p>Zaczynam od konserwatywnych <strong>Warto\u015bci<\/strong> i mierz\u0119, czy po\u0142\u0105czenia maj\u0105 tendencj\u0119 do zawieszania si\u0119 lub zbyt wczesnego zamykania. Je\u015bli spodziewam si\u0119 szczyt\u00f3w obci\u0105\u017cenia, skracam limity czasu, aby utrzyma\u0107 woln\u0105 pami\u0119\u0107 RAM bez zmuszania przegl\u0105darek do ci\u0105g\u0142ego ponownego \u0142\u0105czenia. Je\u015bli r\u00f3wnoleg\u0142o\u015b\u0107 jest wysoka, ustawiam maksymalne deskryptory plik\u00f3w wystarczaj\u0105co wysoko, aby unikn\u0105\u0107 w\u0105skich garde\u0142 akceptacji. Poni\u017csza tabela zawiera szybki przegl\u0105d tego, jak zaczynam i co robi\u0105 poszczeg\u00f3lne ustawienia. Nast\u0119pnie dostosowuj\u0119 je stopniowo i uwa\u017cnie obserwuj\u0119 metryki pod k\u0105tem <strong>Poprawki<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Parametry<\/th>\n      <th>Nginx<\/th>\n      <th>Apacz<\/th>\n      <th>Typowa warto\u015b\u0107 pocz\u0105tkowa<\/th>\n      <th>Efekt<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Limit czasu bezczynno\u015bci<\/td>\n      <td>keepalive_timeout<\/td>\n      <td>KeepAliveTimeout<\/td>\n      <td>60\u2013120 s<\/td>\n      <td>Wyr\u00f3wnuje ponowne u\u017cycie i zu\u017cycie pami\u0119ci RAM<\/td>\n    <\/tr>\n    <tr>\n      <td>\u017b\u0105dania na po\u0142\u0105czenie<\/td>\n      <td>keepalive_requests<\/td>\n      <td>MaxKeepAliveRequests<\/td>\n      <td>50-200<\/td>\n      <td>Stabilizuje wykorzystanie na gniazdo<\/td>\n    <\/tr>\n    <tr>\n      <td>Wersja proxy<\/td>\n      <td>proxy_http_version<\/td>\n      <td>\u2013<\/td>\n      <td>1.1<\/td>\n      <td>Umo\u017cliwia przekazywanie keep-alive<\/td>\n    <\/tr>\n    <tr>\n      <td>Otwarte deskryptory<\/td>\n      <td>worker_rlimit_nofile<\/td>\n      <td>ulimit -n<\/td>\n      <td>&gt;= 65535<\/td>\n      <td>Zapobiega niedoborom gniazd<\/td>\n    <\/tr>\n    <tr>\n      <td>Akceptuj kolejk\u0119<\/td>\n      <td>net.core.somaxconn<\/td>\n      <td>ListenBacklog<\/td>\n      <td>512-4096<\/td>\n      <td>Zmniejsza spadki przy szczytach<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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\/04\/webserver_perf_3498.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Monitorowanie i testy obci\u0105\u017ceniowe: licz\u0105 si\u0119 metryki<\/h2>\n\n<p>Oceniam <strong>Ponowne u\u017cycie<\/strong>-Sukcesy z wrk lub ApacheBench i skorelowa\u0107 je z logami i metrykami systemowymi. Wa\u017cne s\u0105 otwarte gniazda, wolne gniazda, oczekuj\u0105ce \u017c\u0105dania i kody b\u0142\u0119d\u00f3w wskazuj\u0105ce na w\u0105skie gard\u0142a. Je\u015bli liczba bezczynnych po\u0142\u0105cze\u0144 wzrasta, obni\u017cam timeouty lub umiarkowanie redukuj\u0119 keepalive_requests. Je\u015bli po\u0142\u0105czenia s\u0105 przerywane zbyt cz\u0119sto, zwi\u0119kszam limity lub sprawdzam, czy backendy odpowiadaj\u0105 zbyt wolno. Pozwala mi to szybko znale\u017a\u0107 punkt, w kt\u00f3rym op\u00f3\u017anienie, przepustowo\u015b\u0107 i wydajno\u015b\u0107 s\u0105 zbyt niskie. <strong>Zasoby<\/strong> dobrze do siebie pasuj\u0105.<\/p>\n\n<h2>Praktyka WordPress: Mniej \u017c\u0105da\u0144, szybsze pierwsze malowanie<\/h2>\n\n<p>Zmniejszam liczb\u0119 \u017c\u0105da\u0144 HTTP o <strong>CSS\/JS<\/strong> bundle, u\u017cywa\u0107 ikon jako sprite'\u00f3w SVG i dostarcza\u0107 czcionki lokalnie. W po\u0142\u0105czeniu z buforowaniem przegl\u0105darki, liczba transfer\u00f3w sieciowych przy ponownych odwiedzinach jest drastycznie zmniejszona. Stwarza to wi\u0119ksze mo\u017cliwo\u015bci ponownego wykorzystania, poniewa\u017c przegl\u0105darki wymagaj\u0105 mniejszej liczby nowych gniazd. Je\u015bli chcesz zag\u0142\u0119bi\u0107 si\u0119 w temat, mo\u017cesz znale\u017a\u0107 praktyczne kroki w sekcji <a href=\"https:\/\/webhosting.de\/pl\/przewodnik-po-optymalizacji-wydajnosci-serwera-www\/\">Przewodnik dostrajania funkcji Keep-Alive<\/a>, kt\u00f3ry wyja\u015bnia \u015bcie\u017cki dostrajania od limitu czasu do konfiguracji pracownika. W ostatecznym rozrachunku liczy si\u0119 to, \u017ce strony \u0142aduj\u0105 si\u0119 zauwa\u017calnie szybciej i \u017ce <strong>Obci\u0105\u017cenie serwera<\/strong> pozostaje przewidywalny.<\/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\/04\/webserverperformance1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Skalowanie i zasoby systemowe<\/h2>\n\n<p>Sprawdzam <strong>CPU<\/strong>-profile, ilo\u015b\u0107 pami\u0119ci na pracownika i kart\u0119 sieciow\u0105, zanim zwi\u0119ksz\u0119 limity. Wy\u017csza r\u00f3wnoleg\u0142o\u015b\u0107 jest przydatna tylko wtedy, gdy ka\u017cda warstwa ma wystarczaj\u0105c\u0105 ilo\u015b\u0107 bufor\u00f3w i deskryptor\u00f3w. NUMA affinity, dystrybucja IRQ i szybkie implementacje TLS zapewniaj\u0105 dodatkowe rezerwy. W przypadku kontener\u00f3w zwracam uwag\u0119 na limity otwartych plik\u00f3w i twarde limity hosta, kt\u00f3re w przeciwnym razie spowalniaj\u0105 ponowne u\u017cycie. W ten spos\u00f3b unikam w\u0105skich garde\u0142, kt\u00f3re szybko staj\u0105 si\u0119 zauwa\u017calne przy rosn\u0105cym ruchu i marnuj\u0105 cenne zasoby. <strong>Wydajno\u015b\u0107<\/strong> kosztowa\u0107.<\/p>\n\n<h2>Obrazy b\u0142\u0119d\u00f3w i rozwi\u0105zywanie problem\u00f3w<\/h2>\n\n<p>Rozpoznaj\u0119 <strong>B\u0142\u0105d<\/strong> Cz\u0119sto zauwa\u017cam wzorce: zbyt wiele gniazd TIME_WAIT, rosn\u0105ce 502\/504 lub nag\u0142e za\u0142amania RPS. Nast\u0119pnie sprawdzam, czy backendy akceptuj\u0105 keep-alive i czy nag\u0142\u00f3wki proxy s\u0105 ustawione poprawnie. Nieprawid\u0142owe czasy bezczynno\u015bci na poszczeg\u00f3lnych w\u0119z\u0142ach cz\u0119sto wywo\u0142uj\u0105 reakcje \u0142a\u0144cuchowe, kt\u00f3re naprawiam, ustawiaj\u0105c sp\u00f3jne warto\u015bci. Problemy z TLS objawiaj\u0105 si\u0119 jako skoki handshake_time, kt\u00f3re \u0142agodzi wznowienie sesji lub optymalizacja 1.3. Dzi\u0119ki ukierunkowanym dostosowaniom stabilizuj\u0119 \u0142a\u0144cuch od kraw\u0119dzi do serwera aplikacji i utrzymuj\u0119 <strong>Czasy reakcji<\/strong> niezawodny.<\/p>\n\n<h2>Utrzymywanie sp\u00f3jnych limit\u00f3w czasu mi\u0119dzy zmianami<\/h2>\n\n<p>Wyr\u00f3wnuj\u0119 <strong>Limity czasu bezczynno\u015bci i aktywno\u015bci<\/strong> na wszystkich w\u0119z\u0142ach: CDN\/WAF, load balancer, reverse proxy i aplikacja. Zbyt kr\u00f3tki limit czasu pochodzenia odcina po\u0142\u0105czenia, gdy przegl\u0105darka wci\u0105\u017c si\u0119 \u0142aduje; zbyt d\u0142ugi limit czasu kraw\u0119dzi wype\u0142nia pami\u0119\u0107 RAM bezczynnymi gniazdami. Dlatego planuj\u0119 kaskadowo: Edge troch\u0119 <em>kr\u00f3tszy<\/em> jako przegl\u0105darka bezczynna, proxy w centrum, najd\u0142u\u017cszy limit czasu backendu. W ten spos\u00f3b unikam RST i zapobiegam bezcelowemu ko\u0144czeniu drogich po\u0142\u0105cze\u0144 TLS.<\/p>\n\n<pre><code># Nginx: precyzyjne timeouty i ponowne wykorzystanie upstreamu\nclient_header_timeout 10s;\nclient_body_timeout 30s;\nsend_timeout 15s;\n\nproxy_read_timeout 60s;\nproxy_send_timeout 60s;\nproxy_socket_keepalive on; # Szybsze wykrywanie martwego peera\n\nupstream backend_pool {\n  server app1:8080;\n  server app2:8080;\n  keepalive 64; # Cache bezczynnych po\u0142\u0105cze\u0144 upstream\n  keepalive_timeout 60s; # (z wersji Nginx z limitem czasu upstream)\n  keepalive_requests 1000;\n}\n<\/code><\/pre>\n\n<p>Rozr\u00f3\u017cniam mi\u0119dzy <strong>HTTP-Keep-Alive<\/strong> z <strong>TCP-Keepalive<\/strong> (SO_KEEPALIVE). U\u017cywam tego ostatniego specjalnie na gniazdach proxy, aby rozpozna\u0107 zawieszaj\u0105ce si\u0119 zdalne stacje bez niepotrzebnego ko\u0144czenia ponownego u\u017cycia HTTP.<\/p>\n\n<h2>Dostrajanie HTTP\/2 i HTTP\/3: prawid\u0142owe korzystanie z multipleksowania<\/h2>\n\n<p>Ustawi\u0142em HTTP\/2 tak, aby strumienie dzia\u0142a\u0142y wydajnie r\u00f3wnolegle bez generowania head-of-line na serwerze. Aby to zrobi\u0107, ograniczam maksymaln\u0105 liczb\u0119 strumieni na sesj\u0119 i utrzymuj\u0119 kr\u00f3tki czas bezczynno\u015bci, aby zapomniane sesje nie pozosta\u0142y w tyle. U\u017cywam priorytetyzacji do <strong>Zasoby krytyczne<\/strong> i upewni\u0107 si\u0119, \u017ce HTTP\/3 ma czyst\u0105 konfiguracj\u0119 0-RTT tylko dla \u017c\u0105da\u0144 idempotentnych.<\/p>\n\n<pre><code>Optymalizacja # Nginx HTTP\/2\nhttp2_max_concurrent_streams 128;\nhttp2_idle_timeout 30s; # Bezczynno\u015b\u0107 na poziomie H2\nhttp2_max_field_size 16k; # Ochrona nag\u0142\u00f3wk\u00f3w (patrz Bezpiecze\u0144stwo)\nhttp2_max_header_size 64k;\n<\/code><\/pre>\n\n<p>Z <strong>\u0141\u0105czenie po\u0142\u0105cze\u0144<\/strong> (H2\/H3), przegl\u0105darka mo\u017ce u\u017cywa\u0107 wielu nazw host\u00f3w poprzez <em>a<\/em> po\u0142\u0105czenie, je\u015bli sieci SAN certyfikat\u00f3w i adresy IP\/konfiguracja s\u0105 zgodne. Wykorzystuj\u0119 to, konsoliduj\u0105c statyczne subdomeny i wybieraj\u0105c certyfikaty obejmuj\u0105ce wiele host\u00f3w. Oszcz\u0119dza mi to dodatkowych uzgodnie\u0144 i rywalizacji port\u00f3w.<\/p>\n\n<h2>Parametry j\u0105dra i gniazda w skr\u00f3cie<\/h2>\n\n<p>Zabezpieczam r\u00f3wnie\u017c Reuse na <strong>Poziom j\u0105dra<\/strong> dzi\u0119ki czemu nie wyst\u0119puj\u0105 niedobory port\u00f3w i gniazd. Efemeryczne zakresy port\u00f3w, zachowanie FIN\/TIME_WAIT i sondowanie keepalive maj\u0105 bezpo\u015bredni wp\u0142yw na stabilno\u015b\u0107 i szybko\u015b\u0107 uzgadniania.<\/p>\n\n<pre><code># \/etc\/sysctl.d\/99-tuning.conf (przyk\u0142ady, testuj ostro\u017cnie)\nnet.ipv4.ip_local_port_range = 10240 65535\nnet.ipv4.tcp_fin_timeout = 15\nnet.ipv4.tcp_keepalive_time = 600\nnet.ipv4.tcp_keepalive_intvl = 30\nnet.ipv4.tcp_keepalive_probes = 5\nnet.core.netdev_max_backlog = 4096\n<\/code><\/pre>\n\n<p>Unikam ryzykownych zmian, takich jak bezmy\u015blna aktywacja <code>tcp_tw_reuse<\/code> na publicznie dost\u0119pnych serwerach. Co wa\u017cniejsze, <strong>Kursy ponownego u\u017cycia<\/strong> dzi\u0119ki czemu nie ma zbyt wielu kr\u00f3tkotrwa\u0142ych po\u0142\u0105cze\u0144. Przy du\u017cym obci\u0105\u017ceniu skaluj\u0119 r\u00f3wnie\u017c dystrybucj\u0119 IRQ i powinowactwo procesora, aby przerwania sieciowe nie tworzy\u0142y klastr\u00f3w i nie generowa\u0142y szczyt\u00f3w op\u00f3\u017anie\u0144.<\/p>\n\n<h2>Bezpiecze\u0144stwo i ochrona przed nadu\u017cyciami bez spowalniania ponownego u\u017cycia<\/h2>\n\n<p>Keep-Alive zach\u0119ca atakuj\u0105cych do <strong>Slowloris<\/strong>-warianty lub nadu\u017cycia HTTP\/2 w przypadku braku limit\u00f3w. Wzmacniam rozmiary nag\u0142\u00f3wk\u00f3w i szybko\u015b\u0107 \u017c\u0105da\u0144 bez zak\u0142\u00f3cania legalnych wzorc\u00f3w ponownego u\u017cycia. Przeciw <em>Szybki reset<\/em>-pattern w H2, ustawiam limity jednoczesnych strumieni i szybko\u015bci RST oraz loguj\u0119 rzucaj\u0105cych si\u0119 w oczy klient\u00f3w.<\/p>\n\n<pre><code># Nginx: Regu\u0142y ochrony\nlarge_client_header_buffers 4 8k;\nclient_body_buffer_size 128k;\n\nlimit_conn_zone $binary_remote_addr zone=perip:10m;\nlimit_conn perip 50;\n\nlimit_req_zone $binary_remote_addr zone=periprate:10m rate=20r\/s;\nlimit_req zone=periprate burst=40 nodelay;\n\n# H2-specyficzne ju\u017c powy\u017cej: http2_max_concurrent_streams, limity nag\u0142\u00f3wk\u00f3w\n<\/code><\/pre>\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\/04\/serverraum-optimierung-5743.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<p>U\u017cywam r\u00f3wnie\u017c <strong>wdzi\u0119czny<\/strong> Wy\u0142\u0105czenia, aby po\u0142\u0105czenia keep-alive ko\u0144czy\u0142y si\u0119 czysto podczas wdro\u017ce\u0144 i nie wyst\u0119powa\u0142y b\u0142\u0119dy klienta.<\/p>\n\n<pre><code># Nginx: Czyste czyszczenie po\u0142\u0105cze\u0144\nworker_shutdown_timeout 10s;\n<\/code><\/pre>\n\n<h2>Load balancery, CDN i upstreams: ponowne wykorzystanie w ca\u0142ym \u0142a\u0144cuchu<\/h2>\n\n<p>Upewniam si\u0119, \u017ce <strong>pomi\u0119dzy<\/strong> Nast\u0119puje ponowne wykorzystanie LB\/proxy i backendu. Aby to zrobi\u0107, obs\u0142uguj\u0119 pule upstream z wystarczaj\u0105c\u0105 liczb\u0105 slot\u00f3w i u\u017cywam strategii sticky lub consistent hashing, je\u015bli sesje s\u0105 wymagane w backendzie. Zmniejszam obci\u0105\u017cenie sieci CDN, u\u017cywaj\u0105c kilku d\u0142ugotrwa\u0142ych sesji. <em>Pochodzenie<\/em>-po\u0142\u0105cze\u0144 i ograniczy\u0107 maksymaln\u0105 liczb\u0119 po\u0142\u0105cze\u0144 na POP, aby serwery aplikacji nie uton\u0119\u0142y w zbyt wielu ma\u0142ych gniazdach.<\/p>\n\n<p>Wa\u017cne s\u0105 <strong>Jednorodne czasy bezczynno\u015bci<\/strong> wzd\u0142u\u017c \u015bcie\u017cki: Edge nie mo\u017ce przerywa\u0107 po\u0142\u0105cze\u0144 wcze\u015bniej ni\u017c Origin, w przeciwnym razie sesje multipleksowania b\u0119d\u0105 niepotrzebnie przywracane. W przypadku HTTP\/3 bior\u0119 pod uwag\u0119, \u017ce klienci notebook\u00f3w i urz\u0105dze\u0144 mobilnych cz\u0119\u015bciej zmieniaj\u0105 adresy IP; dlatego planuj\u0119 tolerancyjne, ale ograniczone czasy bezczynno\u015bci.<\/p>\n\n<h2>Rozszerzenie puli klient\u00f3w: Node.js, Python, gRPC<\/h2>\n\n<p>Po stronie klienta dbam o rozs\u0105dne <strong>pooling<\/strong> i wyczy\u015b\u0107 limity, aby nie by\u0142o stempli ani wyciek\u00f3w. W Node.js ustawiam limity wolnych gniazd i limity czasu bezczynno\u015bci, aby po\u0142\u0105czenia by\u0142y ciep\u0142e, ale nie pozostawa\u0142y otwarte na zawsze.<\/p>\n\n<pre><code>\/\/ Dostrajanie agenta Node.js\nconst https = require('https');\nconst agent = new https.Agent({\n  keepAlive: true,\n  keepAliveMsecs: 60000,\n  maxSockets: 100,\n  maxFreeSockets: 20\n});\n\/\/ axios\/fetch: httpsAgent: agent\n<\/code><\/pre>\n\n<pre><code>\u017b\u0105dania # Python: wi\u0119ksza pula na hosta\nimport requests\nfrom requests.adapters import HTTPAdapter\n\nsession = requests.Session()\nadapter = HTTPAdapter(pool_connections=50, pool_maxsize=200, max_retries=0)\nsession.mount('https:\/\/', adapter)\nsession.mount('http:\/\/', adapter)\n<\/code><\/pre>\n\n<p>Dla <strong>asynchroniczny<\/strong> (aiohttp), ograniczam maksymaln\u0105 liczb\u0119 gniazd i u\u017cywam buforowania DNS, aby utrzyma\u0107 op\u00f3\u017anienia na niskim poziomie. Z <strong>gRPC<\/strong> (H2), ustawiam pingi keep-alive na umiarkowanym poziomie, aby d\u0142ugie fazy bezczynno\u015bci nie prowadzi\u0142y do roz\u0142\u0105czenia bez zalewania sieci.<\/p>\n\n<h2>Metryki i warto\u015bci docelowe dla p\u0119tli strojenia<\/h2>\n\n<p>Steruj\u0119 dostrajaniem iteracyjnie za pomoc\u0105 kluczowych liczb, kt\u00f3re sprawiaj\u0105, \u017ce ponowne u\u017cycie jest widoczne:<\/p>\n<ul>\n  <li><strong>Kwota ponownego u\u017cycia<\/strong> (\u017c\u0105dania\/po\u0142\u0105czenia) oddzielnie dla frontend i upstream.<\/li>\n  <li><strong>U\u015bciski d\u0142oni\/s TLS<\/strong> vs. pro\u015bby\/s - Cel: Zmniejszenie odsetka u\u015bcisk\u00f3w d\u0142oni.<\/li>\n  <li><strong>Op\u00f3\u017anienie p95\/p99<\/strong> dla TTFB i og\u00f3\u0142em.<\/li>\n  <li><strong>Po\u0142\u0105czenia bezczynne<\/strong> i ich \u017cywotno\u015b\u0107.<\/li>\n  <li><strong>Profile b\u0142\u0119d\u00f3w<\/strong> (4xx\/5xx), resety, timeouty.<\/li>\n  <li><strong>TIME_WAIT\/FIN_WAIT<\/strong>-licznik i wykorzystanie portu efemerycznego.<\/li>\n<\/ul>\n<p>Prosty obraz docelowy: <em>U\u015bciski d\u0142oni\/s TLS<\/em> stabilny znacznie poni\u017cej <em>Wnioski\/s<\/em>, wska\u017anik ponownego wykorzystania w zakresie H1 &gt;= 20-50 w zale\u017cno\u015bci od rozmiaru obiektu, dla H2\/H3 kilka jednoczesnych strumieni na sesj\u0119 bez przeci\u0105\u017cenia.<\/p>\n\n<h2>Strategie front-end sprzyjaj\u0105ce ponownemu u\u017cyciu<\/h2>\n\n<p>Unikam <strong>Sharding domen<\/strong> z H2\/H3, konsoliduj\u0119 hosty i selektywnie korzystam z preload\/preconnect, aby zaoszcz\u0119dzi\u0107 kosztownych handshake'\u00f3w tam, gdzie s\u0105 one nieuniknione. \u0141aduj\u0119 du\u017ce obrazy w nowoczesny i skompresowany spos\u00f3b, aby przepustowo\u015b\u0107 nie sta\u0142a si\u0119 w\u0105skim gard\u0142em, kt\u00f3re niepotrzebnie blokuje sloty keep-alive. Minimalizuj\u0119 pliki cookie, aby zachowa\u0107 ma\u0142e nag\u0142\u00f3wki i efektywnie wysy\u0142a\u0107 wi\u0119cej obiekt\u00f3w w ramach tych samych sesji.<\/p>\n\n<h2>Rozwa\u017c sieci mobilne i NAT<\/h2>\n\n<p>W mobilnych \u015brodowiskach radiowych i NAT <strong>Limity czasu bezczynno\u015bci<\/strong> cz\u0119sto kr\u00f3tszy. Dlatego utrzymuj\u0119 umiarkowan\u0105 bezczynno\u015b\u0107 serwera i akceptuj\u0119 cz\u0119stsze ponowne \u0142\u0105czenie si\u0119 klient\u00f3w. Przy wznowieniu sesji i 0-RTT (H3), ponowne po\u0142\u0105czenia nadal pozostaj\u0105 szybkie. Po stronie serwera, sondy TCP keep-alive na gniazdach proxy pomagaj\u0105 szybko pozby\u0107 si\u0119 martwych \u015bcie\u017cek.<\/p>\n\n<h2>Wdro\u017cenia i wysoka dost\u0119pno\u015b\u0107<\/h2>\n\n<p>W przypadku wdro\u017ce\u0144 zarz\u0105dzam po\u0142\u0105czeniami <strong>mi\u0119kki<\/strong> wy\u0142: Zatrzymaj nowe akceptacje, poczekaj na istniej\u0105ce gniazda keep-alive, dopiero wtedy zako\u0144cz procesy. Umieszczam opr\u00f3\u017cnianie po\u0142\u0105cze\u0144 za LB, aby sesje multipleksowania nie by\u0142y przerywane w \u015brodku strumienia. Kontrole kondycji s\u0105 agresywne, ale nieempotentne, aby wcze\u015bnie rozpozna\u0107 b\u0142\u0119dy i zrestrukturyzowa\u0107 pule w odpowiednim czasie.<\/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\/04\/http-connection-reuse-8542.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Podsumowanie szybkiego sukcesu<\/h2>\n\n<p>Polegam na <strong>HTTP<\/strong> Ponowne wykorzystanie po\u0142\u0105czenia, kr\u00f3tkie limity czasu i rozs\u0105dne limity, aby po\u0142\u0105czenia pozosta\u0142y produktywne i nie wi\u0105za\u0142y zasob\u00f3w, gdy s\u0105 bezczynne. Nowoczesne protoko\u0142y, takie jak HTTP\/2 i HTTP\/3, wzmacniaj\u0105 ten efekt, podczas gdy client pooling odci\u0105\u017ca backendy. Dzi\u0119ki monitorowaniu wcze\u015bnie rozpoznaj\u0119, gdzie gniazda le\u017c\u0105 bezczynnie lub s\u0105 zbyt rzadkie i iteracyjnie dostosowuj\u0119 warto\u015bci. W przypadku WordPressa i podobnych stos\u00f3w \u0142\u0105cz\u0119 ponowne u\u017cycie z buforowaniem, \u0142\u0105czeniem zasob\u00f3w i lokalnie hostowanymi czcionkami. Skutkuje to szybkimi stronami, p\u0142ynnymi krzywymi \u0142adowania i <strong>Serwer sieciowy<\/strong>-Wydajno\u015b\u0107, kt\u00f3ra jest widoczna w ka\u017cdym wska\u017aniku.<\/p>","protected":false},"excerpt":{"rendered":"<p>Ponowne wykorzystanie po\u0142\u0105cze\u0144 HTTP i optymalizacja po\u0142\u0105cze\u0144 keep-alive znacznie zwi\u0119kszaj\u0105 wydajno\u015b\u0107 serwera WWW. Poznaj wskaz\u00f3wki dotycz\u0105ce strojenia, aby zmniejszy\u0107 op\u00f3\u017anienia i zwi\u0119kszy\u0107 przepustowo\u015b\u0107.<\/p>","protected":false},"author":1,"featured_media":18874,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-18881","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"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":"548","_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":"HTTP Connection Reuse","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":"18874","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/18881","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=18881"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/18881\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/18874"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=18881"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=18881"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=18881"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}