Hoy continuaremos con la cadena de artículos sobre el protocolo HTTP/3, hablando sobre la evolución de las conexiones.
Para obtener un mayor entendimiento sobre la evolución de las conexiones en Internet, es necesario profundizar sobre las diversas capas que forman la red. La mejora de las conexiones ha venido ligada, en su mayor parte, a la constante mejora de los medios físicos sobre los que se realiza la conexión, a la llegada de la fibra óptica, a la creación de nuevos protocolos de conexiones inalámbricas con mayor ancho de banda y al diseño de cables de mayor categorización, lo que ha permitido en su conjunto un mayor flujo de datos. Esto ha dado lugar a que los servicios publicados en Internet permitan un mayor consumo de información, evolucionando desde los antiguos sitios web estáticos con escaso formato, basados en HTML 4, a sitios web mucho más elaborados, con alto contenido visual.
Pero el crecimiento de las redes y las constantes mejoras sobre la velocidad de conexión no han sido el único facilitador de esta evolución, los distintos protocolos que intervienen en las conexiones de red han jugado también un papel fundamental, aplicando mejoras no sólo a nivel de optimización, sino también de seguridad, en busca de la protección de la confidencialidad, la disponibilidad e integridad de los datos que canalizan.
Evolución de HTTP: Mejoras en la capa de aplicación
Las primeras mejoras ligadas al mundo de la Web vienen de la mano de la definición de HTML, en la que en las primeras versiones sólo permitían la estructuración de la información y unas pautas muy genéricas sobre estilos visuales, que han ido evolucionando en busca de una mejor experiencia de usuario. Entre los cambios más destacables, se debe reseñar la llegada y la integración de elementos Javascript dentro de la web, que junto con las hojas de estilo CSS3, dieron lugar a su última revisión, HTML5.
HTTPs y las comunicaciones cifradas
Con la expansión de Internet, el lanzamiento de nuevos servicios por parte de las empresas, y en especial, el lanzamiento de plataformas de compras online y de banca electrónica, fue necesario el diseño de sistemas de seguridad que permitieran garantizar la confidencialidad e integridad de la información transmitida. La primera aproximación a la solución llegó de la mano de Netscape Communications, que definió HTTPS en 1992 para su navegador Netscape Navigator, haciendo uso de SSL.
Años más tarde, en el año 2000, HTTPS fue adoptado como un estándar web, con la publicación de la RFC 2818, en la que se trataba el uso de HTTP sobre TLS, con el fin de garantizar, de igual manera que con SSL, el cifrado de las comunicaciones HTTP.
Con el paso de los años, SSL y TLS han ido evolucionando con nuevas versiones, pero sus fallos de diseño con importantes vulnerabilidades como “Beast” para SSL y TLS (CVE-2011-3389), “Crime” (CVE-2012-4929), “Heartbleed” para TLS (CVE-2014-0160), “Poodle” para SSL 3 (CVE-2014-3566), “Freak” (CVE-2015-0204) o “Logjam” (CVE-2015-4000), han puesto de manifiesto la necesidad de rediseñar los protocolos de cifrado utilizados hasta el momento.
SPDY: Mejoras en la capa de sesión
SPDY es un protocolo de nivel de sesión, ya obsoleto, complementario al protocolo HTTP, que funcionaba sobre TCP/IP. Fue lanzado por Google en 2009 con el objetivo de mejorar el rendimiento en las comunicaciones entre servidor y cliente. Permitía flujos simultáneos ilimitados a través de una sola conexión TCP. Debido a que las solicitudes se intercalaban en un solo canal, la eficiencia de TCP era mucho mayor, al necesitar menos conexiones de red y menos paquetes, aunque con mayor densidad.
SPDY ha contado con el soporte de navegadores como Internet Explorer, Google Chrome, Mozilla Firefox y Opera, sin embargo, a comienzos de 2015, Google anunció el fin del soporte para SPDY, tras la ratificación final del estándar HTTP 2. Google Chrome dejó de soportar SPDY en su versión 51.2 y Mozilla Firefox en su versión 50.
HTTP 2: Optimizando la capa de aplicación y sesión
Siguiendo con el desarrollo de SPDY promovido por Google, el IETF (Internet Engineering Task Force) creó un equipo para el desarrollo de una nueva revisión del protocolo protocolo HTTP. A parte del uso de una única conexión para todo el tráfico HTTP, se añadieron mejoras como la multiplexación, que permite el envío de paquetes de manera simultánea; la compresión de las cabeceras (HPACK), siendo esta una de sus mayores virtudes y las mejoras añadidas en la caché, con el servicio “cache push”, que permiten al servidor enviar de antemano recursos que considera que el cliente va a necesitar en un futuro, ahorrando así gran cantidad de peticiones. Aunque se trata de un protocolo reciente, cuya definición data de Mayo de 2015, ya hay un 32,2% de sitios webs que soportan este protocolo.
QUIC: Mejoras en la capa de transporte
Hasta el momento, pocas eran las mejoras realizadas a nivel de capa de transporte para mejorar el rendimiento y la seguridad de las comunicaciones entre cliente y servidor, y este fue uno de los principales motivos por los que Google decidió lanzar el protocolo QUIC.
QUIC llegó en 2014 para resolver una serie de problemas a nivel de capa de transporte y de aplicación experimentados por las aplicaciones web modernas. QUIC es muy similar a TCP + TLS + HTTP / 2, con la diferencia de que se encuentra implementado sobre UDP. Esto permite mejorar la latencia de establecimiento de conexión, el control de la congestión, el multiplexado sin bloqueos por congestión, y la corrección de errores directa, entre otros. Pero sobre esto os hablaremos en el próximo post de la cadena.
Saludos!
No hay comentarios:
Publicar un comentario