Por qué no deberías aplicar el pensamiento de TCP a UDP

Tags:
Categories:
  • Por qué no deberías aplicar el pensamiento de TCP a UDP

¿Por qué no deberías aplicar el pensamiento de TCP a UDP?

Diferencias de Estructura

Encabezado TCP
Encabezado UDP

TCP tiene muchos conceptos: establecimiento de enlace, uso de recursos, transmisión de datos, transmisión confiable, retransmisión basada en confirmaciones acumulativas, retransmisión por tiempo de espera, suma de verificación, control de flujo, control de congestión, tamaño máximo de segmento, confirmación selectiva, opción de escalado de ventana TCP, marca de tiempo TCP, entrega forzada de datos, finalización de enlace.

La mayoría de estas capacidades no existen en UDP; solo tiene una capacidad adicional sobre la capa de enlace para distinguir los destinos de la capa de aplicación. La simplicidad de UDP significa gran flexibilidad.

Si Puede Ocurrir, Ocurrirá

Ley de Murphy:

Si hay más de una forma de hacer algo, y una de esas formas conduce a un desastre, entonces alguien elegirá esa forma.

Normalmente se dice que UDP es adecuado para juegos, voz y video, donde unos pocos paquetes incorrectos no afectan el servicio. ¿Por qué UDP es adecuado para estos escenarios? El hecho de que UDP pueda usarse en estos escenarios no significa que sea la solución óptima para estos escenarios. Necesariamente existen problemas que TCP no puede resolver, lo que lleva a estos servicios a elegir el protocolo UDP, que tiene capacidades básicas. Los paquetes incorrectos no afectan el negocio, lo que se refiere a que TCP se preocupa por los paquetes incorrectos, mientras que UDP no. UDP se preocupa más por la transmisión en tiempo real y continua. Las características de UDP son que no se preocupa por los factores que importan para TCP, y estos factores afectan la transmisión en tiempo real.

En la implementación del código, UDP solo necesita crear un socket, vincularlo a un puerto, y luego puede comenzar a enviar y recibir. Normalmente, cuando se usa un socket, también se utiliza el puerto.

Por lo tanto, puedo usar UDP de la siguiente manera:

  1. Enviar paquetes aleatorios a cualquier puerto de cualquier IP para ver qué puerto responde
  2. A envía un paquete de solicitud desde el puerto A al puerto B de B; B envía un paquete de respuesta desde el puerto C al puerto D de A
  3. A envía un paquete de solicitud desde el puerto A al puerto B de B; B encarga a C que envíe un paquete de respuesta desde el puerto C al puerto D de A
  4. A envía un paquete de solicitud desde el puerto A al puerto B de B, pero modifica la IP de origen del paquete a la IP de C, B enviará el paquete de respuesta a C
  5. Ambas partes acuerdan usar 10 puertos UDP, enviando y recibiendo simultáneamente

Estos métodos no son viables en TCP, pero en el protocolo UDP, siempre que se pueda hacer, alguien lo hará. Por lo tanto, aplicar el pensamiento de TCP a UDP es idealismo; la realidad a menudo no se puede enumerar completamente.

Los paquetes UDP son muy simples y se usan de manera muy flexible. Originalmente no tenía el concepto de conexión y se necesita definir una conexión UDP por uno mismo. Se han intentado varios métodos de definición, ninguno de los cuales puede determinar completamente la dirección de la conexión, por lo que se necesita aceptar cierto margen de error, ya que originalmente no existía una definición de conexión UDP. Cuando las partes tienen diferentes definiciones de conexión UDP, inevitablemente habrá comportamientos que no coinciden con las expectativas.

Perspectiva UDP del Cliente

Los servicios de voz y video a menudo generan pérdida de paquetes, pero diferentes métodos de pérdida de paquetes afectan el negocio de manera diferente. Por ejemplo, el 30% de pérdida de paquetes distribuida uniformemente versus pérdida concentrada en un período de tiempo tiene una clara distinción en la experiencia. Obviamente, esperamos una pérdida de paquetes más uniforme. Sin embargo, UDP no tiene métodos de control de flujo, por lo que hay varias formas de manejar la pérdida de paquetes. Aunque la comunicación UDP se describe a menudo como “hacer lo posible”, diferentes formas de “hacer lo posible” alcanzan diferentes efectos.

Perspectiva UDP del Proveedor de Servicios

En un ataque TCP, el cliente necesita cierto costo, creando y manteniendo la conexión, es decir, el atacante necesita pagar un precio. Pero en un ataque UDP, el costo del atacante es mucho menor. Si el atacante quiere consumir el ancho de banda del servidor, UDP es una buena manera. Por ejemplo, si el servidor compra 100 GB de tráfico sin límite de velocidad, con capacidad de procesamiento de solo 10 MB por segundo, pero velocidad de recepción de 1 GB por segundo, entonces el 90% del tráfico de solicitud es inválido, pero este tráfico no es gratuito. El proveedor de servicios debe evitar esta situación.

Perspectiva UDP del Operador

Completar una comunicación requiere múltiples terminales y canales de comunicación. Siempre nos preocupamos por el servidor y el cliente, pero la perspectiva del operador también es importante. En los ataques DDoS, a menudo nos preocupamos por el consumo de recursos del servidor, pero en realidad los recursos del operador también son limitados. El servidor simplemente no responde a las solicitudes, pero recibir tráfico ya consume ancho de banda, aunque este recurso generalmente pertenece al operador. Por lo tanto, el operador necesariamente intentará bloquear este tráfico, es decir, el QoS de UDP. En TCP hay control de congestión, pero en UDP, el operador puede controlar el tráfico mediante la pérdida de paquetes. En la práctica, el operador es más simple y directo, bloqueando directamente el tráfico de puertos que se usan durante mucho tiempo, es decir, el bloqueo de puertos UDP. En las pruebas reales de llamadas de WeChat, se descubrió que cada llamada usa múltiples puertos en el cliente, uno de los cuales se comunica con 6 puertos UDP del mismo servidor, se sospecha que es para enfrentar el bloqueo de puertos UDP del operador.

Resumen

La flexibilidad de UDP se manifiesta en que al implementar un objetivo, tiene múltiples métodos de implementación, y todos son legales. Siempre que se logre una comunicación estable al final, no importa cuán diferente sea de TCP, es “la existencia es razón”. Por lo tanto, no podemos aplicar completamente los conceptos de TCP a UDP. Incluso si creamos una nueva definición de conexión UDP para el diseño del producto, también deberíamos poder anticipar y permitir errores, ya que “permitir errores” es la función central de UDP, es su ventaja, no su defecto, es la capacidad central del protocolo elegida activamente por el servicio, no un defecto que se debe aceptar.

Lecturas Adicionales