Perché la perdita di pacchetti rallenta un collegamento di un server domestico altrimenti veloce?

La perdita di pacchetti rallenta un collegamento home server altrimenti veloce perché la velocità del collegamento misura quanto rapidamente l'interfaccia può trasmettere bit, mentre il throughput utile dipende da quanti dati applicativi arrivano correttamente e da come il protocollo di trasporto reagisce quando i pacchetti scompaiono.

I trasporti affidabili ripetono i dati mancanti e di solito riducono la loro velocità di invio perché la perdita può segnalare congestione. Un'interfaccia 1GbE o 10GbE può quindi rimanere completamente negoziata mentre una copia di file, un backup remoto, una sessione web o uno stream multimediale forniscono solo una frazione delle prestazioni utili attese.

Perché la velocità del collegamento può rimanere alta mentre il throughput utile cala?

La larghezza di banda è la capacità nominale del percorso, mentre il goodput conta solo il carico utile applicativo consegnato con successo. In un esperimento controllato sulla qualità del percorso, il throughput utile può crollare prima che la velocità del collegamento cambi perché anche un piccolo tasso di perdita interrompe ripetutamente il flusso di trasporto.

I byte ritrasmessi, i dati duplicati, le intestazioni e i gap di recupero consumano tempo senza far avanzare il file completato o la risposta dell'applicazione. I contatori dell'interfaccia possono comunque mostrare traffico sostanziale anche quando il ricevitore riceve dati utili lentamente.

Un test di velocità può anche nascondere il problema usando diversi flussi paralleli, un server vicino o un intervallo di test breve. Un singolo trasferimento a lungo termine verso un endpoint distante è più esposto a perdite ripetute e recupero del round-trip.

Quale lavoro ripete il trasporto affidabile dopo una perdita?

TCP e i flussi affidabili QUIC tengono traccia dei dati che hanno raggiunto il ricevitore. Quando viene rilevato un gap, i dati persi devono essere trasmessi nuovamente, consumando larghezza di banda aggiuntiva e ritardando il completamento.

Il mittente può rilevare la perdita tramite riconoscimenti duplicati, riconoscimenti selettivi, un timer di perdita QUIC o un timeout di ritrasmissione. Una rilevazione rapida limita la pausa, mentre un timeout può aggiungere un ritardo molto più lungo prima che il mittente riprovi.

La ritrasmissione non sostituisce semplicemente un pacchetto mancante in isolamento. Il pacchetto originale ha già utilizzato la capacità del collegamento, la sostituzione la utilizza di nuovo, e pacchetti vicini possono essere anch'essi ritrasmessi quando il mittente non riesce a identificare con precisione la perdita.

Perché TCP riduce la sua velocità di invio dopo la perdita di pacchetti?

Il TCP classico tratta la perdita come prova che troppi dati potrebbero entrare nel percorso. il controllo della congestione basato sulla perdita riduce la velocità di invio così il mittente smette di alimentare un possibile collo di bottiglia al tasso precedente.

La finestra di congestione controlla quanta quantità di dati non riconosciuti può rimanere in volo. Ridurre quella finestra può diminuire la velocità molto più della percentuale di pacchetti effettivamente persi, perché il mittente deve poi far crescere di nuovo la finestra nei successivi round di riconoscimento.

Algoritmi diversi reagiscono in modo diverso: Reno, CUBIC, varianti BBR e implementazioni QUIC non usano segnali o riduzioni identiche. Il limite generale rimane che un collegamento fisico veloce non può erogare la sua capacità quando il trasporto limita deliberatamente i dati in volo.

Come il round-trip time amplifica il recupero dalla perdita?

Un mittente apprende della consegna tramite feedback che viaggia dal ricevitore e ritorna. un RTT più alto allunga ogni ciclo di recupero perché ogni aggiustamento della finestra e conferma di ritrasmissione consuma un'altra porzione del RTT.

