¿Cuál es el tamaño de paquete UDP seguro más grande en Internet?

201

He leído varios artículos sobre el tamaño de los paquetes UDP, pero no he podido llegar a una conclusión sobre cuál es la correcta.

Varios servicios restringen el paquete UDP más grande a 512 bytes (como dns)

Dado que el MTU mínimo en Internet es 576, y el tamaño del encabezado IPv4 es de 20 bytes, y el encabezado UDP de 8 bytes. Esto deja 548 bytes disponibles para los datos del usuario.

¿Podría usar paquetes de hasta el tamaño de 548 sin fragmentación de paquetes? ¿O hay algo que los creadores de DNS sabían y por eso lo restringieron a 512 bytes?

¿Podría incluso ir más allá de 548 bytes de forma segura?

— KM
fuente

2

Duplicar, ver stackoverflow.com/questions/900697/…

— ChrisW

10

Es una pregunta ligeramente diferente. Estoy preguntando cuál es el paquete más grande que puedo enviar a través de Internet (sin ningún conocimiento de las otras redes, o sondeo) que no tendrá fragmentación. Esencialmente, el tamaño máximo seguro, que funcionará en todo sin tener que preocuparse por probar la conexión.

— KM

2

No puede eliminar la posibilidad de fragmentación, pero esto no hace que las cosas sean menos seguras. Si se descarta un fragmento, es lo mismo que si se descartara todo el paquete, lo que ocurre con UDP de todos modos. No sería seguro si un paquete excediera el tamaño mínimo que los enrutadores debían admitir y, por lo tanto, no se garantiza que se pueda entregar (en lugar de garantizar que se entregue). Aquí es donde entra en

— juego la

129

Es cierto que un encabezado IPv4 típico tiene 20 bytes y el encabezado UDP tiene 8 bytes. Sin embargo, es posible incluir opciones de IP que pueden aumentar el tamaño del encabezado de IP hasta 60 bytes. Además, a veces es necesario que los nodos intermedios encapsulen datagramas dentro de otro protocolo como IPsec (utilizado para VPN y similares) para enrutar el paquete a su destino. Entonces, si no conoce la MTU en su ruta de red en particular, es mejor dejar un margen razonable para otra información de encabezado que no haya previsto. Por lo general, se considera que una carga útil UDP de 512 bytes hace eso, aunque incluso eso no deja suficiente espacio para un encabezado IP de tamaño máximo.

— mark4o
fuente

36

Para ser claros: tener un tamaño pequeño para evitar la fragmentación no hace que la entrega del paquete sea "Segura", todavía hay una cantidad infinita de posibilidades que hacen que la entrega no sea confiable, como por ejemplo el cable de mi red. Dicho eso tener menos fragmentos hace que la entrega sea "más segura" porque si hubo más de uno y alguno de ellos nunca lo hizo, UDP descartó todo el paquete (datagrama).

— markmnl

3

Para propósitos de una pregunta, uno presumiría usar la definición de carteles de 'seguro', no alguna definición en algún libro de estándares que nunca hayan visto.

— Astara

¿Se sabe que los enrutadores del mundo real descartan paquetes UDP en lugar de fragmentarlos?

— user253751

60

El límite teórico (en Windows) para el tamaño máximo de un paquete UDP es 65507 bytes. Esto se documenta aquí :

El tamaño correcto correcto del mensaje UDP es 65507, según lo determinado por la siguiente fórmula: 0xffff - (sizeof (Encabezado IP) + sizeof (Encabezado UDP)) = 65535- (20 + 8) = 65507

Dicho esto, la mayoría de los protocolos se limitan a un tamaño mucho más pequeño, generalmente 512 u ocasionalmente 8192. A menudo puede ir más alto que 548 de manera segura si está en una red confiable, pero si está transmitiendo a través de Internet en general, cuanto más grande vaya, lo más probable es que se encuentre con problemas de transmisión de paquetes y pérdida.

— Reed Copsey
fuente

39

Un enlace de Microsoft no es una referencia normativa. Los RFC son la referencia normativa; y lo que ha citado se aplica solo a IPv4.

— Marqués de Lorne

2

El hecho de que MS lo permita no significa que siempre sea una buena idea, ya que los enrutadores intermedios, etc., podrían verse obligados a fragmentar paquetes de mayor tamaño (como usted mencionó).

— rogerdpack

