{"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":"tcp-time-wait-optimering-webserver-ydeevne-netvaerk","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/tcp-time-wait-optimierung-webserver-performance-netzwerk\/","title":{"rendered":"Optimering af TCP TIME_WAIT p\u00e5 webservere: Praktisk vejledning til administratorer"},"content":{"rendered":"<p>Jeg viser, hvordan jeg <strong>TCP TIME_WAIT<\/strong> p\u00e5 webservere p\u00e5 en s\u00e5dan m\u00e5de, at en h\u00f8j kortvarig belastning ikke udt\u00f8mmer portene, og at nye forbindelser hurtigt kan etableres. Denne praktiske vejledning indeholder klare m\u00e5lepunkter, sikre kerneindstillinger, applikationsn\u00e6r socket-optimering og arkitektoniske finesser, der bevarer TIME_WAIT som et nyttigt sikkerhedsnet og samtidig \u00f8ger gennemstr\u00f8mningen.<\/p>\n\n<h2>Centrale punkter<\/h2>\n<p>De f\u00f8lgende centrale aspekter giver en m\u00e5lrettet vejledning i analyse og optimering af TIME_WAIT p\u00e5 Linux-webservere.<\/p>\n<ul>\n  <li><strong>Forst\u00e5else<\/strong>: TIME_WAIT sikrer dataintegriteten; m\u00e5let er kontrol frem for nedlukning.<\/li>\n  <li><strong>messer<\/strong>: Registrer n\u00f8jagtigt andelen af TIME_WAIT, portudnyttelsen og genopkoblingsfrekvenserne.<\/li>\n  <li><strong>Kernen<\/strong>: ip_local_port_range, tcp_fin_timeout, tcp_tw_reuse \u2013 juster forsigtigt og m\u00e5lbart.<\/li>\n  <li><strong>Stik<\/strong>: Keep-Alive, HTTP\/2\/3 og forbindelsespuljer reducerer forbindelsesoms\u00e6tningen.<\/li>\n  <li><strong>Arkitektur<\/strong>: Skalering, ekstra IP-adresser\/porte og proxyservere fordeler TIME_WAIT-belastningen.<\/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>TIME_WAIT \u2013 korrekt klassificering<\/h2>\n\n<p>Mange administratorer ser tusindvis af forbindelser i <strong>TIME_WAIT<\/strong> og t\u00e6nker, at der er tale om en fejl, men det er netop det modsatte, der er tilf\u00e6ldet. Tilstanden holder slettede forbindelser tilbage et \u00f8jeblik, s\u00e5 senere segmenter ikke forstyrrer nye forbindelser, og alle bytes n\u00e5r frem til deres modtager. Jeg respekterer denne sikkerhedslogik, da den forhindrer sammenblanding af data og irriterende RST\u2019er. P\u00e5 st\u00e6rkt trafikerede webservere stiger antallet af kortlivede sockets naturligvis, hvilket kr\u00e6ver en vurdering og ikke panik. Det afg\u00f8rende er stadig, om der rent faktisk opst\u00e5r portmangel, backlog-overl\u00f8b eller brugerfejl, f\u00f8r jeg iv\u00e6rks\u00e6tter optimering.<\/p>\n\n<h2>At genkende symptomer p\u00e5 st\u00e6rkt belastede servere<\/h2>\n\n<p>Jeg tjekker f\u00f8rst <strong>Havn<\/strong>-Fejlmeddelelser som \u201eCannot assign requested address\u201c eller \u201eAddress already in use\u201c tyder p\u00e5, at adresserne er opbrugt. Forsinkede handshakes, sporadiske afvisninger og spidsbelastninger p\u00e5 kernel-CPU\u2019en i netv\u00e6rksstien er yderligere advarselssignaler. N\u00e5r overv\u00e5gningen viser et us\u00e6dvanligt stort antal TIME_WAIT-sockets, sammenligner jeg altid dette tal med antallet af nye forbindelser og svartiderne. En h\u00f8j andel af TIME_WAIT-sockets er i sig selv acceptabel, s\u00e5 l\u00e6nge ledige ephemeral-porte og socket-tabellerne giver tilstr\u00e6kkelig spillerum. F\u00f8rst konkrete flaskehalse f\u00e5r mig til at justere parametrene m\u00e5lrettet i stedet for at handle p\u00e5 mistanke.<\/p>\n\n<h2>M\u00e5ling og evaluering: Oversigt over tilstande og porte<\/h2>\n\n<p>Uden tal optimerer jeg ikke noget, s\u00e5 jeg starter med <strong>ss<\/strong> og Netstat for at registrere tilstandsfordelinger og tendenser. Derudover kigger jeg i \/proc\/net\/tcp, da der findes detaljer om lokale og eksterne porte samt tilstande. Fra overv\u00e5gningen udtr\u00e6kker jeg TIME_WAIT-t\u00e6llinger pr. v\u00e6rt, nye forbindelser pr. sekund og fejlprocenter pr. minut. Jeg er interesseret i forholdet mellem TIME_WAIT og det samlede antal sockets samt udnyttelsen af de kortvarige porte for at skelne mellem reel belastning og rent optisk indtryk. F\u00f8rst n\u00e5r disse m\u00e5linger bekr\u00e6fter flaskehalse, planl\u00e6gger jeg konkrete tiltag p\u00e5 kerne- og applikationsniveau.<\/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>Kernel-tuning: sikre justeringsmuligheder med sans for proportioner<\/h2>\n\n<p>Jeg begynder med <strong>konservativ<\/strong> Foretag \u00e6ndringer og indf\u00f8r dem gradvist, altid ledsaget af m\u00e5linger og en mulighed for at vende tilbage til den oprindelige indstilling. En udvidet ip_local_port_range \u00f8ger udvalget af kildeporte, hvilket mindsker portkollisioner. En forsigtig neds\u00e6ttelse af tcp_fin_timeout forkorter visse afslutningstilstande uden at risikere for tidlige afbrydelser. I NAT-frie ops\u00e6tninger kan tcp_tw_reuse m\u00e6rkbart mindske portbelastningen, forudsat at jeg kender milj\u00f8et godt, og at testene forl\u00f8ber problemfrit. En tilstr\u00e6kkelig h\u00f8j tcp_max_tw_buckets-v\u00e6rdi undg\u00e5r aggressiv kassering, men skal passe til den tilg\u00e6ngelige RAM-kapacitet.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Parametre<\/strong><\/th>\n      <th><strong>Form\u00e5l<\/strong><\/th>\n      <th><strong>Eksempel p\u00e5 v\u00e6rdi<\/strong><\/th>\n      <th><strong>Risiko<\/strong><\/th>\n      <th><strong>M\u00e5lt variabel<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>net.ipv4.ip_local_port_range<\/td>\n      <td>Udvid ephemeral-port-puljen<\/td>\n      <td>12000 65535<\/td>\n      <td>Flere \u00e5bne <strong>Havne<\/strong> bruger kerneressourcer<\/td>\n      <td>Ledige porte, forbindelsesfejl<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_fin_timeout<\/td>\n      <td>Reducere varigheden af FIN-faser<\/td>\n      <td>30\u201345 sekunder<\/td>\n      <td>For lave v\u00e6rdier \u00f8ger risikoen for abort<\/td>\n      <td>Gengivelser, RST-andel<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_tw_reuse<\/td>\n      <td>Genbrug af TIME_WAIT-sockets<\/td>\n      <td>1 (selektiv)<\/td>\n      <td>Risikabelt i NAT-milj\u00f8er<\/td>\n      <td>TIME_WAIT-andel, fejlprocenter<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_max_tw_buckets<\/td>\n      <td>Maksimalt antal TIME_WAIT-sockets<\/td>\n      <td>H\u00f8j, passende v\u00e6rdi<\/td>\n      <td>For lille st\u00f8rrelse udl\u00f8ser forvridninger<\/td>\n      <td>Kernel-drops, RST'er<\/td>\n    <\/tr>\n    <tr>\n      <td>for\u00e6ldede indstillinger (f.eks. tcp_tw_recycle)<\/td>\n      <td>Gammel, problematisk adf\u00e6rd<\/td>\n      <td>Lad den v\u00e6re deaktiveret<\/td>\n      <td>Blokeringer ved NAT og legitime forbindelsesfejl<\/td>\n      <td>En r\u00e6kke fejl, klager fra kunder<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Bedste praksis for \u00e6ndringer i netv\u00e6rksstakken<\/h2>\n\n<p>Jeg \u00e6ndrer kun nogle f\u00e5 pr. trin <strong>Parametre<\/strong>, s\u00e5 jeg kan skelne klart mellem \u00e5rsag og virkning. F\u00f8rst fastl\u00e6gger jeg klare m\u00e5l, f.eks. ingen portudt\u00f8mning, acceptable TIME_WAIT-tal og konstante latenstider. Enhver \u00e6ndring implementeres f\u00f8rst p\u00e5 testsystemer med realistiske belastningsm\u00f8nstre og kontrollerede rollback-planer. Under udrulningen sammenholder jeg netv\u00e6rks- og applikationsmetrikker, fordi det kun er samspillet mellem dem, der afspejler brugeroplevelsen. F\u00f8rst n\u00e5r m\u00e5lev\u00e6rdierne er overbevisende over flere belastningsfaser, implementerer jeg indstillingerne permanent.<\/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>Socket-optimering p\u00e5 applikationsniveau<\/h2>\n\n<p>Den st\u00f8rste lettelse opn\u00e5r jeg ofte ved at <strong>Keep-Alive<\/strong> og genbrug af forbindelser, fordi f\u00e6rre nye forbindelser ogs\u00e5 genererer f\u00e6rre TIME_WAIT-tilstande. Jeg aktiverer HTTP Keep-Alive og v\u00e6lger fornuftige inaktivitetstider, s\u00e5 f\u00e5 langvarige forbindelser kan h\u00e5ndtere mange anmodninger. Hvor det er hensigtsm\u00e6ssigt, bruger jeg HTTP\/2 eller HTTP\/3 til at multiplexe flere anmodninger over f\u00e5 forbindelser. Til backend-klienter arbejder jeg med forbindelsespuljer, der holder forbindelserne \u00e5bne og fornyer dem omhyggeligt. Et kortfattet overblik over emnet finder du i min henvisning til <a href=\"https:\/\/webhosting.de\/da\/http-forbindelse-genbrug-keepalive-optimering-serverperf-boost\/\">HTTP Keep-Alive<\/a>, som jeg konsekvent bruger til webtjenester.<\/p>\n\n<h2>Arkitektoniske l\u00f8sninger, der afb\u00f8der TIME_WAIT<\/h2>\n\n<p>Jeg fordeler belastningen vandret, s\u00e5 <strong>TIME_WAIT<\/strong> ikke koncentreret p\u00e5 \u00e9n host, og der bliver mangel p\u00e5 porte. Flere IP-adresser eller yderligere listeporte \u00f8ger antallet af mulige kilde-\/m\u00e5lkombinationer og mindsker kollisioner. Reverse proxyer foran origin-serveren samler klientforbindelser og kommunikerer internt effektivt med poolede backends. Det er stadig afg\u00f8rende at have afstemte timeout-v\u00e6rdier, s\u00e5 proxyer, load balancere og backend-servere ikke afbryder forbindelserne for tidligt. Hvis man bruger Apache, b\u00f8r man <a href=\"https:\/\/webhosting.de\/da\/optimal-indstilling-af-apache-keepalive-timeout-med-fokus-pa-ydeevne\/\">Keep-Alive-timeout<\/a> tilpasse omhyggeligt til trafikm\u00f8nstre og ventetider.<\/p>\n\n<h2>Valg af hosting og server med hensyn til TIME_WAIT<\/h2>\n\n<p>Jeg foretr\u00e6kker udbydere med opdateret <strong>Linux<\/strong>-Kernel, fordi moderne TCP-funktioner g\u00f8r hverdagen nemmere. Detaljeret kontrol via sysctl-parametre sparer tid ved analyse og implementering. Integreret overv\u00e5gning af netv\u00e6rks- og socket-tilstande fremskynder vurderingen efter \u00e6ndringer. For tjenester med mange kortvarige forbindelser er det en fordel at have h\u00f8jtydende hardware og et netv\u00e6rk, der uden problemer kan h\u00e5ndtere spidsbelastninger. P\u00e5 den m\u00e5de implementerer jeg ikke kun TIME_WAIT-optimeringer, men sikrer ogs\u00e5, at de fungerer p\u00e5lideligt i drift.<\/p>\n\n<h2>Praktisk vejledning: API-server under kortvarig belastning<\/h2>\n\n<p>Jeg starter med en m\u00e5lerunde og registrerer <strong>Nye forbindelser<\/strong> pr. sekund, andelen af TIME_WAIT og fejlprocenten. Derefter indstiller jeg ip_local_port_range til et bredere interval og s\u00e6nker tcp_fin_timeout forsigtigt, mens jeg overv\u00e5ger antallet af genudsendelser. I et NAT-frit milj\u00f8 aktiverer jeg tcp_tw_reuse som en test, dokumenterer resultaterne og reagerer straks p\u00e5 afvigelser. Samtidig sikrer jeg, at Keep-Alive er aktiveret, at HTTP\/2 k\u00f8rer, og at applikationen udnytter forbindelsespuljer korrekt. Til sidst tjekker jeg TIME_WAIT-tendenser over flere spidsbelastningsfaser, f\u00f8r jeg fastl\u00e6gger indstillingerne.<\/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>Overv\u00e5gning og l\u00f8bende drift<\/h2>\n\n<p>Jeg dokumenterer hver eneste <strong>\u00c6ndring<\/strong> med startv\u00e6rdi, m\u00e5l og observeret effekt, s\u00e5 jeg senere hurtigt kan kontrollere resultaterne. Forandringsprocesser med en klar rollback-strategi beskytter mod langsigtede skader i tilf\u00e6lde af fejltagelser. Ud over TIME_WAIT m\u00e5ler jeg RTT, retransmissioner, goodput og fejlrater for at f\u00e5 et fuldst\u00e6ndigt billede af brugeroplevelsen. For langvarige backend-forbindelser anser jeg <a href=\"https:\/\/webhosting.de\/da\/tcp-keepalive-indstillinger-hosting-optimering-serverboost\/\">TCP Keepalive<\/a> konsekvent, s\u00e5 ineffektive sammenkoblinger forsvinder, og ressourcerne forbliver tilg\u00e6ngelige. P\u00e5 den m\u00e5de f\u00f8lger jeg optimeringerne i hverdagen, i stedet for at betragte dem som en engangsforanstaltning.<\/p>\n\n<h2>Hvem b\u00e6rer TIME_WAIT? Aktiv vs. passiv lukning<\/h2>\n<p>Jeg vurderer altid, hvilken side der aktivt lukker forbindelsen, da den side, der aktivt lukker forbindelsen, typisk ender i <strong>TIME_WAIT<\/strong>. Ved klassiske webklienter lukker klienten ofte ned, s\u00e5 serveren ser f\u00e6rre TIME_WAIT-tilstande \u2013 ved backend-kald er min applikation derimod selv klienten og akkumulerer TIME_WAIT-tilstande. Jeg undg\u00e5r tvungen aktiv lukning p\u00e5 serveren (f.eks. SO_LINGER=0), da dette kan udl\u00f8se RST\u2019er og medf\u00f8re datatab. I stedet satser jeg p\u00e5 <em>en yndefuld afslutning<\/em>, fornuftige Keep-Alive-timeouts og lad, hvor det er muligt, klienten lukke f\u00f8rst. Det mindsker ikke blot TIME_WAIT p\u00e5 serveren, men reducerer ogs\u00e5 fejl, der skyldes for tidlige afbrydelser. N\u00e5r jeg opretter mange udg\u00e5ende forbindelser (f.eks. til databaser eller upstreams), har god genbrug af forbindelser en mere umiddelbar effekt end enhver form for kernel-tuning.<\/p>\n\n<h2>Dimensionering af liste- og acceptk\u00f8er<\/h2>\n<p>Jeg s\u00f8rger for, at indg\u00e5ende forbindelser ikke afbrydes, f\u00f8r de n\u00e5r frem til applikationen. Til det form\u00e5l tilpasser jeg <strong>net.core.somaxconn<\/strong> og v\u00e6rdierne for min webservers backlog, s\u00e5 Accept-k\u00f8en ikke l\u00f8ber over. <strong>net.ipv4.tcp_max_syn_backlog<\/strong> Jeg dimensionerer den i overensstemmelse med toppen af de indg\u00e5ende handshakes; for sm\u00e5 v\u00e6rdier f\u00f8rer til tab allerede i SYN-fasen. <strong>tcp_syncookies<\/strong> Jeg holder den aktiveret for at sikre stabilitet ved korte spidsbelastninger, men tjekker i belastningstests, om den legitime trafik ikke bliver bremset. N\u00e5r jeg bruger flere arbejdsprocesser, indstiller jeg <strong>SO_REUSEPORT<\/strong>, for at fordele belastningen j\u00e6vnt p\u00e5 CPU-kernerne og mindske \u00bbAccept-Lock-Contention\u00ab. Disse foranstaltninger l\u00f8ser ikke problemet med portmangel, men forhindrer fejlagtige fortolkninger, hvor afvisninger fejlagtigt tilskrives 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>Hold \u00f8je med NAT, load balancer og conntrack<\/h2>\n<p>Jeg skelner strengt mellem host- og edge-problemer. Bag en SNAT eller Cloud-NAT kan der ikke kun v\u00e6re en server, men ogs\u00e5 NAT-gatewayen med dens <em>udg\u00e5ende<\/em> Ephemeral-porte bliver til flaskehalse. I s\u00e5danne scenarier afhj\u00e6lper jeg presset ved hj\u00e6lp af yderligere udg\u00e5ende IP-adresser, en mere finmasket portfordeling eller lavere genforbindelsesfrekvenser via puljer. P\u00e5 Linux-edge-enheder tjekker jeg <strong>nf_conntrack_max<\/strong> og TCP-timeouts i Conntrack; hvis man opbevarer sporing t\u00e6t p\u00e5 TIME_WAIT for l\u00e6nge, optager det hukommelse og kan fortr\u00e6nge legitime datastr\u00f8mme. Jeg s\u00e6nker kun Conntrack-timeouts med forsigtighed og altid i sammenh\u00e6ng med applikations- og kernelv\u00e6rdier, s\u00e5 jeg ikke afsk\u00e6rer forsinkede segmenter. Vigtigt: <strong>tcp_tw_reuse<\/strong> virker udelukkende p\u00e5 v\u00e6rtsens udg\u00e5ende forbindelser, ikke p\u00e5 de indg\u00e5ende forbindelser til lytteren, og indstiller <strong>tcp_timestamps=1<\/strong> Derfor tester jeg NAT-milj\u00f8er s\u00e6rligt grundigt.<\/p>\n\n<h2>HTTP\/3 og UDP: Hvad \u00e6ndrer sig?<\/h2>\n<p>Med HTTP\/3 skifter transporten til <strong>QUIC\/UDP<\/strong>, hvilket g\u00f8r den klassiske TCP-TIME_WAIT overfl\u00f8dig. Derfor planl\u00e6gger jeg p\u00e5 en anden m\u00e5de: I stedet for TCP-tilstande overv\u00e5ger jeg antallet af UDP-sockets, udnyttelsen af ephemeral-porte og Conntrack-poster for UDP. QUIC s\u00e6nker omkostningerne ved oprettelse af forbindelser m\u00e6rkbart og reducerer forbindelsesafbrydelser, men kr\u00e6ver ensartede inaktivitetstimeouts mellem klient, proxy og oprindelsesserver. I blandede milj\u00f8er (H2\/H3) s\u00f8rger jeg for, at Keep-Alive-politikker forbliver sammenh\u00e6ngende, s\u00e5 fordelene ved multiplexing ikke g\u00e5r tabt p\u00e5 grund af for korte inaktivitetstimer.<\/p>\n\n<h2>Ressourcebegr\u00e6nsninger og operativsystembegr\u00e6nsninger<\/h2>\n<p>Jeg l\u00e6gger f\u00f8rst et solidt fundament <strong>Begr\u00e6nsninger for fildeskriptorer<\/strong> et (ulimit nofile, fs.file\u2011max, fs.nr_open), da for stramme gr\u00e6nser skaber sekund\u00e6re fejl, som TIME_WAIT blot skjuler. TCP-hukommelsesgr\u00e6nserne (<strong>net.ipv4.tcp_mem<\/strong>, <strong>tcp_rmem<\/strong>, <strong>tcp_wmem<\/strong>) justerer jeg det s\u00e5ledes, at stakken ikke kommer under hukommelsespres, n\u00e5r der er mange samtidige forbindelser. For klart adskilte serviceporte mener jeg, at <strong>ip_local_reserverede_porte<\/strong> opdateret, s\u00e5 ephemeral-porte ikke ved en fejl kolliderer med serverporte. I belastningstests kontrollerer jeg, om slab-v\u00e6ksten (f.eks. for TCP-kontrolblokke) forbliver stabil \u2013 kun p\u00e5 den m\u00e5de kan jeg vurdere, om en h\u00f8jere tcp_max_tw_buckets-v\u00e6rdi rent faktisk er holdbar.<\/p>\n\n<h2>S\u00e6rlige forhold vedr\u00f8rende containere og Kubernetes<\/h2>\n<p>I containere tager jeg h\u00f8jde for, at omr\u00e5der for ephemeral-porte, ulimits og sysctls pr. <em>Navnerum<\/em> kan variere. Service-meshes og sidecars fordobler ofte antallet af forbindelser (klient\u2194sidecar\u2194proxy\u2194backend) og dermed risikoen for TIME_WAIT \u2013 her opn\u00e5r jeg den st\u00f8rste gevinst gennem genbrug af forbindelser og afstemte inaktivitetstimere. NodePorts og SNAT p\u00e5 arbejdere belaster desuden Conntrack-tabellerne; jeg overv\u00e5ger disse v\u00e6rdier separat fra pod-v\u00e6rten. Under belastning fordeler jeg udg\u00e5ende trafik p\u00e5 flere noder eller bruger dedikerede udg\u00e5ende gateways for at undg\u00e5 port-hotspots. Det er vigtigt at huske: Hvis jeg optimerer i pod\u2019en, skal v\u00e6rtsnetv\u00e6rket (inkl. NAT\/Conntrack) passe til det, ellers flytter jeg blot problemet.<\/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>Diagnosevejledning og nyttige retningslinjer<\/h2>\n<p>For hurtigt at kunne vurdere situationen f\u00f8lger jeg en fast r\u00e6kkef\u00f8lge: For det f\u00f8rste <em>ss -s<\/em> og <em>ss -tan state time-wait<\/em> Hvad ang\u00e5r st\u00f8rrelsesordenen, for det andet <em>\/proc\/sys\/net\/ipv4\/ip_local_port_range<\/em> kontrollere og estimere ledige ephemeral-porte, for det tredje krydstjekke fejlmeddelelser og RST-kvoter i app- og kernel-loggen. Derefter m\u00e5ler jeg antallet af nye forbindelser pr. sekund og korrelerer dem med latenstider. Som retningslinjer tolererer jeg h\u00f8je TIME_WAIT-andele, s\u00e5 l\u00e6nge: der ikke opst\u00e5r portudt\u00f8mning, ingen Accept-k\u00f8 l\u00f8ber over, retransmissioner forbliver stabile, og svartiderne ikke afviger. Jeg betragter f\u00f8rst en optimering som \u201ef\u00e6rdig\u201c, n\u00e5r de samme belastningsspidser kan genneml\u00f8bes reproducerbart over flere dage uden afvigelser.<\/p>\n\n<h2>Almindelige fejl og anti-m\u00f8nstre<\/h2>\n\n<p>Jeg undg\u00e5r generelle afbrydelser af <strong>TIME_WAIT<\/strong>, for dermed risikerer jeg, at data blandes sammen, og at der opst\u00e5r sporadiske fejl. En blind s\u00e6nkning af timeout-v\u00e6rdier straffer brugerne med afbrudte forbindelser under h\u00f8j belastning. For\u00e6ldede indstillinger som tcp_tw_recycle lader jeg v\u00e6re u\u00e6ndrede, fordi de kan afbryde legitime adgangsforesp\u00f8rgsler. Ren kernel-tuning uden arbejde med apps og arkitektur nytter ikke meget, hvis der opst\u00e5r for mange kortvarige forbindelser. Hvis man \u00e6ndrer alt p\u00e5 \u00e9n gang, hindrer man en grundig \u00e5rsagsanalyse og forl\u00e6nger fejls\u00f8gningen.<\/p>\n\n<h2>Kompakt oversigt til administratorer<\/h2>\n\n<p>Jeg behandler <strong>TIME_WAIT<\/strong> Som en sikkerhedsforanstaltning m\u00e5ler jeg f\u00f8rst n\u00f8je og optimerer derefter trin for trin. Jeg opn\u00e5r den st\u00f8rste effekt med genbrug af forbindelser via Keep-Alive, HTTP\/2\/3 og puljer, suppleret med forsigtige sysctl-justeringer. Arkitektoniske st\u00f8tteelementer som ekstra IP-adresser, proxyservere og horisontal skalering fordeler forbindelsesbelastningen effektivt. L\u00f8bende overv\u00e5gning, grundig dokumentation og klare m\u00e5l sikrer konstante latenstider og tilg\u00e6ngelige porte. P\u00e5 den m\u00e5de forbliver webserveren reaktionshurtig selv ved h\u00f8j trafik, mens TIME_WAIT fungerer kontrolleret og forudsigeligt.<\/p>","protected":false},"excerpt":{"rendered":"<p>Find ud af, hvordan du sikkert kan optimere TCP time_wait p\u00e5 st\u00e6rkt belastede webservere og undg\u00e5 portudt\u00f8mning ved hj\u00e6lp af m\u00e5lrettet Linux- og socket-optimering.<\/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\/da\/wp-json\/wp\/v2\/posts\/21215","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=21215"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/21215\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/21208"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=21215"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=21215"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=21215"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}