Protocolo TCP: o que é, como funciona e diferenças para UDP

Entenda o protocolo TCP em nível de engenharia: header, three-way handshake, estados, sequência e ACK, SACK, RTO, janelas, congestionamento, CUBIC, desempenho e diferenças para UDP.

Confira!

O TCP — Transmission Control Protocol é um protocolo da camada de transporte da arquitetura TCP/IP que fornece às aplicações um fluxo de bytes bidirecional, orientado a conexão, confiável e entregue em ordem entre dois endpoints. Ele foi projetado para funcionar sobre o serviço de datagramas do IP, que por si só não garante entrega, ordem, ausência de duplicação ou latência máxima. Para oferecer uma abstração mais confiável à aplicação, o TCP mantém estado nos dois extremos, numera bytes, confirma recepção, controla janelas, retransmite dados quando necessário e adapta a quantidade de informação em trânsito às condições do receptor e da rede.

A confiabilidade do TCP não significa que toda comunicação necessariamente chegará ao destino: uma conexão pode falhar e a aplicação receberá o erro. Significa que, enquanto a conexão puder ser mantida, o TCP não entrega silenciosamente à aplicação um fluxo com lacunas ou bytes fora de ordem. Também é importante separar conceitos: TCP não criptografa dados, não autentica os endpoints, não preserva fronteiras de mensagens da aplicação e não garante baixa latência.

A especificação-base vigente é o RFC 9293, STD 7, que consolidou a definição do TCP e substituiu o histórico RFC 793. O comportamento de uma implementação moderna, entretanto, também depende de documentos complementares sobre congestionamento, retransmissão, opções e extensões. Por isso, compreender TCP em nível de engenharia exige analisar o protocolo como um sistema de controle distribuído, e não apenas memorizar o three-way handshake.

O que o TCP realmente oferece à aplicação

O TCP estabelece uma associação lógica entre dois processos e apresenta a cada aplicação um byte stream. Se uma aplicação escrever 100 bytes e depois 200 bytes em um socket, o receptor não deve assumir que fará duas leituras de exatamente 100 e 200 bytes. O TCP pode segmentar, combinar e entregar os 300 bytes em blocos diferentes conforme buffers, MSS, temporização e comportamento da pilha.

Essa característica diferencia o TCP de protocolos orientados a mensagens: a unidade semântica da aplicação pertence ao protocolo de aplicação, não ao TCP. HTTP, por exemplo, define sua própria estrutura acima do transporte. A relação entre as camadas pode ser compreendida em conjunto com o comparativo técnico dos modelos OSI e TCP/IP.

Fluxo full-duplex

Uma conexão TCP é full-duplex: há um fluxo lógico de bytes em cada direção, e cada direção possui seus próprios números de sequência, acknowledgements, janela de recepção e estado de transmissão. Consequentemente, um endpoint pode continuar recebendo dados mesmo depois de encerrar sua própria direção de envio por meio de um FIN, situação conhecida como half-close.

Como uma conexão é identificada

Em operação normal, uma conexão é distinguida pela combinação dos endereços IP e portas dos dois extremos, frequentemente descrita como 4-tuple:

endereço IP de origem;
porta TCP de origem;
endereço IP de destino;
porta TCP de destino.

O protocolo de transporte TCP é implícito nessa identificação. A porta do servidor costuma corresponder a uma porta conhecida ou configurada para o serviço, enquanto o cliente normalmente usa uma porta efêmera. Dois clientes podem, portanto, acessar a mesma porta TCP de um servidor simultaneamente sem que as conexões se confundam.

O que o TCP não fornece

TCP não deve ser confundido com segurança de aplicação ou qualidade de serviço. O protocolo-base não fornece:

criptografia do conteúdo;
autenticação criptográfica das partes;
garantia de tempo máximo de entrega;
preservação das mensagens originais da aplicação;
garantia de largura de banda;
prioridade semântica entre diferentes registros da aplicação.

Quando confidencialidade e autenticação são necessárias, protocolos como TLS são colocados acima do TCP. Quando a aplicação prioriza atraso baixo e pode tolerar perdas pontuais, UDP ou transportes baseados em UDP podem ser mais adequados.

Onde o TCP se encaixa no encapsulamento da rede

Do ponto de vista de encapsulamento, os dados da aplicação são entregues ao TCP, que constrói segmentos; o IP encapsula esses segmentos em pacotes; e a camada de enlace transporta os pacotes em frames apropriados ao meio físico.

Camada funcional	Unidade típica	Responsabilidade principal
Aplicação	mensagem/registro definido pela aplicação	Semântica do serviço, como HTTP, TLS ou RTSP
Transporte	segmento TCP	Conexão, byte stream, confiabilidade, fluxo e congestionamento
Internet/rede	pacote IP	Endereçamento e roteamento entre redes
Enlace	frame	Entrega no enlace local, como Ethernet ou Wi-Fi

