¿Por qué el tamaño del paquete IP en la práctica es de solo 1500 bytes?

Ok, siéntate. Calma. Baja la presión arterial.

La respuesta es historia y estupidez.

La primera parte es simple: cuando Ethernet se diseñó originalmente, 1500B era grande. Realmente molesto grande. Mantenerse alrededor de los amortiguadores tan grandes era costoso. Entonces fue muy razonable entonces.

¿Por qué no ha cambiado?

Porque el IEEE lo dijo. Porque no están dispuestos a considerar aumentarlo para que haya una compatibilidad con el 100% hacia atrás. El IEEE incluso se niega a considerar estándares para que los adultos con consentimiento disfruten ellos mismos de paquetes grandes. Por lo tanto, hay jugadores deshonestos que ahora admiten ‘marcos gigantes’, que van hasta 9200B. Sin embargo, no hay un estándar y muchas personas diferentes que implementan diferentes tamaños máximos. Entonces es un desastre.

Muy, muy frustrante.

Cuando sea elegido Dios Emperador, esto se solucionará.

La WAN es la parte costosa

Hoy, no es tan obvio … pero originalmente, la parte más cara de una red era la red “WAN”. La línea que une dos sitios, por ejemplo. A principios de 1980 (en Montreal), unir dos sitios separados por 40 millas costaba alrededor de $ 800 por mes. Velocidad 2400 baudios / 2.4 KB / S. Viste un precio similar en los Estados Unidos. Además de eso, si solicitó una línea … la empresa de telecomunicaciones puede pedirle unos increíbles $ 50K para que expandan su propia red.

Por lo tanto, todo el “protocolo de telecomunicaciones” ha sido diseñado para explotar la “Capacidad” completamente y de la manera más eficiente posible. Todos los protocolos se han diseñado de la misma manera: si podemos ahorrar tan poco como el 10% del costo de las telecomunicaciones, esto sería 80 $ por mes. Ahora, si tiene una línea transcanadiense / estadounidense que cuesta 5000 $ por mes, el 10% son 500 $ por mes.

Red más nueva:

Con una red más nueva como 1Gbe y 10Gbe, podría parecer una tontería tratar de exprimir un poco más de datos en cada paquete … en comparación con la optimización de la eficiencia de la transferencia de memoria de la computadora. Por ejemplo, el paquete 1K podría ofrecer una “transferencia de memoria” más eficiente tanto en el servidor como en el cliente.

Sin embargo, la prueba generalmente indica que establecer una interfaz de 1Gbe en 1024 Byte MTU produce un resultado más lento que el valor predeterminado de 1500 byte MTU.

De acuerdo a su pregunta:

Probablemente, el paquete IP que recibe se originó en una red Ethernet o en una red ATM que funciona en modo de emulación “Ethernet”.

El IP ni siquiera es parcial a 1500 Bytes, es solo parcial al tamaño del paquete más grande que puede ser transitado en la interfaz en la que el servidor también está conectado. (La interfaz MTU máxima).

Ejemplo para un escritorio de PC con Linux:

Tabla de interfaz de kernel

Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg

eno1 1500 0 697609 0 0 0 524364 0 0 0 BMRU

lo 65536 0 85555 0 0 0 85555 0 0 0 LRU

Ajuste automático

Ahora, en la actualidad, muchos enrutadores intentan mejorar el rendimiento y adaptar la “MTU” al valor más eficiente posible utilizando las opciones de TCP Path MTU Discovery . Entonces, si tiene un módem DSL / PPPOE en su camino, es probable que vea un paquete máximo de 1492 bytes. El enrutador “reajusta” esta MTU máxima porque es más eficiente tener una MTU que coincida con la “MTU” más pequeña de la ruta de transmisión.

Si no ajusta la MTU, “un enrutador a lo largo del camino” se verá obligado a “fragmentar” el paquete para que se ajuste a la MTU máxima de su propia interfaz. entonces, para un enrutador DSL que opera PPPOE con una MTU MÁXIMA de 1492 … si su computadora emite un paquete 1500, el enrutador debe crear 2 paquetes para cada uno de ellos. Uno de 1492 + uno de 8 bytes. En este caso, simplemente “duplica” la cantidad de paquetes (y el rendimiento de un enrutador se basa en la cantidad de paquetes transmitidos / recibidos, no tanto en el tamaño de cada paquete individual).

