Wat zijn de waarschuwingssignalen dat een tunnelrelay de doorvoersnelheid beperkt?

Een relay beperkt waarschijnlijk de doorvoersnelheid wanneer de verbinding via een relay verloopt en sterk verbetert bij een directe of dichtere route, terwijl beide eindpunten onderbenut blijven.

Overlay VPN's en uitgaande tunnels vallen vaak terug op een gedeelde of zelf-gehoste relay wanneer NAT-traversal geen peer-to-peer pad kan vormen. De relay kan de connectiviteit behouden, maar voegt een extra netwerksegment, wachtrij, TCP- of TLS-laag, geografische omweg, eerlijkheidslimiet en verwerkingspunt toe. Betrouwbare diagnose vergelijkt relaystatus, latentie, jitter, richting, CPU van het eindpunt en een direct-padcontrole in plaats van encryptie of de NAS de schuld te geven op basis van één trage bestandsoverdracht.

Bevestig dat het datapad daadwerkelijk via een relay verloopt

Controleer de peerstatus van de tunnelclient terwijl er verkeer actief is. Noteer of het pad direct, via relay, via proxy verloopt of wisselt tussen modi, plus de geselecteerde relayregio of host.

Een Tailscale-issue documenteert mobiele clients die op DERP blijven met latenties variërend van 200 tot 900 milliseconden. Een verbonden status bewijst dus bereikbaarheid, niet een efficiënt datapad.

Als de client tijdens de trage test directe connectiviteit rapporteert, wijs de relay dan niet aan als oorzaak. Ga door met testen van CPU van het eindpunt, tunnel offloads, MTU, ISP-upload, Wi-Fi en opslag.

Vergelijk gerelayde en directe paden met dezelfde eindpunten

Voer een netwerk-only doorvoertest uit tussen dezelfde client en thuisserver terwijl er een relay wordt gebruikt, en herhaal dit na het opzetten van een direct peerpad of een tijdelijk testnetwerk met bereikbare poorten. Houd protocol, richting en hardware van het eindpunt ongewijzigd.

Een gepubliceerde peer-relay case mat zowel een grote latentievermindering als een 12,5-voudige toename in doorvoersnelheid na alleen de relaytopologie te wijzigen.

Een grote en herhaalbare verbetering na het verwijderen of verplaatsen van de relay is sterk bewijs. Een kleine verandering betekent dat de relay mogelijk niet de dominante bottleneck is, vooral wanneer de upload van thuis of de Wi-Fi van de externe locatie al een lagere limiet stelt.

Let op hoge latentie, jitter en geografische omwegen

Meet minimale, mediane en hoge percentiel latentie naar de peer en naar de relayregio. Noteer jitter en pakketverlies tijdens inactiviteit en tijdens een langdurige overdracht.

Een onafhankelijk diagnostisch rapport registreerde een gerelayd pad met gemiddelde latentie boven 400 ms, aanzienlijke jitter en meetbaar pakketverlies, een combinatie die TCP-bestandsoverdrachten en interactieve toegang kan laten instorten, zelfs als de tunnel actief blijft.

Als de relay geografisch ver van beide eindpunten ligt of de latentie sterk schommelt onder belasting, test dan een dichterbij gelegen regio, zelf-gehoste relay of peer relay. Stabiele lage relaylatentie met slechte doorvoer wijst meer op capaciteit, eerlijkheid, CPU of transportgedrag.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Controleer of de relay een consistente doorvoersnelheidslimiet heeft

Voer meerdere grote overdrachten uit op verschillende tijdstippen en in beide richtingen. Een relaylimiet verschijnt vaak als een stabiel plateau dat niet stijgt wanneer de internetsnelheid van het eindpunt, NAS-opslag of Wi-Fi van de client verbetert.

Benchmarkwerk aan relay-implementaties toont aan dat doorvoercapaciteit, CPU-efficiëntie en gelijktijdige belasting de tunneldoorvoer aanzienlijk beïnvloeden. Een huidig DERP-compatibel project publiceert multi-load relay benchmarks over CPU-groottes en verkeersniveaus.

Als één stream een plateau bereikt, voeg dan een tweede gecontroleerde stream toe en observeer de totale doorvoer. Een vaste gedeelde limiet suggereert relay- of padcapaciteit; ongewijzigde lage doorvoer met een inactieve relay-CPU wijst op RTT, verlies, congestiecontrole of beperkingen van het eindpunt.

Maak onderscheid tussen relaylimieten en CPU van het eindpunt en ISP-upload

Monitor CPU, soft interrupts, gebruik van encryptieprocessen, NIC-utilisatie en schijfactiviteit bij beide eindpunten en de zelf-gehoste relay. Vergelijk de trage richting met de gemeten upload- en downloadsnelheid van de thuisverbinding.

Een relay kan alleen zo snel doorsturen als zijn traagste inkomende of uitgaande verbinding. Het draaien van de relay op een VPS van lage klasse, een verre regio, een beperkte container of gedeelde thuisupload kan hetzelfde symptoom veroorzaken als een beheerde relaylimiet.

Als de CPU van het eindpunt of de relay verzadigd raakt, optimaliseer of upgrade die node voordat je de relaylocatie wijzigt. Als de CPU laag is maar één ISP-richting vol zit, onthult de relay de toegangslinklimiet in plaats van deze te creëren.

Wijzig het relayontwerp bij de stopgrens

Vervang het relaypad wanneer het blijft geselecteerd voor normaal verkeer, onaanvaardbare latentie of jitter veroorzaakt, de doorvoersnelheid onder de werkbelastinglimiet houdt, en een directe of dichtere relaycontrole bewijst dat de rest van het pad beter kan presteren.

De ZimaSpace-gids over CGNAT remote-access alternatieven legt uit waarom een relay soms noodzakelijk is, zelfs als het niet het snelste pad is.

Kies een dichtere peer relay, beter gepositioneerde VPS, verbeterde NAT-traversal of een workflow met lagere bandbreedte in plaats van het enige bereikbare pad zonder vervanging uit te schakelen. Valideer het nieuwe ontwerp met de oorspronkelijke externe bestand-, media- of synchronisatiewerkbelasting, niet alleen met een korte ping.