Essa separação é essencial para troubleshooting. Uma retransmissão TCP, por exemplo, não prova sozinha que o problema está no protocolo TCP: ela pode ser consequência de perda em Wi-Fi, congestionamento em um roteador, descarte em firewall, erro físico, microburst, policer, buffer congestionado ou indisponibilidade temporária do receptor.

MTU e MSS não são a mesma coisa

A MTU — Maximum Transmission Unit pertence ao caminho de rede/enlace e representa o maior pacote IP que pode ser transportado sem fragmentação naquele contexto. A MSS — Maximum Segment Size é uma opção TCP e representa a quantidade máxima de dados TCP que o endpoint informa poder receber em um segmento.

Em uma Ethernet com MTU IP de 1500 bytes, um caso clássico com IPv4 sem opções e cabeçalho TCP mínimo resulta em MSS de 1460 bytes: 1500 – 20 bytes de IPv4 – 20 bytes de TCP. Em IPv6, os tamanhos e extensões precisam ser considerados conforme o caso real. A relação não deve ser tratada como uma constante universal.

O MSS é negociado nos segmentos SYN e ajuda a evitar que o transmissor produza segmentos incompatíveis com a capacidade anunciada pelo receptor. Em paralelo, mecanismos de Path MTU Discovery ajudam a adaptar o tamanho efetivo ao caminho.

Como é estruturado o cabeçalho TCP

O cabeçalho TCP mínimo possui 20 bytes e pode crescer com opções. Seus campos não existem isoladamente: em conjunto, eles implementam multiplexação por portas, numeração, confirmação, controle de janela e sinalização do estado da conexão.

Campo	Tamanho básico	Função de engenharia
Source Port	16 bits	Identifica a porta de origem
Destination Port	16 bits	Identifica a porta de destino
Sequence Number	32 bits	Identifica a posição dos bytes enviados no espaço de sequência
Acknowledgment Number	32 bits	Indica o próximo número de sequência esperado quando ACK está ativo
Data Offset	4 bits	Informa o comprimento do cabeçalho TCP em palavras de 32 bits
Control bits	bits individuais	Sinalizam estados e eventos como SYN, ACK, FIN e RST
Window	16 bits	Anuncia a janela de recepção, sujeita a Window Scale quando negociado
Checksum	16 bits	Detecta corrupção acidental sobre cabeçalho e dados, incluindo pseudo-header IP
Urgent Pointer	16 bits	Relacionado ao mecanismo histórico de dados urgentes
Options	variável	Permite MSS, SACK, Window Scale, Timestamps e outras extensões

Como Data Offset possui quatro bits e mede palavras de 32 bits, o cabeçalho básico corresponde a valor 5, isto é, 20 bytes. O espaço tradicional de cabeçalho pode chegar a 60 bytes, deixando até 40 bytes para opções quando se usa esse formato convencional.

Sequence Number: o TCP numera bytes, não pacotes

Um dos conceitos mais importantes é que o Sequence Number referencia o byte stream, e não simplesmente um contador de segmentos. Se um segmento começa com SEQ = 1000 e carrega 1000 bytes de dados, o próximo segmento contínuo pode começar em SEQ = 2000.

SYN e FIN também consomem uma posição no espaço de sequência. Essa regra explica por que, após receber um SYN com número de sequência inicial x, o peer responde com ACK = x + 1, mesmo que o SYN não transporte um byte normal de aplicação.

Acknowledgment Number é cumulativo

Quando o bit ACK está ativo, o Acknowledgment Number informa o próximo número de sequência esperado. Portanto, ACK = 5001 significa, em essência, que os bytes anteriores até 5000 foram recebidos de maneira que o receptor pode avançar a borda esquerda da janela cumulativa.

ACK cumulativo é eficiente, mas pode fornecer informação limitada quando existem múltiplas lacunas. É justamente aí que extensões como SACK adicionam informação seletiva sobre blocos recebidos fora de ordem.

Flags de controle

As flags clássicas mais relevantes são:

SYN: sincroniza números de sequência e participa da abertura da conexão;
ACK: indica que o campo Acknowledgment Number é válido;
FIN: sinaliza que o emissor não enviará mais dados naquela direção;
RST: aborta ou rejeita uma conexão em determinadas condições;
PSH: sinaliza intenção de push de dados ao mecanismo receptor;
URG: ativa o mecanismo relacionado ao Urgent Pointer;
ECE/CWR: integram mecanismos de Explicit Congestion Notification quando utilizados.

PSH não transforma TCP em protocolo orientado a mensagens. URG também não deve ser interpretado como um mecanismo geral de QoS ou prioridade de aplicação.