EJEMPLO MTU para varias interfaces

Ejemplo de MTU: (IP siempre intentará llenar cualquier “MTU de transmisión” asociada a la interfaz de salida de la computadora)

Entonces, para dos hosts conectados en una red Ethernet, son 1500 bytes . Algunos son 1492 (pero no suelen estar en casa)

Loopback en la misma computadora: 65536 bytes

En 2 hosts conectados WIFI, es de 2,312 bytes

para 2 hosts conectados a través de 10GBE Ethernet conectados con “Jumbo Frame”, puede alcanzar los 9K.

para una línea DSL bajo PPPOE, es 1492 bytes.

Histórico

En 198 *, era común que la mayoría de los protocolos usaran paquetes de 576 bytes (Decnet, IP, IPX, etc.). Esto fue para reducir el “requisito de memoria” en la computadora que recibe el paquete. A principios de 1980, incluso una mini computadora “potente” a menudo se limitaba a unos 3 Mbits (300 KB / S) o menos bajo Ethernet. Una IBM PC XT con un automóvil 3COM de 290 kbits / s (29 KB), un poco más rápido en modo Transmisión.

Requisito de IP V4

El mínimo para IP V4 es 68 Bytes (MTU). Nunca he visto una red de tan baja capacidad … pero si la MTU es inferior a 68, generalmente interrumpe la comunicación a corto plazo. (Algunos paquetes no se pueden transmitir).

Los paquetes IPv4 pueden tener una longitud de 2 ^ 16 bytes, porque el campo de longitud es de 16 bits. Sin embargo, para evitar la fragmentación, intentan encajar en las tramas LAN (Ethernet). Los tamaños máximos de trama de Ethernet varían con los estándares vigentes (por ejemplo, los diversos estándares 802.11), pero en su mayoría, son alrededor de 1536 bytes (los paquetes IP son 1500 bytes porque Ethernet usa algunos bytes de la trama para su propio direccionamiento). Y ese número contenía una potencia oculta de dos cuando se inventó Ethernet por primera vez (antes de que hubiera paquetes IP para exprimirlos).

Entonces, ¿por qué 1536 bytes en el Ethernet original? Debido a la velocidad de la luz, la impedancia del cable coaxial y una potencia oculta de dos.

La Ethernet original se transportaba a través de cables coaxiales. La Ethernet muy original corría a 3 megabits. ¿Por qué 3Mb? Porque eso fue más lento que la ruta de datos en la computadora Alto, para la cual se inventó Ethernet. Esto significaba que las interfaces Ethernet originales no tenían que almacenar los datos en el búfer a medida que llegaban (la memoria era muy costosa entonces).

Una trama de Ethernet de 1536 bytes es de 12288 bits, que (¡ding!) Toma 4096 (2 ^ 12) microsegundos para transmitir a 3Mb / s.

… Y, a una velocidad de 3Mb, un poco es de unos 300 pies de largo en el cable.

… Y ~ 300 pies también era una longitud de cable conveniente para construir hardware para bombear una señal en 1974.

… Y Ethernet funciona escuchando para ver si el cable está inactivo antes de intentar transmitir una trama, por lo que desea que todas sus interfaces Ethernet estén un poco separadas entre sí. Que esta bien! Esta es una red de área local construida para una oficina.

Entonces, ¿por qué su controlador Ethernet aún asume una unidad de transmisión máxima de 1500 bytes a pesar de que se transmite cientos o incluso miles de veces más rápido por radio u cables ópticos? Las normas tienen una larga memoria (cf. Medidores de ferrocarril y carros romanos).

[ETA: para corregir metros a pies. Un bit a 3Mb tarda 300 nseg en transmitir y, como Grace Hopper solía demostrar al entregar cables largos de nanosegundos de luz, un nanosegundo de luz es aproximadamente un pie.]

Tenga en cuenta que los estándares para Ethernet, IEEE 802.3, existen desde hace casi 50 años. Los tamaños de trama se eligieron para la tolerancia y eficiencia de error de transmisión / recepción, y la potencia de procesamiento en las tarjetas de red era patética según los estándares actuales, por lo que solo se podían realizar algoritmos CRC32 simples en el marco de tiempo de un paquete a 10 MBit / s. RAM era muy, muy caro también. Una tarjeta de red de la década de 1980 podría haber tenido 4K de RAM, e incluso en la década de 1990, 64K era común. La eficiencia (datos transmitidos divididos por el tamaño del paquete) a 1500 bytes de carga útil es aproximadamente del 95%, y la tolerancia a fallas es tal que solo los errores agregados significativos dentro del paso CRC32 pueden dar como resultado que un paquete se transmita incorrectamente. Eso significa que si se producen dos errores que se cancelan, pero el resto del paquete no se ve afectado, el CRC32 estará bien. Eso es fenomenalmente raro.