1

@EJP No lo explican claramente en el enlace de Microsoft, pero parece ser una consecuencia necesaria de IPv4: el campo de longitud total de IPv4 es de 16 bits, y ese valor debe incluir la longitud del encabezado IP y la longitud del Encabezado UDP

— jtpereyda

@jtpereyda Soy plenamente consciente de todo eso. Mi punto es exactamente lo que ya dije: debe citar referencias normativas donde existan.

— Marqués de Lorne

No creo que el tamaño máximo del paquete UDP sea de 65.507 bytes, dado que mi tarjeta wifi (IEEE 802.3) solo puede hacer 1500 MTU, y las tramas gigantes son solo 9k bytes.

— Christian Stewart

52

La carga útil máxima segura de UDP es de 508 bytes. Este es un tamaño de paquete de 576, menos el encabezado IP máximo de 60 bytes y el encabezado UDP de 8 bytes. Se garantiza que cualquier carga útil UDP de este tamaño o menor se entregará a través de IP (aunque no se garantiza que se entregue). Cualquier enrutador puede dejarse caer por cualquier enrutador por cualquier motivo. Excepto en una ruta de solo IPv6, donde la carga útil máxima es de 1.212 bytes. Como otros han mencionado, se podrían agregar encabezados de protocolo adicionales en algunas circunstancias. En su lugar, se puede preferir un valor más conservador de alrededor de 300-400 bytes.

Cualquier paquete UDP puede estar fragmentado. Pero esto no es demasiado importante, porque perder un fragmento tiene el mismo efecto que perder un paquete no fragmentado: se descarta todo el paquete. Con UDP, esto va a suceder de cualquier manera.

Curiosamente, el tamaño teórico máximo del paquete es de alrededor de 30 MB (1,500 MTU de Ethernet - 60 encabezado IP x 65,536 número máximo de fragmentos), aunque la probabilidad de que llegue sería infinitesimal.

Fuentes: RFC 791, RFC 2460

— Beejor
fuente

2

Cualquier paquete UDP, por defecto, se considera "_U_nlialia". El único tamaño de paquete UDP seguro que podría esperar recibir sería 1, paquete no fragmentado. Si desea paquetes "seguros", use un protocolo de paquetes sobre TCP.

— Astara

26

@Astara True, por naturaleza UDP no es confiable. Pero la pregunta es si un paquete de un tamaño dado está garantizado para ser entregado, no garantizado para ser entregado. Los paquetes de más de un tamaño determinado pueden ser descartados (y son) descartados por cualquier enrutador por cualquier motivo, mientras que los más pequeños deben ser manejados por todos los enrutadores, según los estándares de la industria. Por lo tanto, "seguro" en este caso significa "¿mi automóvil encajará debajo del puente" y no "se quedará atascado en el tráfico"?

— Beejor

1

Recomiendo dejar de repetir lo que dijo un tipo aleatorio y verificar los hechos, porque UDP es bastante confiable. Por cierto, tengo paquetes seguros encima de UDP sin la sobrecarga innecesaria de TCP. openmymind.net/How- Unreliable

— Pablo Ariel

55

UDP no es "poco confiable" debido a la cantidad de paquetes descartados, sino porque los paquetes se pueden descartar (y se descartan). No puede "confiar" en la llegada, pedido o confirmación de un paquete específico. Los datos son frágiles y es como decir que la dirección del automóvil que funciona el 99% del tiempo y el 89% en la dirección correcta es confiable. No es que UDP no sea excelente para muchas cosas, solo que requiere que básicamente escriba su propia versión de "TCP" encima. Aquí hay un caso fascinante del mundo real en el mundo del desarrollo del juego (aunque un poco desactualizado): gamasutra.com/view/feature/131781

— Beejor

@Beejor Estaba en el camino correcto, pero "requiere que básicamente escriba su propia versión de" TCP "encima" es descaradamente incorrecto. UDP es excelente para la transmisión y excelente para el envío rápido de datos 'no críticos'. (En lo que respecta a los juegos) puede descubrir servidores / servicios (LAN) utilizando UDP y utilizar UDP para enviar ubicaciones de jugadores rápidamente. Si se está descartando un paquete; no le importa porque el próximo paquete tendrá una ubicación más actualizada de los otros jugadores. TCP puede tener paquetes "fuera de servicio", tiene gastos generales y no hace conexiones de uno a muchos. En algunos casos UDP puede ser más aplicable.

