Hvis du krangler med ham hver dag Lag, hakking og høy pingDu er ikke alene. Bak den dårlige opplevelsen med å spille på nett, foreta videosamtaler eller jobbe eksternt, ligger det en veldig klar synder: kombinasjonen av hjemmenettverket ditt og hvordan TCP/IP-protokollen er konfigurert på enhetene og serverne dine.
Optimaliser TCP/IP for redusere forsinkelse Det handler ikke bare om å finjustere et par «magiske» innstillinger. Du må forstå hvordan konsepter som ... fungerer. MTU, MSS, TCP-vindu, latens eller bufferbloatOg deretter kan du bruke spesifikke endringer på PC-en, ruteren, Wi-Fi-nettverket og til og med skyservere eller virtuelle maskiner. La oss se på det trinn for trinn, men med en praktisk tankegang: hva hver ting er, og hva du kan gjøre for at forbindelsen din skal reagere raskere.
Viktige TCP/IP-konsepter som påvirker forsinkelser
For å få mest mulig ut av forbindelsen din, er det nyttig å forstå et par ting. grunnleggende TCP/IP-parametere som direkte påvirker ping, stabilitet og ytelse i spill, videosamtaler eller ekstern tilgang.
MTU, fragmentering og LSO
La MTU (Maximum Transmission Unit) Dette er den maksimale størrelsen, i byte, på pakken som kan forlate et nettverksgrensesnitt uten å bli fragmentert. I de aller fleste Ethernet-nettverk (og i virtuelle maskiner på Azure eller Google Cloud) er standardverdien 1500 byte, som inkluderer nettverksoverskrifter og data.
Når en pakke overstiger den MTU-en, deler IP-laget den opp i flere mindre fragmenter. IP-fragmentering Dette innebærer mer CPU- og minnearbeid, både på maskinen som fragmenterer dataene og på den som setter sammen fragmentene igjen ved ankomst. Dette introduserer ekstra ventetid og ytelsestap, spesielt under mye trafikk.
I tillegg er det den berømte biten «Ikke fragmenter» (DF) i IP-headeren. Hvis den er aktivert, og en mellomliggende ruter mottar en pakke som er større enn MTU-en sin, forkaster den den og sender tilbake en ICMP-melding om at fragmentering er nødvendig. Dette brukes i MTU-rutedeteksjon (PMTUD)Men hvis en brannmur blokkerer disse ICMP-pakkene, vil avsenderen fortsette å prøve å sende for store pakker, noe som forårsaker forsinkelser og resendinger.
I miljøer som Azure eller Google Cloud har fragmenterte pakker også en tendens til å miste fordelene med akselererte nettverkSR-IOV og SmartNIC-er. De behandles via hypervisorens langsomme rute, med mer rystelsedårligere latens og færre pakker per sekund. Derfor er den generelle anbefalingen Unngå fragmentering ved å justere MTU og MSS riktig og ikke blåse opp MTU-en for mye hvis det er brannmurer eller VPN-er imellom.
På den annen side, funksjonen Large Send Offload (LSO) Dette gjør at operativsystemets TCP/IP-stabel kan generere store «superpakker», som deretter fragmenteres internt av nettverkskortet i henhold til MTU. Dette reduserer CPU-belastningen betydelig, selv om du i trafikkregistreringer kan se tilsynelatende enorme rammer som ikke indikerer fragmentering på nettverket, men snarere at fragmenteringen skjer i selve adapteren.
MSS, PMTUD og VPN
El TCP MSS (maksimal segmentstørrelse) Dette definerer hvor mange byte med brukbare data som får plass i hvert TCP-segment, unntatt IP- og TCP-overskrifter. Vanligvis beregner systemer MSS som:
MSS = MTU - (tamaño cabecera IP + tamaño cabecera TCP)
Med en MTU på 1500 og IPv4+TCP-headere på 20+20 byte, er den typiske MSS 1460 bytesDenne verdien forhandles under TCP-treveishåndtrykket, og hver ende foreslår sin egen. Forbindelsen bruker den laveste av de to.
Det kan imidlertid være enheter underveis (brannmurer, rutere, VPN-gatewayerosv.) med en mindre MTU som effektivt tvinger frem en reduksjon i MSS. Det er her Sti MTU-oppdagelse (PMTUD)Når en ruter ikke kan videresende en pakke fordi den er for stor og har DF-biten satt, dropper den den og sender en ICMP-melding «Fragmentation Needed» som indikerer den maksimale MTU-en den støtter, slik at kilden reduserer størrelsen.
Hvis disse ICMP-pakkene blokkeres, går forbindelsen inn i en løkke med videresending og tap, noe som resulterer i Lag, resendinger og uendelige lastetiderDerfor er det ikke alltid en god idé å lett øke MTU-en på datamaskiner eller virtuelle maskiner uten å sjekke hele banen eller brannmurpolicyen.
På sosiale medier med IPsec VPN eller andre tunneler, reduserer de ekstra overskriftene plassen som er tilgjengelig for data, så mindre MTU og MSS anbefales (f.eks. MTU 1400 og MSS ~1350 i typiske tunneler) for å unngå tunnelfragmentering og tilhørende forsinkelser.
Latens-, RTT- og TCP-vindu
Den berømte «pingen» er ikke noe mer enn tur-retur-forsinkelse (RTT) mellom to punkter. På et fysisk nivå er det begrenset av lysets forplantningshastighet i fiber (omtrent 200 km per millisekund) og av den faktiske banen dataene følger. Det er sjelden en rett linje.
I TCP bestemmes den maksimale teoretiske gjennomstrømningen for en enkelt forbindelse av denne grunnleggende formelen:
rendimiento máximo ≈ tamaño de ventana TCP / RTT
La TCP-vindu Dette er mengden data en avsender kan ha "underveis" uten å ha mottatt en bekreftelse (ACK). Med et vindu på 65 535 byte og en MSS på 1460, kan bare omtrent 45 pakker sendes før man venter på en ACK. Hvis RTT-en er høy (for eksempel 80–160 ms mellom kontinenter), er det uskalerte vinduet langt fra i stand til å utnytte høykapasitetskoblinger.
Som standard er vindusfeltet i TCP-headeren 16 bits, noe som begrenser den maksimale verdien til 65 535 byte. For moderne nettverk er dette latterlig, så for mange år siden ble [manglende informasjon - sannsynligvis en spesifikk funksjon eller metode] introdusert. TCP-vinduskalering, som bruker en multiplikasjonsfaktor 2^na på den verdien og tillater vinduer på hundrevis av MB eller til og med GB.
I systemer som Windows eller Linux administreres vindusskalering automatisk med forhåndsdefinerte innstillinger (autojustering), og kan vises eller endres ved hjelp av kommandoer som Get-NetTCPSetting o sysctlMer aggressive nivåer (f.eks. «eksperimentelle») tillater gigantiske vinduer og kan forbedre ytelsen betraktelig på langdistansenettverk, forutsatt at det ikke er for mye pakketap.
Akselererte nettverk, RSS og GRO/TSO
På skyplattformer (Azure, Google Cloud osv.) er tradisjonelle nettverksgrensesnitt i stor grad avhengige av verts-CPU-en for å behandle hver pakke, anvende regler, innkapsle og dekapsulere. Dette resulterer i en brutal belastning på hypervisoren når det er mye trafikk og det genererer ustabil latens.
Derfor er den såkalte akselererte nettverkDisse er basert på teknologier som SR-IOV og SmartNIC-kort med FPGA-er. Tanken er at en betydelig del av den programvaredefinerte nettverksstakken kjører på NIC-maskinvaren, og datatrafikk kan gå praktisk talt direkte fra den virtuelle maskinen til kortet, og omgå vertens virtuelle svitsj.
Dette gir flere fordel:
- Mindre ventetid, mer PPS.
- Mindre jitter
- Lavere CPU-forbruk på verten og i den virtuelle maskinen.
Det finnes imidlertid viktige detaljer. For eksempel behandler ikke mange akselererte nettverkssystemer fragmenterte pakker via den raske ruten. Hvis det er IP-fragmentering, blir den trafikken rutet via den langsomme ruten, med den påfølgende effekten på ytelsen.
På siden av gjesteoperativsystemet er det viktig å ha teknologier som aktivert. Motta sideskalering (RSS)som distribuerer behandlingen av innkommende pakker på tvers av flere CPU-kjerner, og segmenterings- og aggregeringsnedlastinger som TSO (Transmit Segmentation Offload) og GRO/LRO (Generic Receive Offload)noe som reduserer antallet pakker som CPU-en må håndtere direkte.
TIME_WAIT og gjenbruk av sokkel
En annen mindre kjent, men viktig TCP-ytelsesfaktor er tilstand VENTETIDNår en TCP-tilkobling lukkes normalt, går endepunktet som sender den siste ACK inn i TIME_WAIT i titalls eller til og med hundrevis av sekunder. I løpet av denne tiden holder systemet sokkelen reservert for å sikre at forsinkede pakker fra den gamle tilkoblingen ikke dukker opp igjen og blir forvekslet med en ny økt.
På servere eller maskiner som brukes mye er det lett å samle seg tusenvis eller titusenvis av stikkontakter i TIME_WAITDette kan uttømme utvalget av kortvarige porter og forårsake feil når nye tilkoblinger åpnes. Derfor lar mange systemer deg justere både TIME_WAIT-varigheten og portområdet, samt visse gjenbrukspolicyer.
En mer aggressiv teknikk, støttet av noen kjerner (for eksempel Windows Server på Azure), kalles TIME_WAIT attentatHvis en ny SYN ankommer med et sekvensnummer som er betydelig høyere enn den gamle tilkoblingen, kan systemet tvinge sokkelen til å lukkes under TIME_WAIT og godta den nye tilkoblingen umiddelbart. Dette øker skalerbarheten, men hvis den er feilkonfigurert, kan det forårsake interoperabilitetsproblemer med visse mer konservative TCP-stabler.
Hvorfor ping er så viktig i hverdagen din
Utover teorien har latens en direkte innvirkning på nesten alt vi gjør på nettet i dag. Det er ikke nok å bare "ha 600 Mbps"; hvis responsen er treg, lider opplevelsen. La oss se på noen tilfeller der en En "anstendig" ping utgjør hele forskjellen.
Online spill og "spillbare" pingnivåer
I konkurransespill teller hvert millisekund. ping under 20 ms Det er praktisk talt ideelt: handlinger registreres nesten i sanntid, og du vil knapt merke noen forsinkelse. Mellom 20 og 50 ms forblir opplevelsen veldig god. Når du går opp til 50–100 ms, kan du merke en liten desynkronisering, spesielt hvis du spiller på eksterne servere.
Fra 100-300 ms Alvorlige problemer begynner: skudd som kommer sent, bevegelser du ser med forsinkelse, biler som "spretter" i et racingspill, osv. Over 300 ms blir spillet mer av en tortur enn noe annet, spesielt i skytespill, racingspill eller sportsspill.
Spilltypen har også stor innflytelse. FPS- og racingspill Det er praktisk talt obligatorisk å ha mindre enn 50 ms for å konkurrere; i online sportstitler er det også ønskelig å holde seg under 30–40 ms. Imidlertid, i MMO-er eller turbaserte strategispillDu kan «overleve» med pings på 150–200 ms uten å forstyrre spillingen, selv om opplevelsen aldri vil bli like jevn. Hvis du spiller på Windows, kan det være interessant å lære hvordan. Reduser inputforsinkelse i Windows 11 for å forbedre responsen i konkurransespill.
Videosamtaler, skjermdeling og VoIP-samtaler
I videosamtaler med Zoom, Teams, Skype eller lignende plattformer er ping også avgjørende. Ideelt sett bør den sveve rundt... 20-40 msder samtalen flyter naturlig, uten overlapping. De fleste brukere tolererer opptil omtrent 100 ms, selv om små forsinkelser allerede er merkbare når man snakker.
Når pingen overstiger 100 msDu begynner utilsiktet å avbryte den andre personen. Svarene kommer med et midlertidig «ekko», og pinlige stillheter blir hyppige. Hvis forbindelsen i tillegg har begrenset båndbredde eller Wi-Fi-en er dårlig, legges det til bilde- og lydbrudd.
med skjermdeling eller fjernkontroll Effekten er lik. Hvert klikk og hver musebevegelse tar tid å registrere seg på skjermen til den eksterne enheten. Med høye pings føles det som om datamaskinen er treg. Dette er utrolig frustrerende for alle som prøver å jobbe produktivt.
Tingenes internett, hjemmeautomasjon og fjernarbeid
I økosystemet til IoT og smarte enheter (høyttalere, lyspærer, kameraer, plugger, roboter, dyrematere osv.), spiller også forsinkelse en nøkkelrolle. Selv om det ikke er dramatisk å slå på et lys med en forsinkelse på 500 ms, blir det veldig merkbart når du kjeder sammen mange handlinger eller samhandler med stemmen (Alexa, Google Assistant).
Når man jobber eksternt, gjør det å få tilgang til eksterne skrivebord, servere eller skyapplikasjoner med konstant forsinkelse enhver oppgave kjedelig. Mange tror det er «mangel på hastighet», når det i virkeligheten er en høy og/eller svært variabel latens (jitter) forårsaket av mettet WiFi, krasjede rutere eller dårlige ruter til serveren.
Latens og sikkerhet: indirekte innvirkning
Høy latens i seg selv innebærer ikke en direkte sikkerhetsrisikoDet kan imidlertid ha bivirkninger. Hvis overvåkingssystemer, IDS eller brannmurer mottar informasjon for sent, kan de reagere for sent på et angrep eller til og med gå glipp av kritiske hendelser.
Når brukere blir desperate over forsinkelser, har de en tendens til å «omgå» sikkerhetskontroller: De deaktiverer brannmuren, avinstallerer antivirusprogrammet eller åpner porter på måfå. på ruteren for å prøve å gjøre den «raskere». Det er her en dårlig nettverksopplevelse kan ende opp med å åpne unødvendige dører for reelle trusler.
Hovedårsaker til høy latens i hjemmenettverk
Pingen du ser i et spill eller en hastighetstest er summen av mange faktorer: operatør, internettrute, destinasjonsserver ... men hjemme er det en god del typiske problemer som du kan kontrollere selv.
Dårlig WiFi-dekning og forstyrrelser
De fleste av oss kobler oss nå nesten utelukkende til via Wi-Fi, og det er der problemene begynner. svakt eller interferensfylt signal Det reduserer ikke bare hastigheten, men øker også latens og jitter fordi enheter må sende pakker på nytt, senke moduleringen, vente på at kanalen skal bli ledig osv.
Hvis du er langt fra ruteren, bak flere vegger, eller omgitt av nærliggende nettverk på samme kanal, vil pingen din bli dårligere. Dessuten, jo flere klienter som er koblet til et tilgangspunkt, desto lengre ventetid blir det for at hver enkelt skal «ta sin tur» til å kommunisere. Og trege klienter påvirker de andre negativt. Finn ut hvor mange enheter som er på WiFi-nettverket ditt å identifisere problemkunder.
Slike funksjoner er ganske nyttige her airtime rettferdighetsom fordeler sendetid mellom enheter slik at tregere enheter ikke monopoliserer radioen. Likevel, bruk [alternativet] når det er mulig for spilling og arbeid fra en fasttelefon. Ethernet-kabel og la WiFi-en være til alle andre.
Utdatert eller overbelastet ruter
En gammel ruter med utdatert fastvare eller svært grunnleggende maskinvare kan bli en betydelig flaskehals. Når ruterens prosessor er overbelastet og administrerer NAT, brannmur, QoS og P2P-trafikk, køforsinkelse og bufferbloatPakkene samler seg i en gigantisk buffer og sendes ut med en betydelig forsinkelse, noe som ødelegger pingen.
Oppdater fastvaren, deaktiver unødvendige funksjoner, og be om nødvendig operatøren din om en erstatningsenhet eller kjøp en ny. kraftigste nøytrale ruteren Det markerer ofte et vendepunkt. Det er også lurt å starte det på nytt av og til for å fjerne minnetilstander og potensielle lekkasjer.
Nedlastinger og andre enheter som bruker båndbredde
Hvis nettverket ditt har flere enheter som laster ned mye (P2P, oppdateringer, 4K-strømming, sikkerhetskopier i skyen), er det normalt at ping-toppene dineProblemet er ikke så mye at «megabytene går tom», men hvordan ruteren håndterer utgående køer.
Løsningen innebærer to veier:
- På den ene siden bedre kontroll over hva som lastes ned i bakgrunnen (PC, mobiler, konsoller, NAS…).
- På den annen side, aktiver og juster riktig QoS og anti-bufferbloat fra ruteren slik at interaktiv trafikk (spill, VoIP, videosamtaler) prioriteres over massive nedlastinger.
VPN, proxy, brannmur og bakgrunnsprogrammer
Las VPN De er veldig nyttige for å kryptere trafikk eller omgå geobegrensninger, men de legger nesten alltid til latens fordi forbindelsen din går gjennom en mellomliggende server. Hvis VPN-et er gratis eller av dårlig kvalitet, kan det være direkte dødelig for ping. Det samme gjelder for visse fullmakter.
Brannmurer, både på PC-en og ruteren, legger også til litt ventetid ved å inspisere hver pakke, og hvis de er feilkonfigurert, kan de redusere hastigheten på forbindelsen betraktelig. I tillegg til det... bakgrunnsprosesser (Windows-oppdateringer, skyklienter, nedlasting av spilloppdateringer osv.) som bruker opp båndbredde uten at du engang merker det.
Skadevare og kompromitterte enheter
En datamaskin infisert med skadelig programvare kan generere skjult trafikk (spam, DDoS-angrep, mining, datanedlastinger) eller bruke mye CPU- og diskressurser, noe som påvirker tilkoblingskvaliteten. Hvis du legger merke til at Alt er tregt, og pingen øker uten noen åpenbar grunn.Det anbefales å kjøre en grundig skanning med et pålitelig antivirusprogram på alle enheter. I tillegg anbefales det å følge beste praksis for opprettholde en sunn nettverksinfrastruktur og unngå kompromittert utstyr.
Verktøy for å måle latens og oppdage problemer
Før du endrer noe, er det viktig å ta nøyaktige målinger. Ikke stol utelukkende på nettleserens hastighetstest: det finnes spesifikke verktøy som kan hjelpe deg med å finne ut hvor pingen din skyter i været og om problemet ligger hos det lokale nettverket, internettleverandøren eller destinasjonsserveren.
Grunnleggende ping og traceroute
Nytte pingDette er utgangspunktet, og finnes i alle operativsystemer. Med en enkel ping 8.8.8.8 (For eksempel) kan du se gjennomsnittlig, minimum og maksimum latens til en bestemt destinasjon og om det er pakketap. Hvis du pinger ruterens gateway, får du latensen til det lokale nettverket ditt.
Hvis du legger til en -t på Windows (ping 8.8.8.8 -tDu kan la den kjøre for å se om det er noen topper, frafall eller jitter. Og med traceroute/tracert Du sjekker hvilke hopp pakkene dine går gjennom, og på hvilket tidspunkt latensen mistenkelig begynner å øke.
Avanserte verktøy: WinMTR, PingPlotter og andre
Programmer som WinMTR De kombinerer traceroute og kontinuerlig ping, og viser prosentandelen signaltap og minimum, gjennomsnittlig og maksimum responstid for hvert hopp. De er svært nyttige for å identifisere om problemet ligger hos internettleverandørens første hopp, en mellomliggende stamnett eller selve spillserveren.
Andre verktøy som f.eks. NetworkLatencyView (NirSoft) måler den faktiske latensen til TCP-tilkoblinger som åpnes av PC-en din. Det finnes også pakker som NetScan-verktøy Inkluderer grafisk ping, portskanner, traceroute og DNS. Alt i ett.
Mål ping på mobil: apper for Android og iOS
På smarttelefoner og nettbrett kan du også måle latens ved hjelp av apper som Fing, He.net nettverksverktøy, NetX eller spesifikke pingverktøy på iOS. Disse er perfekte for å sjekke om problemet er med et bestemt roms Wi-Fi, mobilnettverket eller om selve fasttelefonen gir dårlig kvalitet.
Avansert TCP/IP-optimalisering på servere og i skyen
Hvis du administrerer servere, virtuelle skymaskiner eller krevende webprosjekter, finnes det mange flere TCP/IP- og kjerneparametere du kan justere. lavere latens og økt ytelse. Spesielt på høyhastighetsnettverk.
Kjerne- og TCP-stakkinnstillinger i Linux
På Linux, ved bruk av sysctl og verktøy som tc o ethtool Du kan bruke avanserte optimaliseringer som:
- Senk minimum RTO (
net.ipv4.tcp_rto_min_us) til sikre verdier som 5000 µs (5 ms) på interne nettverk med lav latens. For å gjenopprette raskere etter pakketap. - Aktiver Rettferdig kø (FQ) med
tc qdisc replace dev <iface> root fq.For å bedre fordele båndbredden mellom flyter og unngå for store utbrudd fra en enkelt tilkobling. - Deaktiver treg start etter inaktivitet (
net.ipv4.tcp_slow_start_after_idle=0) på servere som bruker vedvarende tilkoblinger. Slik at de ikke starter på nytt fra en latterlig lav båndbredde hver gang de våkner fra hvilemodus. - Deaktiver den problematiske delen av HyStart (ACK-togdeteksjon) i Cubic TCP. For å forhindre at falske positiver om overbelastning bremser vindusveksten.
- Øk TCP-buffere (
tcp_rmem, tcp_wmem, rmem_max, wmem_max). for å kunne opprettholde høy gjennomstrømning på lenker med høy RTT, og forhindre at sokkeler går tom for minne. - Grense
tcp_notsent_lowatDette forhindrer at for mye usendte data samler seg i kjernen, og beskytter dermed systemet mot overdrevent minneforbruk. - aktiver maskinvare GRO/LRO på kompatible nettverkskort (
ethtool -K <iface> rx-gro-hw on). For å gruppere pakker og redusere CPU-belastningen per avbrudd.
store MTU-er og høyytelsesnettverk
I interne skynettverk (f.eks. Google Cloud VPC-er) der det gis støtte jumbo MTU opptil ~8900 byteDet anbefales på det sterkeste å øke MTU (for eksempel til omtrent 4082 byte kompatibelt med 4 KB minnesider) for å redusere antall pakker som behandles per sekund og forbedre CPU-effektiviteten.
Du må imidlertid være forsiktig med trafikk som går ut til Internett eller passerer gjennom VPN-er: i så fall er det best å enten opprettholde en standard MTU på 1500 eller justere den per rute (ip route change med mtu y advmss) slik at ekstern kommunikasjon ikke blir fragmentert eller mistet på grunn av for store pakker.
Webservere, HTTP/2/3 og mellomlagring
På webservere (Nginx, Apache osv.) kan du, i tillegg til å finjustere TCP, redusere opplevd latens betraktelig ved å aktivere HTTP/2 og HTTP/3 (QUIC)som tillater multipleksing av flere forespørsler over en enkelt tilkobling og reduserer kostnadene for håndtrykk.
Aktivering GZIP-komprimering eller Brotli, bruk minnebuffer (Redis, Memcached), minimere CSS/JS og servere statisk innhold gjennom en CDN med nærliggende tilstedeværelsespunkter til brukeren. Hvert millisekund du sparer i TTFB (Time To First Byte) og nettverks-RTT oversettes til et nettsted som reagerer «raskere» i den besøkendes øyne.
Kontinuerlig overvåking og latensmålinger
Til slutt, hvis du tar ytelse på alvor, må du måle den kontinuerlig. Verktøy som ApacheBench, wrk, JMeter eller observasjonspakker (Prometheus + Grafana, New Relic, Datadog…) lar deg overvåke RTT, TTFB, latenspersentiler, gjennomstrømning og feilrate under belastning.
Å sette opp varsler når TTFB overskrider visse terskler, når intern ping mellom tjenester øker, eller når pakketap øker, bidrar til å proaktivt oppdage nettverksproblemer, CPU-metning, ruteendringer eller flaskehalser før forsinkelser når sluttbrukeren.
Med alle disse konseptene og innstillingene på bordet, fra MTU og MSS til ruter QoS, akselererte skynettverk og webserverkonfigurasjon, er det tydelig at forsinkelser ikke er et resultat av én enkelt magisk faktor. Det er summen av mange nettverkskomponenter og TCP/IP i seg selv som, når de er riktig innstilt, lar spill, videosamtaler, fjernarbeid og nettsteder reagere med den responsiviteten. følelse av umiddelbarhet som vi alle søker, og som ofte oppnås mer ved å justere og forstå nettverket enn ved å bare kontrahere «flere megabyte».
