DEV Community

Cover image for Como o navegador funciona
Helton
Helton

Posted on

Como o navegador funciona

Uma das lacunas de conhecimento importantes que precisamos preencher quando trabalhamos com desenvolvimento web é sobre como o navegador funciona, e é isso que iremos tratar neste curto artigo.

O primeiro passo para iniciar uma navegação pela web é fazer uma requisição web, e isso pode ser feito de algumas maneiras possíveis, mas principalmente digitando uma URL na barra de endereço do navegador.

DNS Lookup / Pesquisa de DNS

Logo após você digitar essa URL no navegador, o próximo passo da requisição é encontrar o servidor onde seus assets/recursos estão disponíveis.

O navegador faz uma pesquisa de DNS que vai direto para um servidor de nomes que responde diretamente com um endereço de IP/Internet Protocol. Após essa requisição, é criado um cache do IP para não ser mais necessário fazer a pesquisa novamente no servidor de nomes. Geralmente, isso é feito apenas uma vez por requisição ao hostname.

TCP Handshake / Negociação TCP

Uma vez que temos um endereço de IP conhecido, o navegador estabelece uma conexão com o servidor através do TCP Handshake.

Como temos o navegador e o servidor web tentando se comunicar, eles precisam negociar os parâmetros da conexão trocados pelo TCP da rede antes de transmitir esses dados, frequentemente sobre HTTPS.

Como isso é feito?

Precisamos do three-way handshake que é responsável por estabelecer conexões TCP. O funcionamento é executado por meio de 3 passos:

  1. O Cliente envia um pacote que tem uma flag SYN (synchronize) ativa para um servidor.
  2. O servidor recebe esse pacote e responde com um pacote com as flags SYN + ACK (synchronize + acknowledgement).
  3. O cliente recebe o pacote do servidor SYN + ACK e responde com um pacote ACK.

O servidor, quando recebe esse último pacote, estabelece a conexão TCP.

Todo esse processo ocorre antes do DNS Lookup e depois do TLS Handshake, criando uma conexão segura. A conexão pode ser finalizada independentemente por cada lado da conexão, onde um par de mensagens FIN (finalizar) e ACK (acknowledgement) são enviadas e recebidas independentemente.

  1. O cliente envia um pacote FIN para o servidor.
  2. O servidor envia um pacote ACK de volta para o cliente.
  3. A conexão está entre aberta e o servidor ainda pode enviar dados. (Por exemplo, o servidor pode terminar de enviar dados para o cliente quando o cliente já fechou sua conexão com o servidor.)
  4. O servidor envia um pacote FIN para o cliente.

O cliente envia um pacote ACK de volta para o servidor, e assim se encerra o processo de finalização da conexão.

TLS Negotiation / Negociação TLS

Conexões seguras criadas sobre a camada HTTPS precisam de uma nova negociação entre cliente e servidor, onde a comunicação será criptografada, o servidor será verificado e estabelecerá que uma conexão segura está em vigor antes de iniciar a transferência real de dados. Isso requer mais cinco pedidos ao servidor.

1 ClientHello
O cliente envia uma mensagem ClientHello ao servidor contendo:

  • Versão do protocolo TLS.
  • Lista de algoritmos de criptografia suportados.

2 ServerHello
O servidor responde com uma mensagem ServerHello contendo:

  • Versão do protocolo TLS escolhida.
  • Algoritmos de criptografia selecionados.

3 Certificado do Servidor

  • O servidor envia seu certificado digital ao cliente para autenticação.

4 Client Key Exchange

  • O cliente gera uma chave pré-mestre, a cifra com a chave pública do servidor (obtida do certificado) e a envia ao servidor.
  • Change Cipher Spec (Cliente e Servidor): Ambos, cliente e servidor, enviam uma mensagem Change Cipher Spec para indicar que as mensagens subsequentes serão cifradas.

Finished (Cliente e Servidor): Ambos enviam uma mensagem Finished para confirmar que o handshake foi concluído com sucesso.

A imagem abaixo ilustra bem essas etapas.

Image description

A partir daqui, a comunicação é cifrada usando as chaves de sessão geradas.

Response / Resposta

Uma vez que nós estivermos com uma conexão estabelecida com o servidor, não importando se estamos em uma camada descriptografada (HTTP) ou criptografada (HTTPS), o navegador envia uma solicitação HTTP usando o verbo GET que, para sites, na maioria das vezes é apenas um HTML estático.

Essa resposta geralmente tem um conteúdo que é o primeiro dado de bytes recebido ou mais conhecido como Time To First Byte. Esse tempo para o primeiro byte é o tempo entre a solicitação do usuário e o recebimento do primeiro pacote.

Parece que acabou, mas essa é apenas a parte inicial do processo de navegação pela web. Após receber a resposta com o HTML estático, é preciso renderizá-lo na tela, o que chamamos de PARSING, e nesse passo o browser/navegador fica totalmente responsável, mas abordaremos isso em outro artigo.

Referências:

https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work

Referência: https://developer.mozilla.org/en-US/docs/Web/Performance/How_browsers_work

Top comments (3)

Collapse
 
msc2020 profile image
msc2020

Parabéns, @heltonss ! Ficou bem didático.

Um outro conteúdo bacana nessa linha é: developer.mozilla.org/pt-BR/docs/L....

Collapse
 
heltonss profile image
Helton

Muito obrigado por compartilhar o link.

Collapse
 
guiseek profile image
Guilherme Siquinelli

Muito bom em meu amigo? Gostei muito do seu conteúdo, parabéns!