Qué pasa cuando abres una página web

Con un viaje de ida y vuelta de 50 ms, una página HTTPS necesita al menos 4 viajes de ida y vuelta, 200 ms, antes de que llegue el primer byte de HTML. HTTP/3 ahorra uno.

Las siete y cuarenta de la mañana. Una estudiante en un tren lleno toca, con datos móviles, un enlace al menú del comedor escolar, y un momento después aparece el menú de hoy. (Es una escena inventada.) En ese momento el teléfono hizo todo lo de las cinco unidades anteriores: una búsqueda DNS, una conexión TCP, una sesión cifrada y una solicitud HTTP respondida con un código de estado. Sigue al teléfono en el proceso y cuenta las esperas.

Primero el teléfono lee el enlace

Supón que el enlace es https://www.example.com/index.html. MDN divide una URL en partes. https es el esquema: usar HTTP sobre una conexión TLS cifrada, en el puerto 443 salvo que se escriba otro puerto. www.example.com es el host, el nombre que el DNS convertirá en una dirección. /index.html es la ruta, el recurso que se pide en ese servidor. Una URL también puede llevar una consulta después de un signo de interrogación y un fragmento después de una almohadilla. El fragmento señala un punto dentro de la página y nunca se envía al servidor.

Cuatro viajes de ida y vuelta antes del primer byte

El tiempo que tarda un mensaje en llegar al servidor y la respuesta en volver es el tiempo de ida y vuelta (RTT). Cuenta los viajes de ida y vuelta y verás de dónde sale la espera. Uno: si el nombre no está en caché, la búsqueda DNS cuesta más o menos un viaje de ida y vuelta al resolutor. Dos: el saludo TCP, SYN de ida y SYN-ACK de vuelta. Tres: TLS 1.3 (RFC 8446) acuerda las claves en un viaje de ida y vuelta, y el último mensaje del saludo del cliente puede viajar junto con la solicitud HTTP. Cuatro: sale la solicitud y vuelve la respuesta. Con un RTT de 50 ms, son 200 ms antes del primer byte del menú, aunque el servidor responda al instante.

HTTP/3 (RFC 9114) funciona sobre QUIC (RFC 9000) en lugar de TCP. QUIC va sobre UDP y establece la conexión y las claves TLS a la vez, así que desaparece el viaje de ida y vuelta separado de TCP: DNS, un viaje de ida y vuelta de saludo y luego la solicitud, tres en total. HTTP simple en el puerto 80 se salta TLS y también necesita tres, pero entonces cualquiera en el camino, como quien gestiona el wifi de una cafetería, puede leer o cambiar la página. El candado de la barra de direcciones significa que la conexión con ese dominio está cifrada. No significa que el sitio en sí sea honesto.

El menú llega con un número delante

La respuesta empieza con un código de estado de tres cifras. El RFC 9110 agrupa los códigos por su primera cifra: 1xx informativos, 2xx éxito, 3xx redirección, 4xx error del cliente y 5xx error del servidor. Los que más verás son 200 OK, 301 Moved Permanently (la página tiene una dirección nueva), 404 Not Found y 500 Internal Server Error. Si la escuela hubiera mudado la página del menú, el teléfono recibiría primero un 301 y luego volvería a pedirla en la dirección nueva. Un 404 significa que el servidor respondió y no tenía nada en esa ruta, así que la red en sí funcionaba.

Una página, muchos archivos

El HTML casi nunca es la página entera. Supón que menciona una hoja de estilos, un script y cinco imágenes. Si el teléfono abriera una conexión nueva para cada uno, cada archivo pagaría otra vez los viajes de ida y vuelta de TCP y TLS. En cambio, el navegador mantiene abierta la conexión y envía por ella las siguientes solicitudes, y con HTTP/2 y HTTP/3 varias solicitudes viajan a la vez por una misma conexión. Los navegadores también tienen su propia caché. Cuando una respuesta dice que se puede reutilizar durante un tiempo, la siguiente visita carga ese archivo desde el almacenamiento sin enviar ninguna solicitud. Solo cuando ya están los archivos, el navegador organiza y pinta lo que ves. Por eso la página del menú que la estudiante abre cada mañana aparece más rápido que un sitio abierto por primera vez, incluso en la misma red.