TCP, UDP, portas e sockets

Transporte conecta aplicações nas pontas da rede

IP conduz um pacote até um host, mas um computador pode executar navegador, mensageiro, servidor web, banco de dados e dezenas de outros processos ao mesmo tempo. A camada de transporte acrescenta informação para que a pilha entregue os dados à aplicação correta e ofereça um tipo de comunicação adequado.

TCP e UDP são dois protocolos centrais dessa camada. Eles compartilham portas de origem e destino, mas oferecem serviços diferentes:

• TCP fornece às aplicações um fluxo de bytes confiável e ordenado dentro de uma conexão;
• UDP fornece um transporte mínimo orientado a mensagens, no qual cada envio forma um datagrama independente.

“Fim a fim” não significa que os dados atravessam a rede sem intermediários. Switches, roteadores, firewalls e outros sistemas continuam no caminho. Significa que o estado e as garantias principais do transporte são coordenados pelas pontas, não reconstruídos por cada roteador.

Esta aula parte do encapsulamento em segmentos e pacotes e do encaminhamento por roteadores. Agora a pergunta deixa de ser “por onde o pacote segue?” e passa a ser “qual aplicação deve recebê-lo e que serviço ela espera?”.

Porta é um identificador lógico, não um conector físico

Uma porta de transporte é um número de 16 bits. Portanto, seu intervalo vai de 0 a 65.535. Ela participa da identificação de um serviço ou endpoint dentro do contexto de um endereço IP e de um protocolo de transporte.

Não confunda esse número com uma porta Ethernet do switch. A porta física ou lógica do equipamento de rede indica uma interface de enlace; a porta TCP ou UDP ajuda a multiplexar aplicações em um host.

A IANA organiza o espaço em três intervalos:

O valor 0 é reservado no registro e não representa um serviço comum. Sistemas operacionais também aplicam regras próprias para vinculação, privilégios, portas efêmeras e reutilização. Por isso, o intervalo da IANA não é uma descrição completa da política de cada plataforma.

TCP e UDP mantêm espaços de portas distintos. A porta numérica 53 em UDP e a porta 53 em TCP são endpoints de protocolos diferentes. Uma aplicação pode usar ambos, apenas um ou outro protocolo sobre números diferentes.

Origem e destino mudam de papel na resposta

Um cliente normalmente escolhe uma porta local disponível e envia ao endereço e à porta do serviço. Considere:

TCP 192.0.2.10:53120 → 198.51.100.20:443

Na resposta, os papéis se invertem:

TCP 198.51.100.20:443 → 192.0.2.10:53120

A porta 443 não identifica sozinha o servidor. É necessário considerar ao menos protocolo, endereço e contexto de rede. Da mesma forma, 53120 não pertence permanentemente ao navegador; o sistema pode escolhê-la para aquela comunicação e reutilizá-la mais tarde quando for seguro.

Um mesmo cliente pode abrir várias conexões ao mesmo serviço usando portas locais diferentes. Muitos clientes podem chegar à mesma porta do servidor porque cada conversa possui endpoints distintos.

Multiplexação permite que um IP atenda várias aplicações

Na saída, a pilha recebe dados de diferentes processos, acrescenta cabeçalhos e os envia pela mesma infraestrutura IP. Esse compartilhamento é multiplexação. Na entrada, endereço, protocolo, portas e estado ajudam a selecionar o socket correto; esse caminho inverso é demultiplexação.

O algoritmo exato depende do sistema e de opções de socket. Uma descrição didática, porém, pode observar:

• família de endereços, como IPv4 ou IPv6;
• protocolo de transporte;
• endereço e porta locais;
• endereço e porta remotos, quando a comunicação está associada a um par;
• interface ou contexto de rede;
• estado do socket e regras de reutilização.

Isso explica por que duas linhas com a mesma porta local não são necessariamente conflito: elas podem estar em endereços, famílias, protocolos, namespaces ou conexões diferentes. Também explica por que olhar apenas “porta 443” é insuficiente para identificar um fluxo capturado.

Socket é a interface da aplicação com a pilha de rede

Socket possui dois usos próximos. Em protocolos, um endpoint TCP é tradicionalmente representado pela combinação de endereço IP e porta. Em sistemas operacionais, socket é uma abstração de programação usada pela aplicação para configurar e realizar comunicação.

Na interface POSIX, socket() cria o objeto; funções como bind(), connect(), listen(), accept(), send() e recv() atuam sobre ele conforme tipo, protocolo e estado. A aplicação costuma receber um descritor e não precisa construir manualmente cada cabeçalho TCP ou UDP.

Um servidor TCP geralmente mantém dois tipos de socket:

1. um listener, vinculado ao endereço e à porta e preparado para novos pedidos;
2. sockets de conexão, criados ou retornados quando conversas são aceitas.

