http connection lifecycle
1.0.0
Índice
Na entrevista técnica ou em outro lugar, as perguntas mais frequentes são: o que acontece quando você digita um URL no navegador? O que acontece nos bastidores quando você navega em um site? O que implica um ciclo de vida típico de conexão HTTP? Responderei a essas perguntas com o melhor de meu conhecimento.
Antes de mergulhar no processo de conexão, vamos examinar o modelo OSI básico (modelo de interconexão de sistemas abertos). O modelo OSI é um modelo conceitual que padroniza a comunicação entre dois sistemas - um onde a solicitação se origina (o cliente) e outro que atende a solicitação e envia uma resposta de volta (o servidor). A tabela abaixo mostra algumas das características importantes de cada camada.
| Não | Camada | Hardware | Função | Protocolos/aplicativos | Adições |
|---|---|---|---|---|---|
| 7 | Aplicativo | Servidor/PC | Aplicativos, interface do usuário | HTTP, SMTP, DNS | Cabeçalho L7 |
| 6 | Apresentação | Servidor/PC | Lida com alterações de criptografia e sintaxe | JPEG, MP3 | Cabeçalho L6 |
| 5 | Sessão | Servidor/PC | Autenticação, permissões, sessões | SCP, agendamento do sistema operacional | Cabeçalho L5 |
| 4 | Transporte | Firewall | Entrega ponta a ponta, controle de erros | TCP, UDP | Cabeçalho L4 |
| 3 | Rede | Roteadores | Endereçamento de rede, roteamento, comutação | PI | Cabeçalho L3 |
| 2 | Link de dados | Interruptores | Endereço físico, detecção de erros, fluxo | Ethernet, Frame Relay | Cabeçalho/Trailer L2 |
| 1 | Físico | Cabos | Bit transferido pela rede física | EIA/TIA | Cabeçalho L1 |
Assim que você digitar o URL no navegador e pressionar a tecla Enter/Return, o navegador (ou qualquer cliente) analisará o URL [1] para extrair componentes importantes dele. Um exemplo de URL é fornecido abaixo:
https://www.google.com/search?q=cats
Aqui estamos apenas procurando gatos no Google. No URL acima, https:// é o protocolo, google.com é o host em www (internet), /search é o parâmetro de caminho e ?q=cats é o parâmetro de string de consulta que indica que estamos consultando gatos no Google [ 2].
Agora, como o navegador conhece o host que está tentando acessar, neste caso google.com , ele tentará obter os endereços IP correspondentes. Domínios como ‘ .com’ ou ‘ .org’ foram criados para que possamos lembrá-los facilmente. Mas para que o navegador envie a solicitação real, digamos, google.com, ele precisa do endereço IP do host. A resolução DNS nos ajuda a obter informações de endereço IP para um determinado nome de domínio. O DNS reside na camada de aplicativo (L7) da tabela acima.
Etapas na resolução de DNS:
$ ipconfig /displaydns no Windows ou $ log stream --predicate 'process == "mDNSResponder"' --info no mac/linux..com , .org , etc. são nomes de domínio de nível superior. O nome do TLD retornaria então o endereço IP do(s) servidor(es) de nomes autoritativo(s).$ dig google.com
; << >> DiG 9.10.6 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;google.com. IN A
;; ANSWER SECTION:
google.com. 180 IN A 172.217.164.174
;; AUTHORITY SECTION:
google.com. 60552 IN NS ns1.google.com.
google.com. 60552 IN NS ns2.google.com.
google.com. 60552 IN NS ns3.google.com.
google.com. 60552 IN NS ns4.google.com.
;; ADDITIONAL SECTION:
ns1.google.com. 60438 IN A 216.239.32.10
ns1.google.com. 58273 IN AAAA 2001:4860:4802:32::a
ns2.google.com. 60438 IN A 216.239.34.10
ns2.google.com. 131763 IN AAAA 2001:4860:4802:34::a
ns3.google.com. 163770 IN A 216.239.36.10
ns3.google.com. 60541 IN AAAA 2001:4860:4802:36::a
ns4.google.com. 75597 IN A 216.239.38.10
ns4.google.com. 60541 IN AAAA 2001:4860:4802:38::a
;; Query time: 13 msec
;; SERVER: 10.4.4.10#53(10.4.4.10)
;; WHEN: Mon Jun 24 12:20:50 PDT 2019
;; MSG SIZE rcvd: 303Em cada camada do modelo OSI, a informação é chamada de PDU (Packet Data Unit). Portanto, as informações na camada de aplicação são chamadas de PDU L7, enquanto as informações na camada de rede são chamadas de PDU L3. Em cada camada, um cabeçalho de camada correspondente é adicionado. O cabeçalho precede seu corpo e contém o endereçamento e outros dados necessários para chegar ao destino pretendido. Os dados, por outro lado, são passados da camada superior para baixo. Os cabeçalhos L4, L3 e L2 são mostrados abaixo:
Antes de o pacote ser enviado para a Internet para finalmente chegar ao servidor de domínio do Google, ele primeiro precisa ser roteado através do roteador. Sempre que um dispositivo precisa se conectar fisicamente a outro dispositivo (neste caso, o roteador local), ele precisa do endereço MAC (endereço de hardware) desse dispositivo. Mas como a máquina local sabe que o roteador é a rota de saída padrão? Essas informações são adquiridas por meio da rota padrão configurada por interface na máquina local. Você pode verificar a rota padrão usando o comando $ ifconfig .
O endereço IP é usado para localizar um dispositivo na rede, enquanto o endereço MAC é usado para identificar o dispositivo real. O protocolo ARP é utilizado para adquirir o endereço MAC do dispositivo, dado o conhecimento do endereço IP. Aqui assumiremos que a máquina solicitante já recebeu um endereço IP (estaticamente ou através do protocolo DHCP).
O ARP reside na camada de enlace de dados do modelo OSI. Neste caso, o navegador da web em execução na máquina local se conectará ao roteador, que é uma porta de entrada para a Internet.
arp -a .Os pacotes são então roteados para a rota padrão. Se você não tiver uma rota padrão definida, eles serão roteados para o roteador. Você pode verificar a rota padrão usando o comando
route get default | grep gateway ou netstat -rn no mac/linux ou ipconfig no windows.
Por exemplo, se você estiver em uma rede 192.168.10.0/24 e tentando acessar a rede do Google em 172.217.164.174/24, por exemplo, quando o pacote chegar ao roteador, o roteador verificará a tabela de roteamento e decidirá como rotear o tráfego para chegar à rede de destino. Portanto, ele enviará o pacote para o gateway especificado para chegar ao destino 172.217.164.174/24
Conexão entre cliente e servidor; neste caso, sua máquina local para o servidor do Google leva muitos saltos. Cada salto é essencialmente um roteador ao longo do caminho até o destino. O roteador aqui ajuda a solicitação a ir de uma rede para outra. Cada dispositivo em seu caminho possui um endereço MAC (endereço de hardware) que é globalmente único.
Agora a máquina local cria uma solicitação com cabeçalho L7 (HTTP), cabeçalho L4 (TCP), cabeçalho L3 (IP), cabeçalho L2 (ARP, endereços MAC), trailer L2 (sequência de verificação de quadro) e os dados reais. Quando o roteador recebe o pacote, ele desencapsula, modifica o cabeçalho/trailer L2 e encapsula o pacote novamente.
O roteador agora o recebe e começa a desencapsular. Ele olha para o cabeçalho L2 e vê o mac de destino por si só. Agora ele remove o cabeçalho L2 e agora olha para o cabeçalho L3 e entende que a solicitação não é para si, mas para o servidor do Google. O roteador então diminui o valor TTL que está dentro do cabeçalho L3. O roteador agora procura em sua tabela de roteamento todas as rotas possíveis que os outros roteadores teriam anunciado para este roteador (via RIP ou IGP) sobre como chegar ao destino. Um roteador então faz ARP para obter o endereço MAC do roteador do próximo salto se ele não tiver o endereço MAC em seu cache.
O roteador também adiciona CRC que segue para o trailer L2. Isso ajuda o próximo roteador a saber que não ocorreram problemas nas rotas que fizeram com que o pacote fosse corrompido na rede. Se estiver corrompido, o quadro será eliminado.
Neste caso, o roteador modificou o cabeçalho L2 e o trailer L2, mas não tocou no cabeçalho L3 e, portanto, nenhum cabeçalho acima dele.
Porta de origem não. será um número de porta efémero e o número da porta de destino será 80.
TCP - Serviço confiável e de mesma ordem. A primeira coisa que a máquina local fará é estabelecer um handshake triplo com o servidor do Google agora, já que ela conhece a rota para o servidor. O estabelecimento da conexão ajuda a finalizar algumas variáveis de estado, como tamanho do MSS, número de sequência inicial, tipo de ACK, tamanho do buffer, etc.
Neste caso, a porta de origem e de destino no cabeçalho TCP é de 16 bits, então 2 ^ 16 é 65535. A porta de origem é usada para identificar o aplicativo cliente, enquanto a porta de destino é usada para identificar o serviço ou o demônio em execução no servidor web.
O cliente (navegador da web) seleciona qualquer porta de 49152 a 65535. Isso garante que nenhum aplicativo use a mesma porta. O endereço da porta junto com o endereço IP é chamado de soquete TCP. A porta de destino é a porta 80 no pacote IP.
Comece a comunicação:
Com as três etapas acima, o handshake TCP é bem-sucedido entre o cliente e o servidor e ambos agora concordam com as regras comuns para transferência de dados.
Após o handshake TCP, o handshake TLS ocorrerá se você estiver se conectando a um site seguro. Com o handshake TLS, o cliente e o servidor concordam com os termos comuns de comunicação segura.
A partir de agora a sessão TLS transmite os dados da aplicação (HTTP) criptografados com a chave simétrica acordada.
O servidor processa as solicitações e envia de volta uma resposta apropriada. Quando a solicitação chega ao servidor na porta 80 (HTTP) ou na porta 443 (HTTPS), um servidor web como Apache ou Nginx escuta a porta 443, trata a conexão da solicitação e a encaminha para outra porta efímera na qual o serviço web está correndo.
Qualquer cliente, servidor ou proxy HTTP pode fechar uma conexão de transporte TCP a qualquer momento. Por exemplo, quando o cliente detecta que a transferência de dados terminou e o canal de conexão aberto não é mais necessário, ele envia uma solicitação de fechamento de conexão ao servidor. Na próxima vez que o cliente quiser se comunicar com o servidor, uma nova conexão deverá ser estabelecida entre as duas máquinas.
| [1] | O padrão de URL |
| [2] | Componentes ou URL |
