«Osificación» de internet. El protocolo QUIC – 2/3

Este post es el detalle de la presentación que hice en el Esnog31 en Madrid. Si quieres acceder a la misma tienes dos opciones:

Si quieres acceder a la primera parte del mismo, lo tienes en este enlace: https://nopacketloss.es/osificacion-de-internet-el-protocolo-quic/


Nos quedamos en la primera parte de este post en los objetivos con los que el grupo QUIC del IETF se constituyó:

Veamos los detalles de implementación del protocolo que permiten cubrirlos.

¿Cómo se diseñó QUIC?

QUIC sobre UDP

QUIC se apoya en UDP usando el puerto 443 por una razón ya conocida: la “osificación” de internet. Como ya hemos visto, era implanteable la creación de un nuevo protocolo y el uso de UDP era la única opción como protocolo de transporte sin entrega garantizada con que contábamos. QUIC sobre TCP no tendría el menor sentido.

Cabe destacar cómo:

  • QUIC integra la multiplexación de «streams» como parte nativa del protocolo y no cómo HTTP/2 que «montaba» los «streams» como un único flujo sobre TLS. Esto termina con el «HoL blocking» de HTTP/2
  • TLS 1.3 es parte integral del protocolo, lo cual permitirá a QUIC reutilizar funcionalidades como 0-RTT. HTTP/2 corre sobre TLS1.2 y éste a su vez sobre TCP.

1-RTT y 0-RTT

La integración de TLS 1.3 en QUIC se traduce en un proceso de “handshaking” de menor número de “round-trips” y por tanto más rápido en dos casos:

  • Primera conexión al servidor con 1-RTT o un único handshaking previo al envío de datos
  • Restablecimiento de conexión a un servidor al que se estuvo conectado o «session resumption» transmitiendo datos desde el primer paquete enviado gracias al 0-RTT

Obviamente, un “handshaking” más rápido no es una mejora notoria en latencia para sesiones de larga duración con una transferencia de archivos de gran tamaño, pero sí que es muy apreciable en las descargas cortas de múltiples objetos típica de HTTP.

Connection-ID

La función principal de un identificador de conexión o «connection-ID» (CID) es garantizar que los paquetes para una conexión QUIC no se envíen al punto final equivocado, debido principalmente a cambios de dirección en los niveles de protocolo inferiores (UDP, IP). Para QUIC la tupla de IPs y puertos origen y destino no es significativa. En toda conexión existen dos CIDs, uno en cada sentido de la comunicación QUIC.

Cabecera QUIC

La integración nativa de TLS1.3 en QUIC permite que la mayor parte de la cabecera vaya encriptada.

QUIC contempla dos tipos de cabeceras:

  • Long-header – usada en el proceso de “handshaking” inicial (1-RTT y 0-RTT) en el que exclusivamente algunos flags y los “connection-ID”s no están encriptados
  • Short-header – usada en la transferencia de datos en que igualmente sólo algunos flags y “destination connection-ID” no están encriptados

Tramas QUIC

Como ya vimos en la entrada inicial sobre QUIC, éste transporta diferentes «streams». Los «stream» son un tipo de trama, pero no el único. Existen tramas:

  • de control y de datos
  • unidireccionales y bidireccionales
  • iniciadas desde el cliente e iniciadas desde el servidor

Sin embargo, hemos de considerar tres tramas principales:

  • Las tramas “stream” llevan los datos y permiten mantener flujos paralelos, terminando así con el “HoL blocking” de HTTP/2
  • Las tramas “crypto” se utilizan en el establecimiento de la conexión segura
  • Las tramas “ACK” permiten la confirmación de recepción de paquetes QUIC (el ACK confirma el paquete QUIC completo con todas las tramas que en él se transporten)

Paquete QUIC

El paquete QUIC principal es el asociado a la «short header» y que transporta tramas de diferente naturaleza, como la presentada a continuación:

Gestión del tráfico

QUIC también plantea mejoras en la gestión del tráfico respecto a TCP, pero en el fondo se apoya en el enorme trabajo desarrollado a lo largo de los años para intentar hacer evolucionar TCP.

  • MTU – la RFC9000 del IETF:
    • Establece que no existe fragmentación en QUIC
    • Asume que la red admite paquetes de 1280bytes IP
    • PMTUD (Path MTU Discovery) para paquetes superiores a 1200 bytes, pero en la prática no está implementado. Por ejemplo, Google Chrome utiliza paquetes QUIC de 1260bytes IP
  • Control de flujo a dos niveles
    • Trame «stream»
    • Agregado de conexión – control del buffer en el receptor para todos los «streams» enviados entre cliente y servidor
  • Control de congestión y recuperación
    • Ambos extremos realizan una estimación del RTT para establecer los timeouts de pérdida de trama (común con TCP)
    • Detección de pérdida de trama
      • PTO (Probe TimeOut) para considerar un paquete como perdido
      • Los ACKs confirman la recepción de paquetes QUIC (no por trama, sino por paquete) y son capaces de notificar pérdidas puntuales de paquetes (confirman un «ACK-range» e identifican un «gap»)
  • Control de la congestión
    • La RFC9002 cita NewReno como algoritmo de control de la congestión, pero deja abierta la puerta a otros.
    • Google Chrome ya soporta hoy Cubic y BBR
    • La evolución hacia el soporte de algoritmos de gestión activa de cola o AQM como BBRv2 y, sobre todo, L4S (Low Latency, Low Loss and Scalable throughput) es imparable. En breve tendremos una entrada específica dedicada a L4S.

Pérdida de un paquete QUIC

Consideremos que tenemos este paquete QUIC como ejemplo:

Y el mismo es perdido en tránsito hacia su destino:

Un posible paquete de recuperación es el presentado a continuación:

Nótese cómo:

  • El número de paquete es creciente – NO se retransmite el paquete como en TCP
  • Se retransmiten las tramas perdidas exclusivamente, pero no la trama de ACK, pues el mismo habrá sido cubierto por tramas de ACK en paquetes posteriores
  • Es posible que este paquete QUIC incorpore tramas adicionales a las dos reenviadas

Migración de conexión

Otra de las propiedades buscadas en el diseño de QUIC fue la migración de conexión, es decir, la capacidad de migración sin impacto de un acceso a otro. Por ejemplo, de una red fija a una red móvil, sin necesidad de restablecer la conexión o pensemos en el caso de una conexión detrás de CGNAT en que se produce un cambio de asignación de puertos tras un periodo de inactividad de la conexión.

La negociación cliente-servidor de QUIC incluye el intercambio de futuros «connection IDs» que serán utilizados más adelante, intercambio encriptado. Cuando el cliente migra la conexión, toma un nuevo «connection ID» y el servidor responde haciendo lo mismo por su parte. Esto hace imposible de tracear la migración de conexión de un usuario desde la red.

En el caso de TCP esto es lo que MPTCP intentó sin éxito por la “osificación” de internet.

Y con todo lo que hemos visto hasta ahora, ¿podemos decir que QUIC es inmune a la «osificación» de internet? ¿Cómo está evolucionando en el IETF?

Esto lo veremos en la tercera y última parte de este post… 😉

¡¡¡No te pierdas nuevas entradas del blog!!!

¡No hago spam! Sólo recibirás un correo cuando haya una nueva entrada en el blog.


Publicado

en

por

Etiquetas:

Comentarios

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *