Qué% del tráfico es sobrecarga de la red en la parte superior de HTTP/S pide

Question

Si:
1) bytes de cuenta/bits en el nivel de adaptador de red (en bruto # de bits a través de la NIC) y,
2) Recuento de bytes en todas las solicitudes/respuestas HTTP/S.

Suponiendo única HTTP/S tráfico está en la caja, y asumiendo una cantidad estadísticamente relevante de la "típica" tráfico web:

Quiero saber acerca de cuánto más tráfico serán contados en el nivel de NIC que en el nivel HTTP/S (contando los encabezados http y todo) debido a la sobrecarga de red adicional.

Answer 1

Tiene cero conocimiento acerca de las capas debajo de HTTP. Ni siquiera puede suponer que la solicitud HTTP se entregará a través de TCP/IP. Incluso si lo es, tiene cero conocimiento sobre la sobrecarga agregada por la capa de red. O cuál será la confiabilidad de la ruta y qué sobrecarga se deberá a los paquetes caídos/reenviados.

actualización: Basado en su comentario, aquí hay algunas estimaciones de back-of-the-servilleta:

El maximum segment size (que no incluye el TCP o cabeceras IP) es normalmente negociados entre las capas de la tamaño del MTU menos el tamaño de los encabezados. Para Ethernet MTU generalmente se configura en 1500 bytes. El TCP header tiene 160 bits o 20 bytes. La parte fija de IPv4 header es 160 bits, o 20 bytes también. La parte fija de IPv6 header es de 320 bits, o 40 bytes.Así:

• para HTTP a través de TCP/IPv4

overhead = TCP + IP = 40 bytes

carga útil = 1500-40 = 1460 bytes

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

• para HTTP a través de TCP/IPv6

overhead = TCP + IP = 60 bytes

carga útil = 1500-60 = 1440 bytes

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

Aquí son los supuestos:

• Amazon cuenta la carga útil NIC sin las cabeceras Ethernet, no todo el paquete NIC
• sus respuestas HTTP son totalmente Utilizac g el paquete TCP/IP: el tamaño de página típico + encabezados HTTP da como resultado uno o más paquetes TCP/IP completos y uno con más del 50% carga útil utilizada
• establece una fecha de caducidad explícita en el contenido almacenado en caché para minimizar la respuesta 302
• a evitar las redirecciones o sus URL son lo suficientemente largos para llenar la carga útil

Answer 2

¿Qué sobrecarga de red adicional? la sobrecarga TLS en la parte superior de HTTP equivale al intercambio de claves. Es sobre todo el procesamiento de gastos generales lo que notas.

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

Abajo de la línea (después de que el servidor) wan acelerador o proxies tratará su differen't el tráfico, ya que no es cacheable o compresible.

Answer 3

con Ethernet de 100 Mbit/s, una transferencia de archivos grandes en 94.1Mbit/s.

Eso es 6% de sobrecarga. Si también cuenta los TCP ACK que fluyen en la dirección opuesta, está más cerca del 9%. Para Gigabit Ethernet, la sobrecarga (en porcentaje) sigue siendo la misma. Suposiciones: TCP/IPv4 y tamaño de archivo> 100kB. (En este tamaño podemos descuidar la configuración inicial de HTTP y TCP).

Al comparar las tasas de descarga, tenga cuidado con el factor 8 de bits a bytes. Supongo que nadie te cobrará por el preámbulo de Ethernet o la brecha entre cuadros, pero la "carga útil" no debe tomarse literalmente.

Cálculo: carga útil/global
carga útil = 1500 - 20 - 32 (Ethernet_MTU - IPv4 - TCP)
general = 8 + 14 + 1500 + 4 + 12 (Preámbulo + Ethernet_header + Ethernet_MTU + CRC + Interframe_gap)

Debido Ethernet siempre es full-duplex en estos días, el ocasional TCP ACK que fluye hacia otro lado no cambia la velocidad de transferencia. Si agrega un ACK por cada dos marcos de datos a la sobrecarga (eso es lo que observé en Wireshark), obtiene un 8,5% de sobrecarga total. Y aunque el tamaño de la MTU suele ser de 1500 bytes, puede ser más pequeño en algunas redes, o mucho más grande si cada equipo en la ruta está configurado para ello.