O listener pode continuar recebendo novos clientes enquanto cada conexão possui seu próprio estado. Em UDP, uma aplicação pode vincular um socket a uma porta e receber datagramas acompanhados da origem. Algumas APIs permitem “conectar” um socket UDP a um peer padrão, mas isso não executa o handshake TCP nem transforma UDP em transporte confiável.

Uma conexão TCP é identificada pelas duas pontas

A RFC 9293 define uma conexão TCP por um par de sockets. Na explicação operacional, uma conversa é distinguida por:

IP local + porta local ↔ IP remoto + porta remota + TCP

Essa combinação costuma ser chamada de quádrupla, com o protocolo entendido pelo contexto, ou 5-tuple quando o protocolo é contado explicitamente. Em sistemas reais, família, interface, namespace e outras informações também podem participar da busca.

Considere um servidor em 198.51.100.20:443:

192.0.2.10:53120 ↔ 198.51.100.20:443
192.0.2.11:53120 ↔ 198.51.100.20:443
192.0.2.10:53121 ↔ 198.51.100.20:443

As três conexões são distintas, mesmo que duas usem a mesma porta no cliente e todas terminem na mesma porta do servidor. Os endereços e o par completo removem a ambiguidade.

NAT pode traduzir endereços e portas durante o caminho, fazendo com que a tupla observada externamente seja diferente daquela vista pelo host interno. Essa tradução será aprofundada na aula própria; aqui basta não tratar a porta como identidade global e imutável.

TCP estabelece contexto com o three-way handshake

Antes do fluxo normal de dados, o TCP sincroniza as pontas. O procedimento comum usa três mensagens conceituais:

1. o cliente envia SYN e apresenta seu número inicial de sequência;
2. o servidor responde SYN + ACK, confirma a informação recebida e apresenta a sua;
3. o cliente envia ACK, confirmando a informação do servidor.

Depois disso, a conexão entra no estado estabelecido e os bytes podem ser entregues à aplicação conforme as regras do TCP. O handshake ajuda as pontas a sincronizar números de sequência e reduz a possibilidade de confundir uma solicitação antiga duplicada com uma nova conexão.

O desenho mostra o fluxo clássico. Extensões podem permitir dados em etapas de abertura sob condições específicas, mas isso não elimina o modelo de sincronização nem deve ser usado para afirmar que todo TCP sempre espera exatamente o mesmo momento para transmitir dados de aplicação.

Ao encerrar normalmente, cada direção do fluxo é fechada com FIN e reconhecimentos conforme o estado das pontas. RST representa uma interrupção ou rejeição abrupta em situações definidas. Estados como TIME-WAIT protegem novas instâncias contra segmentos atrasados de uma conexão anterior. O diagrama completo de estados é importante para implementação, mas está além da introdução necessária aqui.

TCP oferece um fluxo confiável e ordenado de bytes

Para a aplicação, TCP apresenta uma sequência contínua de bytes. Ele numera dados, reconhece o que chegou e recupera perdas conforme seus algoritmos. Os bytes são entregues em ordem dentro da conexão.

Mas TCP não preserva fronteiras de mensagens da aplicação. Se um programa executar:

send("ABC")
send("DEF")
send("GHI")

o receptor pode ler ABCDEFGHI de uma vez, receber uma parte e depois o restante ou obter outra divisão. Segmentação da rede e agrupamento das chamadas não fazem parte da interface de mensagem oferecida ao programa.

Por isso, protocolos sobre TCP precisam definir framing próprio, por exemplo:

• tamanho antes do conteúdo;
• delimitador com regras de escape;
• cabeçalho que informa o comprimento;
• estrutura textual ou binária capaz de indicar onde termina uma unidade.

Confiabilidade também não significa que a aplicação sempre terá sucesso. A conexão pode falhar, expirar, ser reiniciada ou terminar depois que uma ponta escreveu bytes sem saber se a outra aplicação os processou. TCP confirma entrega ao mecanismo TCP remoto, não a conclusão de uma operação de negócio.

UDP preserva cada mensagem, mas não promete entregá-la

UDP acrescenta um cabeçalho básico com:

• porta de origem;
• porta de destino;
• comprimento;
• checksum.

O cabeçalho UDP básico possui oito bytes. A RFC 9868 definiu uma área e mecanismos para UDP Options, atualizando a RFC 768, mas uma aplicação não deve presumir que toda pilha ou caminho já ofereça a mesma utilização dessas extensões. O serviço básico continua sendo o ponto de partida interoperável.

Cada envio UDP corresponde a um datagrama. Se a aplicação envia três mensagens, o receptor que as obtiver recebe unidades separadas; elas não se fundem em um fluxo de bytes como no TCP.

