networking - redireccionar - ¿Qué porcentaje del tráfico es la sobrecarga de red sobre las solicitudes HTTP/S?

redireccionar https nginx (3)

Si nosotros:
1) Cuente los bytes / bits en el nivel del adaptador de red (número de bits sin procesar a través del NIC) y,
2) Cuente los bytes en todas las solicitudes / respuestas HTTP / S.

Suponiendo que solo el tráfico HTTP / S está en la caja, y asumiendo una cantidad estadísticamente relevante de tráfico web "típico":

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

¿Qué sobrecarga de red extra? la sobrecarga de TLS en la parte superior del 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

Más adelante (después del servidor), el acelerador o los proxies tratarán la diferencia de tráfico ya que no es almacenable en caché ni comprimible.

Con 100Mbit / s Ethernet, un archivo grande se transfiere a 94.1Mbit / s.

Eso es un 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 / general
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 a que Ethernet es siempre dúplex completo en estos días, el TCP ACK ocasional que fluye hacia el 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.

Tienes cero conocimiento sobre 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 : En base a su comentario, aquí hay algunas estimaciones de la parte posterior de la servilleta:

El tamaño máximo de segmento (que no incluye los encabezados TCP o IP) generalmente se negocia entre las capas al tamaño de la MTU menos el tamaño de los encabezados. Para Ethernet MTU generalmente se configura en 1500 bytes. El encabezado TCP es de 160 bits o 20 bytes. La parte fija del encabezado IPv4 es 160 bits, o 20 bytes también. La parte fija del encabezado IPv6 es de 320 bits, o 40 bytes. Así:

para HTTP sobre TCP / IPv4

overhead = TCP + IP = 40 bytes

carga útil = 1500 - 40 = 1460 bytes

gastos generales% = 2% (40 * 100/1460)

para HTTP sobre TCP / IPv6

overhead = TCP + IP = 60 bytes

carga útil = 1500 - 60 = 1440 bytes

gastos generales% = 4% (60 * 100/1440)

Aquí están las suposiciones:

Amazon cuenta la carga de NIC sin los encabezados de Ethernet, no el paquete de NIC completo
sus respuestas HTTP están utilizando completamente 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% de carga útil utilizada
establece una fecha de caducidad explícita en el contenido en caché para minimizar la respuesta 302
evita las redirecciones o sus URL son lo suficientemente largas como para llenar la carga