Su un percorso Ethernet locale breve, una ritrasmissione veloce può completarsi abbastanza rapidamente da essere quasi impercettibile. La stessa perdita su una VPN, backup remoto, montaggio cloud o connessione transcontinentale può bloccare il progresso per decine o centinaia di millisecondi.

L'alta larghezza di banda rende la penalità più sorprendente perché più dati potrebbero essere stati in transito durante ogni round trip. La perdita svuota o riduce quella pipeline, e un percorso più lungo richiede più tempo per riempirla di nuovo.

Perché un pacchetto mancante può ritardare dati già arrivati?

TCP presenta un flusso di byte ordinato all'applicazione. un segmento mancante può bloccare dati successivi anche quando i pacchetti successivi sono già arrivati al ricevitore.

Quei byte successivi possono attendere in un buffer di ricezione finché il gap non viene riparato. Per HTTP/2, diverse richieste logiche condividono una connessione TCP, quindi una perdita a livello di trasporto può ritardare flussi di risposta altrimenti indipendenti trasportati dietro i byte mancanti.

QUIC evita il blocco in testa alla linea di trasporto tra flussi perché i flussi possono recuperare indipendentemente, ma la perdita consuma comunque capacità di ritrasmissione e budget di controllo della congestione. Rimuovere un meccanismo di stallo non rende gratuiti i pacchetti persi.

Perché i trasferimenti di file, i flussi e le app UDP falliscono in modo diverso?

TCP e UDP espongono la perdita in modo diverso. Un trasferimento file attende i byte esatti, mentre una chiamata live può preferire un frame danneggiato o saltato piuttosto che attendere dati già troppo tardivi per essere riprodotti.

La perdita TCP appare come throughput inferiore, buffering o completamento ritardato di pagine e file. La perdita UDP può apparire come interruzioni audio, artefatti a blocchi, jitter di controllo, telemetria persa o ritentativi a livello applicativo, a seconda della correzione d'errore in avanti e del design del recupero.

Il traffico locale e internet può condividere un collo di bottiglia. Per questo motivo la perdita di pacchetti deve essere interpretata in base al percorso e al carico di lavoro: una copia pulita in LAN non dimostra che il percorso remoto sia pulito, e un'interfaccia veloce non garantisce una consegna affidabile dell'applicazione.

Domande frequenti

Una perdita dell'1% di pacchetti può davvero causare una riduzione molto maggiore della velocità?

Sì in alcune condizioni, specialmente per un flusso TCP con RTT significativo. L'impatto esatto dipende dall'algoritmo di controllo della congestione, schema di perdita, RTT, dimensione della finestra, flussi paralleli e funzionalità di recupero.

La perdita di pacchetti significa sempre che la rete è congestionata?

No. La congestione è comune, ma la perdita può anche derivare da interferenze Wi-Fi, cavi danneggiati, ottiche difettose, host sovraccarichi, schede di rete difettose, problemi MTU o limiti di software e driver.

Perché un test di velocità parallelo può sembrare normale?

Più flussi si recuperano indipendentemente e possono collettivamente saturare il collegamento anche quando ogni flusso funziona male. Una singola connessione applicativa potrebbe non ricevere lo stesso beneficio.

UDP evita il costo in termini di prestazioni della perdita di pacchetti?

UDP evita la ritrasmissione incorporata e la consegna ordinata, ma l'applicazione perde dati o deve aggiungere un proprio meccanismo di recupero, occultamento, ridondanza o ritentativo.

Conclusione finale

La perdita di pacchetti trasforma un collegamento veloce in un percorso applicativo lento sprecando capacità di trasmissione, costringendo a un recupero affidabile, riducendo le finestre di congestione e ritardando la consegna ordinata. L'interfaccia fisica può rimanere a piena velocità mentre i dati utili arrivano lentamente. RTT, protocollo di trasporto, schema di perdita e carico di lavoro determinano se il risultato appare come bassa velocità, buffering, latenza a coda lunga o mancanza di media in tempo reale.