Em contrapartida, UDP básico não garante:

• que o datagrama chegará;
• que chegará uma única vez;
• que múltiplos datagramas chegarão na ordem de envio;
• que o receptor está pronto;
• que o remetente reduzirá a taxa diante de congestionamento;
• que haverá resposta.

O protocolo de aplicação pode acrescentar números, confirmações, retransmissão, controle de congestionamento, criptografia e estabelecimento de sessão quando sua necessidade exigir. QUIC é um exemplo de protocolo completo construído sobre UDP; suas garantias vêm do QUIC, não aparecem automaticamente por usar UDP.

Checksum detecta erros, não autentica o remetente

TCP e UDP possuem checksum que inclui um pseudoheader com informações IP, o cabeçalho de transporte e os dados cobertos. O objetivo é detectar determinadas corrupções acidentais.

No UDP sobre IPv4, a especificação histórica permite transmitir checksum zero para indicar ausência dessa verificação. No IPv6, checksum UDP normalmente é obrigatório, com exceções específicas definidas para determinados usos de tunelamento. Aplicações comuns não devem desabilitar proteção com base em uma generalização sobre desempenho.

Checksum não oferece identidade criptográfica, sigilo nem proteção contra alteração intencional. Um atacante capaz de modificar a mensagem pode recalcular a soma. Autenticação e confidencialidade pertencem a mecanismos como TLS, QUIC, IPsec ou protocolos de aplicação apropriados.

Tamanho da mensagem UDP exige cuidado

Uma chamada UDP pode aceitar um datagrama grande, mas o caminho IP possui limites de MTU. Fragmentação IP aumenta a fragilidade: perder um fragmento impede remontar o datagrama completo, e middleboxes podem tratar fragmentos de maneira restritiva.

Protocolos robustos controlam o tamanho das mensagens, consideram Path MTU e empregam mecanismos de descoberta adequados. “UDP permite até 65.535 bytes” é uma simplificação perigosa quando usada como recomendação operacional; cabeçalhos, família IP, extensões, MTU e caminho reduzem o que pode ser transportado de forma segura.

TCP também segmenta seu fluxo conforme o caminho, mas apresenta bytes à aplicação e gerencia essa divisão no transporte. Isso não torna transferências enormes infalíveis; apenas coloca a segmentação e recuperação dentro do serviço TCP.

UDP não libera a aplicação de controlar congestionamento

Como UDP básico não reage à capacidade disponível, uma aplicação pode enviar mais rápido do que o caminho suporta. O resultado não afeta apenas ela: filas crescem, latência aumenta, datagramas são descartados e outros fluxos perdem oportunidade de uso.

A RFC 8085 estabelece boas práticas para que aplicações UDP controlem taxa, considerem o caminho e compartilhem a capacidade de forma responsável. Se o protocolo implementa transferência contínua, ele precisa de mecanismos apropriados de congestionamento ou usar um transporte que já os forneça.

Isso desmonta a frase “UDP é mais rápido porque não controla nada”. Ausência de mecanismo embutido reduz o cabeçalho e o estado básico, mas transfere responsabilidades para o protocolo superior. Uma implementação segura e justa pode ser sofisticada.

TCP e UDP não formam uma corrida com vencedor universal

Escolher transporte exige observar os requisitos completos.

TCP costuma ser uma boa base quando a aplicação precisa de fluxo confiável e não deseja reinventar recuperação e congestionamento. UDP é apropriado quando fronteiras de mensagem, multicast, controle próprio de temporização ou outro protocolo superior justificam o modelo mínimo.

Latência depende de mais fatores que o cabeçalho:

• conexão nova ou reutilizada;
• quantidade e direção dos dados;
• perda, RTT e congestionamento;
• criptografia e autenticação;
• comportamento do protocolo de aplicação;
• suporte do sistema e dos intermediários;
• algoritmos implementados sobre UDP ou TCP.

DNS, por exemplo, possui operação tanto sobre UDP quanto sobre TCP conforme situação e especificação. Protocolos modernos sobre UDP podem estabelecer estado e retransmitir. Portanto, associar uma aplicação fixa a um transporte por slogan prejudica o projeto.

Porta aberta, fechada e filtrada descrevem evidências diferentes

Em diagnóstico, “porta aberta” normalmente significa que existe um socket ou serviço capaz de receber naquele protocolo, endereço e contexto. “Fechada” pode significar que o host respondeu indicando ausência de listener. “Filtrada” descreve ausência ou bloqueio inferido por uma ferramenta, não uma verdade observável diretamente em todos os casos.

Em TCP:

• SYN seguido de SYN + ACK indica que a abertura avançou;
• RST pode indicar rejeição ou ausência de listener;
• timeout pode resultar de filtro, perda, rota ou host indisponível.