Lo que es impresionante es que con procesadores de bajo MHz y 4K de RAM, teníamos 10Mbit / s con un 95% de eficiencia. Ponga eso en el contexto “¿qué es lo máximo que puede ahorrar en una compra de $ 1”, y con una eficiencia del 100%, solo tendríamos un 5,3% más de datos transmitidos!

Esa eficiencia del 95% es la razón por la que nunca se usurpó correctamente. Claro, las compañías han promocionado varios métodos de transmisión de paquetes “Jumbo Frames” no conformes, pero con un kit de red de buena calidad, simplemente está recuperando la mayor parte de ese 5.3%, y eso es solo en el mejor de los casos. Si descarta un solo paquete, debe retransmitir más de 9000.

De todos modos, la elección para 1500 se basó en el hardware de los años 1970/80, y su robustez ha resistido la prueba del tiempo a medida que 100Mbit-> 1Gbit-> 10Gbit han evolucionado. Dado que muchas aplicaciones dependen de la transmisión (videollamada, VoIP, etc.) donde los paquetes más pequeños son mejores para la latencia, es probable que sea una de esas opciones de diseño de “fluke histórico funciona durante 100 años”.

En el otro extremo del rango, 1500 bytes, hubo dos factores que llevaron a la introducción de este límite. Primero, si los paquetes son demasiado largos, introducen demoras adicionales a otro tráfico usando el cable Ethernet. El otro factor fue un dispositivo de seguridad integrado en los primeros transceptores de cable compartido. Este dispositivo de seguridad era un sistema anti-balbuceo. Si el dispositivo conectado a un transceptor desarrollara una falla y comenzara a transmitir continuamente, entonces bloquearía efectivamente cualquier otro tráfico para usar ese segmento de cable Ethernet. Para evitar que esto ocurra, los primeros transceptores fueron diseñados para apagarse automáticamente si la transmisión excedía aproximadamente 1.25 milisegundos. Esto equivale a un contenido de datos de poco más de 1500 bytes. Sin embargo, como el transceptor usaba un temporizador analógico simple para apagar la transmisión si se detectaba balbuceo, entonces se seleccionó el límite de 1500 como una aproximación segura al tamaño máximo de datos que no activaría el dispositivo de seguridad.

Referencia:. https://answers.yahoo.com/questi

  • Debido al tamaño de la memoria intermedia disponible en dispositivos de red tradicionales, incluidos enrutadores, NIC de servidor y de escritorio, conmutadores, etc.
  • La velocidad de transmisión de paquetes en sí era lenta: se suponía que había un equilibrio entre eficiencia y rendimiento.
  • Incluso en los años venideros, muchas aplicaciones en tiempo real basadas principalmente en Voz / Video y que consumen el 80% del tráfico de Internet continuarán utilizando MTU más bajas.

No olvide que el contenido en vivo tiene que encontrar “agujeros” entre otros datos para mantener completa una transmisión de video o VoIP en vivo. Los paquetes pequeños lo hacen más fácil. Sé que cuando se logró por primera vez la voz sobre el servicio público de Internet, el tamaño del paquete y la prioridad de la voz fueron las grandes soluciones que lo hicieron funcionar.

Es fácil pagar en cuotas que en grandes cantidades.

Los paquetes son unidades de datos desde el punto de origen. Se llama con diferentes términos a medida que viaja en diferentes capas del modelo OSI de topología de red.

Una unidad de datos en la capa de red se llama como paquete. Las razones que limitan el paquete de datos a 1500 en esta capa es reducir el tiempo de transmisión causado por la pérdida de paquetes. Los paquetes grandes tienden a causar errores. Es probable que cause errores si está contando grandes cantidades de dinero en efectivo. Es fácil contar pequeñas cantidades. Los paquetes tienen menos errores a este tamaño y también es fácil reenviar paquetes pequeños en caso de corrupción de paquetes.