Paz no localhost e ilusões quebradas
Quando eu estava na escola, meu mundo inteiro era localhost. Mesmo que eu instalasse algo como o XAMPP e criasse um quadro de avisos usando PHP, era um mundo que só rodava no meu computador.
Quando entrei na empresa, tive a sorte de ser o principal responsável pela manutenção front-end. Era uma página de administração baseada em Quasar (Vue.js), e a dificuldade da tarefa não era alta. Tudo o que tive que fazer foi corrigir o erro de digitação ou chamar a API que meus superiores já haviam criado bem com axios.get() e exibi-la na tela.
Naquela época, axios era como uma varinha mágica para mim. Mesmo não conhecendo os princípios complicados, acabei de inserir a URL e os dados foram recuperados rapidamente. Também tive um pensamento atrevido: “Não há nada de especial na comunicação entre o front-end e o back-end, certo?”
Mas a paz não durou muito. Isso ocorre porque eu era um desenvolvedor full-stack de estilo de vida em uma empresa de pequeno e médio porte que não tinha mão de obra.
Logo chegou o momento em que tive que criar minha própria API para uma nova função, em vez de modificar a tela. Iniciei um servidor usando Spring Boot, que aprendi rapidamente no YouTube, e enviei uma solicitação do front-end. No entanto, tudo o que apareceu na minha tela foram erros de CORS e erros de Timeout vermelhos, não dados.
“Funcionou bem quando passei como uma variável local, mas por que não posso simplesmente usar a rede?”
Mover a variável A para a variável B no meu computador (Localhost) foi um método 100% seguro e garantido. Mas o mundo fora do cabo LAN era diferente. Era como um cruzamento com um semáforo quebrado, e meus dados eram um caminhão dirigindo naquela estrada perigosa. Todo esse tempo eu estava apenas carregando o caminhão e enviando, mas não tinha ideia de qual rota o caminhão fazia ou como ele estava dividido.
Sistema de entrega em centro logístico digital
Vamos expandir a visão de mundo do nosso “centro de logística digital”. Agora temos que entregar os itens (dados) fabricados em nossa fábrica (computador) para clientes (servidores) distantes.
1. Pacote: Caixa de envio padrão
Não importa o tamanho dos dados que queremos enviar (por exemplo, um vídeo de 1 GB), eles não podem ser enviados todos de uma vez. Isso ocorre porque as estradas são estreitas e os caminhões são pequenos. Então cortamos os dados em pedaços bem pequenos e os colocamos em caixas padronizadas. Este é um ‘Pacote’.
2. IP (Protocolo de Internet): Endereço e navegação
O que posso fazer se tiver apenas uma caixa? Você precisa saber para onde ir.
3. TCP/UDP: diferenças nos métodos de entrega
Agora precisamos decidir para qual caminhão enviar as caixas.
[Verificação de código] A verdadeira face do HTTP é apenas texto
O HTTP que normalmente usamos é, na verdade, apenas o ‘conteúdo da carta’ transportado em um caminhão de entrega chamado TCP. Vamos conversar com o servidor Naver da forma mais primitiva (Socket) sem navegador ou biblioteca. Você verá como o HTTP é simples, apenas um pedaço de texto.
import socket
# 1. Criar socket TCP (atender o telefone)
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
# 2. Conectar ao servidor Naver (223.130.195.200) na porta 80 (discar)
# O IP do Naver pode mudar (verifique com nslookup [www.naver.com](https://www.naver.com))
target_host = "[www.naver.com](https://www.naver.com)"
target_port = 80
sock.connect((target_host, target_port))
# 3. Escrever mensagem de requisicao HTTP (montar o que voce vai falar)
# Forma mais bruta de uma requisicao HTTP
request = "GET / HTTP/1.1rnHost: [www.naver.com](https://www.naver.com)rnrn"
# 4. Enviar (falar)
sock.send(request.encode())
# 5. Receber resposta (ouvir)
response = sock.recv(4096)
print(response.decode())
# 6. Encerrar conexao (desligar)
sock.close()
Resultados da execução (parciais):
HTTP/1.1 200 OK
Server: NWS
Date: Mon, 01 Jan 2024 00:00:00 GMT
Content-Type: text/html; charset=UTF-8
...
<html>...</html>
Análise: isso é tudo o que acontece internamente quando chamamos axios.get().
HTTP não é uma tecnologia especial, é apenas uma promessa feita de “trocar textos usando este protocolo (protocolo) quando nos comunicamos”.
Compensação na prática: confiabilidade ou velocidade
Na prática, especialmente no desenvolvimento back-end, chega um momento em que você precisa decidir entre TCP e UDP. (Claro, a maioria usa HTTP baseado em TCP)
HTTP/3, que é frequentemente perguntado em perguntas de entrevistas recentes, é o produto dessa compensação. A Internet que usamos (HTTP/1.1, HTTP/2) funciona em TCP. Porque os dados nunca devem ser destruídos.
Mas os tempos mudaram. As pessoas querem assistir a vídeos em 4K sem interrupção. O meticuloso processo de verificação do TCP (Handshake) e recursos como “Filar na fila (Bloqueio do chefe de linha)” agora se tornaram frustrantes.
Foi o que o Google pensou. “Ei, vamos usar o UDP. Podemos apenas cuidar do desconforto no nível do aplicativo. É importante enviá-lo rapidamente!”
Este é o protocolo QUIC e é a base do HTTP/3. É uma tendência da tecnologia moderna que abandonou a estabilidade incondicional (TCP) e escolheu a velocidade avassaladora (UDP), mesmo que isso significasse correr alguns riscos.
Encerramento: imagine uma estrada invisível
Agora sabemos como os dados são divididos (pacotes) e em qual caminhão (TCP/UDP) eles viajam.
Quando uma solicitação de API falha no front-end, não pense apenas: “O servidor está morto?” como antes. “Ah, o handshake de três vias falhou? O pacote foi descartado pelo roteador no meio? Ou o DNS não encontrou o endereço?” Se você consegue imaginar uma camada de rede como esta, você não é mais ‘apenas um programador’
Agora, as mercadorias de nossa fábrica chegaram com segurança ao cliente. Mas como um cliente recebe esse item, desembala e mostra na tela? Como o código HTML que enviamos será exibido no navegador?
Na próxima vez, falaremos sobre o destino final do desenvolvimento web, os princípios da renderização do navegador.