QUIC: los en­tre­si­jos del protocolo ex­pe­ri­me­n­tal 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 co­n­se­cue­n­cia, hoy se da por sentado que las páginas han de abrirse rá­pi­da­me­n­te cuando se visitan, de modo que los proyectos web que se cargan con lentitud apenas tienen po­si­bi­li­da­des de so­bre­vi­vir. La situación se complica aún más dada la im­po­r­ta­n­cia creciente que está ad­qui­rie­n­do la co­di­fi­ca­ción: el estándar HTTPS ha de­mo­s­tra­do ser un firme aliado para proteger la esfera privada de los usuarios, pero tiene como co­n­se­cue­n­cia la demora adicional del proceso de carga a través del protocolo handshake TLS y del in­te­r­ca­m­bio de ce­r­ti­fi­ca­dos y de claves, una situación que debe so­lu­cio­nar el QUIC protocol iniciado por Google.

QUIC es un protocolo de tra­n­s­po­r­te ex­pe­ri­me­n­tal de Google publicado en 2013. El nombre se deriva de “Quick UDP Internet Co­n­ne­c­tio­ns”, lo que se debe a que este po­si­bi­li­ta el envío de paquetes sencillos de datos a través del UDP (User Datagram Protocol) o protocolo de da­ta­gra­mas de usuario, que no necesita conexión. El telón de fondo de los trabajos en QUIC fue el deseo de de­sa­rro­llar una al­te­r­na­ti­va a las so­lu­cio­nes de seguridad es­ta­ble­ci­das a partir de TCP, HTTP/2 y TLS/SSL que ofrecen la misma pro­te­c­ción, pero también una demora reducida en la conexión y en el tra­n­s­po­r­te, y po­si­bi­li­ta co­ne­xio­nes mu­l­ti­ple­xa­das.

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 in­te­r­ca­m­bian los ce­r­ti­fi­ca­dos y las claves ne­ce­sa­rios para el cifrado de los da­ta­gra­mas enviados. Este in­te­r­ca­m­bio no se aplica en po­s­te­rio­res co­mu­ni­ca­cio­nes, lo que reduce la latencia. Como protocolo de cifrado se aplica la actual versión TLS 1.3 con velocidad op­ti­mi­za­da (versión es­ta­n­da­ri­za­da en marzo de 2017), que obtuvo pre­fe­re­n­cia a la solución cri­p­to­grá­fi­ca propia. En términos de mu­l­ti­ple­xa­ció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 ca­ra­c­te­rí­s­ti­cas y ventajas im­po­r­ta­n­tes de QUIC, pero a co­n­ti­nua­ción de­ta­lla­mos en qué consiste otra serie de mejoras. Para hacerlo tomaremos como re­fe­re­n­cia al protocolo TCP, el cual juega un papel im­po­r­ta­n­te como precursor del concepto del nuevo protocolo de tra­n­s­po­r­te pero queda algo por debajo del protocolo de Google, tal y como aclaran las si­guie­n­tes ventajas de QUIC.

La razón principal del re­n­di­mie­n­to superior de QUIC frente a TCP es su rapidez en es­ta­ble­cer conexión. Aun sin un cifrado SSL/TLS, la conexión a través del protocolo de tra­n­s­po­r­te 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 pa­rá­me­tros TLS o HTTPS ne­ce­sa­rios. En la mayoría de los casos, un cliente puede enviar datos di­re­c­ta­me­n­te a un servidor sin que este tenga que enviar una respuesta, mientras que TCP debe obtener y procesar la co­n­fi­r­ma­ción del servidor.

TCP recurre a los puertos TCP y a las di­re­c­cio­nes IP de los sistemas co­ne­c­ta­dos para ide­n­ti­fi­car las co­ne­xio­nes. 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 re­cu­rrie­n­do a una ide­n­ti­fi­ca­ción de la conexión de 64 bits y a di­fe­re­n­tes “streams” para tra­n­s­po­r­tar los datos en una conexión. Las co­ne­xio­nes QUIC no están vi­n­cu­la­das a un puerto es­pe­cí­fi­co (en este caso puerto UDP), a una dirección IP o a un punto final de­te­r­mi­na­do. La mo­di­fi­ca­ción de los puertos y de las di­re­c­cio­nes IP es, como co­n­se­cue­n­cia, igual de posible que las me­n­cio­na­das co­ne­xio­nes mu­l­ti­ple­xa­das.

Cada segmento de datos de una conexión QUIC obtiene un número de secuencia propio in­de­pe­n­die­n­te­me­n­te de que se trate de un segmento original o de uno reenviado. TCP no establece esta di­s­ti­n­ción, por lo que un host tampoco puede de­te­r­mi­nar el estado de una secuencia. Solo la uti­li­za­ción de una extensión de cro­no­se­lla­dor (timestamp) permite al protocolo de tra­n­s­po­r­te clásico dicha di­s­ti­n­ción. El marcado continuo de los paquetes es, por lo tanto, una ventaja, ya que permite una es­ti­ma­ción más precisa del tiempo de recorrido del paquete (RTT, Round Trip Time).