Checksum não é mecanismo de segurança

O checksum TCP detecta diversos tipos de corrupção acidental e incorpora um pseudo-header construído com informações da camada IP. Isso ajuda a detectar, por exemplo, associação incorreta entre segmento e endpoints. Entretanto, checksum não fornece autenticidade nem proteção contra alteração maliciosa. Para isso são necessários mecanismos criptográficos em outras camadas.

Como funciona o three-way handshake do TCP

Antes que uma transferência normal comece, os endpoints precisam sincronizar estado. No caso mais comum, um servidor executa um passive open, ficando em LISTEN, e o cliente executa um active open.

Considere números de sequência iniciais x no cliente e y no servidor:

Cliente → Servidor: SYN, SEQ = x. O cliente solicita a abertura e apresenta seu Initial Sequence Number.
Servidor → Cliente: SYN + ACK, SEQ = y, ACK = x + 1. O servidor reconhece o SYN do cliente e apresenta seu próprio espaço de sequência.
Cliente → Servidor: ACK, ACK = y + 1. O cliente confirma o SYN do servidor e a conexão alcança o estado estabelecido para o fluxo normal.

Esse mecanismo é chamado de three-way handshake porque são necessários três passos lógicos para sincronizar as duas direções, validar que cada lado consegue receber informação do outro e estabelecer números de sequência independentes.

Por que dois pacotes não bastariam

Uma conexão TCP precisa confirmar não apenas que um pedido chegou ao servidor, mas também que a resposta do servidor chegou ao iniciador e foi compreendida no contexto correto. A terceira mensagem completa essa confirmação e reduz ambiguidades com segmentos antigos ou tentativas que não chegaram a estabelecer comunicação bidirecional.

O handshake também é o momento em que opções importantes podem ser anunciadas ou negociadas. MSS, SACK-Permitted, Window Scale e Timestamps são exemplos de capacidades que influenciam o comportamento da conexão posterior.

Principais estados da máquina TCP

TCP possui uma máquina de estados explícita. Os estados mais importantes para análise operacional são:

Estado	Significado resumido
CLOSED	Não há conexão ativa
LISTEN	Endpoint aguarda solicitação de conexão
SYN-SENT	SYN foi enviado e aguarda resposta
SYN-RECEIVED	SYN foi recebido e a sincronização ainda não terminou
ESTABLISHED	Conexão sincronizada, apta à transferência normal
FIN-WAIT-1	Endpoint iniciou fechamento e aguarda progresso do FIN
FIN-WAIT-2	FIN local foi confirmado; aguarda FIN remoto
CLOSE-WAIT	FIN remoto foi recebido; aplicação local ainda precisa fechar sua direção
CLOSING	Ambos os lados iniciaram fechamento quase simultaneamente
LAST-ACK	Endpoint aguarda ACK para seu FIN final
TIME-WAIT	Fechamento ativo concluído logicamente, preservando estado temporário contra segmentos antigos

Em troubleshooting de servidores, grande quantidade de conexões em CLOSE-WAIT pode indicar que a aplicação recebeu o fechamento remoto, mas não encerrou corretamente seu socket. Muitas conexões em TIME-WAIT, por outro lado, não representam automaticamente defeito: esse estado faz parte do desenho do protocolo.

Como o TCP garante ordenação e recupera perdas

A rede IP pode descartar, duplicar, atrasar ou reordenar pacotes. O TCP mantém variáveis de estado para saber o que já foi enviado, o que foi confirmado e o que o receptor espera em seguida. Entre as variáveis conceituais da especificação estão SND.NXT, SND.UNA e RCV.NXT.

Em termos simplificados:

SND.NXT representa o próximo número de sequência a ser enviado;
SND.UNA representa o byte mais antigo ainda não confirmado;
RCV.NXT representa o próximo byte que o receptor espera em sequência.

A diferença entre o que foi enviado e o que foi confirmado forma dados in flight. O transmissor não pode aumentar arbitrariamente esse volume: ele é limitado tanto pelo receptor quanto pelo controle de congestionamento.

Recepção fora de ordem

Se segmentos posteriores chegam antes de uma lacuna, uma implementação pode armazená-los temporariamente. A aplicação, entretanto, recebe o fluxo em ordem. Isso cria uma consequência importante: um byte ausente pode impedir que bytes posteriores já recebidos sejam entregues à aplicação, mesmo que estejam disponíveis no buffer TCP.

Esse comportamento é parte do head-of-line blocking do byte stream TCP e tem implicações relevantes para aplicações interativas e mídia em tempo real.

ACK cumulativo e duplicate ACK