Em UDP, a ausência de resposta é ainda mais ambígua. A aplicação pode não ter resposta prevista, o datagrama pode ter sido perdido, um ICMP pode ter sido filtrado ou o serviço pode não existir.

Uma porta em escuta também não prova que o serviço está saudável ou autorizado. O processo pode aceitar a conexão e falhar no protocolo de aplicação. Da mesma forma, um firewall pode permitir o transporte e negar etapas posteriores por política em outra camada.

A arquitetura de controle entre zonas está em Segurança de redes: firewall, VPN e segmentação. Portas ajudam a descrever fluxos, mas não autenticam aplicações nem substituem menor privilégio.

Diagnostique do socket para o caminho e de volta

Quando uma aplicação não se comunica, organize as evidências:

1. confirme protocolo, endereço e porta esperados;
2. verifique se o processo criou um listener no endereço correto;
3. diferencie vínculo apenas em loopback de vínculo em uma interface externa;
4. observe sockets em escuta e conexões existentes;
5. gere uma tentativa controlada;
6. capture SYN, SYN + ACK, ACK, RST ou datagramas UDP;
7. confirme rota e próximo salto até o destino;
8. verifique regras de firewall e tradução em cada direção;
9. analise a resposta da aplicação, não apenas a abertura do transporte;
10. considere o caminho de retorno e limites de MTU.

Se o SYN sai e não retorna nada, ainda não há evidência suficiente para culpar a aplicação do servidor. Se SYN + ACK chega e o cliente não envia o ACK final, examine o caminho de retorno local, filtros e estado do cliente. Se o handshake conclui, mas não há resposta útil, avance para TLS ou protocolo de aplicação.

No UDP, capture endereço e porta de origem da resposta, pois a aplicação ou intermediário pode usar um endpoint inesperado. Compare o que o cliente espera com o que realmente chegou ao sistema operacional.

Erros comuns sobre TCP, UDP, portas e sockets

• confundir porta TCP com porta do switch: uma identifica aplicações; a outra identifica interfaces de enlace;
• achar que IP identifica o processo: vários serviços compartilham o mesmo endereço;
• tratar uma porta registrada como obrigatória: ela é uma convenção, não uma garantia de configuração;
• supor que TCP preserva mensagens: ele entrega um fluxo de bytes;
• supor que um send() equivale a um recv(): as fronteiras podem mudar no TCP;
• dizer que UDP sempre é mais rápido: o protocolo completo e o caminho determinam latência e capacidade;
• dizer que UDP não pode ser confiável: um protocolo sobre UDP pode implementar garantias próprias;
• achar que TCP confirma a operação de negócio: ACK reconhece o fluxo, não o significado processado;
• usar checksum como segurança: ele detecta erros acidentais, não autentica;
• enviar datagramas enormes sem considerar MTU: fragmentação aumenta risco e incompatibilidade;
• interpretar timeout como porta fechada: filtro, perda e rota podem produzir o mesmo sintoma;
• confundir listener com conexão: o servidor mantém contextos diferentes para aceitar e atender clientes.

O que você deve guardar

O endereço IP conduz ao host; protocolo e portas ajudam a chegar ao contexto de aplicação. Portas TCP e UDP ocupam espaços distintos, e uma conversa precisa ser interpretada com ambas as pontas, não por um número isolado.

TCP estabelece uma conexão, sincroniza estado e oferece fluxo de bytes confiável e ordenado. A aplicação precisa definir suas próprias fronteiras de mensagem. UDP entrega datagramas independentes e preserva essas fronteiras, mas deixa entrega, ordem, recuperação e congestionamento para o protocolo que o utiliza.

Socket é a abstração pela qual aplicações usam esses serviços. Listener, conexão TCP e socket UDP possuem comportamentos diferentes. A escolha correta nasce dos requisitos de comunicação, não de uma disputa simplista entre “rápido” e “confiável”.

Referências

• IETF — RFC 9293: Transmission Control Protocol. Acesso em 29 ago. 2026.
• IETF — RFC 768: User Datagram Protocol. Acesso em 29 ago. 2026.
• IETF — RFC 9868: Transport Options for UDP. Acesso em 29 ago. 2026.
• IETF — RFC 8085: UDP Usage Guidelines. Acesso em 29 ago. 2026.
• IETF — RFC 6335: Service Name and Transport Protocol Port Number Registry Procedures. Acesso em 29 ago. 2026.
• IETF — RFC 8095: Services Provided by IETF Transport Protocols. Acesso em 29 ago. 2026.
• IANA — Service Name and Transport Protocol Port Number Registry. Acesso em 29 ago. 2026.
• The Open Group — Base Specifications Issue 8: General Information for Sockets. Acesso em 29 ago. 2026.