Una conversación sobre QUIC con Jana Iyengar: el rediseño de los estándares básicos de la web
Desde que empecé a trabajar con Fastly hace algunos meses, una de las cosas que más me ha entusiasmado ha sido ver cómo Fastly lucha por el bien de internet, además de conocer en primera persona a la gente que lidera esa causa. Entre sus logros, se encuentra QUIC, un revolucionario protocolo de red de la capa de transporte que ha reemplazado al protocolo TCP que conocíamos. De hecho, ya hay más de mil millones de personas que han integrado QUIC y lo usan a diario en la web.
Uno de los miembros principales del equipo encargado de este logro en Fastly es Jana Iyengar, VP of Product for Infrastructure Services. Jana es un veterano experto en las normas de transporte y las conexiones de red, y ha trabajado durante años en la creación y el despliegue de QUIC y HTTP/3, entre otras muchas cosas. Además, ha sido editor de las especificaciones del IETF para QUIC.
Dada la trayectoria de Jana, no podía perder la oportunidad de hablar con él sobre su experiencia trabajando con una comunidad de grandes mentes para rediseñar las normas básicas que sientan los cimientos del internet que todos usamos a diario. Y, por qué no decirlo, quería escuchar la historia de una persona normal y corriente que ha conseguido hacer de internet un lugar mejor.
Anil Dash: Empecemos por el principio. En 2010, entregué el premio Webby honorífico a Vint Cerf (uno de los padres de internet) por su trayectoria como creador del protocolo TCP/IP. Ahora, este protocolo ha sido sustituido por QUIC, lo cual parecía impensable. ¿Cómo ha sucedido? ¿Cómo se vive desde dentro?
Jana Iyengar: Para empezar, déjame aclarar que llevo trabajando 23 años en el ámbito del transporte, por lo que no todo se reduce a QUIC. Sin embargo, sí que era un problema que llevábamos intentando solucionar desde hace 20 años.
Desde la «entrada de siglo».
Exacto, desde entonces queríamos resolver este problema. Si te paras a pensar en lo último que se ha hecho, todo es de finales de los años 90, como el HTTP de última generación o HTTPNG, que es como solían llamarlo. Sin embargo, tras el estallido de la burbuja puntocom, no se renovaron los esfuerzos en este ámbito.
Hay que aclarar en este punto que el sector se aprovechó de los proyectos de licencia libre y no dio nada a cambio. Además, nadie invertía en lo fundamental, en los cimientos de la web.
Nadie llegó a comprender el verdadero potencial de la web, ya que la gente pensaba que el futuro estaba en los portales web y todo el mundo se creaba uno por aquel entonces. Cuando todo esto se esfumó, aún quedaba la esencia de internet, y esta empezó a crecer con la confianza de cada vez más empresas que ya no querían tener un sitio web bonito, sino que lo necesitaban de verdad. Hacía falta un internet que funcionase. En 2010, se entendió que la seguridad y la velocidad eran importantes, pero la privacidad no era un tema que preocupase mucho todavía. Esta mentalidad cambió en 2013, seguramente al revelar Edward Snowden información sobre cómo el gobierno vigilaba el tráfico de internet.
Hablemos sobre ese tema.
Primero, hay que distinguir entre seguridad y privacidad. La seguridad consiste en establecer cifrados donde existan riesgos, mientras que la privacidad consiste en mantener segura la información personalmente identificable (PII). Tras las revelaciones de Snowden, descubrimos que el tráfico en los puntos de intercambio estaba bajo constante vigilancia y ninguna comunicación se realizaba de manera segura, por lo que alguien ajeno podía observar los datos del usuario. Entonces empezaron a saltar las alarmas, ya que hasta ese momento no se había considerado que la seguridad pudiese tener mayor o menor rendimiento, y podía suponer una carga para los recursos del servidor. Al fin y al cabo, la infraestructura tenía que asumir una sobrecarga de seguridad que no era eficiente y se veía como un gran coste.
Cambió esta mentalidad y se realizaron grandes cambios para garantizar la seguridad de las comunicaciones. La única manera era el cifrado de extremo a extremo, que pasó a ser la norma para todo, incluso en los centros de datos entre servicios. Entretanto, seguía en el aire el deseo de reducir la latencia, ya que todo el mundo quería comunicarse rápidamente y de manera segura.
En ese momento, la gente estaba acostumbrada a utilizar el protocolo TCP, pero la disponibilidad de nuevos dispositivos y el crecimiento generalizado lo llevaron al límite. ¿Qué pasó entonces?
QUIC surgió de esa necesidad, aunque los problemas de rendimiento del protocolo TCP en el tráfico web ya se conocían desde 1995.
QUIC surgió de la necesidad de seguridad, baja latencia y despliegues rápidos y, por tanto, había que actuar rápido. Ya se había trabajado en algunos aspectos interesantes previamente, pero aún no era el momento hasta que apareció QUIC. Cuando se concibió, nuestro objetivo era eliminar los gastos causados por la latencia de los protocolos de enlace TLS y TCP que intervenían en todas las comunicaciones de la web.
QUIC resultó ser el vehículo que sirvió para unir todos los avances que ya existían. Era 2015 y acababa de salir el protocolo HTTP/2. Todo el mundo había intentado reducir la latencia en la parte superior del stack, pero la respuesta se encontraba mucho más abajo. La idea de hacerlo así surgió en Google, donde yo estaba por aquel entonces. Trabajamos en ello a nivel interno, lo iteramos y, por último, lo lanzamos. Después hubo que extender su uso entre más personas, pero tras introducir todo un conjunto de normas del IETF, otras empresas como Mozilla, Apple, Microsoft y Fastly se unieron también al ver cómo había funcionado la prueba de concepto en Google.
Entonces, vale la pena realizar las reuniones que haga falta para desarrollar un prototipo.
Claro que sí. El prototipo que teníamos estaba activo y en funcionamiento, lo que provocó que muchas personas se subieran al carro.
¿Hubo algún tipo de oposición? La estandarización puede llegar a ser polémica, así que estoy seguro de que alguien tuvo que llevar la contraria.
Sí, había gente que aseguró que no iba a permitir que tal cosa ocurriese en su red,
y nosotros les explicamos que eso ya estaba pasando en su red.
Si no hubiese estado funcionando, lo hubiésemos sabido al desplegarlo, pero como no fue el caso, nos ahorramos muchas conversaciones innecesarias.
Nuestro objetivo era extender cada vez más la seguridad y el cifrado en el transporte del propio protocolo QUIC, por lo que hubo muchas discusiones sobre el tema.
¿Puedes contarnos algunas de ellas por encima? ¿Sobre qué se discutía?
Tuvimos problemas para desplegar las nuevas tecnologías de transporte en la red. Había muchos mecanismos que se obstaculizaban entre sí, y leían y manipulaban los encabezados TCP, así que resultaba imposible realizar estos despliegues.
Casi todos los encabezados del protocolo QUIC estaban cifrados y muchos operadores de red se quejaron por ello (y aún lo siguen haciendo). Sin embargo, nosotros nos encargamos de proteger el protocolo para iterarlo y perfeccionarlo, por lo que nadie puede manipularlo por dentro y dar problemas. A partir de ahora, nosotros somos los que tenemos el control del protocolo, ya que los encabezados son opacos para los sistemas que dependen del contenido.
Hay muchas más anécdotas sobre la historia de QUIC, que han quedado registradas en GitHub, en los archivos de las listas de distribución de correo y en la memoria de la gente que participó en las conversaciones donde se concibió este protocolo. De hecho, en un artículo que he escrito sobre la maduración de QUIC, hablo sobre su historia.
Volviendo al presente, QUIC es el protocolo invisible que todos utilizamos, pero ¿ahora qué? ¿Qué podemos hacer con el protocolo TCP nuevo?
QUIC se creó para la web y casi todos los navegadores admiten ya de forma nativa QUIC. iOS y Microsoft lo admiten en el ámbito de la plataforma y la mayoría de proveedores de plataformas de CDN también lo hacen.
No obstante, la web solo actúa como un vehículo para conseguir que QUIC llegue a los stacks del cliente y el servidor, y es que, en realidad, QUIC es un protocolo y una plataforma a la vez. MASQUE proporciona túneles que sirven para ocultar tu identidad. Por ejemplo, de esta base también parten Relay privado de iCloud y el producto de Relay que hemos desarrollado con INVISV.
Ya eres un integrante más de la lista de pioneros que han trabajado para construir internet, pero la sombra de estos es muy alargada. ¿Qué papel crees que ocuparás en todo este legado?
No sé qué decirte. He hablado con algunos y ninguno de ellos esperaba tener la repercusión que tuvo. Por ejemplo, IPv4 se suponía que era un experimento, no el internet de producción. Por eso, los mejores resultados no se obtienen teniendo en mente la repercusión de estos, sino esforzándose para trabajar lo mejor posible. QUIC ha sido el arduo trabajo de una gran comunidad con varias personas con capacidad de liderazgo.
Mentiría si dijera que en ningún momento aspiré a tener cierta repercusión, ya que habíamos afrontado un desafío muy interesante. Llevo trabajando 23 años en el ámbito de los protocolos de transporte y ya había intentado realizar otros despliegues en el pasado. De hecho, me llamo a mí mismo «el patrón de los transportes fallidos». Se necesitaron muchas personas para hacer realidad QUIC y alcanzar la fase de despliegue en la que se encuentra en la actualidad. Me muero de ganas de saber qué nos deparará el futuro.
Este artículo forma parte de la serie Privacy Week, en la que explicamos cómo Fastly integra su tecnología y sus prácticas de privacidad en la propia red de internet.
