Quale% del traffico è overhead di rete sulla parte superiore del HTTP/S richieste

Question

Se noi:
1) Contare byte/bit a livello di scheda di rete (# grezzo di bit attraverso il NIC) e,
2) Count byte in tutte le richieste/risposte HTTP/S.

Supponendo solo HTTP/traffico S è sulla scatola, e assumendo una quantità statisticamente rilevante di "tipica" traffico web:

Voglio sapere circa quanto più traffico sarà conteggiato a livello di NIC che a il livello HTTP/S (contando le intestazioni http e tutte) a causa dell'overhead aggiuntivo della rete.

Answer 1

Hai zero conoscenze sugli strati sotto HTTP. Non si può nemmeno presumere che la richiesta HTTP verrà consegnata su TCP/IP. Anche se lo è, non hai conoscenza del sovraccarico aggiunto dal livello di rete. O quale sarà l'affidabilità del percorso e quale sovraccarico sarà dovuto a pacchetti abbandonati/rispediti.

Aggiornamento: In base al commento, ecco alcuni back-of-the-tovagliolo di stime:

Il maximum segment size (che non include il TCP o header IP) è di solito negoziato tra gli strati al dimensione del MTU meno la dimensione dell'intestazione. Per Ethernet MTU è solitamente configurato a 1500 byte. Il TCP header è di 160 bit o 20 byte. La parte fissa di IPv4 header corrisponde a 160 bit o 20 byte. La parte fissa di IPv6 header è di 320 bit o 40 byte.Così:

• per HTTP su TCP/IPv4

sovraccarico = TCP + IP = 40 byte

payload = 1500-1540 = 1460 byte

sovraccarico% = 2% (40 * 100/1460)

• per HTTP su TCP/IPv6

sovraccarico = TCP + IP = 60 byte

payload = 1500-1560 = 1440 byte

sovraccarico% = 4% (60 * 100/1440)

Ecco le ipotesi:

• Amazon conta il payload NIC senza le intestazioni Ethernet, non l'intero pacchetto NIC
• vostre risposte HTTP sono completamente utilizin g il pacchetto TCP/IP - le tipiche dimensioni della pagina + intestazioni HTTP risultano in uno o più pacchetti TCP/IP completi e uno con più del 50% del carico utile utilizzato
• si imposta la data di scadenza esplicita sul contenuto memorizzato nella cache per ridurre al minimo la risposta 302
• si evitano i reindirizzamenti o gli URL sono lunghi abbastanza per riempire il payload

Answer 2

Quale ulteriore sovraccarico di rete? l'overhead TLS sopra gli importi HTTP allo scambio di chiavi. Si tratta principalmente di elaborare un sovraccarico che si nota.

http://en.wikipedia.org/wiki/HTTP_Secure#Difference_from_HTTP

giù la linea (dopo che il server) wan acceleratore o proxy considererà il suo differen't traffico in quanto non è memorizzabile nella cache o comprimibile.

Answer 3

Con Ethernet a 100 Mbit/s, un file di grandi dimensioni viene trasferito a 94,1 Mbit/s.

Questo è il 6% di spese generali. Se contate anche gli ACK TCP che scorrono nella direzione opposta, è più vicino al 9%. Per Gigabit Ethernet l'overhead (in percentuale) rimane lo stesso. Presupposti: TCP/IPv4 e dimensione del file> 100kB. (A questa dimensione possiamo trascurare l'impostazione iniziale di HTTP e TCP.)

Quando si confrontano le velocità di download, fare attenzione al fattore 8 da bit a byte. Immagino che nessuno ti addebiterà per il preambolo Ethernet o il divario interframe, ma il "carico utile" non dovrebbe essere preso alla lettera.

Calcolo: payload/ft
payload = 1500 - 20 - 32 (Ethernet_MTU - IPv4 - TCP)
complessiva = 8 + 14 + 1500 + 4 + 12 (Preambolo + Ethernet_header + Ethernet_MTU + CRC + Interframe_gap)

Poiché Ethernet è sempre completamente full duplex in questi giorni, l'occasionale TCP ACK che scorre nell'altro modo non modifica la velocità di trasferimento. Se aggiungi un ACK per ogni due frame di dati al sovraccarico (questo è quello che ho osservato in Wireshark), ottieni un overhead totale dell'8,5%. E mentre la dimensione MTU è in genere di 1500 byte, può essere più piccola in alcune reti, o molto più grande se ogni pezzo di equipaggiamento nel percorso è configurato per esso.