Hopp til innhold
DDoS-beskyttelse · Peeryx · 15 Tbps+
Alle guider

Mål forsinkelse og pakketap gjennom DDoS-beskyttelsen

Ett ping er ikke nok til å vurdere et beskyttet spillnett. Opplevelsen påvirkes av ruter, pakketap, variasjon og belastningen på serveren. En nyttig sammenligning bruker samme mål og protokoll før og etter endringen og viser både metode og begrensninger.

← Alle guiderCubixServ

Før du begynner

Velg relevante operatørnett og den faktiske spilladressen og porten. Noter tidspunkt, protokoll, belastning og konfigurasjon. Bruk begrensede tester med tillatelse og behold rådata slik at resultatet kan kontrolleres.

RTT er en tur-retur-måling

RTT viser tiden frem og tilbake. Halvparten er ikke nødvendigvis den nøyaktige forsinkelsen én vei, siden rutene kan være forskjellige. Måling én vei krever blant annet egnet metode og synkroniserte klokker. Beskriv det som faktisk er målt, fremfor å vise presise tall som metoden ikke støtter.

Sammenlign flere prøver i stedet for det beste resultatet. Hold minimum, en sentral verdi og høye verdier ved siden av prøvetellingen. Variasjon og avbrudd kan bety mer enn en liten gjennomsnittlig forskjell. Separat nettverksforsinkelse fra spillets tid for å simulere og svare.

Mål fra nett spillerne bruker

Geografi alene sier ikke hvilken rute en operatør tar til Frankrike. Velg flere relevante nett og gjenta på ulike tidspunkt. Ta med mobilnett når de brukes av spillerne. Et raskt resultat innen samme nettverk er ikke en garanti for alle klienter i landet eller hos en annen operatør.

Par målinger med en vanlig tjenesteforbindelse. Hold nettverksstatistikk og kontekst i spillet når det er tilgjengelig. Mellomliggende utstyr kan begrense diagnostiske svar under videresending av trafikk; et stille traceroute-hopp alene beviser ikke tap når spilleren.

Sammenlign like vilkår

Bruk samme adresse, protokoll, pakkestørrelse og varighet før og etter. Noter serverlast og testtidspunkt. Medianen og spredningen er mer informative enn det beste enkeltresultatet. En opptatt klient, lokal Wi-Fi-feil eller midlertidig omvei må ikke uten videre tilskrives DDoS-beskyttelsen; gjenta først den samme målingen under kontrollerte forhold.

Behold rå resultater og feil i stedet for å velge gunstige verdier. Inkluder antall forsøk og observasjonsperiode. En kort grunnlinje viser atferd på det tidspunktet; det er ikke en permanent ventetid eller tilgjengelighetsgaranti.

Ta med tap og topper

Et lavt gjennomsnitt kan skjule perioder med pakketap eller store forsinkelser. Vis antall prøver, median, høye percentiler og tapsandel. Undersøk avvik uten å slette dem for å pynte resultatet. Sammenhold hendelser med CPU, nettverkskøer og klientens forbindelse for å skille ulike mulige årsaker til hakkete spilling.

For tunneler, undersøk også MTU og symptomer som involverer pakkestørrelse. For proxyer, sjekk tidsavbrudd og nedstrømstilkoblinger. Ikke skift flere komponenter samtidig. Bekreft legitim trafikk før du fjerner en regel som bidrar til beskyttelse.

Test spillets faktiske forbindelse

ICMP eller TCP 443 bekrefter ikke spillets UDP-vei. Bruk riktig klient og port og tillatte protokolltester. Tolke traceroute med forsiktighet: mellomrutere kan begrense kontrollsvar selv om de videresender vanlig trafikk. En stille mellomruter er derfor ikke alene bevis på at den taper spillets pakker; undersøk sluttdestinasjonen også.

Der det finnes et kompatibelt verktøy, profiler under nedgangen. Papers spark-rapporter kan identifisere dyrt arbeid. Bundet mål og kopikonfigurasjon før du gjør endringer. Kjøp flere ressurser bare når en observert begrensning rettferdiggjør det.

Publiser avgrensede resultater

Oppgi dato, mål, kildenett, protokoll og antall prøver hvis målinger brukes på en tilbudsside. Skill normaldrift fra dokumentert drift under angrep. Gjenta etter ruteendringer og ta vedvarende avvik opp med operatøren. Et syntetisk testresultat beskriver sine egne vilkår, ikke alle fremtidige spillerforbindelser eller en garantert latency.

Etter en fiksering, gjenta samme metode og kontroller en normal økt. En forbedret prøve fastslår ikke at alle stier er faste. Beskriv målte markeder og forbindelser uten å love ventetid for et helt land eller forveksle geografisk nærhet med rutingkvalitet.

Hva bør du gjøre i din situasjon?

SituasjonNeste steg
Medianen øker etter endringGjenta samme test og kontroller ruten før neste justering.
Spillet hakker med godt gjennomsnittUndersøk pakketap, topper og serverbelastning i samme tidsrom.
Resultater varierer sterkt i ett landDel opp etter operatør og etterprøv avvikende nettveier.

Offisielle kilder

Kildene beskriver protokoller og innstillinger. Kontroller dokumentasjonen for versjonen du bruker.

  1. RFC Editor / IETF/rfc/rfc7679
  2. RFC Editor / IETF/rfc/rfc2680
  3. RFC Editor / IETF/rfc/rfc8899
  4. PaperMC/paper/profiling/