Portas, sockets e protocolos essenciais em servidores: HTTP/HTTPS/SSH e além

Portas e sockets: como um servidor “se oferece” na rede

Quando um cliente acessa um servidor, ele não fala apenas com um IP. Ele fala com um IP + porta. A porta identifica qual serviço (aplicação) deve receber aquela conexão. O par (IP, porta, protocolo) forma a base para entregar tráfego ao processo correto.

TCP vs UDP (o que muda na prática)

• TCP: orientado a conexão. Existe estabelecimento (handshake), controle de entrega e retransmissão. É comum em serviços onde confiabilidade importa (HTTP/HTTPS, SSH, SMTP, bancos de dados).
• UDP: sem conexão. Envia datagramas “no melhor esforço”, com menos overhead e menor latência. É comum em DNS, NTP, streaming e alguns serviços de descoberta.

O que é um socket

Um socket é um endpoint de comunicação criado pelo sistema operacional para uma aplicação enviar/receber dados. Em servidores, o socket mais típico é o de escuta (listening), que fica aguardando conexões.

Para TCP, um servidor geralmente cria um socket, faz bind em um IP/porta e entra em listen. Quando um cliente conecta, o sistema cria um novo socket “filho” para aquela sessão, permitindo múltiplos clientes simultâneos.

Para UDP, o servidor cria um socket e faz bind na porta. Não há “conexão”; ele recebe datagramas e responde para o endereço/porta de origem.

O que significa “serviço escutando”

“Escutando” significa que existe um processo com um socket associado a uma porta, pronto para receber conexões (TCP) ou datagramas (UDP). Se ninguém está escutando naquela porta, o comportamento típico é:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• TCP: o sistema responde com RST e o cliente vê connection refused.
• UDP: pode haver um ICMP “port unreachable”, mas muitas vezes o cliente só percebe como timeout (depende do aplicativo e do caminho).

Portas bem conhecidas e portas efêmeras

• 0–1023: “bem conhecidas” (ex.: 22 SSH, 80 HTTP, 443 HTTPS). Em sistemas Unix-like, normalmente exigem privilégios elevados para abrir.
• 1024–49151: registradas (muitos serviços e aplicações usam aqui).
• 49152–65535: efêmeras (normalmente usadas como porta de origem do cliente).

Exemplo de conexão: ao acessar https://exemplo.com, o cliente abre uma porta efêmera local (ex.: 52344) e conecta ao destino IP_do_servidor:443 via TCP.

HTTP, HTTPS e SSH: o que são e como se comportam

HTTP (TCP/80): texto e sem criptografia

HTTP é um protocolo de aplicação que normalmente roda sobre TCP. Ele define como o cliente pede recursos e como o servidor responde (métodos como GET, POST, códigos de status, headers).

Características práticas:

• Tráfego em claro (sem criptografia) quando usado como HTTP puro.
• Fácil de testar com ferramentas simples.
• Erros comuns: servidor não escutando, firewall bloqueando, virtual host/host header incorreto.

HTTPS (TCP/443): HTTP + TLS (visão de alto nível)

HTTPS é HTTP encapsulado em uma camada de segurança chamada TLS. Antes de qualquer requisição HTTP, ocorre um handshake TLS para negociar criptografia e validar identidade do servidor (certificado).

O que acontece em alto nível:

• Cliente conecta em 443/TCP.
• Cliente e servidor negociam versões/cifras e o servidor apresenta um certificado.
• Se tudo estiver ok, cria-se um canal criptografado e então o HTTP acontece por dentro.

Falhas típicas em HTTPS:

• Handshake TLS falha por certificado inválido/expirado, cadeia incompleta, nome (SNI/hostname) não corresponde, ou incompatibilidade de versões/cifras.
• Porta 443 aberta, mas serviço errado (ex.: algo não-TLS respondendo em 443) também causa falha de handshake.

SSH (TCP/22): acesso remoto e tunelamento

SSH é um protocolo para acesso remoto seguro e também para túneis (port forwarding). Ele roda sobre TCP e tem um handshake próprio (troca de chaves, verificação de host key, autenticação por senha/chave).

Diferenças de comportamento em relação a HTTP/HTTPS:

• SSH é interativo e orientado a sessão (shell, execução de comandos, SFTP).
• Erros de autenticação são comuns (chave não autorizada, usuário errado), mesmo com a porta aberta.
• Um firewall pode permitir 22/TCP, mas políticas do serviço podem negar (ex.: AllowUsers, PermitRootLogin).

