Plataforma educacional técnica
Explore os protocolos, fluxos e mecanismos que fazem a Internet funcionar — do handshake TCP até DNS, CDN, TLS e Edge Computing.
Fundamentos
O modelo TCP/IP organiza responsabilidades para que aplicações, redes diferentes e tecnologias de enlace interoperem. Ele não é idêntico ao modelo OSI: o OSI tem sete camadas; o TCP/IP agrupa algumas delas em uma pilha prática.
Ao descer a pilha, cada camada adiciona controle. Dados da aplicação viram segmento TCP, pacote IP, quadro no enlace e sinais em bits. No destino, a remoção dos cabeçalhos ocorre no sentido inverso.
Aplicação, apresentação e sessão do OSI são tratadas como Aplicação no TCP/IP. Transporte corresponde diretamente; rede se aproxima de Internet; enlace e físico se aproximam de Enlace. O mapeamento auxilia o diagnóstico sem misturar os modelos.
Módulo 1 · Transporte
A camada de transporte multiplexa aplicações por portas e entrega dados ao processo certo. Um socket é normalmente associado a protocolo, IP e porta; uma conexão TCP se distingue pelo conjunto de IPs e portas de ambos os lados.
TCP é orientado à conexão e entrega bytes em ordem. Números de sequência detectam lacunas; ACKs confirmam o próximo byte esperado; perdas podem disparar retransmissão. A receiver window protege o receptor, enquanto a janela de congestionamento busca não sobrecarregar a rede.
ACKs normalmente são cumulativos: ao confirmar o próximo byte esperado, o receptor confirma implicitamente os bytes anteriores contíguos. Retransmissão pode vir de temporizador ou ACKs duplicados. Controle de congestionamento reduz a taxa diante de perda ou ECN.
O cliente envia SYN com seu ISN. O servidor responde SYN+ACK, reconhecendo o ISN do cliente e propondo o próprio. O ACK final confirma que o cliente recebeu a proposta. Isso sincroniza os espaços de sequência e reduz confusão com segmentos antigos.
IP identifica uma interface na rede; a porta identifica um ponto de comunicação no host. A porta 443 é convenção para HTTPS, mas um serviço pode escutar outra porta. O kernel encaminha dados ao processo pelo socket.
Além da capacidade do link, importam RTT, perda, filas e algoritmo de congestionamento. A janela efetiva do emissor é limitada pelo menor valor entre janela do receptor e janela de congestionamento.
A janela permite enviar mais de um segmento antes de aguardar confirmação. Bytes in flight são bytes enviados ainda não reconhecidos. Janela maior pode elevar vazão em RTT alto, desde que receptor e caminho suportem.
UDP não faz handshake, nem fornece ordenação, retransmissão, controle de fluxo ou congestionamento por si só. Tem cabeçalho menor e permite à aplicação decidir o que fazer com atraso e perda. É comum em DNS, VoIP, jogos, telemetria e streaming de tempo real.
UDP não é automaticamente “mais rápido”. Se a aplicação precisa recuperar e ordenar muito conteúdo, ela pode recriar complexidade. QUIC usa UDP como base, mas acrescenta confiabilidade, segurança e controle de congestionamento.
A escolha depende da semântica necessária, não de uma preferência universal.
| Característica | TCP | UDP |
|---|---|---|
| Conexão | Estabelece estado de conexão. | Não estabelece conexão de transporte. |
| Confiabilidade | Fluxo confiável enquanto a conexão é viável. | Não garante entrega. |
| Ordenação | Entrega bytes em ordem. | Datagramas podem chegar fora de ordem. |
| Retransmissão | Controlada pelo protocolo. | Responsabilidade da aplicação, se desejada. |
| Handshake | Three-way handshake típico. | Ausente. |
| Overhead | Mais estado e cabeçalho. | Cabeçalho de 8 bytes; menos estado. |
| Latência | Pode esperar ordenação e recuperação. | Evita espera do transporte, mas pode perder dados. |
| Controle de fluxo | Sim, receiver window. | Não nativo. |
| Congestion control | Sim. | Não nativo; aplicações devem cooperar. |
| Aplicações típicas | Web, e-mail, SSH, bancos de dados. | DNS, mídia em tempo real, jogos, QUIC. |
São convenções úteis, não vínculos rígidos: serviços podem ser configurados em outras portas.
| Porta | Uso comum | Observação |
|---|---|---|
| 20/21 | FTP | Dados e controle no FTP tradicional. |
| 22 | SSH | Acesso remoto e túnel. |
| 25 | SMTP | Transporte de e-mail entre servidores. |
| 53 | DNS | UDP é comum; TCP atende casos como transferências de zona. |
| 67/68 | DHCP | Servidor e cliente. |
| 80 | HTTP | Convenção para HTTP sem TLS. |
| 110 / 143 | POP3 / IMAP | Acesso a e-mail. |
| 443 | HTTPS | HTTP sobre TLS por convenção. |
Módulo 2 · Aplicação e segurança
HTTP é um protocolo de aplicação de requisição e resposta. Ele é stateless: o protocolo não exige que o servidor retenha contexto entre requests. Sessões podem existir por cookies, tokens ou estado da aplicação.
GET /api/users HTTP/1.1 Host: netdepth.dev Accept: application/json User-Agent: NetDepthClient
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 26
{
"status": "success"
}Lê representação. Seguro e idempotente.
Submete processamento ou cria. Geralmente não idempotente.
Cria ou substitui no alvo. Pretendido idempotente.
Modificação parcial; pode não ser idempotente.
Solicita remoção; intenção idempotente.
Como GET, mas sem corpo de resposta.
Consulta capacidades; relevante em CORS.
O código descreve a classe de resultado; a causa concreta depende da aplicação e da infraestrutura.
Informação provisória durante processamento.
Sucesso: 200 em leitura, 201 após criação.
Redirecionamento: 301 sugere mudança permanente; 302 é temporário comum.
400 malformada, 401 requer autenticação, 403 negada, 404 ausente, 429 limitada.
500 interno, 502 gateway inválido, 503 indisponível.
HTTPS
HTTPS é HTTP dentro de conexão TLS. TLS busca autenticar o servidor por certificado, negociar chaves e proteger confidencialidade e integridade. Não corrige XSS, permissões erradas ou vulnerabilidades no servidor.
Em TLS 1.3, ClientHello e ServerHello negociam parâmetros. Com ECDHE, as partes derivam segredo compartilhado efêmero. Certificado e assinatura autenticam a troca; dados passam a usar criptografia simétrica autenticada, como AES-GCM ou ChaCha20-Poly1305.
ClientHello: versões, cipher suites, key share.
Seleciona parâmetros e apresenta identidade.
Cliente valida cadeia, nome, validade e assinatura.
Comunicação simétrica autenticada.
Chave pública e assinaturas autenticam e ajudam a estabelecer segredos. TLS 1.3 moderno não é “cifrar uma chave de sessão com RSA”: ECDHE fornece forward secrecy quando corretamente implementado.
Com as chaves estabelecidas, algoritmos simétricos autenticados são eficientes para tráfego contínuo. Integridade acompanha confidencialidade; alteração do ciphertext deve ser detectada.
No TLS 1.3 a negociação é mais enxuta que antes. A suíte trata algoritmos simétricos e integridade; grupos de troca, assinaturas e certificados são negociados em extensões relacionadas.
Módulo 3 · Infraestrutura
Antes de uma conexão chegar à aplicação, nomes precisam ser resolvidos e a infraestrutura pode decidir de onde o conteúdo será servido. Caches, roteamento e distância mudam a experiência.
Ao digitar www.exemplo.com, o navegador pode consultar seu cache e o resolvedor do sistema operacional. Sem resposta válida, um resolvedor recursivo costuma consultar a hierarquia: raiz aponta ao TLD, TLD aponta autoritativos e estes respondem pelo registro.
Caches podem evitar esse caminho em consultas futuras. Respostas permanecem utilizáveis até TTL expirar; isso melhora latência e reduz carga, mas mudanças precisam considerar entradas ainda armazenadas.
ANome → IPv4, por exemplo 192.0.2.20.
AAAANome → IPv6, como 2001:db8::20.
CNAMEAlias para outro nome canônico.
MXServidores que recebem e-mail do domínio.
TXTTexto, comum em SPF, DKIM e verificações.
NSDelegação para servidores autoritativos.
PTRResolução reversa, usualmente IP → nome.
example.com. A 192.0.2.20 TTL: 3600
Com TTL de 3600, um cache pode reutilizar a resposta por até uma hora desde o armazenamento. “Propagação DNS” costuma ser expiração e atualização distribuída de caches, não cópia instantânea global.
Uma CDN distribui conteúdo e, em alguns casos, lógica por PoPs. Edge responde cache HIT localmente; em cache MISS busca no origin ou camada intermediária. O origin permanece necessário para não cacheado e operações dinâmicas.
Além de cache, edge nodes podem executar lógica curta: autenticação de borda, redirecionamentos e normalização. Há restrições de estado, tempo e consistência; edge não elimina a arquitetura de origem.
Em Anycast, o mesmo prefixo é anunciado em múltiplos pontos via BGP. A infraestrutura escolhe rota conforme políticas e topologia. Isso não é garantia de servidor fisicamente mais próximo.
Round Trip Time
Cliente → servidor: 30 ms
Servidor → cliente: 30 ms
RTT ≈ 60 ms
Caminho completo
Fluxo didático: navegadores, protocolos e infraestruturas podem otimizar ou pular etapas por cache, HTTP/3 e pré-conexões.
Navegador separa esquema, host, porta e caminho, então consulta cache e políticas locais.
Nome é resolvido por cache ou resolvedor, obtendo registros e possíveis IPs.
Cliente seleciona endereço e estabelece transporte: TCP faz handshake; HTTP/3 usa QUIC sobre UDP.
Servidor é autenticado e chaves de sessão são derivadas antes do HTTP protegido.
Navegador envia método, alvo e headers; CDN ou edge pode responder antes da origem.
Servidor gera ou recupera response; HTML descobre CSS, JavaScript e recursos adicionais.
Browser calcula estilos e layout, pinta a página e executa JavaScript conforme prioridades.
Prática guiada
Os simuladores são didáticos e locais: não realizam tráfego real nem consultam DNS externo.
Observe a sincronização antes do fluxo de dados.
Simulação educacional: o IP documental não pertence necessariamente ao domínio informado.
Referência rápida
Pesquise por sigla, protocolo ou conceito.
Avaliação técnica
Quinze questões intermediárias e avançadas com explicação e revisão das incorretas.
Melhor resultado
Ainda não realizado
Quizzes realizados
0
Última pontuação
—
Dúvidas recorrentes
Não. TCP oferece ordem, confiabilidade, fluxo e congestionamento. Para dados que precisam chegar completos e ordenados, reimplementar isso sobre UDP pode ser mais complexo e não resultar em menor tempo percebido.
HTTPS cifra conteúdo HTTP, mas não remove todos os metadados. IPs, horários e volume permanecem observáveis; DNS tradicional e detalhes de handshake também podem revelar contexto em alguns cenários.
Ambos. UDP é comum em consultas; TCP é usado, por exemplo, em transferências de zona e quando a resposta precisa disso. DoH e DoT adicionam HTTPS ou TLS, respectivamente.
Em geral, não. CDN atende cache ou lógica de borda, mas a origem fornece conteúdo em cache miss, operações dinâmicas e a fonte autoritativa.
TLS sucedeu SSL. “SSL” ainda aparece no uso comercial, mas SSL antigo é obsoleto e inseguro; configurações atuais usam TLS moderno.
Não. BGP seleciona caminhos por políticas, anúncios, preferência local, AS path e topologia. A rota pode ser eficiente, mas proximidade geográfica não é uma garantia.