{"id":18056,"date":"2026-03-03T18:23:49","date_gmt":"2026-03-03T17:23:49","guid":{"rendered":"https:\/\/webhosting.de\/http-keepalive-timeout-server-performance-konfiguration\/"},"modified":"2026-03-03T18:23:49","modified_gmt":"2026-03-03T17:23:49","slug":"http-keepalive-timeout-konfiguration-av-serverprestanda","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/http-keepalive-timeout-server-performance-konfiguration\/","title":{"rendered":"HTTP Keep-Alive Timeout: Optimal konfiguration f\u00f6r serverprestanda"},"content":{"rendered":"<p>Med fokus p\u00e5 <strong>Tidsgr\u00e4ns f\u00f6r HTTP Keep-Alive<\/strong> Jag visar dig hur du st\u00e4ller in tomg\u00e5ngstider s\u00e5 att anslutningar \u00e5teranv\u00e4nds utan att blockera tr\u00e5dar. Jag f\u00f6rklarar specifika v\u00e4rden, visar typiska fallgropar och tillhandah\u00e5ller bepr\u00f6vade och testade konfigurationer f\u00f6r <strong>nginx<\/strong>, Apache och operativsystemet.<\/p>\n\n<h2>Centrala punkter<\/h2>\n<ul>\n  <li><strong>Balans<\/strong>: F\u00f6r korta \u00f6kar handskakningar, f\u00f6r l\u00e5nga blockerar tr\u00e5dar.<\/li>\n  <li><strong>V\u00e4rden<\/strong>Oftast 5-15 s och 100-500 f\u00f6rfr\u00e5gningar per anslutning.<\/li>\n  <li><strong>Samordning<\/strong>Koordinera timeouts f\u00f6r klienter, LB och brandv\u00e4ggar.<\/li>\n  <li><strong>S\u00e4rskilda fall<\/strong>WebSockets, SSE, Long Polling separat.<\/li>\n  <li><strong>\u00d6vervakning<\/strong>: \u00d6vervaka \u00f6ppna socklar, FD:er och latenser.<\/li>\n<\/ul>\n\n<h2>Kort f\u00f6rklaring av HTTP Keep-Alive<\/h2>\n<p>Jag har TCP-anslutningar med <strong>Keep-Alive<\/strong> \u00f6ppna s\u00e5 att flera f\u00f6rfr\u00e5gningar anv\u00e4nder samma linje. Detta sparar mig upprepade TCP- och TLS-handskakningar och minskar <strong>CPU<\/strong>-overhead m\u00e4rkbart. Detta \u00e4r s\u00e4rskilt f\u00f6rdelaktigt f\u00f6r m\u00e5nga sm\u00e5 filer, t.ex. ikoner, JSON eller CSS. Varje ny anslutning som undviks minskar antalet kontextbyten och avlastar k\u00e4rnans rutiner. I benchmarks med en h\u00f6g andel GET minskas den totala varaktigheten avsev\u00e4rt eftersom f\u00e4rre SYN\/ACK-paket genereras och mer ber\u00e4kningstid flyter in i applikationslogiken.<\/p>\n<p>Jag m\u00e4ter snabbt effekten: den glidande genomsnittliga latensen blir j\u00e4mnare och antalet nya TCP-anslutningar per sekund sjunker. Jag uppn\u00e5r inte detta genom magi, utan genom att <strong>\u00c5teranv\u00e4ndning av anslutning<\/strong> och rimliga gr\u00e4nser. Det \u00e4r fortfarande viktigt att Keep-Alive inte ers\u00e4tter snabb rendering eller cachelagring. Det f\u00f6rkortar v\u00e4ntetiderna vid n\u00e4tverksgr\u00e4nsen, medan sj\u00e4lva appen m\u00e5ste forts\u00e4tta att svara effektivt. B\u00e5da tillsammans \u00f6kar <strong>Prestanda<\/strong> m\u00e4rkbart.<\/p>\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\/03\/server-optimierung-4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>F\u00f6rst\u00e5else f\u00f6r r\u00e4tt timeout<\/h2>\n<p>Timeout definierar hur l\u00e4nge en inaktiv anslutning f\u00f6rblir \u00f6ppen innan servern st\u00e4nger den. <strong>st\u00e4nger<\/strong>. Om jag st\u00e4ller in den f\u00f6r kort \u00f6ppnar klienterna st\u00e4ndigt nya TCP-anslutningar, vilket <strong>Overhead<\/strong> h\u00f6js. Om jag st\u00e4ller in den f\u00f6r l\u00e4nge parkerar oanv\u00e4nda anslutningar v\u00e4rdefulla arbetare eller tr\u00e5dar. Tricket \u00e4r att hitta en balans mellan \u00e5teranv\u00e4ndning och resursf\u00f6rbrukning. Jag testar praktiskt: f\u00f6rst st\u00e4ller jag in den grovt, sedan finjusterar jag den med belastningstester.<\/p>\n<p>Jag \u00e4r ocks\u00e5 uppm\u00e4rksam p\u00e5 f\u00f6rh\u00e5llandet mellan svarstider och lediga f\u00f6nster. Om den typiska anv\u00e4ndarinteraktionen mellan tv\u00e5 klick \u00e4r 2-4 sekunder, t\u00e4cker en timeout p\u00e5 5-15 sekunder vanligtvis det verkliga m\u00f6nstret. Korta API-anrop kan l\u00e4tt tolerera 5-10 sekunder, mediearbetsbelastningar 10-15 sekunder. Det \u00e4r viktigt att jag inte \u00f6verdriver: alltf\u00f6r l\u00e5nga timeouts leder s\u00e4llan till mer <strong>Genomstr\u00f6mning<\/strong>, men leder ofta till blockerade <strong>Resurser<\/strong>. Jag kan snabbt k\u00e4nna igen detta p\u00e5 det \u00f6kande antalet \u00f6ppna uttag och h\u00f6ga FD-siffror.<\/p>\n\n<h2>Separera timeout-typer p\u00e5 ett snyggt s\u00e4tt<\/h2>\n<p>Jag g\u00f6r en strikt \u00e5tskillnad mellan <strong>Tidsgr\u00e4ns f\u00f6r inaktivitet<\/strong> (Keep-Alive), <strong>Tidsgr\u00e4ns f\u00f6r l\u00e4sning\/header<\/strong> (hur l\u00e4nge servern v\u00e4ntar p\u00e5 inkommande f\u00f6rfr\u00e5gningar) och <strong>Timeout f\u00f6r s\u00e4ndning\/skrivning<\/strong> (hur l\u00e4nge s\u00e4ndning mot kunden tolereras). Dessa kategorier fyller olika uppgifter:<\/p>\n<ul>\n  <li><strong>Tidsgr\u00e4ns f\u00f6r tomg\u00e5ng:<\/strong> Styr \u00e5teranv\u00e4ndningen och parkeringstiden f\u00f6r inaktiva anslutningar.<\/li>\n  <li><strong>Tidsgr\u00e4ns f\u00f6r l\u00e4sning\/header:<\/strong> Skyddar mot l\u00e5ngsamma klienter (l\u00e5ngsamma loris) och halvt skickade headers.<\/li>\n  <li><strong>Timeout f\u00f6r s\u00e4ndning\/skrivning:<\/strong> F\u00f6rhindrar att servern v\u00e4ntar i all o\u00e4ndlighet p\u00e5 en l\u00e5ngsam mottagning hos klienten.<\/li>\n<\/ul>\n<p>P\u00e5 <strong>nginx<\/strong> Jag anv\u00e4nder medvetet header_timeout\/read_timeout och send_timeout per kontext (http\/server\/location) ut\u00f6ver keepalive_timeout. Sedan nyare versioner st\u00e4ller jag valfritt in <strong>keepalive_tid<\/strong>, f\u00f6r att begr\u00e4nsa den maximala livsl\u00e4ngden f\u00f6r en anslutning, \u00e4ven om den f\u00f6rblir aktiv. I <strong>Apache<\/strong> Jag anv\u00e4nder ocks\u00e5 <strong>RequestReadTimeout<\/strong> (mod_reqtimeout) och kontrollera <strong>Tidsgr\u00e4ns<\/strong> (global) separat fr\u00e5n <strong>KeepAliveTimeout<\/strong>. Denna uppdelning \u00e4r en viktig byggsten mot att binda upp resurser utan n\u00e5gon verklig nytta.<\/p>\n\n<h2>Rekommenderade v\u00e4rden i praktiken<\/h2>\n<p>F\u00f6r produktiva milj\u00f6er st\u00e4ller jag in en timeout f\u00f6r keep-alive p\u00e5 5-15 sekunder och 100-500 f\u00f6rfr\u00e5gningar per anslutning. Det h\u00e4r intervallet ger bra \u00e5teranv\u00e4ndning av anslutningar och h\u00e5ller antalet vilande anslutningar nere. P\u00e5 <strong>nginx<\/strong> Jag anv\u00e4nder keepalive_timeout 10s som startv\u00e4rde och keepalive_requests 200. Om det \u00e4r mycket trafik \u00f6kar jag det m\u00e5ttligt om jag ser f\u00f6r m\u00e5nga nya TCP-anslutningar. Om trafiken \u00e4r gles s\u00e4nker jag den igen f\u00f6r att f\u00f6rhindra en \u00f6versv\u00e4mning av oanv\u00e4nd trafik.<\/p>\n<p>De som g\u00e5r djupare kommer att dra nytta av en tydlig tuningprocess med m\u00e4tpunkter. D\u00e4rf\u00f6r har jag sammanfattat mina riktlinjer i en praktisk guide som beskriver v\u00e4gen fr\u00e5n m\u00e4tning till konfiguration och kontroll. F\u00f6r en snabb start h\u00e4nvisar jag dig till mina steg i <a href=\"https:\/\/webhosting.de\/sv\/http-keep-alive-tuning-serverbelastning-prestandaoptimering-floede\/\">Keep-Alive-inst\u00e4llning<\/a>. Hur man kontrollerar <strong>\u00c5teranv\u00e4ndning<\/strong> och begr\u00e4nsningar och undvika \u00f6verraskningar. Det som r\u00e4knas i slut\u00e4ndan \u00e4r l\u00e5g latens med stabil <strong>Genomstr\u00f6mning<\/strong>.<\/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\/03\/http-keep-alive-optimierung-1723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Risker med l\u00e5nga timeouts<\/h2>\n<p>En l\u00e5ng timeout g\u00f6r att anslutningarna blir konstgjorda <strong>\u00f6ppna<\/strong> och blockerar arbetare \u00e4ven om ingen beg\u00e4ran f\u00f6ljer. Detta g\u00f6r att uttagen sv\u00e4ller och driver upp filbeskrivningsnummer. Om processen n\u00e5r sina gr\u00e4nser ser jag avvisande acceptfel eller k\u00f6er n\u00e4r jag uppr\u00e4ttar en anslutning. Minnet v\u00e4xer, garbage collectors eller allocators kostar extra tid och latensen \u00f6kar. I h\u00e4ndelse av ett fel skickar klienter sedan till socklar som redan \u00e4r st\u00e4ngda och f\u00e5r kryptiska <strong>Fel<\/strong>.<\/p>\n<p>Jag undviker detta genom att s\u00e4tta m\u00e5ttliga v\u00e4rden och kontrollera regelbundna m\u00e4tv\u00e4rden. Om antalet inaktiva anslutningar \u00f6kar f\u00f6r mycket under l\u00e5g belastning s\u00e4nker jag timeouten. Om jag ser m\u00e5nga nya anslutningar per sekund under trafiktoppar \u00f6kar jag den f\u00f6rsiktigt i sm\u00e5 steg. Det \u00e4r s\u00e5 h\u00e4r jag h\u00e5ller <strong>Kapacitet<\/strong> anv\u00e4ndbara och f\u00f6rhindrar d\u00f6da anslutningar. Resultatet \u00e4r ett smidigare system med f\u00e4rre <strong>Tips<\/strong> i kurvorna.<\/p>\n\n<h2>Konfiguration: nginx, Apache och OS-lager<\/h2>\n<p>Jag b\u00f6rjar p\u00e5 webbserverniv\u00e5 och st\u00e4ller in timeout och gr\u00e4nser. P\u00e5 <strong>nginx<\/strong> Jag st\u00e4ller in keepalive_timeout 5-15s och keepalive_requests 100-500. I Apache med event-MPM kombinerar jag KeepAlive On, KeepAliveTimeout 5-15 och MaxKeepAliveRequests 100-500. Sedan kalibrerar jag worker- eller tr\u00e5dpooler enligt den f\u00f6rv\u00e4ntade belastningen. Detta f\u00f6rhindrar att inaktiva keep-alives blir produktiva. <strong>Spelautomater<\/strong> binda.<\/p>\n<p>Jag \u00f6kar gr\u00e4nserna och k\u00f6erna p\u00e5 operativsystemniv\u00e5. Jag s\u00e4tter ulimit -n till minst 100 000, justerar net.core.somaxconn och tcp_max_syn_backlog och kontrollerar TIME_WAIT-hanteringen. Detta s\u00e4kerst\u00e4ller att k\u00e4rnan och processen har tillr\u00e4ckligt med <strong>Resurser<\/strong> tillhandah\u00e5lla. Slutligen verifierar jag v\u00e4garna fr\u00e5n NIC via IRQ-balansering till appen. Detta g\u00f6r att jag kan uppt\u00e4cka flaskhalsar i god tid och h\u00e5lla <strong>F\u00f6rdr\u00f6jning<\/strong> l\u00e5g.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Komponent<\/th>\n      <th>Direktiv\/Inst\u00e4llning<\/th>\n      <th>Rekommendation<\/th>\n      <th>Ledtr\u00e5d<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>nginx<\/td>\n      <td>keepalive_timeout<\/td>\n      <td>5\u201315 s<\/td>\n      <td><strong>Kortare<\/strong> med liten trafik, l\u00e4ngre med m\u00e5nga sm\u00e5 f\u00f6rfr\u00e5gningar<\/td>\n    <\/tr>\n    <tr>\n      <td>nginx<\/td>\n      <td>keepalive_requests<\/td>\n      <td>100\u2013500<\/td>\n      <td>\u00c5tervinner f\u00f6reningar och minskar <strong>L\u00e4ckage<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Apache (evenemang)<\/td>\n      <td>KeepAliveTimeout<\/td>\n      <td>5\u201315 s<\/td>\n      <td>Event-MPM hanterar tomg\u00e5ng mer effektivt \u00e4n <strong>prefork<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Operativsystem<\/td>\n      <td>ulimit -n<\/td>\n      <td>\u2265 100.000<\/td>\n      <td>Fler \u00f6ppna FD:er f\u00f6r m\u00e5nga <strong>Socklar<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Operativsystem<\/td>\n      <td>net.core.somaxconn<\/td>\n      <td>\u00d6kning<\/td>\n      <td>F\u00e4rre avvisade anslutningar under <strong>Toppbelastning<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/03\/server-optimization-http-keep-alive-4317.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Omv\u00e4nd proxy och \u00e5teranv\u00e4ndning uppstr\u00f6ms<\/h2>\n<p>Jag t\u00e4nker alltid keep-alive <strong>end-to-end<\/strong>. Bakom edge-servern finns ofta en kedja av reverse proxy \u2192 app-servrar. F\u00f6r nginx aktiverar jag min egen <strong>Keep Alive Pools<\/strong> (uppstr\u00f6ms keepalive, keepalive_requests, keepalive_timeout), st\u00e4ll in proxy_http_version 1.1 och ta bort \u201eConnection: close\u201c. Detta sparar mig ocks\u00e5 <em>intern<\/em> handskakningar och avlasta app-backends (Node.js, Java, PHP-FPM). I Apache med mod_proxy beh\u00e5ller jag ocks\u00e5 best\u00e4ndiga anslutningar till backend-servrar och begr\u00e4nsar dem per destination s\u00e5 att en hotspot inte monopoliserar poolerna.<\/p>\n<p>Jag m\u00e4ter separat: \u00c5teranv\u00e4ndningsgrad Client\u2192Edge och Edge\u2192Backend. Om jag ser god \u00e5teranv\u00e4ndning vid kanten, men m\u00e5nga nya anslutningar till backend, \u00f6kar jag selektivt poolerna uppstr\u00f6ms. Detta g\u00f6r att jag kan skala utan att globalt \u00f6ka timeouts f\u00f6r frontend.<\/p>\n\n<h2>Arbetare, tr\u00e5dar och OS-gr\u00e4nser<\/h2>\n<p>Jag dimensionerar inte medarbetare, h\u00e4ndelser och tr\u00e5dar efter \u00f6nskade v\u00e4rden, utan efter <strong>lastprofil<\/strong>. F\u00f6r att g\u00f6ra detta \u00f6vervakar jag aktiva f\u00f6rfr\u00e5gningar, lediga arbetare, anv\u00e4ndning av h\u00e4ndelseslingor och kontextbyten. Om tr\u00e5dar parkeras i inaktivitetsl\u00e4ge s\u00e4nker jag timeouten eller maxgr\u00e4nsen f\u00f6r inaktivitet per tr\u00e5d. Om jag ser 100 procent CPU hela tiden kontrollerar jag acceptk\u00f6er, IRQ-distribution och n\u00e4tverksstack. Sm\u00e5 korrigeringar av FD-gr\u00e4nser och backlogs g\u00f6r ofta stor skillnad. <strong>Effekter<\/strong>.<\/p>\n<p>Jag planerar mitt utrymme p\u00e5 ett realistiskt s\u00e4tt. En 20-30-procentig reserv i tr\u00e5dar och FD:er ger s\u00e4kerhet f\u00f6r toppar. Om jag \u00f6verdriver f\u00f6rlorar jag cacher och sl\u00f6seriet \u00f6kar. Om jag underdriver hamnar f\u00f6rfr\u00e5gningar i k\u00f6er eller f\u00f6rfaller. Den r\u00e4tta sk\u00e4rningspunkten mellan <strong>Kapacitet<\/strong> och effektivitet h\u00e5ller latenstiderna l\u00e5ga och skyddar <strong>Stabilitet<\/strong>.<\/p>\n\n<h2>Samordna timeouts f\u00f6r klienter, lastbalanserare och brandv\u00e4ggar<\/h2>\n<p>Jag s\u00e4tter tidsgr\u00e4nser l\u00e4ngs hela v\u00e4gen s\u00e5 att det inte blir n\u00e5gra \u00e5terv\u00e4ndsgr\u00e4nder. <strong>Anslutningar<\/strong> skapas. Klienter st\u00e4nger helst minimalt tidigare \u00e4n servern. Lastbalanseraren f\u00e5r inte sk\u00e4ra av kortare, annars kommer jag att se ov\u00e4ntade \u00e5terst\u00e4llningar. Jag inkluderar tomg\u00e5ngsv\u00e4rden f\u00f6r NAT och brandv\u00e4ggar s\u00e5 att anslutningar inte g\u00e5r f\u00f6rlorade i n\u00e4tverksv\u00e4gen. <strong>f\u00f6rsvinna<\/strong>. Denna inst\u00e4llning f\u00f6rhindrar retransmissioner och j\u00e4mnar ut belastningskurvorna.<\/p>\n<p>Jag h\u00e5ller kedjan begriplig med tydliga diagram: Klient \u2192 LB \u2192 webbserver \u2192 app. Jag dokumenterar tidsfrister f\u00f6r inaktivitet, tidsfrister f\u00f6r l\u00e4sning\/skrivning och strategier f\u00f6r ompr\u00f6vning f\u00f6r varje l\u00e4nk. Om jag \u00e4ndrar ett v\u00e4rde kontrollerar jag grannarna. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir v\u00e4gen konsekvent och jag f\u00e5r reproducerbara m\u00e4tresultat. Denna disciplin sparar tid i <strong>Fels\u00f6kning<\/strong> och \u00f6kar <strong>tillf\u00f6rlitlighet<\/strong>.<\/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\/03\/optimal_configuration_server_9837.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e4kerhet: Skydd mot l\u00e5ngsamma loris och missbruk i on\u00f6dan<\/h2>\n<p>\u00d6ppna timeouts som \u00e4r f\u00f6r gener\u00f6sa <strong>Attackera ytor<\/strong>. Jag s\u00e4tter d\u00e4rf\u00f6r gr\u00e4nser som till\u00e5ter legitim \u00e5teranv\u00e4ndning men g\u00f6r det sv\u00e5rare att h\u00e5lla dem \u00f6ppna p\u00e5 ett illvilligt s\u00e4tt. I nginx hj\u00e4lper header och read_timeout, request_headers_size-gr\u00e4nser och en h\u00e5rd \u00f6vre gr\u00e4ns f\u00f6r keepalive_requests. I Apache anv\u00e4nder jag mod_reqtimeout och begr\u00e4nsar parallella anslutningar per IP. Hastighetsgr\u00e4nser och <strong>limit_conn<\/strong> i nginx skyddar ocks\u00e5 mot \u00f6versv\u00e4mningar av m\u00e5nga lediga socklar. F\u00f6r l\u00e5ngk\u00f6rande slutpunkter separerar jag dedikerade pooler s\u00e5 att attacker p\u00e5 str\u00f6mmar inte binder vanliga API-arbetare.<\/p>\n\n<h2>Specialfall: Long Polling, SSE och WebSockets<\/h2>\n<p>L\u00e5nga str\u00f6mmar kolliderar med korta <strong>Tidsfrister<\/strong> och beh\u00f6ver sina egna regler. Jag separerar dessa slutpunkter tekniskt fr\u00e5n klassiska API- och tillg\u00e5ngsv\u00e4gar. F\u00f6r SSE och WebSockets st\u00e4ller jag in h\u00f6gre timeouts, dedikerade arbetspooler och h\u00e5rda gr\u00e4nser per IP. Jag h\u00e5ller anslutningen vid liv med hj\u00e4rtslag eller ping\/pong och k\u00e4nner snabbt igen avbrott. P\u00e5 s\u00e5 s\u00e4tt blockerar inte str\u00f6mmar tr\u00e5dar f\u00f6r vanliga <strong>Korta f\u00f6rfr\u00e5gningar<\/strong>.<\/p>\n<p>Jag begr\u00e4nsar samtidiga anslutningar och m\u00e4ter aktivt. Gr\u00e4nser som \u00e4r f\u00f6r h\u00f6ga f\u00f6rbrukar FD och RAM. Gr\u00e4nser som \u00e4r f\u00f6r sn\u00e4va st\u00e4nger av legitima anv\u00e4ndare. Jag hittar den r\u00e4tta punkten med rena m\u00e4tv\u00e4rden f\u00f6r \u00f6ppna, inaktiva, aktiva och avbrutna anslutningar. Den h\u00e4r separationen sparar mig globala <strong>\u00d6kar<\/strong> timeouts och skyddar den <strong>Kapacitet<\/strong>.<\/p>\n\n<h2>HTTP\/2, multiplexering och keep-alive<\/h2>\n<p>HTTP\/2 multiplexerar flera str\u00f6mmar via en <strong>Anslutning<\/strong>, men \u00e4r fortfarande beroende av timeouts. Jag h\u00e5ller inaktivitetsf\u00f6nstret m\u00e5ttligt eftersom sessioner ocks\u00e5 kan parkeras under HTTP\/2. H\u00f6ga keepalive_requests \u00e4r mindre viktiga h\u00e4r, men \u00e5tervinning \u00e4r fortfarande anv\u00e4ndbart. Head-of-line-blockering flyttas till ramniv\u00e5, s\u00e5 jag forts\u00e4tter att m\u00e4ta latens per <strong>Str\u00f6m<\/strong>. Om du vill j\u00e4mf\u00f6ra mer i detalj hittar du bakgrundsinformation p\u00e5 <a href=\"https:\/\/webhosting.de\/sv\/http2-multiplexing-vs-http11-prestanda-bakgrund-optimering\/\">HTTP\/2-multiplexering<\/a>.<\/p>\n<p>Under HTTP\/2 \u00e4r jag s\u00e4rskilt uppm\u00e4rksam p\u00e5 antalet aktiva str\u00f6mmar per anslutning. F\u00f6r m\u00e5nga parallella str\u00f6mmar kan \u00f6verbelasta apptr\u00e5dar. Jag s\u00e4nker d\u00e5 gr\u00e4nserna eller \u00f6kar antalet serverarbetare. Samma sak g\u00e4ller h\u00e4r: m\u00e4t, justera, m\u00e4t igen. Detta h\u00e5ller <strong>Svarstider<\/strong> s\u00e4llsynta och v\u00e4lbevarade <strong>Resurser<\/strong>.<\/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\/03\/dev_desk_HTTP_timeout_4783.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>TLS, \u00e5terupptagande av session och HTTP\/3\/QUIC<\/h2>\n<p>TLS-handskakningar \u00e4r dyra. Jag anv\u00e4nder <strong>\u00c5terupptagande av session<\/strong> (biljetter\/ID:n) och OCSP-h\u00e4ftning s\u00e5 att \u00e5teranslutningarna g\u00e5r snabbare om en anslutning bryts. Under HTTP\/3 tar QUIC \u00f6ver transportlagret: H\u00e4r \u00e4r <strong>QUIC idle timeout<\/strong> som liknar Keep-Alive, men p\u00e5 UDP-basis. \u00c4ven h\u00e4r h\u00e5ller jag f\u00f6nstren m\u00e5ttliga och m\u00e4ter retransmits, eftersom paketf\u00f6rluster har en annan effekt \u00e4n med TCP. F\u00f6r blandade milj\u00f6er (H1\/H2\/H3) v\u00e4ljer jag standardiserade referensv\u00e4rden och g\u00f6r finjusteringar f\u00f6r varje protokoll.<\/p>\n\n<h2>\u00d6vervakning, m\u00e4tv\u00e4rden och belastningstester<\/h2>\n<p>Jag litar mer p\u00e5 m\u00e4tdata \u00e4n p\u00e5 magk\u00e4nsla och b\u00f6rjar med tydliga <strong>KPI:er<\/strong>. Viktigt \u00e4r: \u00f6ppna uttag, FD-anv\u00e4ndning, nya anslutningar\/s, latenser (P50\/P90\/P99), felfrekvenser och retransmissioner. Jag k\u00f6r realistiska belastningsprofiler: Uppv\u00e4rmning, plat\u00e5, nedrampning. Sedan j\u00e4mf\u00f6r jag kurvorna f\u00f6re och efter \u00e4ndringar av timeouten. En titt p\u00e5 <a href=\"https:\/\/webhosting.de\/sv\/webbserver-koe-latens-begaeran-hantering-serverkoe\/\">Serverk\u00f6er<\/a> hj\u00e4lper till att tydligt tolka v\u00e4ntetider.<\/p>\n<p>Jag dokumenterar varje justering med en tidsst\u00e4mpel och m\u00e4tv\u00e4rden. P\u00e5 s\u00e5 s\u00e4tt kan jag bevara historiken och k\u00e4nna igen samband. Jag tar negativa effekter p\u00e5 allvar och \u00e5terst\u00e4ller dem snabbt. Sm\u00e5, begripliga steg sparar mycket tid. Det som r\u00e4knas i slut\u00e4ndan \u00e4r en stabil <strong>F\u00f6rdr\u00f6jning<\/strong> och l\u00e5g <strong>Felprocent<\/strong> under belastning.<\/p>\n\n<h2>M\u00e4tmetoder och verktyg i praktiken<\/h2>\n<ul>\n  <li><strong>Snabbtester:<\/strong> Jag anv\u00e4nder verktyg som wrk, ab eller vegeta f\u00f6r att kontrollera \u00e5teranv\u00e4ndningskvoter (-H-anslutning: keep-alive vs. close), anslutningar\/s och latenspercentiler.<\/li>\n  <li><strong>Systemvy:<\/strong> ss\/netstat visar status (ESTABLISHED, TIME_WAIT), lsof -p FD-f\u00f6rbrukning, dmesg\/syslog indikation p\u00e5 dropp.<\/li>\n  <li><strong>M\u00e4tv\u00e4rden f\u00f6r webbserver:<\/strong> nginx stub_status\/VTS och Apache mod_status ger aktiv\/ledig\/v\u00e4ntande och f\u00f6rfr\u00e5gningar\/s. Fr\u00e5n detta kan jag k\u00e4nna igen lediga toppar eller flaskhalsar f\u00f6r arbetare.<\/li>\n  <li><strong>Sp\u00e5r:<\/strong> Jag anv\u00e4nder distribuerad sp\u00e5rning f\u00f6r att \u00f6vervaka om v\u00e4ntetider uppst\u00e5r vid n\u00e4tverksgr\u00e4nsen eller i appen.<\/li>\n<\/ul>\n\n<h2>Konfigurera steg f\u00f6r steg<\/h2>\n<p>F\u00f6rst fastst\u00e4ller jag det verkliga anv\u00e4ndningsm\u00f6nstret: hur m\u00e5nga f\u00f6rfr\u00e5gningar per session, vilka <strong>Intervaller<\/strong> mellan klick, hur stora \u00e4r svaren. Sedan st\u00e4ller jag in en f\u00f6rsta profil: timeout 10 s, keepalive_requests 200, m\u00e5ttligt antal arbetare. Sedan utf\u00f6r jag belastningstester med representativa data. Jag utv\u00e4rderar antalet nya anslutningar per sekund och FD-anv\u00e4ndningen. Jag justerar sedan <strong>V\u00e4rden<\/strong> i steg om 2-3 sekunder.<\/p>\n<p>Jag upprepar cykeln tills latenserna f\u00f6rblir stabila under belastning och FD-topparna inte n\u00e5r gr\u00e4nsen. Vid h\u00f6g belastning \u00f6kar jag timeouten endast om jag tydligt ser att det finns f\u00e4rre nya anslutningar och att det fortfarande finns lediga arbetare. Vid l\u00e5g anv\u00e4ndning minskar jag timeouten f\u00f6r att undvika tomg\u00e5ngsk\u00f6rning. I specialfall som SSE st\u00e4ller jag in dedikerade serverblock med h\u00f6gre gr\u00e4nser. Den h\u00e4r v\u00e4gen leder till en motst\u00e5ndskraftig <strong>Inst\u00e4llning<\/strong> utan priskartong.<\/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\/03\/servereinstellung-performance-1987.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kubernetes, containrar och automatisk skalning<\/h2>\n<p>I containermilj\u00f6er anv\u00e4nder jag <strong>conntrack<\/strong>-gr\u00e4nser, pod FD-gr\u00e4nser och node backlogs. Jag s\u00e4kerst\u00e4ller konsekventa timeouts f\u00f6r inaktivitet mellan Ingress, service mesh\/proxy och app. F\u00f6r automatisk skalning \u00e4r jag uppm\u00e4rksam p\u00e5 <strong>Avloppstider<\/strong>N\u00e4r pods avslutas b\u00f6r de avvisa nya anslutningar via \u201eConnection: close\u201c och betj\u00e4na befintliga anslutningar p\u00e5 ett snyggt s\u00e4tt. Keep alive-v\u00e4rden som \u00e4r f\u00f6r l\u00e5nga drar ut p\u00e5 tiden i on\u00f6dan, medan de som \u00e4r f\u00f6r korta genererar handskakningsstormar vid utskalning.<\/p>\n\n<h2>Graceful shutdown och rullande drifts\u00e4ttningar<\/h2>\n<p>Jag planerar ocks\u00e5 att st\u00e4nga av. Innan en utrullning minskar jag gradvis Keep-Alive eller skickar riktade <strong>Anslutning: st\u00e4ng<\/strong> p\u00e5 Responses s\u00e5 att klienterna inte \u00f6ppnar nya oanv\u00e4nda anslutningar. I nginx \u00e4r en <strong>timeout f\u00f6r avst\u00e4ngning av arbetare<\/strong> f\u00f6r p\u00e5g\u00e5ende f\u00f6rfr\u00e5gningar. I Apache anv\u00e4nder jag graci\u00f6sa mekanismer och h\u00e5ller ett \u00f6ga p\u00e5 MaxConnectionsPerChild\/Worker s\u00e5 att \u00e5tervinning sker automatiskt \u00f6ver tid. Detta h\u00e5ller distributionerna smidiga utan att h\u00e5rt begr\u00e4nsa \u00f6ppna socklar.<\/p>\n\n<h2>OS-tuning: portar, timeouts, k\u00e4rnparametrar<\/h2>\n<ul>\n  <li><strong>kortlivade hamnar:<\/strong> V\u00e4lj ett brett ip_local_port_range s\u00e5 att kortlivade anslutningar inte hamnar i en bristsituation.<\/li>\n  <li><strong>TIME_WAIT:<\/strong> Jag h\u00e5ller koll p\u00e5 TW-toppar. Moderna stackar hanterar detta bra; jag undviker tveksamma tweaks (tw_recycle).<\/li>\n  <li><strong>tcp_keepalive_tid:<\/strong> Jag blandar inte ihop det med HTTP Keep-Alive. Det \u00e4r en k\u00e4rnmekanism f\u00f6r att k\u00e4nna igen d\u00f6da peers - anv\u00e4ndbart bakom NAT, men inte en ers\u00e4ttning f\u00f6r HTTP:s idle-f\u00f6nster.<\/li>\n  <li><strong>Eftersl\u00e4pningar och buffertar:<\/strong> dimensionera somaxconn, tcp_max_syn_backlog och rmem\/wmem p\u00e5 ett f\u00f6rnuftigt s\u00e4tt f\u00f6r att inte strypas under belastning.<\/li>\n<\/ul>\n\n<h2>Checklista f\u00f6r fels\u00f6kning<\/h2>\n<ul>\n  <li><strong>M\u00e5nga nya anslutningar\/s trots keep-alive:<\/strong> Timeout f\u00f6r kort eller klienter\/LB st\u00e4ngdes av tidigare.<\/li>\n  <li><strong>H\u00f6ga tomg\u00e5ngssiffror och full FD:<\/strong> F\u00f6r l\u00e5ng timeout eller f\u00f6r stora arbetspooler f\u00f6r trafikm\u00f6nstret.<\/li>\n  <li><strong>RST\/Timeout-fel f\u00f6r l\u00e4ngre sessioner:<\/strong> NAT\/brandv\u00e4ggsledighet f\u00f6r kort i v\u00e4gen, asymmetri mellan l\u00e4nkar.<\/li>\n  <li><strong>L\u00e5nga v\u00e4ntetider (P99):<\/strong> Kontrollera timeouts f\u00f6r s\u00e4ndning\/l\u00e4sning, l\u00e5ngsamma klienter eller \u00f6verfyllda backlogs.<\/li>\n  <li><strong>Backends \u00f6verbelastade trots l\u00e5g kantbelastning:<\/strong> Buren uppstr\u00f6ms saknas eller \u00e4r f\u00f6r liten.<\/li>\n<\/ul>\n\n<h2>\u00d6vningsprofiler och startv\u00e4rden<\/h2>\n<ul>\n  <li><strong>API-first (korta anrop):<\/strong> Keep-Alive 5-10 s, keepalive_requests 200-300, tight header\/read timeouts.<\/li>\n  <li><strong>E-handel (blandad):<\/strong> 8-12 s, 200-400, n\u00e5got mer gener\u00f6st f\u00f6r produktbilder och cachetr\u00e4ffar.<\/li>\n  <li><strong>Tillg\u00e5ngar\/CDN-liknande (m\u00e5nga sm\u00e5 filer):<\/strong> 10-15 s, 300-500, starka uppstr\u00f6mspooler och h\u00f6ga FD-gr\u00e4nser.<\/li>\n  <li><strong>Intran\u00e4t\/l\u00e5g belastning:<\/strong> 5-8 s, 100-200, s\u00e5 att tomg\u00e5ng inte dominerar.<\/li>\n<\/ul>\n\n<h2>Kortfattat sammanfattat<\/h2>\n<p>Jag st\u00e4ller in HTTP keep-alive timeout s\u00e5 att anslutningar \u00e5teranv\u00e4nds utan att blockera tr\u00e5dar. I praktiken ger 5-15 sekunder och 100-500 f\u00f6rfr\u00e5gningar per anslutning mycket bra resultat. Jag samordnar timeouts f\u00f6r klienter, lastbalanserare och brandv\u00e4ggar, separerar l\u00e5ngvariga anslutningar som WebSockets och reglerar OS-gr\u00e4nser. Med noggrann \u00f6vervakning, realistiska belastningstester och sm\u00e5 steg uppn\u00e5r jag l\u00e5ga <strong>F\u00f6rdr\u00f6jningar<\/strong> och h\u00f6g <strong>Genomstr\u00f6mning<\/strong>. De som uppr\u00e4tth\u00e5ller denna disciplin f\u00e5r ut m\u00e4tbar prestanda av befintlig h\u00e5rdvara.<\/p>","protected":false},"excerpt":{"rendered":"<p>Optimerade inst\u00e4llningar f\u00f6r HTTP keep-alive timeout f\u00f6r b\u00e4ttre serverprestanda. Praktisk guide f\u00f6r inst\u00e4llning av webbserver och anslutningshantering.<\/p>","protected":false},"author":1,"featured_media":18049,"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-18056","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":"840","_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 Keep-Alive Timeout","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":"18049","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/18056","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/comments?post=18056"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/18056\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/18049"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=18056"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=18056"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=18056"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}