{"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-webbserverprestanda-naetverk","status":"publish","type":"post","link":"https:\/\/webhosting.de\/sv\/tcp-time-wait-optimierung-webserver-performance-netzwerk\/","title":{"rendered":"Optimering av TCP TIME_WAIT p\u00e5 webbservrar: Praktisk guide f\u00f6r administrat\u00f6rer"},"content":{"rendered":"<p>Jag visar hur jag <strong>TCP TIME_WAIT<\/strong> p\u00e5 webbservrar s\u00e5 att h\u00f6g kortvarig belastning inte tar slut p\u00e5 portarna och att nya anslutningar kan startas snabbt. Denna praktiska guide ger tydliga m\u00e4tpunkter, s\u00e4kra k\u00e4rnalternativ, applikationsn\u00e4ra socketoptimering och arkitekturknep som bevarar TIME_WAIT som ett anv\u00e4ndbart s\u00e4kerhetsn\u00e4t och samtidigt \u00f6kar genomstr\u00f6mningen.<\/p>\n\n<h2>Centrala punkter<\/h2>\n<p>F\u00f6ljande nyckelaspekter ger en m\u00e5linriktad v\u00e4gledning genom analys och optimering av TIME_WAIT p\u00e5 Linux-webbservrar.<\/p>\n<ul>\n  <li><strong>F\u00f6rst\u00e5else<\/strong>: TIME_WAIT skyddar dataintegriteten; m\u00e5let \u00e4r kontroll ist\u00e4llet f\u00f6r avst\u00e4ngning.<\/li>\n  <li><strong>m\u00e4ssor<\/strong>: Noggrant registrera andelen TIME_WAIT, portutnyttjande och andelen \u00e5teranslutningar.<\/li>\n  <li><strong>K\u00e4rnan<\/strong>: ip_local_port_range, tcp_fin_timeout, tcp_tw_reuse \u2013 justera f\u00f6rsiktigt och m\u00e4tbart.<\/li>\n  <li><strong>Socklar<\/strong>: Keep-Alive, HTTP\/2\/3 och anslutningspooler minskar oms\u00e4ttningen av anslutningar.<\/li>\n  <li><strong>Arkitektur<\/strong>: Skalning, ytterligare IP-adresser\/portar och proxyservrar f\u00f6rdelar 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>Att korrekt tolka TIME_WAIT<\/h2>\n\n<p>M\u00e5nga administrat\u00f6rer ser tusentals anslutningar i <strong>TIME_WAIT<\/strong> och tror att det \u00e4r ett fel, men det \u00e4r precis tv\u00e4rtom. Systemet h\u00e5ller kvar avslutade anslutningar en kort stund, s\u00e5 att senare segment inte st\u00f6r nya anslutningar och s\u00e5 att alla byte n\u00e5r sina mottagare. Jag respekterar denna s\u00e4kerhetslogik, eftersom den f\u00f6rhindrar att data blandas ihop och att irriterande RST-paket skickas. P\u00e5 h\u00f6gtrafikerade webbservrar \u00f6kar antalet kortlivade socklar naturligtvis, vilket kr\u00e4ver en noggrann bed\u00f6mning snarare \u00e4n panik. Det avg\u00f6rande \u00e4r fortfarande om portbrist, backlog-\u00f6verfl\u00f6d eller anv\u00e4ndarfel faktiskt uppst\u00e5r innan jag p\u00e5b\u00f6rjar en optimering.<\/p>\n\n<h2>Att uppt\u00e4cka symptom p\u00e5 \u00f6verbelastade servrar<\/h2>\n\n<p>Jag kontrollerar f\u00f6rst <strong>Port<\/strong>-Felmeddelanden: \u201eCannot assign requested address\u201c eller \u201eAddress already in use\u201c tyder p\u00e5 att utrymmet \u00e4r fullt. F\u00f6rdr\u00f6jda handskakningar, sporadiska avvisningar och toppar i k\u00e4rnans CPU-anv\u00e4ndning l\u00e4ngs n\u00e4tverksv\u00e4gen \u00e4r ytterligare varningssignaler. Om \u00f6vervakningen visar ovanligt m\u00e5nga TIME_WAIT-socklar j\u00e4mf\u00f6r jag alltid denna siffra med antalet nya anslutningar och svarstiderna. En h\u00f6g andel TIME_WAIT-socklar \u00e4r i sig acceptabel s\u00e5 l\u00e4nge lediga efemeriska portar och sockeltabellerna ger tillr\u00e4ckligt med utrymme. F\u00f6rst n\u00e4r konkreta flaskhalsar uppst\u00e5r justerar jag parametrarna m\u00e5lmedvetet ist\u00e4llet f\u00f6r att agera p\u00e5 misstankar.<\/p>\n\n<h2>M\u00e4tning och utv\u00e4rdering: \u00d6versikt \u00f6ver tillst\u00e5nd och portar<\/h2>\n\n<p>Utan siffror kan jag inte optimera n\u00e5gonting, s\u00e5 jag b\u00f6rjar med <strong>ss<\/strong> och Netstat f\u00f6r att kartl\u00e4gga tillst\u00e5ndsf\u00f6rdelningar och trender. Jag tittar dessutom i \/proc\/net\/tcp, eftersom det d\u00e4r finns detaljer om lokala\/externa portar och tillst\u00e5nd. Fr\u00e5n \u00f6vervakningen h\u00e4mtar jag TIME_WAIT-v\u00e4rden per v\u00e4rd, nya anslutningar per sekund och felprocent per minut. Jag \u00e4r intresserad av f\u00f6rh\u00e5llandet mellan TIME_WAIT och det totala antalet socklar samt utnyttjandet av de tillf\u00e4lliga portarna f\u00f6r att skilja verklig belastning fr\u00e5n ren ytlighet. F\u00f6rst n\u00e4r dessa m\u00e4tv\u00e4rden bekr\u00e4ftar flaskhalsar planerar jag konkreta \u00e5tg\u00e4rder p\u00e5 k\u00e4rn- och applikationsniv\u00e5.<\/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>K\u00e4rnoptimering: s\u00e4kra justeringsm\u00f6jligheter med gott omd\u00f6me<\/h2>\n\n<p>Jag b\u00f6rjar med <strong>konservativ<\/strong> G\u00f6r \u00e4ndringar och inf\u00f6r dem stegvis, alltid i kombination med m\u00e4tningar och en \u00e5terg\u00e5ngsplan. Ett ut\u00f6kat ip_local_port_range \u00f6kar urvalet av k\u00e4llportar, vilket minskar portkollisioner. En f\u00f6rsiktig s\u00e4nkning av tcp_fin_timeout f\u00f6rkortar vissa slutstadier utan att riskera f\u00f6r tidiga avbrott. I NAT-fria konfigurationer kan tcp_tw_reuse m\u00e4rkbart minska portbelastningen, f\u00f6rutsatt att jag k\u00e4nner till milj\u00f6n v\u00e4l och att testerna g\u00e5r smidigt. Ett tillr\u00e4ckligt h\u00f6gt v\u00e4rde p\u00e5 tcp_max_tw_buckets f\u00f6rhindrar aggressivt avvisande, men m\u00e5ste anpassas till den tillg\u00e4ngliga RAM-kapaciteten.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Parametrar<\/strong><\/th>\n      <th><strong>Syfte<\/strong><\/th>\n      <th><strong>Exempel p\u00e5 v\u00e4rde<\/strong><\/th>\n      <th><strong>Risk<\/strong><\/th>\n      <th><strong>M\u00e4tt variabel<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>net.ipv4.ip_local_port_range<\/td>\n      <td>Ut\u00f6ka poolen med tillf\u00e4lliga portar<\/td>\n      <td>12000 65535<\/td>\n      <td>Fler \u00f6ppna <strong>Portar<\/strong> f\u00f6rbrukar k\u00e4rnresurser<\/td>\n      <td>Lediga portar, anslutningsfel<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_fin_timeout<\/td>\n      <td>Minska varaktigheten f\u00f6r FIN-faserna<\/td>\n      <td>30\u201345 sekunder<\/td>\n      <td>F\u00f6r l\u00e5ga v\u00e4rden \u00f6kar risken f\u00f6r missfall<\/td>\n      <td>\u00c5teruts\u00e4ndningar, RST-andel<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_tw_reuse<\/td>\n      <td>\u00c5teranv\u00e4nda TIME_WAIT-socklar<\/td>\n      <td>1 (selektivt)<\/td>\n      <td>Riskabelt i NAT-milj\u00f6er<\/td>\n      <td>Andel TIME_WAIT, felprocent<\/td>\n    <\/tr>\n    <tr>\n      <td>net.ipv4.tcp_max_tw_buckets<\/td>\n      <td>Maximalt antal TIME_WAIT-socklar<\/td>\n      <td>H\u00f6gt, l\u00e4mpligt v\u00e4rde<\/td>\n      <td>F\u00f6r liten storlek orsakar snedvridningar<\/td>\n      <td>K\u00e4rnfall, RST:er<\/td>\n    <\/tr>\n    <tr>\n      <td>f\u00f6r\u00e5ldrade alternativ (t.ex. tcp_tw_recycle)<\/td>\n      <td>Gammalt, problematiskt beteende<\/td>\n      <td>L\u00e5t den vara inaktiverad<\/td>\n      <td>Blockeringar vid NAT och legitima anslutningsfel<\/td>\n      <td>En rad fel, klagom\u00e5l fr\u00e5n kunder<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>B\u00e4sta praxis f\u00f6r \u00e4ndringar i n\u00e4tverksstacken<\/h2>\n\n<p>Jag \u00e4ndrar bara n\u00e5gra f\u00e5 per steg <strong>Parametrar<\/strong>, s\u00e5 att jag tydligt kan koppla samman orsak och verkan. Inledningsvis fastst\u00e4ller jag tydliga m\u00e5l, till exempel att undvika portuttr\u00f6ttning, acceptabla TIME_WAIT-v\u00e4rden och konstanta latensv\u00e4rden. Varje \u00e4ndring testas f\u00f6rst p\u00e5 testsystem med realistiska belastningsm\u00f6nster och kontrollerade \u00e5terg\u00e5ngsplaner. Under utrullningen korrelerar jag n\u00e4tverks- och applikationsm\u00e5tt, eftersom det \u00e4r endast samspelet mellan dem som \u00e5terspeglar anv\u00e4ndarupplevelsen. F\u00f6rst n\u00e4r m\u00e4tv\u00e4rdena \u00f6ver flera belastningsfaser \u00e4r \u00f6vertygande inf\u00f6r jag inst\u00e4llningarna 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 applikationsniv\u00e5<\/h2>\n\n<p>Den st\u00f6rsta avlastningen uppn\u00e5r jag ofta genom <strong>Keep-Alive<\/strong> och \u00e5teranv\u00e4ndning av anslutningar, eftersom f\u00e4rre nya anslutningar ocks\u00e5 genererar f\u00e4rre TIME_WAIT-tillst\u00e5nd. Jag aktiverar HTTP Keep-Alive och v\u00e4ljer rimliga vilotider s\u00e5 att ett f\u00e5tal l\u00e5ngvariga anslutningar kan hantera m\u00e5nga f\u00f6rfr\u00e5gningar. D\u00e4r det \u00e4r l\u00e4mpligt anv\u00e4nder jag HTTP\/2 eller HTTP\/3 f\u00f6r att multiplexera flera f\u00f6rfr\u00e5gningar \u00f6ver ett f\u00e5tal anslutningar. F\u00f6r backend-klienter arbetar jag med anslutningspooler som h\u00e5ller anslutningarna \u00f6ppna och f\u00f6rnyar dem noggrant. En kortfattad \u00f6versikt \u00f6ver \u00e4mnet finns i min h\u00e4nvisning till <a href=\"https:\/\/webhosting.de\/sv\/http-anslutning-ateranvaendning-keepalive-optimering-serverperf-boost\/\">HTTP Keep-Alive<\/a>, som jag konsekvent anv\u00e4nder f\u00f6r webbtj\u00e4nster.<\/p>\n\n<h2>Arkitekturbeslut som mildrar effekterna av TIME_WAIT<\/h2>\n\n<p>Jag f\u00f6rdelar belastningen horisontellt s\u00e5 att <strong>TIME_WAIT<\/strong> inte koncentreras till en enda v\u00e4rd och portarna b\u00f6rjar ta slut. Fler IP-adresser eller ytterligare listportar \u00f6kar antalet m\u00f6jliga k\u00e4ll-\/m\u00e5lkombinationer och minskar kollisionerna. Omv\u00e4nda proxyservrar f\u00f6re ursprungsservern sammanf\u00f6r klientanslutningar och kommunicerar internt p\u00e5 ett effektivt s\u00e4tt med poolade backend-servrar. Det \u00e4r fortfarande avg\u00f6rande med v\u00e4l avst\u00e4mda timeout-v\u00e4rden s\u00e5 att proxyservrar, lastbalanserare och backend-servrar inte avbryter anslutningarna i f\u00f6rtid. Den som anv\u00e4nder Apache b\u00f6r <a href=\"https:\/\/webhosting.de\/sv\/optimera-instaellningen-foer-apache-keepalive-timeout-fokus-pa-prestanda\/\">Keep-Alive-timeout<\/a> noggrant anpassa efter trafikm\u00f6nster och f\u00f6rdr\u00f6jningar.<\/p>\n\n<h2>Val av webbhotell och server med h\u00e4nsyn till TIME_WAIT<\/h2>\n\n<p>Jag f\u00f6redrar leverant\u00f6rer med aktuell <strong>Linux<\/strong>-K\u00e4rnan, eftersom moderna TCP-funktioner underl\u00e4ttar det dagliga arbetet. Detaljerad kontroll \u00f6ver sysctl-parametrar sparar tid vid analys och drifts\u00e4ttning. Integrerad \u00f6vervakning av n\u00e4tverks- och socket-tillst\u00e5nd p\u00e5skyndar utv\u00e4rderingen efter \u00e4ndringar. F\u00f6r tj\u00e4nster med m\u00e5nga kortvariga anslutningar l\u00f6nar det sig att ha h\u00f6gpresterande h\u00e5rdvara och ett n\u00e4tverk som klarar belastningstoppar utan problem. P\u00e5 s\u00e5 s\u00e4tt implementerar jag inte bara TIME_WAIT-optimeringar, utan ser ocks\u00e5 till att de fungerar p\u00e5litligt under drift.<\/p>\n\n<h2>Praktisk guide: API-servrar under kortvarig belastning<\/h2>\n\n<p>Jag b\u00f6rjar med en m\u00e4tningsrunda och registrerar <strong>Nya f\u00f6rbindelser<\/strong> per sekund, andelen TIME_WAIT och felfrekvenserna. D\u00e4refter ut\u00f6kar jag ip_local_port_range och s\u00e4nker tcp_fin_timeout f\u00f6rsiktigt, samtidigt som jag \u00f6vervakar \u00e5teruts\u00e4ndningarna. I en NAT-fri milj\u00f6 aktiverar jag tcp_tw_reuse p\u00e5 prov, dokumenterar resultaten och reagerar omedelbart om n\u00e5got avvikande uppt\u00e4cks. Samtidigt ser jag till att Keep-Alive \u00e4r aktiverat, att HTTP\/2 fungerar och att applikationen anv\u00e4nder anslutningspooler p\u00e5 r\u00e4tt s\u00e4tt. Slutligen granskar jag TIME_WAIT-trenderna \u00f6ver flera toppperioder innan jag fastst\u00e4ller inst\u00e4llningarna.<\/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>\u00d6vervakning och l\u00f6pande drift<\/h2>\n\n<p>Jag dokumenterar varje <strong>\u00c4ndring<\/strong> med utg\u00e5ngsv\u00e4rde, m\u00e5l och observerad effekt, s\u00e5 att jag senare snabbt kan kontrollera resultaten. F\u00f6r\u00e4ndringsprocesser med en tydlig \u00e5terg\u00e5ngsstrategi skyddar mot l\u00e5ngsiktiga skador vid felbeslut. F\u00f6rutom TIME_WAIT m\u00e4ter jag RTT, \u00e5teruts\u00e4ndningar, goodput och felfrekvenser f\u00f6r att f\u00e5 en fullst\u00e4ndig bild av anv\u00e4ndarupplevelsen. F\u00f6r l\u00e5ngvariga backend-anslutningar anser jag att <a href=\"https:\/\/webhosting.de\/sv\/tcp-keepalive-instaellningar-hosting-optimering-serverboost\/\">TCP Keepalive<\/a> konsekvent, s\u00e5 att ineffektiva kopplingar f\u00f6rsvinner och resurser f\u00f6rblir tillg\u00e4ngliga. P\u00e5 s\u00e5 s\u00e4tt st\u00f6der jag optimeringar i det dagliga arbetet, ist\u00e4llet f\u00f6r att betrakta dem som eng\u00e5ngs\u00e5tg\u00e4rder.<\/p>\n\n<h2>Vem st\u00e5r f\u00f6r TIME_WAIT? Aktivt kontra passivt st\u00e4ngning<\/h2>\n<p>Jag utv\u00e4rderar alltid vilken sida som aktivt st\u00e4nger anslutningen, eftersom den sida som aktivt st\u00e4nger anslutningen vanligtvis hamnar i <strong>TIME_WAIT<\/strong>. Vid klassiska webbklienter st\u00e4ngs ofta klienten, vilket g\u00f6r att servern ser f\u00e4rre TIME_WAIT-tillst\u00e5nd \u2013 vid backend-anrop \u00e4r d\u00e4remot min applikation sj\u00e4lv klienten och ackumulerar TIME_WAIT-tillst\u00e5nd. Jag undviker att tvinga fram en aktiv st\u00e4ngning p\u00e5 servern (t.ex. SO_LINGER=0), eftersom detta kan orsaka RST-fel och leda till dataf\u00f6rlust. Ist\u00e4llet satsar jag p\u00e5 <em>en elegant avslutning<\/em>, rimliga Keep-Alive-timeouts och l\u00e5t, d\u00e4r det \u00e4r m\u00f6jligt, klienten st\u00e4nga f\u00f6rst. Detta minskar inte bara TIME_WAIT p\u00e5 servern, utan minskar ocks\u00e5 fel som uppst\u00e5r p\u00e5 grund av f\u00f6r tidiga avbrott. N\u00e4r jag skapar m\u00e5nga utg\u00e5ende anslutningar (t.ex. till databaser eller uppstr\u00f6ms) ger en bra \u00e5teranv\u00e4ndning av anslutningar en mer omedelbar effekt \u00e4n n\u00e5gon form av k\u00e4rnoptimering.<\/p>\n\n<h2>Dimensionera list- och acceptk\u00f6er korrekt<\/h2>\n<p>Jag ser till att inkommande anslutningar inte avbryts redan innan de n\u00e5r applikationen. F\u00f6r att g\u00f6ra detta anpassar jag <strong>net.core.somaxconn<\/strong> och v\u00e4rdena f\u00f6r backloggen p\u00e5 min webbserver, s\u00e5 att Accept-k\u00f6n inte blir \u00f6verbelastad. <strong>net.ipv4.tcp_max_syn_backlog<\/strong> Jag dimensionerar den s\u00e5 att den passar topparna i de inkommande handskakningarna; f\u00f6r l\u00e5ga v\u00e4rden leder till avbrott redan i SYN-fasen. <strong>tcp_syncookies<\/strong> Jag h\u00e5ller den aktiverad f\u00f6r att systemet ska klara korta trafiktoppar, men kontrollerar i belastningstester att den legitima trafiken inte bromsas upp. Om jag anv\u00e4nder flera arbetare st\u00e4ller jag in <strong>SO_REUSEPORT<\/strong>, f\u00f6r att f\u00f6rdela belastningen j\u00e4mnt \u00f6ver CPU-k\u00e4rnorna och minska konkurrensen om accept-l\u00e5s. Dessa \u00e5tg\u00e4rder l\u00f6ser inte problemet med portbrist, men f\u00f6rhindrar felaktiga tolkningar n\u00e4r avvisningar felaktigt tillskrivs 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>H\u00e5lla koll p\u00e5 NAT, lastbalanserare och conntrack<\/h2>\n<p>Jag g\u00f6r en tydlig \u00e5tskillnad mellan v\u00e4rd- och kantproblem. Bakom en SNAT eller Cloud-NAT kan det inte bara finnas servern, utan \u00e4ven NAT-gatewayen med dess <em>utg\u00e5ende<\/em> Ephemeral-portar blir flaskhalsar. I s\u00e5dana situationer l\u00f6ser jag problemet genom att anv\u00e4nda ytterligare utg\u00e5ende IP-adresser, en mer finjusterad portf\u00f6rdelning eller l\u00e4gre \u00e5teranslutningsfrekvenser via pooler. P\u00e5 Linux-edges kontrollerar jag <strong>nf_conntrack_max<\/strong> och TCP-timeouts i Conntrack; att beh\u00e5lla sp\u00e5rning n\u00e4ra TIME_WAIT-tillst\u00e5ndet f\u00f6r l\u00e4nge tar upp minne och kan tr\u00e4nga undan legitima fl\u00f6den. Jag s\u00e4nker Conntrack-timeouts endast f\u00f6rsiktigt och alltid i kombination med applikations- och k\u00e4rnv\u00e4rden, s\u00e5 att jag inte avsk\u00e4r n\u00e5gra sena segment. Viktigt: <strong>tcp_tw_reuse<\/strong> p\u00e5verkar endast v\u00e4rdens utg\u00e5ende anslutningar, inte de inkommande anslutningarna till lyssnaren, och st\u00e4ller in <strong>tcp_timestamps=1<\/strong> D\u00e4rf\u00f6r testar jag NAT-milj\u00f6er s\u00e4rskilt noggrant.<\/p>\n\n<h2>HTTP\/3 och UDP: Vad f\u00f6r\u00e4ndras?<\/h2>\n<p>Med HTTP\/3 \u00f6verg\u00e5r \u00f6verf\u00f6ringen till <strong>QUIC\/UDP<\/strong>, vilket inneb\u00e4r att det klassiska TCP\u2011TIME_WAIT inte l\u00e4ngre beh\u00f6vs. Jag planerar d\u00e4rf\u00f6r p\u00e5 ett annat s\u00e4tt: Ist\u00e4llet f\u00f6r TCP-tillst\u00e5nd \u00f6vervakar jag antalet UDP-socklar, belastningen p\u00e5 tillf\u00e4lliga portar och Conntrack-poster f\u00f6r UDP. QUIC s\u00e4nker kostnaderna f\u00f6r uppkoppling m\u00e4rkbart och minskar bortfallet av anslutningar, men kr\u00e4ver konsekventa inaktivitetstidsgr\u00e4nser mellan klient, proxy och ursprung. I blandade milj\u00f6er (H2\/H3) ser jag till att Keep-Alive-policyerna f\u00f6rblir enhetliga, s\u00e5 att f\u00f6rdelarna med multiplexering inte g\u00e5r f\u00f6rlorade p\u00e5 grund av f\u00f6r korta inaktivitetstimer.<\/p>\n\n<h2>Resursbegr\u00e4nsningar och operativsystemets begr\u00e4nsningar<\/h2>\n<p>Jag l\u00e4gger f\u00f6rst en stabil <strong>Begr\u00e4nsningar f\u00f6r fildeskriptorer<\/strong> ett (ulimit nofile, fs.file\u2011max, fs.nr_open), eftersom f\u00f6r sn\u00e4va gr\u00e4nser ger upphov till sekund\u00e4ra fel som TIME_WAIT endast d\u00f6ljer. TCP-minnesgr\u00e4nserna (<strong>net.ipv4.tcp_mem<\/strong>, <strong>tcp_rmem<\/strong>, <strong>tcp_wmem<\/strong>) justerar jag s\u00e5 att stacken inte hamnar i minnesbrist vid m\u00e5nga samtidiga anslutningar. F\u00f6r tydligt \u00e5tskilda tj\u00e4nsteportar anser jag att <strong>ip_local_reserverade_portar<\/strong> aktuell, s\u00e5 att tillf\u00e4lliga portar inte av misstag kolliderar med serverportar. I belastningstester kontrollerar jag om slab-tillv\u00e4xten (t.ex. f\u00f6r TCP-kontrollblock) f\u00f6rblir stabil \u2013 det \u00e4r det enda s\u00e4ttet f\u00f6r mig att bed\u00f6ma om ett h\u00f6gre v\u00e4rde p\u00e5 tcp_max_tw_buckets verkligen \u00e4r h\u00e5llbart.<\/p>\n\n<h2>S\u00e4rdrag hos containrar och Kubernetes<\/h2>\n<p>I containrar tar jag h\u00e4nsyn till att Ephemeral-port-intervall, ulimits och sysctls per <em>Namnomr\u00e5de<\/em> kan variera. Service-meshes och sidecars f\u00f6rdubblar ofta antalet anslutningar (klient\u2194sidecar\u2194proxy\u2194backend) och d\u00e4rmed risken f\u00f6r TIME_WAIT \u2013 h\u00e4r vinner jag mest p\u00e5 \u00e5teranv\u00e4ndning av anslutningar och anpassade inaktivitetstimer. NodePorts och SNAT p\u00e5 arbetare belastar dessutom Conntrack-tabellerna; jag \u00f6vervakar dessa v\u00e4rden separat fr\u00e5n pod-v\u00e4rden. Under belastning f\u00f6rdelar jag utg\u00e5ende trafik \u00f6ver flera noder eller anv\u00e4nder dedikerade utg\u00e5ende gateways f\u00f6r att undvika port-hotspots. Det \u00e4r viktigt att komma ih\u00e5g: Om jag optimerar i poden m\u00e5ste v\u00e4rdn\u00e4tverket (inkl. NAT\/Conntrack) anpassas d\u00e4refter, annars flyttar jag bara 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>Diagnoshandbok och anv\u00e4ndbara riktv\u00e4rden<\/h2>\n<p>F\u00f6r att snabbt kunna bed\u00f6ma situationen anv\u00e4nder jag en fast ordningsf\u00f6ljd: F\u00f6r det f\u00f6rsta <em>ss -s<\/em> och <em>ss -tan state time-wait<\/em> vad g\u00e4ller storleksordningen, f\u00f6r det andra <em>\/proc\/sys\/net\/ipv4\/ip_local_port_range<\/em> kontrollera och uppskatta antalet lediga efem\u00e4ra portar, och f\u00f6r det tredje dubbelkontrollera felmeddelanden och RST-andelar i app- och k\u00e4rnloggarna. D\u00e4refter m\u00e4ter jag antalet nya anslutningar per sekund och korrelerar dem med latenser. Som riktv\u00e4rden tolererar jag h\u00f6ga TIME_WAIT-andelar s\u00e5 l\u00e4nge som: ingen portutarmning uppst\u00e5r, ingen Accept-k\u00f6 \u00f6verfl\u00f6dar, \u00e5teruts\u00e4ndningarna f\u00f6rblir stabila och svarstiderna inte avviker. Jag betraktar en optimering som \u201ef\u00e4rdig\u201c f\u00f6rst n\u00e4r samma belastningstoppar kan reproduceras under flera dagar utan avvikelser.<\/p>\n\n<h2>Vanliga misstag och anti-m\u00f6nster<\/h2>\n\n<p>Jag undviker generella avst\u00e4ngningar av <strong>TIME_WAIT<\/strong>, eftersom det medf\u00f6r en risk f\u00f6r att data blandas ihop och sporadiska fel uppst\u00e5r. Att blint s\u00e4nka timeout-v\u00e4rdena straffar anv\u00e4ndarna med avbrutna anslutningar vid h\u00f6g belastning. F\u00f6r\u00e5ldrade inst\u00e4llningar som tcp_tw_recycle l\u00e4mnar jag or\u00f6rda, eftersom de kan avbryta legitima \u00e5tkomstf\u00f6rs\u00f6k. Ren k\u00e4rnoptimering utan arbete med applikationer och arkitektur ger f\u00f6ga resultat om det uppst\u00e5r f\u00f6r m\u00e5nga korta anslutningar. Den som \u00e4ndrar allt p\u00e5 en g\u00e5ng f\u00f6rsv\u00e5rar en ordentlig orsaksanalys och f\u00f6rl\u00e4nger fels\u00f6kningen.<\/p>\n\n<h2>Kompakt sammanfattning f\u00f6r administrat\u00f6rer<\/h2>\n\n<p>Jag behandlar <strong>TIME_WAIT<\/strong> Som en s\u00e4kerhets\u00e5tg\u00e4rd m\u00e4ter jag f\u00f6rst noggrant och optimerar sedan stegvis. Jag uppn\u00e5r st\u00f6rst effekt med \u00e5teranv\u00e4ndning av anslutningar via Keep-Alive, HTTP\/2\/3 och pooler, kompletterat med f\u00f6rsiktiga sysctl-justeringar. Arkitektoniska st\u00f6d som ytterligare IP-adresser, proxyservrar och horisontell skalning f\u00f6rdelar anslutningsbelastningen effektivt. Kontinuerlig \u00f6vervakning, tydlig dokumentation och klara m\u00e5l s\u00e4kerst\u00e4ller konstanta latenser och tillg\u00e4ngliga portar. P\u00e5 s\u00e5 s\u00e4tt f\u00f6rblir webbservern responsiv \u00e4ven vid h\u00f6g trafik, samtidigt som TIME_WAIT fungerar p\u00e5 ett kontrollerat och f\u00f6ruts\u00e4gbart s\u00e4tt.<\/p>","protected":false},"excerpt":{"rendered":"<p>Uppt\u00e4ck hur du p\u00e5 ett s\u00e4kert s\u00e4tt kan optimera TCP:s time_wait p\u00e5 h\u00e5rt belastade webbservrar och undvika portutmattning genom m\u00e5linriktad Linux- och 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":"182","_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\/sv\/wp-json\/wp\/v2\/posts\/21215","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=21215"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/posts\/21215\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media\/21208"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/media?parent=21215"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/categories?post=21215"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/sv\/wp-json\/wp\/v2\/tags?post=21215"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}