QUIC: los entresijos del protocolo experimental de Google

El que el acceso a Internet con DSL sea cada vez más rápido ha hecho que, en general, disminuya el tiempo de carga de las páginas de Internet. Como consecuencia, hoy se da por sentado que las páginas han de abrirse rápidamente cuando se visitan, de modo que los proyectos web que se cargan con lentitud apenas tienen posibilidades de sobrevivir. La situación se complica aún más dada la importancia creciente que está adquiriendo la codificación: el estándar HTTPS ha demostrado ser un firme aliado para proteger la esfera privada de los usuarios, pero tiene como consecuencia la demora adicional del proceso de carga a través del protocolo handshake TLS y del intercambio de certificados y de claves, una situación que debe solucionar el QUIC protocol iniciado por Google.

QUIC es un protocolo de transporte experimental de Google publicado en 2013. El nombre se deriva de “Quick UDP Internet Connections”, lo que se debe a que este posibilita el envío de paquetes sencillos de datos a través del UDP (User Datagram Protocol) o protocolo de datagramas de usuario, que no necesita conexión. El telón de fondo de los trabajos en QUIC fue el deseo de desarrollar una alternativa a las soluciones de seguridad establecidas a partir de TCP, HTTP/2 y TLS/SSL que ofrecen la misma protección, pero también una demora reducida en la conexión y en el transporte, y posibilita conexiones multiplexadas.

Con este motivo, Google ha diseñado QUIC de manera que el mismo protocolo regule el control de la conexión. En el primer acuerdo de conexión (handshake) entre emisor y receptor, estos se intercambian los certificados y las claves necesarios para el cifrado de los datagramas enviados. Este intercambio no se aplica en posteriores comunicaciones, lo que reduce la latencia. Como protocolo de cifrado se aplica la actual versión TLS 1.3 con velocidad optimizada (versión estandarizada en marzo de 2017), que obtuvo preferencia a la solución criptográfica propia. En términos de multiplexación, QUIC se orienta al protocolo SPDY elaborado por Google, que sirvió de modelo para HTTP/2: los flujos de datos se envían a través de una única conexión cliente-servidor, por lo que disminuye el tiempo de carga.

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 o la 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.

Para desactivar el protocolo, selecciona la entrada “Disabled” (desactivado) y clica en el botón “REINICIAR AHORA”. Chrome dejará de funcionar y la próxima vez que se inicie el navegador los nuevos ajustes estarán activos. Si quieres volver a activar el protocolo, procede de la misma manera y selecciona “Default” (por defecto) o la opción “Enabled” (activado).