03 - Controle de Erro e Fluxo

O Controle de Erro e o Controle de Fluxo são os dois mecanismos de regulação mais críticos implementados pelo serviço de Circuito Virtual (especialmente o TCP) na Camada de Transporte. Enquanto ambos envolvem a regulação da transmissão de dados, eles resolvem problemas diferentes:

• O Controle de Erro lida com a confiabilidade: garante que os dados enviados cheguem íntegros e na ordem correta, apesar da rede subjacente ser não confiável.
• O Controle de Fluxo lida com a velocidade: garante que o remetente não envie dados mais rápido do que o receptor consegue processar, evitando o congestionamento do buffer de memória do receptor.

Juntos, esses mecanismos criam um canal de comunicação onde a integridade dos dados é preservada e o sistema opera estável, sem sobrecargas localizadas.

1. Controle de Erro (Error Control)

O objetivo do controle de erro é transformar o serviço não confiável da Camada de Rede (IP) em um canal livre de erros para a aplicação. Ele deve detectar pacotes corrompidos, recuperar pacotes perdidos, reordenar pacotes que chegaram fora de sequência e eliminar duplicatas.

A. Detecção de Erros: Checksum

A primeira linha de defesa é a detecção. O cabeçalho TCP possui um campo Checksum de 16 bits.

• Escopo: Diferente do IP (que verifica apenas o cabeçalho), o TCP calcula o checksum sobre um pseudo-cabeçalho (que inclui endereços IP origem/destino), o cabeçalho TCP e os dados (payload).
• Ação: Se o receptor calcula o checksum e o valor não corresponde, o segmento é corrompido. O receptor o descarta silenciosamente. A recuperação ocorrerá via ausência de ACK (retransmissão).
• Limitação: O checksum de complemento de 1 é fraco contra erros intencionais (ataques) e contra algumas corrupções — em ambientes com alto BER (Bit Error Rate), recomenda-se usar TCP sobre links com CRC forte (ex: Ethernet FCS, PPP CRC-32).

B. Numeração de Sequência (Sequence Numbers)

Para ordenar os dados e detectar perdas, cada byte do fluxo de dados é numerado sequencialmente.

• Função: O número de sequência do cabeçalho TCP indica o número do primeiro byte de dados contido naquele segmento.
• Remontagem: Se o receptor recebe o segmento com os bytes 1000-1499, mas ainda não recebeu o 500-999, ele sabe que existe uma "lacuna" (hole). Ele guarda o segmento 1000-1499 no buffer e aguarda o anterior.
• Tamanho do campo: 32 bits. Com ISN aleatório, o TCP sobrevive a ciclos de wrap-around (RFC 1323 PAWS protege contra confusão em altas taxas).

C. Confirmação de Recebimento (ACK - Acknowledgment)

O receptor envia feedback contínuo para o remetente sobre o que recebeu com sucesso.

• ACK Cumulativo: O TCP usa um mecanismo de ACK cumulativo. Se o receptor envia um ACK com número de confirmação 2001, ele está dizendo: "Recebi todos os bytes até o 2000 com sucesso. Estou aguardando o byte 2001". Isso confirma implicitamente o recebimento de todos os bytes anteriores.
• ACKs Atrasados (Delayed ACK, RFC 1122): Para reduzir carga, o receptor pode segurar o ACK até 200 ms ou até acumular 2 segmentos full-MSS, o que reduz pela metade o tráfego de ACK em fluxos regulares.
• SACK - Selective ACK (RFC 2018): Quando o receptor suporta SACK (negociado no handshake), ele pode anunciar explicitamente faixas recebidas fora de ordem. Ex: SACK blocks: [5000-5999] [8000-8999]. O remetente retransmite só as lacunas (4000-4999 e 6000-7999), economizando banda em perdas múltiplas.

D. ARQ - Automatic Repeat reQuest

A filosofia do TCP é a de um protocolo ARQ — detecta perdas via timeout/ACKs duplicados e retransmite automaticamente. Variantes:

• Stop-and-Wait: Envia 1 pacote, espera ACK, envia próximo. Ineficiente em qualquer rede não-trivial. Não usado pelo TCP.
• Go-Back-N: Envia N pacotes; em caso de perda, retransmite a partir do perdido. Usado por padrão pelo TCP sem SACK.
• Selective Repeat: Retransmite só o que foi perdido. Aproximado pelo TCP-SACK.

O TCP moderno, com SACK habilitado (default em Linux desde 2.6), comporta-se praticamente como Selective Repeat.

E. Retransmissão (Retransmission)

A parte ativa do controle de erro é a recuperação de falhas. O remetente deve reenviar o que foi perdido.

1. Retransmissão por Timeout (RTO - Retransmission Timeout):
   • O remetente inicia um temporizador sempre que envia um segmento.
   • Se o temporizador expirar antes de o ACK chegar, o remetente assume que o segmento foi perdido e o reenvia.
   • O valor do timeout é dinâmico e se ajusta baseado no RTT (Round Trip Time) medido da rede, usando o algoritmo de Karn/Partridge e, em implementações modernas, o algoritmo ERTT/RTO (RFC 6298): RTO = SRTT + 4 * RTTVAR, com born inferior de 1 s (Linux: 200 ms).
