Quali sono i segnali di avvertimento che indicano che un relay tunnel sta limitando la larghezza di banda?

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

What Are the Warning Signs That a Tunnel Relay Is Limiting Throughput? - Zima Store Online

Un relay probabilmente limita la velocità di trasmissione quando la connessione rimane instradata tramite relay e migliora notevolmente su un percorso diretto o più vicino, mentre entrambi gli endpoint rimangono sotto-utilizzati.

Le VPN overlay e i tunnel in uscita spesso ricorrono a un relay condiviso o self-hosted quando il NAT traversal non riesce a formare un percorso peer-to-peer. Il relay può preservare la connettività ma aggiunge un ulteriore segmento di rete, una coda, uno strato TCP o TLS, una deviazione geografica, un limite di equità e un punto di elaborazione. Una diagnosi affidabile confronta lo stato del relay, latenza, jitter, direzione, CPU degli endpoint e un controllo del percorso diretto invece di incolpare la crittografia o il NAS da una singola copia file lenta.

Confermare che il Percorso dei Dati sia Effettivamente Instradato Tramite Relay

Controlla lo stato del peer del client del tunnel mentre il traffico è attivo. Registra se il percorso è diretto, instradato tramite relay, proxy o se sta passando tra modalità diverse, oltre alla regione o host del relay selezionato.

Un problema di Tailscale documenta client cellulari che rimangono su DERP con latenza che varia da 200 a 900 millisecondi. Uno stato connesso quindi dimostra la raggiungibilità, non un percorso dati efficiente.

Se il client segnala connettività diretta durante tutto il test lento, non attribuire il problema al relay. Continua con test su CPU degli endpoint, offload del tunnel, MTU, upload ISP, Wi-Fi e storage.

Confrontare Percorsi Instradati Tramite Relay e Diretti con gli Stessi Endpoint

Esegui un test di throughput solo di rete tra lo stesso client e il server domestico mentre si usa il relay, poi ripeti dopo aver stabilito un percorso peer diretto o una rete di test temporanea con porta raggiungibile. Mantieni protocollo, direzione e hardware degli endpoint invariati.

Un caso pubblicato di peer-relay ha misurato sia una grande riduzione della latenza sia un incremento del throughput di 12,5 volte dopo aver cambiato solo la topologia del relay.

Un miglioramento grande e ripetibile dopo aver rimosso o spostato il relay è una forte evidenza. Un cambiamento piccolo significa che il relay potrebbe non essere il collo di bottiglia dominante, specialmente quando l’upload domestico o il Wi-Fi remoto già impongono un limite inferiore.

Attenzione a Latenza Elevata, Jitter e Deviazioni Geografiche

Misura la latenza minima, mediana e ai percentili alti verso il peer e verso la regione del relay. Registra jitter e perdita di pacchetti durante periodi di inattività e durante un trasferimento sostenuto.

Un rapporto diagnostico indipendente ha rilevato un percorso instradato tramite relay con latenza media superiore a 400 ms, jitter sostanziale e perdita di pacchetti misurabile, una combinazione che può far collassare i trasferimenti TCP di file e l’accesso interattivo anche quando il tunnel rimane stabilito.

Se il relay è geograficamente lontano da entrambi gli endpoint o la latenza varia molto sotto carico, prova una regione più vicina, un relay self-hosted o un peer relay. Una latenza stabile e bassa del relay con throughput scarso indica più probabilmente problemi di capacità, equità, CPU o comportamento del trasporto.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

Verifica se il Relay Ha un Soffitto di Throughput Costante

Esegui diversi trasferimenti grandi in momenti diversi e in entrambe le direzioni. Un limite del relay spesso appare come un plateau stabile che non aumenta quando la velocità di internet degli endpoint, lo storage NAS o il Wi-Fi del client migliorano.

Il lavoro di benchmark sulle implementazioni di relay mostra che la capacità di inoltro, l’efficienza della CPU e il carico concorrente influenzano materialmente il throughput del tunnel. Un progetto DERP-compatibile attuale pubblica benchmark multi-carico del relay su diverse dimensioni di CPU e livelli di traffico.

Se uno stream raggiunge un plateau, aggiungi un secondo stream controllato e osserva il throughput totale. Un soffitto condiviso fisso suggerisce capacità del relay o del percorso; un throughput basso invariato con CPU del relay inattiva suggerisce RTT, perdita, controllo della congestione o vincoli degli endpoint.

Separare i Limiti del Relay dalla CPU degli Endpoint e dall’Upload ISP

Monitora CPU, interruzioni software, uso del processo di crittografia, utilizzo della NIC e attività del disco su entrambi gli endpoint e sul relay self-hosted. Confronta la direzione lenta con la capacità di upload e download misurata della connessione domestica.

Un relay può inoltrare dati solo alla velocità della sua gamba più lenta in ingresso o uscita. Eseguire il relay su un VPS di fascia bassa, in una regione distante, in un container limitato o su un uplink domestico condiviso può riprodurre lo stesso sintomo di un limite di relay gestito.

Se la CPU dell’endpoint o del relay raggiunge la saturazione, ottimizza o aggiorna quel nodo prima di cambiare la geografia del relay. Se la CPU è bassa ma una direzione ISP è saturata, il relay sta esponendo il limite del collegamento di accesso piuttosto che crearlo.

Cambia il Design del Relay al Confine di Stop

Sostituisci il percorso del relay quando rimane selezionato per il traffico normale, crea latenza o jitter inaccettabili, limita il throughput sostenuto al di sotto del requisito del carico di lavoro e un controllo diretto o di relay più vicino dimostra che il resto del percorso può performare meglio.

La guida ZimaSpace alle alternative di accesso remoto CGNAT spiega perché un relay può essere necessario anche quando non è il percorso più veloce.

Scegli un peer relay più vicino, un VPS meglio posizionato, un NAT traversal migliorato o un flusso di lavoro a banda inferiore piuttosto che disabilitare l’unico percorso raggiungibile senza un sostituto. Valida il nuovo design con il carico di lavoro originale di file remoti, media o sincronizzazione, non solo con un ping breve.