Il calcolo delle prestazioni reali di una connessione di rete richiede un'analisi che va ben oltre la semplice velocità nominale del proprio abbonamento. Quando si trasferiscono dati attraverso un singolo flusso TCP, entrano in gioco vincoli fisici e di protocollo come la latenza, la dimensione dei buffer di ricezione e la perdita di pacchetti. Il Network Latency Bandwidth Calculator consente di calcolare il limite massimo teorico e pratico di una trasmissione TCP in base alle condizioni reali del percorso di rete.
Inserendo parametri fondamentali come la velocità del collegamento, il tempo di andata e ritorno (RTT) e la dimensione dei dati, lo strumento identifica istantaneamente quale fattore agisce da collo di bottiglia e stima il tempo totale richiesto per il trasferimento.
Come funziona il calcolo del throughput TCP
Le prestazioni di un singolo flusso TCP sono determinate dal valore più basso tra tre limiti indipendenti che agiscono in parallelo: la capacità fisica del collegamento (ridotta dall'overhead del protocollo), la capacità di buffering del ricevitore (finestra di ricezione) e la degradazione causata dalla perdita di pacchetti (modello di Mathis).
La formula generale applicata per determinare il throughput è:
throughput = min(velocità × eff, finestra ÷ RTT, MSS ÷ RTT ÷ √p) · BDP = velocità × RTT
Il calcolo si articola attraverso passaggi matematici precisi che analizzano ogni singolo vincolo:
- Efficienza del protocollo: Ogni pacchetto inviato sulla rete include un overhead fisico e di intestazione. Su una rete Ethernet standard, vengono aggiunti 78 byte per pacchetto (40 byte di intestazioni TCP/IP e 38 byte sulla linea fisica). L'efficienza viene calcolata come:
Efficienza del protocollo = MSS ÷ (MSS + 78 B) = ‹mss› ÷ ‹frame› = ‹eff› (40 B di intestazioni dei pacchetti + 38 B sulla linea fisica) - Limite del collegamento al netto dell'overhead: Rappresenta la velocità massima teorica del canale una volta sottratto l'overhead di protocollo:
Limite del collegamento = velocità × efficienza = ‹rate› × ‹eff› = ‹value› - Prodotto larghezza di banda-ritardo (BDP): Definisce la quantità di dati che devono essere costantemente "in viaggio" per saturare completamente il canale:
BDP = velocità × RTT = ‹rate› × ‹rtt› = ‹bdp› = ‹bytes› - Finestra per riempire il percorso: Indica la dimensione minima del buffer di ricezione necessaria per non interrompere il flusso di dati:
Finestra per riempire il percorso = BDP ÷ 8 = ‹bdp› → ‹window› - Limite della finestra: Se la finestra di ricezione è inferiore al BDP, il trasmettitore deve arrestarsi in attesa delle conferme di ricezione (ACK), limitando la velocità a:
Limite della finestra = finestra ÷ RTT = ‹window› ÷ ‹rtt› = ‹value› - Limite da perdita (Mathis): In presenza di perdita di pacchetti, il TCP riduce la finestra di trasmissione. Il modello di Mathis stima questo limite come:
Limite da perdita (Mathis) = MSS ÷ RTT ÷ √p = ‹mss› ÷ ‹rtt› ÷ √‹p› = ‹value›
Il throughput finale stimato corrisponde al valore più basso tra questi limiti:
Throughput previsto = il minore di questi limiti = ‹value› → limitato da ‹constraint›
Infine, il tempo di trasferimento totale viene calcolato sommando la latenza iniziale per il primo byte al tempo richiesto per muovere l'intero payload alla velocità calcolata:
Tempo di trasferimento = RTT + 8 × dimensione ÷ throughput = ‹rtt› + 8 × ‹size› ÷ ‹throughput› = ‹time›
Parametri di configurazione dello strumento
Per eseguire il calcolo, l'utente può configurare i seguenti campi di input nell'interfaccia:
- Velocità del collegamento: Rappresenta l'hop più lento sul percorso, spesso corrispondente alla velocità nominale del proprio piano di abbonamento. Deve essere maggiore di zero.
- Tempo di andata e ritorno (RTT): Il tempo di ping verso l'estremità lontana, idealmente misurato sotto carico. Deve essere maggiore di zero.
- Dimensione dei dati: Il payload complessivo da trasferire (un file, un backup o un intero set di dati). Deve essere maggiore di zero.
- Finestra di ricezione: I byte che il ricevitore può memorizzare nel buffer. Deve essere maggiore di zero e non può superare 1.073.725.440 byte. Se lasciato vuoto, indica l'assenza di limiti di finestra.
- MSS (byte): I byte di payload per singolo pacchetto (ad esempio, 1.460 byte per un frame Ethernet standard). Deve essere un numero intero compreso tra 1 e 65.495. Se lasciato vuoto, l'overhead e la perdita vengono ignorati.
- Perdita di pacchetti (%): La probabilità media di perdita dei pacchetti sul canale. Deve essere compresa tra 0 e 100 percento. Se lasciata vuota o impostata a 0, non viene applicato alcun limite di perdita.
- Decimali visualizzati: Regola la precisione decimale dei risultati mostrati.
L'interfaccia dispone inoltre dei pulsanti Carica esempio per inserire dati dimostrativi, Cancella per azzerare i campi, e Copia risultato per salvare i dati calcolati negli appunti.
Regole di calcolo e limitazioni del modello
Il calcolo si basa su presupposti matematici precisi e presenta alcune limitazioni intrinseche di cui tenere conto:
- Unità di misura: Tutte le unità utilizzate sono decimali (1 kbit = 1.000 bit, 1 MB = 1.000.000 di byte). I file manager dei sistemi operativi utilizzano spesso unità binarie basate su 1024 (dove un file da "100 MB" è in realtà di 100 MiB, ovvero circa 104,86 MB decimali).
- Limiti del modello di Mathis: Questo modello presuppone perdite di pacchetti distribuite uniformemente e indipendenti. È affidabile solo per tassi di perdita inferiori all'1%. Se la perdita supera questa soglia, lo strumento mostra l'avviso ("La perdita superiore all'1% è al di fuori dell'intervallo di affidabilità del modello di Mathis — consideri il limite di perdita como ottimistico.").
- Window Scaling (RFC 7323): Lo standard TCP classico prevede un limite massimo per la finestra di ricezione di 65.535 byte. Se il percorso richiede una finestra superiore per essere riempito, lo strumento mostra la nota. Se la finestra necessaria supera il limite massimo assoluto consentito dal window scaling (1.073.725,440 byte), viene mostrato l'avviso.
- Esclusioni dal modello: I calcoli ipotizzano un singolo flusso TCP in stato stazionario. Fattori reali come la fase di slow start, l'ottimizzazione del controllo della congestione, la presenza di un ricevitore lento o i tempi di handshake TLS non sono inclusi nel modello. Di conseguenza, i trasferimenti reali inizieranno più lentamente e potrebbero attestarsi al di sotto delle cifre calcolate.
Gestione degli errori di input
In caso di inserimento di valori non validi, lo strumento mostra messaggi di errore specifici per guidare la correzione:
- Se un valore non è numerico:
"‹field›: “‹token›” non è un numero." - Se la velocità del collegamento è zero o negativa:
"La velocità del collegamento deve essere maggiore di zero." - Se l'RTT è zero o negativo:
"Il tempo di andata e ritorno deve essere maggiore di zero." - Se la dimensione dei dati è zero o negativa:
"La dimensione dei dati deve essere maggiore di zero." - Se la finestra di ricezione è zero o negativa:
"La finestra di ricezione deve essere maggiore di zero." - Se la finestra supera il limite massimo di scaling:
"TCP non può negoziare una finestra superiore a 1,073,725,440 byte (window scaling RFC 7323)." - Se l'MSS è fuori dall'intervallo consentito:
"L'MSS deve essere un numero intero di byte compreso tra 1 e 65,495." - Se il tasso di perdita è fuori dall'intervallo consentito:
"Il tasso di perdita deve essere compreso tra 0 e 100 percento." - Se i calcoli superano i limiti di calcolo del sistema:
"Un valore o un risultato intermedio supera l'intervallo numerico supportato."
Riservatezza dei dati inseriti
La privacy dell'utente è interamente preservata durante l'uso del calcolatore. Ogni valore inserito viene calcolato localmente all'interno del browser web in uso; nessun dato viene inviato a server esterni o memorizzato altrove.
Domande frequenti (FAQ)
Perché il mio trasferimento è più lento della velocità di collegamento per cui pago?
Un singolo flusso TCP deve fare i conti con tre limiti indipendenti, e il più basso ha la meglio. L'overhead del protocollo riduce il collegamento stesso di circa il 5% — un frame Ethernet standard trasporta 1,460 byte di payload su 1,538 sulla linea fisica. La finestra di ricezione limita il throughput a finestra ÷ RTT, quindi la classica finestra da 65,535 byte limita un percorso da 50 ms a circa 10.5 Mbit/s, indipendentemente dalla velocità del collegamento. E la perdita lo limita a (MSS ÷ RTT) ÷ √perdita. Il risultato sopra indica quale limite è vincolante per i Suoi numeri.
Cos'è il prodotto larghezza di banda-ritardo e perché determina la dimensione della finestra?
Il BDP — velocità del collegamento × tempo di andata e ritorno — è la quantità di dati in transito in qualsiasi momento. TCP può avere al massimo una finestra non confermata in sospeso, quindi una finestra più piccola del BDP lascia il canale parzialmente vuoto: a 100 Mbit/s con un RTT di 50 ms il canale contiene 625 kB, e una finestra di 65,535 byte ne riempie a malapena un decimo. Ecco perché i percorsi veloci e lunghi necessitano del window scaling TCP (RFC 7323), che eleva il massimo negoziabile da 65,535 byte a circa 1 GB.
In che modo la perdita di pacchetti limita il throughput TCP?
Il TCP tratta la perdita come congestione e dimezza la sua velocità di invio a ogni evento di perdita, quindi anche tassi di perdita minuscoli sono importanti su percorsi veloci. Il modello di Mathis stima il limite come (MSS ÷ RTT) ÷ √p — con una perdita dello 0.01% su un percorso di 50 ms con un MSS di 1,460 byte, si tratta di circa 23 Mbit/s, indipendentemente dalla velocità del collegamento. Il modello presuppone eventi di perdita distribuiti uniformemente e indipendenti; al di sotto dell'1% circa rispecchia bene la realtà, mentre per perdite a raffica risulta ottimistico.
I megabyte qui sono gli stessi del mio file manager?
Non esattamente. Questa pagina utilizza unità decimali, la convenzione delle reti: 1 kbit = 1,000 bit e 1 MB = 1,000,000 di byte. La maggior parte dei file manager conta in unità basate su 1024, spesso erroneamente etichettate come MB — un file da “100 MB” lì è solitamente di 100 MiB ≈ 104.86 MB decimali, quindi richiede circa il 5% di tempo in più per essere trasferito rispetto a quanto suggerito dalla cifra decimale. Inserisca 104.86 MB qui per farlo corrispondere esattamente.