Quando um receptor continua recebendo dados além de uma lacuna, ele pode continuar confirmando o último ponto contínuo do fluxo. ACKs repetidos para o mesmo ponto fornecem ao transmissor evidência de que segmentos posteriores chegaram e de que possivelmente há uma perda anterior.

No comportamento clássico descrito nos algoritmos de congestionamento, múltiplos duplicate ACKs permitem iniciar Fast Retransmit sem esperar a expiração do retransmission timeout. Isso reduz o custo temporal de determinadas perdas.

SACK: reconhecimento seletivo

O Selective Acknowledgment — SACK, especificado no RFC 2018, permite que o receptor informe blocos não contíguos já recebidos. Assim, o transmissor obtém uma visão mais precisa das lacunas e evita retransmitir desnecessariamente dados que já estão no destino.

SACK é particularmente relevante quando há múltiplas perdas dentro de uma janela grande. Em enlaces de alta capacidade ou grande RTT, recuperar uma perda por round-trip apenas com ACK cumulativo pode degradar severamente o throughput.

RTT, RTO e o temporizador de retransmissão

O TCP não pode usar um timeout fixo universal para toda rede. Um enlace local de baixa latência e uma conexão intercontinental possuem escalas temporais diferentes. Por isso, o TCP estima o RTT — Round-Trip Time e sua variação para calcular o RTO — Retransmission Timeout.

O RFC 6298 define o algoritmo padrão. Conceitualmente, o transmissor mantém:

SRTT: RTT suavizado;
RTTVAR: estimativa da variação do RTT;
RTO: timeout de retransmissão;
G: granularidade do relógio.

Após amostras de RTT, o RTO é calculado a partir de SRTT acrescido de uma margem baseada em RTTVAR. Na forma especificada, usa-se fator K = 4, com atualização exponencial de SRTT e RTTVAR. Para amostras subsequentes, os pesos tradicionais são alpha = 1/8 para SRTT e beta = 1/4 para RTTVAR.

De forma representativa:

RTO = SRTT + max(G, 4 × RTTVAR)

O RFC 6298 estabelece ainda comportamento de exponential backoff: quando o RTO expira e ocorre retransmissão, o timeout é aumentado, normalmente dobrado conforme o algoritmo. Isso evita que um transmissor continue pressionando agressivamente uma rede ou caminho que não está conseguindo entregar os dados.

Por que retransmissão excessiva aumenta latência

Confiabilidade possui custo. Se um segmento é perdido, os bytes posteriores não podem simplesmente ultrapassar a lacuna no byte stream entregue à aplicação. A recuperação exige retransmissão e, dependendo da detecção da perda, pode custar frações relevantes de RTT ou até uma expiração de RTO. Por isso, TCP confiável não é sinônimo de TCP com menor atraso.

Controle de fluxo: a janela anunciada pelo receptor

O controle de fluxo protege o receptor. Um endpoint pode ter rede rápida, mas aplicação lenta, CPU saturada ou buffer limitado. Se o transmissor ignorasse essa realidade, poderia exceder a capacidade de recepção.

O receptor anuncia uma receive window, frequentemente representada por rwnd, que indica quanto espaço de sequência adicional ele aceita naquele momento. O transmissor ajusta a quantidade de dados não confirmados para respeitar essa limitação.

A janela se move à medida que a aplicação receptora consome dados e libera buffer. Esse comportamento é a base da expressão sliding window.

Zero Window e persistência

Se o buffer fica temporariamente sem espaço, o receptor pode anunciar janela zero. O transmissor deve então interromper o envio normal de novos dados. Entretanto, existe um problema potencial: se a futura atualização abrindo novamente a janela for perdida, os dois lados poderiam permanecer em deadlock.

Para evitar essa situação, TCP utiliza o mecanismo de zero-window probing/persistência, provocando periodicamente informação suficiente para que o receptor volte a anunciar seu estado de janela. Em análise de captura, sequências prolongadas de Zero Window e Window Probe costumam indicar gargalo no endpoint ou na aplicação receptora, não necessariamente perda na rede.

Window Scale

O campo Window básico possui 16 bits. Sem extensão, o valor máximo representável é 65.535 bytes, insuficiente para manter enlaces modernos de alto bandwidth-delay product plenamente ocupados.

O RFC 7323 define a opção Window Scale, negociada durante o handshake. Ela aplica um fator de escala ao campo de janela, permitindo janelas efetivas muito maiores. O shift count é limitado conforme a especificação, possibilitando janelas efetivas da ordem de aproximadamente 1 GiB.

Controle de congestionamento: proteger a rede é diferente de proteger o receptor

Controle de fluxo e controle de congestionamento resolvem problemas distintos:

rwnd limita o envio conforme a capacidade anunciada pelo receptor;
cwnd — congestion window limita o envio conforme a capacidade estimada da rede;
o volume efetivamente permitido em trânsito é limitado, em termos conceituais, pelo menor dos dois limites, além das demais regras do protocolo.