Los paquetes que se pierden re­pre­se­n­tan un gran problema en el tra­n­s­po­r­te de datos con QUIC. Gracias a un sistema de co­rre­c­ción de errores basado en XOR no es necesaria una tra­n­s­mi­sión nueva de los datos, pues estos pueden re­co­n­s­trui­r­se en cualquier momento con ayuda de paquetes FEC (Forward Error Co­rre­c­tion), copias de seguridad de los paquetes ori­gi­na­les para un grupo de datos. La co­rre­c­ció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 co­n­tri­bu­ye a la velocidad de las co­ne­xio­nes pero va ligado también a cierto índice de pérdida. Si un paquete se pierde, se inicia una nueva tra­n­s­fe­re­n­cia (TCP fast re­tra­n­s­mit). Para ello, TCP disminuye de manera tra­n­si­to­ria la ventana de vi­sua­li­za­ción, lo que tiene como co­n­se­cue­n­cia que los datos se tra­n­s­mi­tan en impulsos. El QUIC protocol co­n­tra­rre­s­ta tales picos de carga con ayuda del llamado packet pacing. Este pro­ce­di­mie­n­to se ocupa de que la tasa de tra­n­s­fe­re­n­cia se limite au­to­má­ti­ca­me­n­te, de manera que se eviten las so­bre­ca­r­gas en co­ne­xio­nes 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 pla­ni­fi­ca­ción y co­n­ce­p­ción de QUIC y, en el tra­n­s­cu­r­so del proceso, los de­sa­rro­lla­do­res se han ocupado de uno de los mayores problemas de TCP: el en­ca­be­za­do de los paquetes enviados está redactado como texto simple y puede leerse sin necesidad de au­te­n­ti­ca­ción. Los ataques man in the middle y las ma­ni­pu­la­cio­nes de paquetes (como, por ejemplo, la de los números de secuencia), no son algo ex­trao­r­di­na­rio. Los paquetes QUIC siempre se au­te­n­ti­fi­can y en general suelen estar cifrados (incluso la carga útil o payload). Asimismo, la au­te­n­ti­ca­ción por parte del de­s­ti­na­ta­rio hace que las partes del en­ca­be­za­do que no se presentan de forma cifrada estén pro­te­gi­das de la inyección y la ma­ni­pu­la­ción.

Otra de las grandes ventajas de QUIC frente a TCP es que el protocolo de Google no depende del sistema. Mientras que los di­s­po­si­ti­vos y pla­ta­fo­r­mas deben soportar el protocolo TCP para po­si­bi­li­tar la co­mu­ni­ca­ción, el soporte de QUIC solo es necesario en las capas de apli­ca­ción. Por eso, en principio son las empresas de software las que integran el protocolo sin depender de los fa­bri­ca­n­tes de hardware. Hasta la fecha son sobre todo apli­ca­cio­nes de Google como los se­r­vi­do­res de Google, Chromium o Chrome, las que disponen de im­ple­me­n­ta­cio­nes para QUIC, pero con el navegador Opera, el software de se­r­vi­do­res Caddy y los productos de balanceo de carga y de se­r­vi­do­res web de LiteSpeed Te­ch­no­lo­gies también existen apli­ca­cio­nes de terceros que permiten co­ne­xio­nes a través del nuevo protocolo de tra­n­s­po­r­te.

La po­si­bi­li­dad de que QUIC se utilice cada vez más en el futuro se debe sobre todo al co­m­pro­mi­so del IETF. Gracias a los ajustes en los es­tá­n­da­res generales efe­c­tua­dos desde la creación del grupo de trabajo en 2016, el protocolo ha pasado de estar fue­r­te­me­n­te adaptado a Google a co­n­ve­r­ti­r­se en un protocolo de red general que está ganando en re­le­va­n­cia. No obstante, el proceso de op­ti­mi­za­ción todavía no ha concluido: el equipo de QUIC sigue ocu­pá­n­do­se de los problemas exi­s­te­n­tes para los que es necesario encontrar las so­lu­cio­nes adecuadas.

En concreto el tema de la seguridad, uno de los más im­po­r­ta­n­tes en el de­sa­rro­llo del protocolo, plantea grandes debates. Mientras que la au­te­n­ti­ca­ción y el cifrado se ocupan, sin duda, de un tra­n­s­po­r­te de datos seguro, estos dos factores también son re­s­po­n­sa­bles de una de­s­ve­n­ta­ja decisiva de QUIC: debido a que los en­ca­be­za­dos del paquete contienen menos in­fo­r­ma­ción con texto claro que en las co­ne­xio­nes TCP, tareas como la solución de problemas, la re­gu­la­ción del tráfico o la gestión de redes en co­ne­xio­nes QUIC se complican no­ta­ble­me­n­te. Tanto los ope­ra­do­res de red como los fa­bri­ca­n­tes de firewalls y de otras cajas in­te­r­me­dias (mi­d­d­le­bo­xes) se en­cue­n­tran con di­fi­cu­l­ta­des para ga­ra­n­ti­zar la calidad de sus servicios.

Otro problema del protocolo QUIC es que el control au­to­má­ti­co de las so­bre­ca­r­gas en las co­ne­xio­nes con un amplio ancho de banda puede provocar en algunos casos una peor tasa de tra­n­s­fe­re­n­cia.

Para des­ac­ti­var el protocolo, se­le­c­cio­na la entrada “Disabled” (des­ac­ti­va­do) 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 se­le­c­cio­na “Default” (por defecto) o la opción “Enabled” (activado).