2. Retransmissão Rápida (Fast Retransmit, RFC 5681):
   • Se o remetente recebe 3 ACKs duplicados consecutivos (ex: três ACKs para o byte 1000 quando ele já esperava o 1500), ele infere que o segmento 1500 foi perdido.
   • Ele retransmite o segmento 1500 imediatamente, sem esperar o timer expirar. Isso acelera a recuperação em redes rápidas.
3. Retransmissão por RACK (RFC 8985, Linux 4.x+): Mais moderno que o dup-ACK count. Usa o maior número de sequência já confirmado como referência temporal; se um segmento foi enviado antes do momento do RACK e ainda não foi ACKado, ele é considerado perdido. Especialmente útil para perdas em fluxos longos com janela grande.

2. Controle de Fluxo (Flow Control)

O objetivo do controle de fluxo é evitar que o receptor seja sobrecarregado. Mesmo que a rede seja rápida e o remetente tenha muita largura de banda, o computador receptor pode ter uma CPU lenta ou pouca memória RAM disponível para processar os dados recebidos.

Se o remetente enviar dados mais rápido do que o receptor pode ler, o buffer de recepção do receptor encherá e começará a descartar novos pacotes, desperdiçando largura de banda com dados que seriam perdidos de qualquer forma.

A. O Mecanismo de Janela Deslizante (Sliding Window)

O controle de fluxo no TCP é implementado através do protocolo de Janela Deslizante. O remetente só pode enviar um certo número de bytes sem ter recebido confirmação (ACK). Esse número é o tamanho da "janela".

• rwnd (Receiver Window): O receptor anuncia em todo segmento TCP (no campo Window Size) quantos bytes de espaço livre ele ainda tem no seu buffer de recepção. Este valor é o rwnd.
• Window Scaling (RFC 7323): Como o campo Window é 16 bits (máx 64 KiB), usa-se um fator de escala até 2^14, permitindo janelas de até 1 GiB — essencial em enlaces de alto BDP (banda-delay product).

B. O Processo de Regulação

1. Anúncio de Capacidade: O receptor diz ao remetente: "Eu tenho espaço para mais X bytes".
2. Envio Limitado: O remetente mantém uma variável cwnd (congestion window - controle de congestionamento) e respeita a regra: Tamanho do Envio = min(rwnd, cwnd). O remetente nunca envia mais dados do que o receptor disse que pode aguentar.
3. Esvaziamento do Buffer: Quando a aplicação no receptor lê dados do buffer, espaço é liberado.
4. Atualização: O receptor envia novos ACKs com o valor atualizado do rwnd, aumentando a janela e permitindo que o remetente acelere novamente.

C. O Problema da Janela Zero (Zero Window)

Se a aplicação no receptor estiver muito lenta e o buffer encher completamente, o receptor enviará um rwnd = 0.

• Bloqueio: O remetente deve parar de enviar novos dados de usuário imediatamente.
• Manutenção da Conexão: O remetente entra em modo de persistência. Ele envia pequenos segmentos de teste chamados Zero Window Probes (sondas de janela zero) para verificar se o receptor já liberou algum espaço.
• Desbloqueio: Assim que o receptor tiver espaço, ele responde à sonda com um novo rwnd > 0, e o remetente retoma a transmissão normal.

D. Silly Window Syndrome

Se o receptor libera espaço aos poucos, anuncia janelas minúsculas (1 byte) e o remetente envia segmentos de 1 byte, com 40+ bytes de cabeçalho — desperdício catastrófico. A solução é dupla: o receptor usa a solução de Clark (só anuncia janela > 0 quando tiver ≥ MSS ou metade do buffer livre) e o remetente usa o algoritmo de Nagle (acumula pequenos segmentos até completar um MSS ou receber ACK). Ambos definidos na RFC 1122.

3. Resumo Comparativo

Ambos os mecanismos operam em conjunto no cabeçalho TCP. O remetente envia dados baseando-se no menor valor entre o que a rede aguenta (Controle de Congestionamento), o que o receptor aguenta (Controle de Fluxo), enquanto o Controle de Erro garante que o que chegou é o que foi enviado.

4. Diagnóstico Prático

Verificar contadores de retransmissões no Linux:

nstat -az | grep -E 'TcpRetransSegs|TcpInErrs|TcpExtTCPLost|TcpExtTCPSACK'
ss -ti   # mostra RTT, rttvar, cwnd, rwnd por socket TCP
tcpdump -n -i any 'tcp[tcpflags] & tcp-ack != 0 and tcp[tcpflags] & tcp-syn == 0' -v

Análise típica de problema: muitas TcpRetransSegs e TcpExtTCPSackRecovery indicam perda em trânsito (controle de erro em ação); TcpExtTCPSchedulerFailed indica window scheduling problem (controle de fluxo).