HTTP / 3 es la próxima generación del protocolo HTTP. Está impulsado por QUIC, que reemplaza a TCP en la capa de transporte y reduce la cantidad de viajes de ida y vuelta que un cliente debe realizar para determinar una conexión.
¿Qué lo hace mejor?
Si no puede saberlo por el acrónimo «QUIC», HTTP / 3 es mucho más rápido.
HTTP es solo parte del Modelo OSI, que impulsa Internet tal como lo conocemos. Cada capa del modelo tiene un propósito distinto, con API de alto nivel como HTTP ubicadas en la parte de arriba (la capa de aplicación), hasta los cables físicos y las conexiones que se conectan a los enrutadores:
Pero hay un cuello de botella en este modelo y, a pesar del nuevo nombre, el estándar HTTP en sí no es el problema.
TCP (la capa de transporte) es el culpable aquí; fue diseñado en los años 70 y, como tal, no fue construido para manejar muy bien la comunicación en tiempo real. HTTP-over-TCP ha alcanzado su límite. Google y el resto del espacio tecnológico han estado trabajando en un reemplazo para TCP.
En 2012, Google creó SPDY, un protocolo que se basa en TCP y soluciona muchos problemas comunes. SPDY en sí está en desuso, pero partes de él se abrieron paso en HTTP / 2, que en este momento utiliza 40% de la web.
QUIC es un nuevo estándar, muy parecido a SPDY, pero está construido sobre UDP en lugar de TCP. UDP es mucho más rápido que TCP, pero de forma general es menos confiable puesto que no tiene la misma verificación de errores y prevención de pérdidas que TCP. Se utiliza comúnmente en aplicaciones que no requieren que los paquetes estén en el exacto orden correcto, pero se preocupan por la latencia (como las videollamadas en vivo).
QUIC sigue siendo confiable, pero implementa su verificación de errores y confiabilidad al mismo tiempo de UDP, por lo que obtiene lo mejor de ambos protocolos. La primera vez que un usuario se conecta a un sitio habilitado para QUIC, lo hará a través de TCP.
El principal problema con TCP que corrige QUIC es el bloqueo de cabecera. Una vez que se establece una conexión entre el servidor y el cliente, el servidor envía paquetes de datos al cliente. Si la conexión es mala y se pierde un paquete, el cliente retiene todos los paquetes recibidos después de eso hasta que el servidor retransmite el paquete perdido. HTTP / 2 soluciona este problema de alguna manera, al permitir múltiples transferencias a través de la misma conexión TCP, pero no es perfecto y en realidad puede ser más lento que HTTP / 1 con conexiones de alta pérdida.
QUIC soluciona este problema y se encarga mucho mejor de las conexiones de alta pérdida. Las primeras pruebas de Google mostraron mejoras de alrededor del 15% en escenarios de alta latencia y hasta un 30% de mejoras en el almacenamiento en búfer de video en conexiones móviles. Debido a que QUIC reduce la cantidad de apretones de manos que se deben realizar, habrá mejoras de latencia en todos los ámbitos.
¿Es difícil de poner en práctica?
Aunque QUIC es un nuevo estándar, se basa en UDP, que ya es compatible en casi todas partes. No requerirá nuevas actualizaciones del kernel, lo que puede ser problemático para los servidores. QUIC debería funcionar de inmediato en cualquier sistema que admita UDP
HTTP-over-QUIC debería ser un reemplazo directo de HTTP-over-TCP una vez que esté disponible. En el momento de escribir este post, Chrome es compatible con QUIC, pero está deshabilitado de forma predeterminada. Puede habilitarlo para realizar pruebas yendo a:
chrome://flags
y activando la bandera «Protocolo QUIC experimental». Firefox agregará soporte a finales de este otoño, y con Edge moviéndose a Chromium, además recibirán soporte pronto.
En el extremo del servidor, si está usando CloudFlare como su CDN, podrá habilitar la opción ya en su panel, aún cuando no tendrá muchos clientes usándola hasta que los navegadores móviles la tengan activada de forma predeterminada. Rápidamente es trabajando activamente en el apoyo. A pesar de esto, si desea habilitarlo en su servidor web, tendrá que esperar un poco; el soporte temprano para QUIC está programado para llegar a lo largo del ciclo de desarrollo de nginx 1.17, pero el soporte de Apache aún no está a la vista.
Una vez que nginx y Apache se actualicen para admitirlo, agregar QUIC a su página web o aplicación web será tan simple como actualizar su servidor web y habilitar la opción. No tendrá que realizar ningún cambio en su aplicación o su código, puesto que todo se maneja a nivel de infraestructura. Aún no está aquí, pero llegará muy pronto, y definitivamente querrá habilitarlo una vez que sea compatible de forma predeterminada.