— Paul

46

576 es el tamaño mínimo de búfer de reensamblado máximo , es decir, cada implementación debe poder reensamblar paquetes de al menos ese tamaño. Vea IETF RFC 1122 para más detalles.

— usuario607811
fuente

2

Si, y solo si tiene una red que no lleva IPv6. Si lleva IPv6, use el tamaño máximo de paquete de los encabezados de IPv6 y luego reste los encabezados de encapsulación para hacer IPv4 sobre IPv6. ;-)

— Astara

@Astara En IPv6, el emisor realiza la fragmentación, por lo que no hay problema con enrutadores intermedios poco compatibles y poco fiables. Y si el destinatario no tiene un tamaño incrustado con memoria limitada, entonces probablemente pueda volver a ensamblar paquetes de hasta 64kB al menos.

— user253751

@ user253751 No solo los enrutadores no compatibles pueden fragmentarse. Hay Path MTU Discovery, pero incluso eso no es suficiente para eliminar por completo la fragmentación.

— dstromberg

@dstromberg ¿En qué situaciones se permite a los enrutadores IPv6 fragmentar datagramas?

— user253751

@ user253751 Todavía no tengo mucho IPv6, pero aquí hay un ejemplo: imagine una red IPv6 que envía jumbogramas (> 65536 bytes) a otra red IPv6 que también admite jumbogramas. Supongamos además que Path MTU Discovery dice que esos jumbogramas deberían ser compatibles sin fragmentación. Pero luego un enrutador se apaga y parte de la ruta de red se reemplaza con un equipo que no está configurado para jumbogramas.

— dstromberg

14

Este artículo describe la unidad de transmisión máxima (MTU) http://en.wikipedia.org/wiki/Maximum_transmission_unit . Establece que los hosts IP deben poder procesar 576 bytes para un paquete IP. Sin embargo, señala que el mínimo es 68. RFC 791: "Todos los módulos de Internet deben poder reenviar un datagrama de 68 octetos sin mayor fragmentación. Esto se debe a que un encabezado de Internet puede tener hasta 60 octetos, y el fragmento mínimo es de 8 octetos. ".

Por lo tanto, el tamaño de paquete seguro de 508 = 576 - 60 (encabezado IP) - 8 (encabezado udp) es razonable.

Según lo mencionado por user607811, la fragmentación por otras capas de red debe ser reensamblada. https://tools.ietf.org/html/rfc1122#page-56 3.3.2 Reensamblaje La capa IP DEBE implementar el reensamblaje de datagramas IP. Designamos el tamaño de datagrama más grande que EMTU_R puede volver a ensamblar ("MTU efectiva para recibir"); esto a veces se llama el "tamaño del búfer de reensamblado". EMTU_R DEBE ser mayor o igual que 576

— edW
fuente

11

El tamaño mínimo del búfer de reensamblado de IPv4 es 576, IPv6 lo tiene en 1500. Resta los tamaños de encabezado desde aquí. Consulte Programación de redes UNIX por W. Richard Stevens :)

— Nikolai Fetissov
fuente

1

Mínimo, por supuesto. Gracias por verlo. No tengo idea de cómo nadie ha notado el error a lo largo de los años.

— Nikolai Fetissov

1

Si bien IPv6 puede tener un búfer de reensamblado mínimo de 1500, los paquetes de IPv6 no pueden fragmentarse, y la MTU mínima de IPv6 es 1280. Un dispositivo final nunca debería necesitar reensamblar un paquete de IPv6 fragmentado.

— Ron Maupin

1

Los paquetes @RonMaupin IPv6 pueden ser fragmentados por los puntos finales. Simplemente no por los enrutadores intermedios.

— Navin

3

@Navin, no, los paquetes IPv6 no se fragmentarán, los datos deben fragmentarse antes de empaquetarse en paquetes IPv6, pero los paquetes en sí no están fragmentados. Hay una diferencia. A diferencia de los encabezados de paquetes IPv4 que tienen campos para lidiar con la fragmentación, los encabezados de paquetes IPv6 no tienen nada que lidiar con la fragmentación. El encabezado del paquete IPv6 es mucho más simple que el encabezado del paquete IPv4.

— Ron Maupin

6

512 es tu mejor apuesta. Se usa en otros lugares y es un buen número par (la mitad de 1024).