Essa distinção é essencial. Um receptor pode anunciar janela de dezenas de megabytes e, ainda assim, o transmissor enviar muito menos porque o algoritmo de congestionamento ainda não confia que o caminho suporte uma janela tão grande.

Slow Start

Ao iniciar uma conexão, o transmissor não conhece a capacidade disponível no caminho. Slow Start faz o TCP sondar progressivamente a rede, aumentando a congestion window à medida que ACKs confirmam a entrega.

O nome pode induzir ao erro: o crescimento inicial de cwnd pode ser rápido, aproximadamente exponencial por RTT em condições ideais, até que o algoritmo alcance um limiar, detecte congestionamento ou seja limitado por outras condições.

Congestion Avoidance

Após a fase de crescimento inicial, algoritmos clássicos passam a aumentar a janela de forma mais conservadora. O RFC 5681 descreve o comportamento Reno tradicional, incluindo Slow Start, Congestion Avoidance, Fast Retransmit e Fast Recovery.

O estado ssthresh — slow-start threshold — ajuda a decidir quando abandonar o crescimento característico de Slow Start e entrar em Congestion Avoidance.

Fast Retransmit e Fast Recovery

Duplicate ACKs podem indicar que o receptor continua recebendo dados posteriores, mas uma parte anterior está ausente. Com evidência suficiente, o transmissor pode retransmitir a perda antes de esperar pelo RTO. Fast Recovery procura evitar que a conexão volte desnecessariamente ao comportamento mais conservador reservado a timeouts severos.

CUBIC em implementações modernas

Não se deve concluir que todo TCP moderno usa apenas o crescimento linear de Reno. O RFC 9438 padroniza o CUBIC, algoritmo de congestionamento que utiliza uma função cúbica para melhorar escalabilidade e estabilidade em redes rápidas e de longa distância. O próprio RFC registra CUBIC como padrão amplamente implantado e adotado como default por pilhas Linux, Windows e Apple.

O RFC 9438 atualiza o RFC 5681 para permitir o comportamento do CUBIC, que em determinadas regiões pode aumentar cwnd de maneira mais agressiva que Reno. Em engenharia de desempenho, portanto, é necessário saber qual algoritmo de congestionamento o sistema operacional realmente utiliza.

Bandwidth-delay product e por que RTT afeta throughput

Uma conexão precisa manter dados suficientes em trânsito para preencher o caminho. O parâmetro fundamental é o BDP — Bandwidth-Delay Product:

BDP = largura de banda × RTT

Para manter aproximadamente 1 Gbit/s ocupado em um caminho com RTT de 40 ms, o volume em trânsito necessário é da ordem de:

1.000.000.000 bit/s × 0,040 s = 40.000.000 bits ≈ 5 MB

Isso significa que uma janela efetiva de apenas 64 KiB seria muito pequena para preencher esse caminho, mesmo se não houvesse qualquer perda. Esse é um dos motivos técnicos para Window Scale existir.

BDP também mostra por que “link de 1 Gbit/s” não garante throughput TCP de 1 Gbit/s. O resultado depende de RTT, janelas, algoritmo de congestionamento, perdas, capacidade de CPU, buffers, MSS, offloads, intermediários e comportamento da aplicação.

Timestamps e medição de RTT

O RFC 7323 também define TCP Timestamps. A opção contribui para mecanismos como medição de RTT mais robusta e PAWS — Protection Against Wrapped Sequences — importante em caminhos de alta velocidade onde o espaço de sequência de 32 bits pode dar a volta durante a vida útil de segmentos atrasados.

Nagle, pequenos segmentos e latência de aplicação

O Nagle algorithm foi criado para reduzir a proliferação de segmentos pequenos. De forma simplificada, quando existem dados não confirmados, novos pequenos writes podem ser mantidos até que os dados pendentes sejam confirmados ou seja possível enviar um segmento de tamanho adequado.

O RFC 9293 recomenda que implementações suportem Nagle e exige que exista uma forma de a aplicação desabilitá-lo por conexão. Isso é relevante porque aplicações request-response e interativas podem sofrer interação indesejada entre Nagle e delayed ACKs.

Desabilitar Nagle indiscriminadamente também não é solução universal: o trade-off envolve latência, eficiência, número de pacotes e comportamento específico da aplicação. Em sistemas de engenharia, a decisão deve ser baseada em captura, perfil de tráfego e requisitos temporais.

Encerramento de uma conexão TCP

Como o TCP é full-duplex, cada direção é encerrada de forma lógica independente. O fechamento normal costuma envolver FIN e ACK para cada sentido.

Um fluxo típico é:

Um endpoint envia FIN, indicando que não enviará novos bytes.
O peer confirma o FIN com ACK, podendo ainda continuar enviando dados na direção oposta.
Quando o peer termina sua própria transmissão, envia seu FIN.
O endpoint original confirma esse FIN.

Por isso, muitas representações mostram um fechamento em quatro mensagens, embora ACK e FIN possam ser combinados em determinadas situações.

RST é diferente de FIN

FIN representa encerramento ordenado da direção de envio. RST indica reset/aborto em condições específicas e pode finalizar a associação de forma abrupta. Para aplicações, a diferença é operacionalmente importante: um reset pode significar rejeição, estado inexistente, erro de aplicação ou encerramento forçado.

Por que existe TIME-WAIT

Após fechamento ativo, a especificação prevê permanência em TIME-WAIT por 2 × MSL — Maximum Segment Lifetime. O objetivo inclui evitar que segmentos atrasados de uma conexão anterior sejam confundidos com uma nova conexão de mesmo 4-tuple e permitir o reenvio do ACK final se o FIN remoto for retransmitido.

Portanto, TIME-WAIT é um mecanismo de correção e robustez, não apenas um “socket preso”. Servidores de altíssima taxa de conexões precisam considerar seu impacto no projeto, mas não se deve simplesmente eliminar esse estado sem compreender as implicações do protocolo.

Segurança: TCP confiável não significa TCP seguro

TCP fornece confiabilidade de transporte, mas não fornece confidencialidade, integridade criptográfica ou autenticação de identidade. Qualquer projeto que trate TCP puro como “canal seguro” está misturando propriedades diferentes.

O checksum é voltado à detecção de corrupção acidental. Proteção contra espionagem ou modificação maliciosa exige protocolos como TLS, IPsec ou mecanismos específicos da aplicação.

Injeção e resets falsificados

Conexões TCP longas historicamente foram alvo de ataques off-path que tentam adivinhar o 4-tuple e números de sequência para inserir RST, SYN ou dados dentro da janela válida. O RFC 5961 especifica melhorias de robustez contra ataques blind in-window, e o RFC 9293 incorporou atualização relacionada a esse tratamento.

Isso reforça uma distinção de engenharia: a máquina de estados e a validação de sequência oferecem robustez protocolar, mas não substituem autenticação criptográfica.

SYN flooding e estado no servidor

O fato de TCP manter estado também cria superfície para ataques de exaustão durante o handshake. Um SYN pode levar o servidor a reservar estado enquanto aguarda a conclusão da conexão. Implementações e equipamentos modernos utilizam diversas mitigações, mas capacidade de backlog, proteção de borda e comportamento sob SYN flood continuam relevantes em projetos de disponibilidade.

TCP em HTTP, HTTPS, RTSP e streaming de vídeo

TCP é infraestrutura de transporte para inúmeros protocolos de aplicação. O HTTP em HTTP/1.1 e HTTP/2 é tradicionalmente transportado sobre TCP. No HTTPS, TLS normalmente é inserido entre HTTP e TCP nessas versões. HTTP/3 é uma exceção arquitetural importante: opera sobre QUIC, que utiliza UDP, e não TCP.

Em sistemas de vídeo IP, RTSP pode usar TCP para sua sessão de controle e também pode haver transporte intercalado de mídia sobre a própria conexão TCP, dependendo do modo empregado. Já RTP é frequentemente associado a UDP quando o objetivo é evitar que a recuperação de uma perda bloqueie o avanço temporal do fluxo.

Por que TCP pode ser vantajoso para streaming

TCP pode atravessar determinados firewalls e NATs com mais facilidade em arquiteturas onde conexões UDP adicionais são problemáticas. Também garante entrega ordenada, o que pode ser desejável quando perda não é aceitável ou quando o buffer de reprodução tolera retransmissões.

Por que TCP pode aumentar atraso em streaming

A mesma propriedade de ordenação cria custo: se um segmento TCP contendo parte da mídia é perdido, bytes posteriores não são entregues ao consumidor do byte stream até que a lacuna seja recuperada. Em tempo real, isso pode transformar perda pontual em aumento de latência ou congelamento perceptível, dependendo do buffer e da aplicação.

Por isso, dizer que “TCP é melhor porque não perde pacote” é tecnicamente incompleto. A questão correta é qual comportamento de falha é preferível para a aplicação: recuperar todos os bytes, mesmo com atraso adicional, ou aceitar perdas localizadas para manter a linha do tempo.

TCP vs UDP: diferenças de engenharia

O protocolo UDP oferece uma abstração diferente. A comparação correta não é “seguro versus inseguro” nem “rápido versus lento”, mas byte stream confiável e com estado versus serviço de datagramas com menos mecanismos embutidos.