Protocolos frequentes no dia a dia (portas e usos típicos)

A tabela abaixo resume portas comuns. Em ambientes reais, portas podem variar por configuração, mas estes são os padrões mais vistos.

Observação prática: DNS usa UDP e TCP na porta 53. Muitos esquecem de liberar TCP/53 quando há respostas grandes, DNSSEC, ou certos cenários de replicação/transferência.

Passo a passo prático: verificar portas, serviços e conflitos

1) Descobrir o que está escutando no servidor

Em Linux, você quer responder: “qual processo está escutando em qual IP/porta e em TCP ou UDP?”.

# Ver sockets escutando (TCP/UDP) com processo (requer privilégios para ver tudo) ss -lntup  # -l listening, -n numérico, -t tcp, -u udp, -p processo # Alternativa tradicional netstat -lntup

Como interpretar:

• Local Address:Port mostra em qual IP e porta o serviço está ligado.
• 0.0.0.0:PORT significa “todas as interfaces IPv4”.
• [::]:PORT significa “todas as interfaces IPv6” (muitas vezes também aceita IPv4 via dual-stack, dependendo do sistema).
• Se estiver ligado em 127.0.0.1:PORT, só aceita conexões locais (útil para serviços atrás de proxy, mas surpreende quando você tenta acessar de fora).

2) Testar conectividade de porta (do cliente para o servidor)

O teste mais simples é: “consigo abrir uma conexão TCP nessa porta?”.

# Teste TCP (rápido) nc -vz IP_DO_SERVIDOR 22 nc -vz IP_DO_SERVIDOR 443  # Alternativa com bash (quando nc não existe) timeout 3 bash -c 'cat < /dev/null > /dev/tcp/IP_DO_SERVIDOR/22'  # Para UDP, nc pode enviar datagrama, mas validar resposta depende do protocolo nc -vu IP_DO_SERVIDOR 123

Interpretação:

• Sucesso: existe caminho e algo respondeu na porta (não garante que o protocolo está correto, apenas que a porta está acessível).
• Connection refused: chegou no host, mas não há serviço escutando naquela porta (ou o host rejeitou ativamente).
• Timeout: algo no caminho está descartando (firewall, ACL, rota, serviço travado sem responder, ou UDP sem resposta).

3) Confirmar o protocolo de aplicação (HTTP/HTTPS/SSH)

Uma porta aberta não garante que o serviço esperado está ali. Confirme falando o protocolo certo.

# HTTP (espera resposta HTTP) curl -v http://IP_DO_SERVIDOR:80/  # HTTPS (mostra detalhes do TLS) curl -vk https://IP_DO_SERVIDOR:443/  # Inspecionar handshake/certificados com OpenSSL openssl s_client -connect IP_DO_SERVIDOR:443 -servername nome.exemplo  # SSH (mostra banner e tenta negociar) ssh -vvv usuario@IP_DO_SERVIDOR -p 22

Dicas de leitura:

• curl -v mostra status HTTP, headers e se houve redirecionamento.
• curl -k ignora validação de certificado (útil para diagnóstico, não como solução).
• openssl s_client ajuda a ver cadeia de certificados, SNI e alertas de handshake.
• ssh -vvv detalha em que etapa falhou (rede, troca de chaves, autenticação).

4) Identificar conflito de porta (quando o serviço não sobe)

Conflito ocorre quando dois processos tentam escutar na mesma combinação de IP/porta/protocolo. Sintomas comuns: o serviço falha ao iniciar e logs mostram “address already in use”.

Passo a passo:

• Verifique quem já usa a porta:

ss -lntup | grep ':443' ss -lntup | grep ':80'

• Se necessário, descubra o PID e o serviço:

# Mostra PID/Processo dono do socket (quando disponível) ss -lntp | grep ':443'  # Alternativa com lsof lsof -iTCP:443 -sTCP:LISTEN

• Ações típicas:
• Se o processo “errado” está ocupando a porta, ajuste a configuração dele ou pare/desabilite.
• Se você precisa de dois serviços HTTP, use portas diferentes (ex.: 8080/8443) ou um reverse proxy na frente (um serviço escuta 80/443 e encaminha internamente).
• Se o serviço está ligado apenas em 127.0.0.1 e você precisa acesso externo, ajuste o bind para o IP correto (com cuidado de segurança).

Erros clássicos e como interpretar (exercícios guiados)

A seguir, cenários típicos para você treinar o raciocínio: “é rota? firewall? serviço? protocolo?”. Em cada um, tente identificar a causa mais provável e o próximo teste.