— Justin Niessner
fuente

6

Dado que IPV6 tiene un tamaño de 1500, afirmaría que los operadores no proporcionarían rutas separadas para IPV4 e IPV6 (ambos son IP con diferentes tipos), forzándolos a equipos para ipv4 que serían viejos, redundantes y más costosos de mantener y menos confiable No tendría ningún sentido. Además, hacerlo podría considerarse fácilmente como un tratamiento preferencial para un poco de tráfico, un no no según las reglas que probablemente no les importan mucho (a menos que los atrapen).

Por lo tanto, 1472 debe ser seguro para uso externo (aunque eso no significa que una aplicación como DNS que no conoce sobre EDNS lo acepte), y si está hablando de redes internas, es más probable que conozca el diseño de su red, en cuyo caso los tamaños de paquetes jumbo se aplican para paquetes no fragmentados, por lo tanto, para 4096 - 4068 bytes, y para tarjetas de inteligencia con buffers de 9014 bytes, un tamaño de paquete de ... espera ... 8086 bytes, ¿sería la máxima ... coincidencia? risa disimulada

****ACTUALIZAR****

Varias respuestas dan los valores máximos permitidos por 1 proveedor de SW o varias respuestas suponiendo la encapsulación. El usuario no solicitó el valor más bajo posible (como "0" para un tamaño UDP seguro), sino el tamaño de paquete seguro más grande.

Los valores de encapsulación para varias capas se pueden incluir varias veces. Dado que una vez que ha encapsulado una transmisión, no hay nada que prohíba, por ejemplo, una capa VPN debajo de eso y una duplicación completa de las capas de encapsulación por encima de eso.

Como la pregunta era sobre los valores máximos seguros, supongo que están hablando sobre el valor máximo seguro para un paquete UDP que se puede recibir. Como no se garantiza ningún paquete UDP, si recibe un paquete UDP, el tamaño seguro más grande sería 1 paquete sobre IPv4 o 1472 bytes.

Nota: si está utilizando IPv6, el tamaño máximo sería de 1452 bytes, ya que el tamaño del encabezado de IPv6 es de 40 bytes frente al tamaño de 20 bytes de IPv4 (y de cualquier manera, uno debe permitir 8 bytes para el encabezado UDP).

— Astara
fuente

1

¿Cómo estás calculando 1472? Ethernet tiene una MTU de 1500, ¿a eso se refiere?

— rogerdpack

44

@rogerdpack Creo que quiere decir que debido a que es probable que IPv4 e IPv6 compartan mucha infraestructura, y que IPv6 se está volviendo relativamente popular, debería ser seguro asumir los límites de IPv6 (por lo tanto, el 1500). Sin embargo, no puedo decir cuán válido es este razonamiento.

— Thomas

2

1500 debe ser compatible con componentes compatibles con IPv6 en la "cadena" de la red: si uno usa IPv4, que puede viajar a través de una cadena compatible con IPv6 (aunque lo contrario no es cierto), entonces dado que el tamaño del encabezado de IPv4 es de 20 bytes, y El tamaño del encabezado UDP es de 8 bytes, lo que dejaría un 1500-20-8 = 1472 como el tamaño máximo seguro (ya que IPv6 no permite la fragmentación). Nota: si las personas agregan suficientes capas de encapsulación, posiblemente no podría haber espacio para DATOS. Como solicitó el MAX, uno supondrá que NO se están utilizando múltiples capas de sobrecarga de encapsulación.

— Astara

" 1500 debe ser compatible con componentes compatibles con IPv6 en la cadena de red " . No, la MTU mínima de IPv6 es 1280. La MTU de Ethernet es 1500.

— Ron Maupin

@RonMaupin: la Q original era el tamaño de paquete UDP seguro más grande, no la MTU. Ver RFC2460. Además de mencionar una MTU de 1280 octetos, dice: Los nodos deben poder aceptar un paquete fragmentado, que cuando se vuelve a ensamblar es de hasta 1500 octetos. El manejo de paquetes de más de 1500 es opcional.

— Astara

6

