Cerchiamo di dare una stima di quanto questa modifica nel protocollo possa impattare nel traffico in rete.

Per raggiungere questo scopo ci dotiamo di due strumenti:

Dati raccolti nei log di vari Server Web


Server Accessi totali Dim. Media (byte) Accessi < 1400 byte Dim. Media (byte)
DIA
61043
13065
20387
592
COMM1(*)
102283
6116
23286
645
COMM2(*)
9676
6935
1048
746
COMM3(*)
28570
3449
15940
525
TOTALE
201572
7863
60671
588

Avremo una media di pacchetti piccoli di circa il 30%

 (*) Server commerciale di cui si omette l'inessenziale nome

Si tratta di un campione non immenso ma sufficientemente significativo per il nostro scopo.

Giusto per renderci conto di cosa parliamo:

201572(pacchetti)*7863(byte/pacchetto)= 1584960636(byte)=1.58 (Gb)

Ipotizzando 4Kb/s (quante volte lo si spera di vederlo sul proprio browser!!)
Ci vogliono per scaricarli:

1.58 x 1.000.000 / 4 = 395000 (secondi) = 109,722 (ore) = 4,571 (giorni)





Modello per la stima


Effettueremo due stime leggermente diverse una incentrata sul numero di pacchetti, l'altra mirata a sapere i byte che attraversano

Stima per pacchetti

Un po' di notazione indispensabile

Nome
Significato
Valore
I pacchetti per instaurare una connessione
3
Tt TCP: pacchetti per trasmettere 1 pachetto (HTTP) una volta instaurata la connessione
4/3
Tu UDP: pacchetti per trasmettere 1 pachetto (ovviamente non c'è connessione)
2
C pacchetti per chiudere una connessione
3
a pacchetti<1400
60671
b pacchetti>1400
140901
am dimensione media degli a
588
bm dimensione media dei b
7863


Analisi numero di pacchetti trasmessi da tcp

Numero di pacchetti TCP necessari per mandare un pacchetto HTTP di tipo a

Tt=I+Tt+C

Ipotizzando di avere una MTU di 1500 byte, e degli header HTTP da 300 byte

bm/S=7863+300/1500=5.442=6

Quindi per i pacchetti di tipo b mediamente 6 pacchetti tcp di dati
Che porta quindi ad un numero di pacchetti per ogni pacchetto di tipo b:

(bm/S) Tt+(I+Tt+C)

Per un totale:

nt=a (I+Tt+C)+b [(bm/S) Tt+(I+Tt+C)]=

    =10 a + 34 b


Analisi numero di pacchetti trasmessi dall'accoppiata tcp/udp

Ci mettiamo nell'ipotesi di provare sempre prima con UDP e per poi eventualmente dover fare la transizione con TCP

Con le stesse ipotesi su MTU e header HTTP avremo un numero totale di pacchetti spedito pari a:

nu=a Tu+b Tu+b [(bm/S) Tt+(I+Tt+C)]=

    =2 a+36 b

Dove gli addendi sono nell'ordine:
  1. Pacchetti di tipo a trasmessi su UDP
  2. Pacchetti di tipo b rifiutati da HTTP-UDP
  3. Pacchetti di tipo b trasmessi su TCP


Il "guadagno" nt/nu è riportato in figura al variare della percentuale di pacchetti di tipo a presenti e per i due valori di Tt.




Stima per byte

Solita noiosa notazione

Nome
Significato
Valore
I byte per l'instaurazione della connessione
60
Ttovh byte per gli ack di un pacchetto
40
C byte chiudere una connessione
60
tcp a byte per spedire 1 pacchetto a
 
tcp b byte per spedire 1 pacchetto b
 
h dimensione dell'header HTTP
300
a pacchetti<1400
60671
b pacchetti>1400
140901
am dimensione media degli a
588
bm dimensione media dei b
7863

Analisi numero di byte trasmessi da tcp

Numero di byte TCP necessari per mandare un pacchetto HTTP di tipo a

tcpa=I+C+2 Ttovh+am+h+40

Sempre ipotizzando di avere una MTU di 1500 byte, e degli header HTTP da 300 byte

bm/S=7863+300/1500=5.442=6

Quindi per i pacchetti di tipo b mediamente 6 pacchetti tcp di dati
Che porta quindi ad un numero di byte per ogni pacchetto di tipo b:

tcpb=I+C+(bm/S) (1500+20+Ttovh)

  • Apertura e chiusura
  • 1500 di pacchetto
  • 20 di header TCP
  • gli ack


    • Per un totale:

    nt=tcpa a+tcpb 
        =1168 a + 9600 b


    Analisi numero di byte trasmessi dall'accoppiata tcp/udp

    Sempre nell'ipotesi di provare sempre prima con UDP e per poi eventualmente dover fare la transizione con TCP

    udpa=am+h+16
    Dove 16 è l'header dei due pacchetti di richieste e risposta

    Con le stesse ipotesi su MTU e header HTTP:

    I+C+(bm/S) (1500+20+Ttovh)
     Per un totale in byte spediti pari a:

    nu=a tcpa+b tcpa+b  I+C+(bm/S) (1500+20+Ttovh)

        =904 a+10384 b



    Il "guadagno" nt/nu è riportato in figura al variare della percentuale di pacchetti di tipo a presenti.



    Conclusioni


    I dati da noi così ottenuti ci portano a dire che una modifica al protocollo HTTP di questo tipo porta vantaggio dal punto di vista del numero di pacchetti che circolano sulla rete(-7,6%), ma un leggero svantaggio dal punto di vista dei byte trasmessi(+7,5%).

    Nonostante questo si può ancora pensare che sia utile introdurre questo cambiamento.
    La banda passante ha dei costi che stanno scendendo (lasciamo stare l'italia che non fa testo). C'è addirittura chi pensa di trovare economicamente vantaggioso in tempi non lontani far passare fonia su ip, operazione che comporta molto overhead rispetto alla normale codifica telefonica.

    Quello che va facilmente in tilt nelle reti sono i nodi. Alcuni router sono sottoposti ad un numero di richieste a cui spesso non sono grado di far fronte. Il loro problema non e' certo la grandezza del buffer, oramai sappiamo che la ram e' una risorsa ad un costo bassissimo, ma bensì proprio il numero di pacchetti. Diminuirli strutturalmente potrebbe migliorare molte situazioni di congestione.
    Protocollo
    Analisi prestazioni
    Client
    Server
    Download
    news
    Last modified: Thu Feb 4 14:40:57 CET 1999