2009-05-23 18 views
49

Necesito saber cuál es el paquete UDP más grande que puedo enviar a otra computadora sin fragmentación.¿Cómo encontrar el paquete UDP más grande que puedo enviar sin fragmentar?

Este tamaño se conoce comúnmente como MTU (Maximum Transmission Unit). Supuestamente, entre 2 computadoras, habrá muchos enrutadores y módems que pueden tener diferentes MTU.

He leído que la implementación de TCP en Windows encuentra automáticamente la MTU máxima en una ruta.

También estaba experimentando, y descubrí que la MTU máxima de mi computadora a un servidor era de 57712 bytes + encabezado. Cualquier cosa por encima de eso fue descartada. Mi computadora está en una LAN, ¿no se supone que la MTU tiene alrededor de 1500 bytes?

Respuesta

21

Lo siguiente no responde su pregunta directamente pero puede que le resulte interesante; se dice que los paquetes IP se pueden desmontar/volver a montar, y por lo tanto más grande que el límite en los medios de comunicación subordinado (por ejemplo, Ethernet 1500 bytes): Resolve IP Fragmentation, MTU, MSS, and PMTUD Issues with GRE and IPSEC


Más sobre este tema:

  • Re: UDP fragmentation que dice debe utilizar ICMP en lugar de UDP para detectar MTU
  • Path MTU Discovery dice que una conexión TCP podría incluir la negociación implícita a través de MTU ICMP

No sé cómo generar ICMP a través de una API en Windows: en un momento se propuso tal API, y fue controvertida porque la gente argumentó que sería más fácil escribir software que implemente la funcionalidad de denegación de servicio generando un inundación de mensajes ICMP.

No, parece que es implementado: vea por ejemplo Winsock Programmer's FAQ Examples: Ping: Raw Sockets Method.

Por lo tanto, para descubrir MTU, genere paquetes ping con el indicador 'do not fragment'.

Quizás haya una API más fácil que esta, no sé; pero espero haberte dado a entender el (los) protocolo (s) subyacente (s).

+1

Gracias, esto fue un poco útil. Me pregunto si todos los demás que usan UDP simplemente cumplen con el mínimo predeterminado de 576, lo que parece una idea horrible. – Unknown

+0

Cuando implementé un protocolo usando UDP, utilizó números de secuencia y retransmisiones para detectar paquetes perdidos. Habiendo establecido una 'conexión' usando paquetes pequeños, traté de 'negociar' usando un paquete más grande, enviando un paquete más grande de extremo a extremo y viendo si recibí una respuesta (o si se perdió en el camino). YMMV. Los paquetes pequeños (por ejemplo, 100 bytes) se utilizan a menudo en el mundo real, para una aplicación como VoIP; No sé qué características de rendimiento necesita, por qué está utilizando UDP: si va a paquetes grandes, entonces quizás esté tratando de optimizar el ancho de banda en lugar de ... – ChrisW

+0

... jitter; pero no sé si usar paquetes tan grandes como sea posible tiene un gran efecto en el ancho de banda de todos modos. – ChrisW

2

Su propia MTU está disponible en el registry, pero la MTU en la práctica va a la MTU más pequeña en la ruta entre su máquina y el destino. Es variable y solo puede determinarse empíricamente. Hay un número de RFCs que muestra cómo determinarlo.

Las LAN pueden tener internamente valores de MTU muy grandes, ya que el hardware de red suele ser homogéneo o al menos administrado centralmente.

+0

¿Por qué la gente a menudo dice que el MTU para ethernet es 1500? – Unknown

+0

Porque eso es lo que se define en el RFC para Ethernet V2. No soy lo suficientemente inteligente como para saber si la fragmentación de los paquetes de ethernet normalmente se invierte en un enrutador de ethernet a ip solamente, por lo que podría o no ser relevante para la pregunta en cuestión. – Jherico

11

Además de todas las respuestas anteriores, citando el classic:

IPv4 e IPv6 definen mínimo reensamblaje tamaño del búfer, el tamaño mínimo de datagramas que se nos garantiza cualquier implementación debe soportar. Para IPv4, esto es 576 bytes. IPv6 aumenta esto a 1.280 bytes.


Esto significa que quiere limitar el tamaño de su datagrama a menos de 576 si trabaja en internet público y solo controla un lado del intercambio, eso es lo que hacen la mayoría de los protocolos estándar basados ​​en UDP.

También tenga en cuenta que PMTU es una propiedad dinámica de la ruta. Esta es una de las cosas que TCP trata para usted. A menos que esté listo para volver a implementar gran cantidad de lógica de secuenciación, temporización y retransmisión, use TCP para cualquier red crítica. El punto de referencia, la prueba, el perfil, es decir comprueban que TCP es su cuello de botella, solo entonces consideren UDP.

+1

"A menos que esté listo para volver a implementar mucha lógica de secuenciación, temporización y retransmisión" ... Sí, ya lo sé y estoy listo para implementar el mío. Además, PMTU no es parte de TCP. No veo ninguna razón por la cual no puedas usarlo para tu propio protocolo. – Unknown

+3

Solo digo que TCP ya implementa RFC 1191/1981 y mucho más, y también en el kernel. Si tiene un motivo para trabajar en UDP, bien, siga adelante, solo asegúrese de que el motivo sea válido. –

+1

¿Y qué ocurre si solo uso una conexión dummy tcp al principio? ¿Es posible extraer el PMTU de eso? – Unknown

2

Este es un tema interesante para mí. Quizás algunos resultados prácticos puedan ser de interés cuando se entregan datos fragmentados de UDP en Internet a través de UDP, y con una velocidad de transmisión de 1 paquete por segundo, los datos continúan apareciendo con una pérdida de paquetes mínima de hasta 2K. Más de esto y comienzas a tener problemas, pero regularmente entregamos paquetes de más de 1600 bytes sin problemas, esto es a través de las redes móviles GPRS y WAN en todo el mundo. En ~ 1K suponiendo que la señal es estable (¡no!) Se obtiene una baja pérdida de paquetes.

Curiosamente, no es el paquete extraño, pero a menudo una borrascosa de paquetes durante unos segundos, que presumiblemente es por lo que las llamadas VoIP simplemente se colapsan ocasionalmente.

Cuestiones relacionadas