He leído algunas buenas respuestas aquí; Sin embargo, hay algunos errores menores. Algunos han respondido que el campo Longitud del mensaje en el encabezado UDP es un máximo de 65535 (0xFFFF); Esto es técnicamente cierto. Algunos han respondido que el máximo real es (65535 - IPHL - UDPHL = 65507). El error es que el campo Longitud del mensaje en el encabezado UDP incluye toda la carga útil (capas 5-7), más la longitud del encabezado UDP (8 bytes). Lo que esto significa es que si el campo de longitud del mensaje es 200 Bytes (0x00C8), la carga útil es en realidad 192 Bytes (0x00C0).

Lo que es difícil y rápido es que el tamaño máximo de un datagrama IP es 65535 Bytes. Este número llega a la suma total de los encabezados L3 y L4, más la carga útil de las capas 5-7. Encabezado IP + Encabezado UDP + Capas 5-7 = 65535 (Máx.).

La respuesta más correcta para cuál es el tamaño máximo de un datagam UDP es 65515 Bytes (0xFFEB), ya que un datagrama UDP incluye el encabezado UDP. La respuesta más correcta para cuál es el tamaño máximo de una carga útil UDP es 65507 Bytes, ya que una carga útil UDP no incluye el encabezado UDP.

— Cerdo
fuente

1

No respondiste la pregunta. El interlocutor quería saber cuál era el tamaño más grande que podían usar para evitar la fragmentación del paquete.

— Astara

0

Me temo que incurriré en reacciones molestas pero, sin embargo, para aclararme si estoy equivocado o si los que ven esta pregunta y están interesados en una respuesta:

Mi comprensión de https://tools.ietf.org/html/rfc1122 cuyo estado es "una especificación oficial" y, como tal, es la referencia para la terminología utilizada en esta pregunta y que no es reemplazada por otro RFC ni tiene erratas que contradicen el siguiendo:

teóricamente, es decir. basado en la especificación escrita., UDP como lo da https://tools.ietf.org/html/rfc1122#section-4 no tiene "tamaño de paquete". Por lo tanto, la respuesta podría ser "indefinida"

En la práctica, que es lo que probablemente buscaron estas preguntas (y que podría actualizarse para la tecnología actual en acción), esto podría ser diferente y no lo sé.

Pido disculpas si causé disgusto. https://tools.ietf.org/html/rfc1122#page-8 El "conjunto de protocolos de Internet" y los "supuestos arquitectónicos" no me dejan claro el "supuesto" en el que estaba, según lo que escuché, que Las capas están separadas . Es decir. la capa en la que se encuentra UDP no tiene que preocuparse por la capa en la que se encuentra la IP (y la capa de IP sí tiene elementos como el reensamblaje, EMTU_R, fragmentación y MMS_R ( https://tools.ietf.org/html/rfc1122#page- 56 ))

— usuario5588495
fuente

1

El encabezado UDP tiene un campo de longitud de datagrama de 16 bits, lo que significa que el datagrama UDP teórico más grande es 65,535, pero eso nunca se puede alcanzar porque UDP está encapsulado dentro de un paquete IP, que tiene una longitud máxima general teórica de 65,535 (el igual) pero debe restar los encabezados IP y UDP de ese tamaño para calcular el tamaño de datos máximo teórico.

— Ron Maupin

Lo pregunté hace mucho tiempo, pero estaba buscando una respuesta pragmática (lo que funciona en la vida real) en lugar de lo que dice en las especificaciones / o en teoría. Quería obtener paquetes de a a b sin fragmentación, fue por un problema de red de juegos en tiempo real. Creo que ahora hay muchas soluciones desarrolladas por personas más inteligentes :)

— KM

0

UDP no es "seguro", por lo que la pregunta no es buena, sin embargo,

Si está en una Mac, el tamaño máximo que puede enviar por defecto es 9216 bytes.
Si está en Linux (CentOS / RedHat) o Windows 7, el máximo es 65507 bytes.

Si envía 9217 o más (mac) o 65508+ (linux / windows), la función de envío de socket regresa con un error.

Las respuestas anteriores sobre la fragmentación y la MTU, etc., están fuera de tema: todo se lleva a cabo en un nivel inferior, es "invisible" para usted y no afecta la "seguridad" en las conexiones típicas en un grado significativo.

Sin embargo, para responder al significado real de la pregunta , no use UDP, use sockets sin procesar para obtener un mejor control de todo; Dado que está escribiendo un juego, debe profundizar en las banderas para tener prioridad en su tráfico de todos modos, por lo que también puede deshacerse de los problemas de UDP al mismo tiempo.

— Anon Coward
fuente