Aspecto	TCP	UDP
Abstração	Fluxo de bytes	Datagramas
Estado de conexão	Mantido nos endpoints	Não há handshake de conexão no UDP-base
Ordenação	Entrega em ordem para a aplicação	Não garante ordem
Recuperação de perda	Retransmissão e mecanismos de recuperação	Não existe retransmissão no UDP-base
Controle de fluxo	Sim, por janela do receptor	Não no UDP-base
Controle de congestionamento	Integrado ao comportamento TCP	Deve ser tratado pelo protocolo/aplicação que usa UDP quando necessário
Fronteira de mensagens	Não preservada	Datagramas são preservados como unidades
Head-of-line do transporte	Sim, no byte stream	Não da mesma forma no UDP-base
Overhead e estado	Maiores	Menores no protocolo-base
Casos típicos	Web sobre TCP, arquivos, sessões confiáveis, muitos protocolos de controle	DNS tradicional, mídia em tempo real, QUIC, telemetria e outros casos específicos

UDP não é “TCP sem confiabilidade”. Aplicações sobre UDP podem implementar ACK, retransmissão, congestion control, criptografia e multiplexação próprios. QUIC é um exemplo importante: usa UDP como substrato, mas implementa mecanismos sofisticados acima dele.

Como diagnosticar TCP em uma captura de rede

Uma análise de engenharia não deve se limitar a “há retransmission no Wireshark”. É necessário correlacionar sequência, ACK, janelas, RTT e contexto da aplicação.

Falha na abertura

Se aparecem SYNs repetidos sem SYN-ACK, as hipóteses incluem:

serviço não alcançável;
firewall descartando silenciosamente;
problema de roteamento;
perda no caminho;
host sem resposta.

Se o servidor responde com RST rapidamente, o caminho IP provavelmente existe, mas o endpoint pode não possuir serviço escutando naquela porta ou pode estar rejeitando a conexão.

Retransmissions e duplicate ACKs

Retransmissão indica que o transmissor concluiu que dados precisavam ser enviados novamente; ela não revela sozinha a causa física da perda. Duplicate ACKs e SACK blocks ajudam a localizar lacunas e distinguir padrões de reordenação e perda.

É necessário verificar também:

RTT antes e durante o problema;
bursts de perda;
mudanças de janela;
interface errors/drops;
congestionamento e filas;
policers e shapers;
comportamento de firewall/IPS;
utilização de CPU e buffers dos endpoints.

Zero Window

TCP Zero Window é evidência forte de que o receptor informou falta de buffer disponível. Nessa situação, aumentar banda do enlace pode não resolver nada. O gargalo pode estar no software consumidor, armazenamento, CPU ou arquitetura de buffers.

Out-of-order não é automaticamente perda

Pacotes podem chegar fora de ordem em caminhos com paralelismo, balanceamento, diferenças de fila ou captura imperfeita. O TCP precisa lidar com reordenação. Diagnóstico correto exige separar reordenação real de perda e também considerar limitações do próprio ponto de captura, como offloads de NIC.

Critérios de projeto para escolher TCP

TCP é apropriado quando a aplicação se beneficia de uma abstração de byte stream e precisa que dados sejam entregues em ordem, sem lacunas silenciosas, com mecanismos padronizados de retransmissão, fluxo e congestionamento.

A escolha deve considerar:

tolerância da aplicação a atraso versus perda;
RTT e bandwidth-delay product;
previsibilidade de perdas;
duração das conexões;
necessidade de atravessar middleboxes;
comportamento de segurança acima do transporte;
quantidade de conexões simultâneas;
capacidade de buffer e processamento dos endpoints;
requisitos de disponibilidade e recuperação.

Em sistemas corporativos, industriais e de segurança eletrônica, TCP aparece tanto em planos de controle quanto em transferência de dados. A engenharia deve observar não apenas “qual porta usa TCP”, mas como as propriedades de transporte afetam desempenho, continuidade e comportamento em falhas.

Considerações finais

TCP permanece central à arquitetura da Internet porque transforma um serviço IP sujeito a perda, atraso e reordenação em uma abstração de transporte muito mais conveniente para aplicações que exigem sequência e recuperação. Essa conveniência, porém, é obtida por meio de estado, buffers, temporizadores, janelas e algoritmos que interagem diretamente com RTT, perdas e capacidade da rede.

Entender TCP em profundidade exige separar quatro mecanismos: confiabilidade, que organiza e recupera o byte stream; controle de fluxo, que protege o receptor; controle de congestionamento, que protege e sonda o caminho; e segurança, que não é fornecida pelo protocolo-base e precisa ser adicionada em outras camadas.

