Un ex studente mi ha inviato un mail che mi ha fatto molto piacere. Ha risolto un grosso problema pratico grazie al fatto di avere studiato TCP...ci è riuscito anche perché lui è molto in gamba, ma se non avesse saputo come funziona TCP il problema sarebbe stato completamente oscuro...
Buondi' Alberto!
Non ho mai avuto il tempo di raccontarti un aneddoto del lavoro, accaduto ormai diversi anni fa, dove quanto studiato nel corso "reti di calcolatori" e' stato fondamentale per risolvere un problema.
Oggi ti racconto solo il caso, senza la soluzione...
Il nostro collegamento internet e', ovviamente, una linea dedicata ad alta velocita' che arriva fino a noi, una serie di routers (alcuni del provider, altri nostri), una serie di passaggi tra firewalls, antivirus, proxy...
Insomma, la piu' tipica delle configurazioni per un uso "professionale".
Un bel giorno decidono di sostituire il proxy con una macchina piu' nuova. La macchina vecchia era un linux RedHat 4 credo, la nuova una versione piu' recente sempre RedHat Linux, non ricordo se 5 o 6.
Configurato tutto si comincia a testare questo nuovo proxy, ma ci si accorge subito che la velocita' di download di questo nuovo proxy e' sempre piu' bassa del vecchio. A volte di poco, a volte notevolmente piu' bassa.
per dare un'idea, nello scaricamento di un file pesante, tipo un iso, se il vecchio teneva una media di 5MB/s, il nuovo andava a 2 o anche meno. In alcuni casi la velocita' era "ridicola".
Il software di proxy non ricordo se era squid o altro, ma non era questo a fare la differenza. Anche scaricando sulla macchina stessa, senza usare il software di proxy, ma per capirci, facendo un wget "qualcosa" diretto, le velocita' erano queste sopra dette.
Fatte tutte le verifiche sullo switch, su firewall... nessuna differenza per le due macchine. Entrambe sulla stessa lan, con le stesse impostazioni. Entrambe in gigabit full duplex.
Provato anche a sostituire fisicamente le due macchine, quindi provato la nuova con l'IP della vecchia (per evitare che ci fossero regole sul firewall magari disperse nella configurazione...), stesso cavo di rete...
Configurazione di linux come da "fabbrica", nessuna operazione particolare fatta se non quanto strettamente necessario alla configurazione del proxy, ma niente da fare. La nuova era sempre sensibilmente piu' lenta....
Io non ero piu' nel gruppo reti, e nemmeno nel "gruppo dei proxy", ma mi sono trovato per caso in un ufficio di colleghi mentre discutevano di questo problema.
Ho riflettuto un poco e mi e' venuta un'idea....
Buondi' Alberto!
Non ho mai avuto il tempo di raccontarti un aneddoto del lavoro, accaduto ormai diversi anni fa, dove quanto studiato nel corso "reti di calcolatori" e' stato fondamentale per risolvere un problema.
Oggi ti racconto solo il caso, senza la soluzione...
Il nostro collegamento internet e', ovviamente, una linea dedicata ad alta velocita' che arriva fino a noi, una serie di routers (alcuni del provider, altri nostri), una serie di passaggi tra firewalls, antivirus, proxy...
Insomma, la piu' tipica delle configurazioni per un uso "professionale".
Un bel giorno decidono di sostituire il proxy con una macchina piu' nuova. La macchina vecchia era un linux RedHat 4 credo, la nuova una versione piu' recente sempre RedHat Linux, non ricordo se 5 o 6.
Configurato tutto si comincia a testare questo nuovo proxy, ma ci si accorge subito che la velocita' di download di questo nuovo proxy e' sempre piu' bassa del vecchio. A volte di poco, a volte notevolmente piu' bassa.
per dare un'idea, nello scaricamento di un file pesante, tipo un iso, se il vecchio teneva una media di 5MB/s, il nuovo andava a 2 o anche meno. In alcuni casi la velocita' era "ridicola".
Il software di proxy non ricordo se era squid o altro, ma non era questo a fare la differenza. Anche scaricando sulla macchina stessa, senza usare il software di proxy, ma per capirci, facendo un wget "qualcosa" diretto, le velocita' erano queste sopra dette.
Fatte tutte le verifiche sullo switch, su firewall... nessuna differenza per le due macchine. Entrambe sulla stessa lan, con le stesse impostazioni. Entrambe in gigabit full duplex.
Provato anche a sostituire fisicamente le due macchine, quindi provato la nuova con l'IP della vecchia (per evitare che ci fossero regole sul firewall magari disperse nella configurazione...), stesso cavo di rete...
Configurazione di linux come da "fabbrica", nessuna operazione particolare fatta se non quanto strettamente necessario alla configurazione del proxy, ma niente da fare. La nuova era sempre sensibilmente piu' lenta....
Io non ero piu' nel gruppo reti, e nemmeno nel "gruppo dei proxy", ma mi sono trovato per caso in un ufficio di colleghi mentre discutevano di questo problema.
Ho riflettuto un poco e mi e' venuta un'idea....
La mia risposta è stata:
a questo punto è PROIBITO NON DIRMI LA SOLUZIONE !!!! -:)
dimmela quando vuoi, ma dimmela... (rcvbufsize ?)
Il problema era effettivamente legato ai parametri del flow control in TCP (come avevo immaginato) ma la faccenda era davvero intricata.
allora... quello che mi ha fatto scattare l'intuizione era una frase del Tanenbaum che diceva che banda, latenza e la "tcp windows size" sono intimamente legate..
cioè anche avendo a disposizione una notevole banda, ma con una latenza non trascurabile, se non si imposta un'opportuna "tcp windows size" il risultato sara' comunque scadente.
La banda attuale e' cresciuta di molti ordini di grandezza rispetto quelle del tempo... la latenza sara' anche migliorata ma non piu' di tanto non si puo' fare.... a 0 non andra' mai...
quindi di conseguenza la "window" dovrebbe essere generosamente aumentata.
E ho subito pensato a questa benedetta window. Ho sniffato un po' di traffico ed effettivamente i valori che vedevo nell'header del nuovo server erano molto bassi.
Non ricordo esattamente, ma era veramente un valore molto molto basso!
Mentre nel vecchio avevo valori molto piu' alti.
cioè anche avendo a disposizione una notevole banda, ma con una latenza non trascurabile, se non si imposta un'opportuna "tcp windows size" il risultato sara' comunque scadente.
La banda attuale e' cresciuta di molti ordini di grandezza rispetto quelle del tempo... la latenza sara' anche migliorata ma non piu' di tanto non si puo' fare.... a 0 non andra' mai...
quindi di conseguenza la "window" dovrebbe essere generosamente aumentata.
E ho subito pensato a questa benedetta window. Ho sniffato un po' di traffico ed effettivamente i valori che vedevo nell'header del nuovo server erano molto bassi.
Non ricordo esattamente, ma era veramente un valore molto molto basso!
Mentre nel vecchio avevo valori molto piu' alti.
Sintetizzo la parte rimanente:
- Il field window size dello header TCP è lungo 16 bit, quindi permette di gestire buffer di ricezione di dimensione massima 64 KB. Questa dimensione può essere eccessivamente piccola, ad esempio nelle network ad alto bandwidth-latency product, pertanto esiste una opzione di TCP che permette di definire window size molto più grandi: (RFC 1323): The window scale extension expands the definition of the TCP window to 32 bits and then uses a scale factor to carry this 32-bit value in the 16-bit Window field of the TCP header. The scale factor is carried in a new TCP option, Window Scale.
- Alcuni router hanno un bug software a causa del quale i bit che definiscono la window scale sono scartati (!). Loro avevano proprio un router di questi. Pertanto il loro proxy inviava una window size ed il partner percepiva una window size completamente diversa. Il problema non finiva qui, infatti:
- Il vecchio proxy impostava un fattore di scala diverso da quello del nuovo proxy; e, colmo della sfortuna, la window size percepita con il vecchio proxy era intorno ai 32 KB (non bellissima ma accettabile) mentre quella percepita con il nuovo era 1 KB (!).
Ovvio che con il nuovo proxy la velocità di trasferimento imposta dal flow control fosse inaccettabilmente bassa...invio 1 KB e attendo riscontro; invio 1 KB e attendo riscontro...
Notare che il bug al punto 2 è davvero sorprendente....
Commenti