[Certification Level: CCNA]
Un client e un server, ciascuno in un paese o continente diverso, si scambiano un file di dimensioni consistenti (nell’ordine di GB) e hanno necessità di concludere il trasferimento nel minor tempo possibile. Ma questo spesso non accade.
Analizzando il cammino fra i due end host, si cercano drop, CRC o qualsiasi altro tipo di errore che porti allo scarto di un pacchetto. Gli apparati di rete però sono innocenti e non presentano alcun tipo di errore o scarto di traffico. Quindi, dove nasce il problema?
Se non abbiamo una chiara idea di cosa stia succedendo, è sempre buona norma analizzare il traffico. Ascoltiamo perciò sul ricevente, per capire se la sua window size è abbastanza grande da raggiungere le velocità desiderate.
Dal tracciato wireshark scopriamo che the il destinatario, trasmette una Receive Window Size di 512KB (KBytes) Bene – ora come calcoliamo la banda massima possibile, data questa window size? Ecco la formula!
BW in bit per secondi = (tcp.win.size * 8) / RTT in secondiE con la nostra finestra di 512 KB e un round trip di, diciamo, 30 ms ricaviamo:
BW bps = 512*8 / 0.030 = 136533000 bps = 136.5 mbpsNon proprio il massimo della velocità su un link che può permetterci fino ad 1 Gbps. Come mai un host trasmette questo valore così basso, nonostante possa avvalersi di molta più banda disponibile?
Esiste qualche valore preimpostato per cui TCP non gestisce dinamicamente la window size?
Sembrerebbe di no: il kernel Linux 2.6.8 e successivi (e le ultime versioni di Windows e OSX) permettono un controllo dinamico di questo valore, consentendo al processo TCP di utilizzare tutta la memoria disponibile allocata dal sistema operativo.
Morale della favola: se state sperimentato una bassa velocità su un trasferimento TCP, molto spesso il server o il client non hanno abbastanza memoria per trasmettere o inviare traffico.
Per altri miei articoli potete visitare www.matteomalvica.com