Para projeto e troubleshooting, a consequência é objetiva: desempenho TCP não pode ser inferido apenas pela velocidade nominal do enlace. rwnd, cwnd, RTT, RTO, MSS, SACK, Window Scale, algoritmo de congestionamento e comportamento da aplicação formam um sistema interdependente. É essa visão sistêmica que permite interpretar corretamente uma captura, dimensionar enlaces de alto BDP e decidir quando TCP ou outro transporte é mais adequado.

Referências técnicas

[1] EDDY, W. (ed.). RFC 9293: Transmission Control Protocol (TCP). Internet Standard STD 7. RFC Editor, 2022.

[2] ALLMAN, M.; PAXSON, V.; BLANTON, E. RFC 5681: TCP Congestion Control. RFC Editor, 2009.

[3] XU, L.; HA, S.; RHEE, I.; GOEL, V.; EGGERT, L. RFC 9438: CUBIC for Fast and Long-Distance Networks. RFC Editor, 2023.

[4] PAXSON, V.; ALLMAN, M.; CHU, J.; SARGENT, M. RFC 6298: Computing TCP's Retransmission Timer. RFC Editor, 2011.

[5] BORMAN, D.; BRADEN, B.; JACOBSON, V.; SCHEFFENEGGER, R. RFC 7323: TCP Extensions for High Performance. RFC Editor, 2014.

[6] MATHIS, M.; MAHDAVI, J.; FLOYD, S.; ROMANOW, A. RFC 2018: TCP Selective Acknowledgment Options. RFC Editor, 1996.

[7] DUKE, M.; BRADEN, R.; EDDY, W.; BLANTON, E.; ZIMMERMANN, A. RFC 7414: A Roadmap for Transmission Control Protocol (TCP) Specification Documents. RFC Editor, 2015.

[8] RAMAIAH, A.; STEWART, R.; DALAL, M. RFC 5961: Improving TCP's Robustness to Blind In-Window Attacks. RFC Editor, 2010.

Perguntas frequentes

O que é o protocolo TCP?

TCP é um protocolo de transporte orientado a conexão que oferece às aplicações um fluxo de bytes bidirecional, confiável e entregue em ordem. Ele usa números de sequência, acknowledgements, janelas, retransmissão e controle de congestionamento para operar sobre o serviço de datagramas do IP.

Qual RFC define o TCP atualmente?

A especificação-base vigente é o RFC 9293, Internet Standard STD 7, publicado em 2022. Ele substituiu o RFC 793 e consolidou diversas atualizações acumuladas ao longo da evolução do TCP.

Como funciona o three-way handshake do TCP?

O iniciador envia SYN com seu número de sequência inicial; o peer responde SYN+ACK reconhecendo esse SYN e apresentando seu próprio número de sequência; o iniciador envia o ACK final. Assim, os dois lados sincronizam os espaços de sequência e confirmam comunicação bidirecional.

Qual é a diferença entre rwnd e cwnd no TCP?

rwnd é a janela anunciada pelo receptor e implementa controle de fluxo. cwnd é a congestion window mantida pelo transmissor e implementa controle de congestionamento. Em termos conceituais, a quantidade de dados em trânsito fica limitada pelo menor desses limites, além das demais regras do protocolo.

O que são RTT e RTO?

RTT é o tempo de ida e volta medido entre transmissão e reconhecimento. RTO é o timeout usado para decidir quando uma ausência de confirmação exige retransmissão. O RFC 6298 define como SRTT, RTTVAR e RTO devem ser calculados e administrados.

O TCP garante que os dados sempre chegarão?

Não. Uma conexão pode falhar e a aplicação receberá um erro. A propriedade de confiabilidade significa que TCP não deve entregar silenciosamente à aplicação um fluxo com lacunas ou fora de ordem enquanto mantém a conexão; perdas são recuperadas por retransmissão quando possível.

TCP é mais rápido que UDP?

Não existe uma resposta universal. TCP possui mais mecanismos de estado, confiabilidade, controle de fluxo e congestionamento; UDP oferece datagramas com menos mecanismos no protocolo-base. O melhor transporte depende de requisitos de latência, perda, ordem e semântica da aplicação.

TCP é seguro ou criptografado?

Não por si só. TCP possui checksum para detectar corrupção acidental, mas não fornece confidencialidade, autenticação ou integridade criptográfica. TLS, IPsec ou mecanismos equivalentes são necessários quando essas propriedades são exigidas.

Por que TCP pode causar atraso em streaming?

Porque a aplicação recebe um byte stream em ordem. Se houver uma lacuna causada por perda, bytes posteriores podem ficar retidos até que o segmento ausente seja recuperado. Esse head-of-line blocking pode transformar uma perda pontual em atraso perceptível.

Materiais técnicos complementares

Serviços relacionados

Projeto de Rede Lógica e Redes Corporativas: arquitetura, redundância, segmentação e segurança