O que acontece quando você abre uma página da web

Com uma ida e volta de 50 ms, uma página HTTPS precisa de pelo menos 4 idas e voltas, 200 ms, antes que o primeiro byte do HTML chegue. O HTTP/3 corta uma.

Sete e quarenta da manhã. Um aluno em um trem lotado toca em um link para o cardápio do almoço da escola usando os dados móveis, e um instante depois o cardápio do dia aparece. (Esta cena é inventada.) Nesse instante o celular fez tudo das últimas cinco unidades: uma consulta DNS, uma conexão TCP, uma sessão criptografada e uma requisição HTTP respondida com um código de status. Acompanhe o celular e conte as esperas.

Primeiro o celular lê o link

Digamos que o link seja https://www.example.com/index.html. O MDN divide uma URL em partes. https é o esquema: usar HTTP sobre uma conexão TLS criptografada, na porta 443, a não ser que outra porta esteja escrita. www.example.com é o host, o nome que o DNS vai transformar em endereço. /index.html é o caminho, o recurso pedido naquele servidor. Uma URL também pode levar uma consulta depois de um ponto de interrogação e um fragmento depois de uma cerquilha. O fragmento aponta para um lugar dentro da página e nunca é enviado ao servidor.

Quatro idas e voltas antes do primeiro byte

O tempo para uma mensagem chegar ao servidor e a resposta voltar é o tempo de ida e volta (RTT). Conte as idas e voltas e você vê de onde vem a espera. Um: se o nome não está em cache, a consulta DNS custa cerca de uma ida e volta até o resolvedor. Dois: o handshake do TCP, SYN indo e SYN-ACK voltando. Três: o TLS 1.3 (RFC 8446) combina as chaves em uma ida e volta, e a última mensagem do handshake do cliente pode viajar junto com a requisição HTTP. Quatro: a requisição vai e a resposta volta. Com um RTT de 50 ms, são 200 ms antes do primeiro byte do cardápio, mesmo que o servidor responda na hora.

O HTTP/3 (RFC 9114) roda sobre QUIC (RFC 9000) em vez de TCP. O QUIC fica sobre o UDP e estabelece a conexão e as chaves TLS ao mesmo tempo, então a ida e volta separada do TCP desaparece: DNS, uma ida e volta de handshake e depois a requisição, três no total. O HTTP simples na porta 80 pula o TLS e também precisa de três, mas aí qualquer um no caminho, como quem administra o Wi-Fi de um café, pode ler ou alterar a página. O cadeado na barra de endereço quer dizer que a conexão com aquele domínio está criptografada. Não quer dizer que o site em si seja honesto.

O cardápio chega com um número na frente

A resposta começa com um código de status de três dígitos. A RFC 9110 agrupa os códigos pelo primeiro dígito: 1xx informativo, 2xx sucesso, 3xx redirecionamento, 4xx erro do cliente e 5xx erro do servidor. Os que você mais vai encontrar são 200 OK, 301 Moved Permanently (a página tem um novo endereço), 404 Not Found e 500 Internal Server Error. Se a escola tivesse mudado a página do cardápio de lugar, o celular primeiro receberia um 301 e depois pediria de novo no novo endereço. Um 404 quer dizer que o servidor respondeu e não tinha nada naquele caminho, então a rede em si estava funcionando.

Uma página, muitos arquivos

O HTML raramente é a página inteira. Digamos que ele mencione uma folha de estilo, um script e cinco imagens. Se o celular abrisse uma conexão nova para cada um, todo arquivo pagaria de novo as idas e voltas do TCP e do TLS. Em vez disso, o navegador mantém a conexão aberta e envia as próximas requisições por ela, e com HTTP/2 e HTTP/3 várias requisições viajam pela mesma conexão ao mesmo tempo. Os navegadores também têm o próprio cache. Quando uma resposta diz que pode ser reutilizada por um tempo, a próxima visita carrega esse arquivo do armazenamento sem enviar nenhuma requisição. Só quando os arquivos chegam é que o navegador monta o layout e desenha o que você vê. É por isso que a página do cardápio que o aluno abre toda manhã aparece mais rápido do que um site aberto pela primeira vez, mesmo na mesma rede.