Exercício 1: “connection refused” ao acessar 10.0.0.10:22

Sintoma: ssh usuario@10.0.0.10 retorna rapidamente Connection refused.

Interpretação:

• Você chegou ao host (não é problema de rota).
• O host respondeu ativamente que não há serviço escutando naquela porta (ou há regra local rejeitando com RST).

Próximos passos:

• No servidor: ss -lntup | grep ':22' para ver se o SSH está escutando.
• Checar se o SSH está em outra porta (ex.: 2222) e se o cliente está usando a porta correta.
• Checar se o serviço está ligado apenas em 127.0.0.1:22 (o que impediria acesso remoto).

Exercício 2: “timeout” ao acessar 10.0.0.10:443

Sintoma: curl -vk https://10.0.0.10 fica esperando e termina com timeout.

Interpretação:

• Algo está descartando o tráfego (firewall/ACL/security group) ou não existe caminho de rede até o destino.
• Também pode ser o serviço travado, mas nesse caso é comum ver conexão estabelecida e depois travar; o timeout “seco” costuma indicar bloqueio no caminho.

Próximos passos:

• Do cliente: teste outra porta conhecida no mesmo host (ex.: 22) para comparar.
• Do servidor: confirme se está escutando em 443: ss -lntup | grep ':443'.
• Verifique regras de firewall no caminho (host e rede). Se houver acesso local ao servidor, teste localmente: curl -vk https://127.0.0.1 (se funcionar local e não remoto, o problema tende a ser firewall/bind/interface).

Exercício 3: “handshake TLS falha” em 443, mas a porta está aberta

Sintoma: nc -vz 10.0.0.10 443 conecta, mas curl https://10.0.0.10 retorna erro de TLS (ex.: handshake failure, wrong version number, certificate verify failed).

Interpretação (separe em possibilidades):

• Serviço errado na porta: algo responde em 443 mas não fala TLS (ex.: HTTP puro em 443). Isso gera erros como wrong version number.
• Certificado/hostname: certificado expirado, cadeia incompleta, CN/SAN não corresponde ao nome acessado, ou falta de SNI correto.
• Incompatibilidade TLS: servidor exige TLS 1.2+ e o cliente tenta versão antiga (ou cifra não suportada).

Próximos passos:

• Inspecione com OpenSSL: openssl s_client -connect 10.0.0.10:443 -servername nome.exemplo.
• Se o acesso é por IP, teste também com o hostname correto (SNI pode ser obrigatório em servidores com múltiplos sites).
• Confirme se o serviço web está configurado para TLS naquela porta (e não apenas redirecionamento ou proxy mal configurado).

Exercício 4: DNS “intermitente” ou falhando em respostas grandes

Sintoma: algumas consultas DNS funcionam, outras dão timeout, especialmente com respostas maiores.

Interpretação:

• UDP/53 pode estar liberado, mas TCP/53 bloqueado. Quando a resposta é grande ou há necessidade de TCP, falha.

Próximos passos:

• Testar explicitamente TCP: ferramentas de consulta DNS geralmente permitem forçar TCP.
• Verificar firewall liberando UDP e TCP na porta 53.

Exercício 5: Banco de dados acessível localmente, mas não remotamente

Sintoma: no servidor, a aplicação conecta no banco via localhost:5432, mas de outra máquina dá timeout ou refused.

Interpretação:

• O banco pode estar escutando apenas em 127.0.0.1 (acesso local ok, remoto não).
• Ou está escutando em todas as interfaces, mas firewall bloqueia.
• Ou a política do banco nega o cliente (autorização/regras), o que pode aparecer como erro de autenticação em vez de rede.

Próximos passos:

• Verificar bind: ss -lntup | grep ':5432' (observe o IP).
• Testar porta do cliente: nc -vz IP_DO_SERVIDOR 5432.
• Se a porta abre, mas o login falha, o problema é de credenciais/permissões/configuração do banco, não de rede.

Checklist mental rápido para diagnosticar “não conecta”

• 1) IP e porta corretos? (inclui porta não padrão e destino certo)
• 2) O serviço está escutando? (no IP certo: 0.0.0.0 vs 127.0.0.1)
• 3) O caminho permite? (firewall/ACL/security group/NAT)
• 4) O protocolo está correto? (HTTPS vs HTTP, TLS na porta certa, SSH na porta certa)
• 5) Se conecta mas falha depois? (TLS/certificado, autenticação, política do serviço)