QUIC: El protocolo experimental de Google ¿un riesgo?

Ya se han puesto de relieve algunas características y ventajas importantes de QUIC, pero a continuación detallamos en qué consiste otra serie de mejoras. Para hacerlo tomaremos como referencia al protocolo TCP, el cual juega un papel importante como precursor del concepto del nuevo protocolo de transporte pero queda algo por debajo del protocolo de Google, tal y como aclaran las siguientes ventajas de QUIC.

La razón principal del rendimiento superior de QUIC frente a TCP es su rapidez en establecer conexión. Aun sin un cifrado SSL/TLS, la conexión a través del protocolo de transporte clásico recorre más pasos con el handshake de tres vías (three-way handshake) que la solución de Google basada en UDP. QUIC inicia una conexión con un único paquete (o dos paquetes si se trata de la primera vez que se establece la conexión) y transmite en ellos todos los parámetros TLS o HTTPS necesarios. En la mayoría de los casos, un cliente puede enviar datos directamente a un servidor sin que este tenga que enviar una respuesta, mientras que TCP debe obtener y procesar la confirmación del servidor.

TCP recurre a los puertos TCP y a las direcciones IP de los sistemas conectados para identificar las conexiones. Así, no es posible que un cliente se comunique con el servidor a través de varios puertos en una única conexión. El QUIC protocol soluciona la situación de manera diferente recurriendo a una identificación de la conexión de 64 bits y a diferentes “streams” para transportar los datos en una conexión. Las conexiones QUIC no están vinculadas a un puerto específico (en este caso puerto UDP), a una dirección IP o a un punto final determinado. La modificación de los puertos y de las direcciones IP es, como consecuencia,igual de posible que las mencionadas conexiones multiplexadas.

Cada segmento de datos de una conexión QUIC obtiene un número de secuencia propio independientemente de que se trate de un segmento original o de uno reenviado. TCP no establece esta distinción, por lo que un host tampoco puede determinar el estado de una secuencia. Solo la utilización de una extensión de cronosellador (timestamp) permite al protocolo de transporte clásico dicha distinción. El marcado continuo de los paquetes es, por lo tanto, una ventaja, ya que permite una estimación más precisa del tiempo de recorrido del paquete (RTT, Round Trip Time).

Los paquetes que se pierden representan un gran problema en el transporte de datos con QUIC. Gracias a un sistema de corrección de errores basado en XOR no es necesaria una transmisión nueva de los datos, pues estos pueden reconstruirse en cualquier momento con ayuda de paquetes FEC (Forward Error Correction), copias de seguridad de los paquetes originales para un grupo de datos. La corrección de errores no funciona, sin embargo, cuando faltan varios paquetes de un grupo de datos.

TCP siempre intenta enviar datos lo más rápido posible, lo que contribuye a la velocidad de las conexiones pero va ligado también a cierto índice de pérdida. Si un paquete se pierde, se inicia una nueva transferencia (TCP fast retransmit). Para ello, TCP disminuye de manera transitoria la ventana de visualización, lo que tiene como consecuencia que los datos se transmitan en impulsos. El QUIC protocol contrarresta tales picos de carga con ayuda del llamado packet pacing. Este procedimiento se ocupa de que la tasa de transferencia se limite automáticamente, de manera que se eviten las sobrecargas en conexiones con un ancho de banda reducido. No obstante, esta técnica no es nueva, puesto que algunos núcleos de Linux utilizan este método para el protocolo TCP.

La seguridad ha sido un aspecto esencial desde el principio en la planificación y concepción de QUIC y, en el transcurso del proceso, los desarrolladores se han ocupado de uno de los mayores problemas de TCP: el encabezado de los paquetes enviados está redactado como texto simple y puede leerse sin necesidad de autenticación. Los ataques man in the middle y las manipulaciones de paquetes (como, por ejemplo, la de los números de secuencia), no son algo extraordinario. Los paquetes QUIC siempre se autentifican y en general suelen estar cifrados (incluso la carga útil o payload). Asimismo, la autenticación por parte del destinatario hace que las partes del encabezado que no se presentan de forma cifrada estén protegidas de la inyección y la manipulación.

Otra de las grandes ventajas de QUIC frente a TCP es que el protocolo de Google no depende del sistema. Mientras que los dispositivos y plataformas deben soportar el protocolo TCP para posibilitar la comunicación, el soporte de QUIC solo es necesario en las capas de aplicación. Por eso, en principio son las empresas de software las que integran el protocolo sin depender de los fabricantes de hardware. Hasta la fecha son sobre todo aplicaciones de Google como los servidores de Google, Chromium o Chrome, las que disponen de implementaciones para QUIC, pero con el navegador Opera, el software de servidores Caddy y los productos de balanceo de carga y de servidores web de LiteSpeed Technologies también existen aplicaciones de terceros que permiten conexiones a través del nuevo protocolo de transporte.

La posibilidad de que QUIC se utilice cada vez más en el futuro se debe sobre todo al compromiso del IETF. Gracias a los ajustes en los estándares generales efectuados desde la creación del grupo de trabajo en 2016, el protocolo ha pasado de estar fuertemente adaptado a Google a convertirse en un protocolo de red general que está ganando en relevancia. No obstante, el proceso de optimización todavía no ha concluido: el equipo de QUIC sigue ocupándose de los problemas existentes para los que es necesario encontrar las soluciones adecuadas.

En concreto el tema de la seguridad, uno de los más importantes en el desarrollo del protocolo, plantea grandes debates. Mientras que la autenticación y el cifrado se ocupan, sin duda, de un transporte de datos seguro, estos dos factores también son responsables de una desventaja decisiva de QUIC: debido a que los encabezados del paquete contienen menos información con texto claro que en las conexiones TCP, tareas como la solución de problemas, la regulación del tráfico ola gestión de redes en conexiones QUIC se complican notablemente. Tanto los operadores de red como los fabricantes de firewalls y de otras cajas intermedias (middleboxes) se encuentran con dificultades para garantizar la calidad de sus servicios.

Otro problema del protocolo QUIC es que el control automático de las sobrecargas en las conexiones con un amplio ancho de banda puede provocar en algunos casos una peor tasa de transferencia.