03 - Funcionalidades

A Camada de Transporte (Camada 4 do modelo OSI) opera como o elemento mediador entre a aplicação (que consome dados) e a camada de rede (que entrega pacotes "best-effort"). Para cumprir seu objetivo de prover comunicação lógica entre processos, ela desempenha um conjunto de funcionalidades críticas que definem a arquitetura da Internet moderna.

Ao contrário da camada de Rede, que está preocupada com a entrega host a host, a camada de Transporte preocupa-se com a entrega processo a processo. Suas funcionalidades centrais projetam um serviço que é ao mesmo tempo flexível na sua abrangência e deliberadamente adaptável às necessidades da aplicação.

As funcionalidades primárias que definem o comportamento da Camada de Transporte são:

1. Multiplexação e De-multiplexação

A função mais visível da camada é permitir que múltiplos processos de aplicação compartilhem a mesma interface de rede. Essa funcionalidade é dividida em dois processos:

• Multiplexação (origem): Vários processos (Chrome, Outlook, Spotify) enviam dados simultaneamente. O TCP/UDP marca cada segmento com a porta de origem e os entrega ao IP para transmissão pela mesma interface.
• De-multiplexação (destino): O receptor lê a porta de destino e encaminha o segmento ao socket correto. No TCP isso é orientado a conexão (5-tuple); no UDP basta a porta.

2. Controle de Erro

A camada de Transporte implementa detecção de erros que vai além da simples verificação de cabeçalho feita pela camada de Rede:

• Checksum TCP/UDP: Verifica a integridade do cabeçalho + payload + pseudo-header (com IPs). No UDP/IPv4 é opcional; no TCP e no UDP/IPv6 é obrigatório.
• Descarte de segmentos corrompidos: Quando o checksum falha, o segmento é silenciosamente descartado, sem ICMP, deixando a cargo do emissor detectar a perda.
• Reparação (somente TCP): O TCP retransmite segmentos perdidos ou corrompidos. O UDP não repara — a aplicação precisa lidar com isso (ex: FEC em codecs de áudio).

3. Controle de Fluxo (Flow Control)

Apenas o TCP implementa flow control, através do campo Window Size do cabeçalho:

• O receptor anuncia continuamente quantos bytes ainda consegue receber sem estourar o buffer.
• Quando o buffer está quase cheio, o receptor anuncia window = 0 (zero window), pausando o emissor.
• O emissor envia periodicamente window probes (1 byte) para detectar a reabertura da janela.
• A opção Window Scale (RFC 7323) permite janelas maiores que 64 KB, essenciais em links de alta velocidade x alta latência (BDP alto).

4. Controle de Congestão (Congestion Control)

Diferente do controle de fluxo (origem-destino), o controle de congestão protege a rede inteira:

• Somente no TCP. O UDP é unreliable by design e não reage a perdas.
• Algoritmos clássicos: Slow Start, Congestion Avoidance, Fast Retransmit, Fast Recovery (RFC 5681).
• Variantes modernas: CUBIC (padrão Linux), BBR (Google, baseado em banda observada), Vegas, BIC, HTCP.
• Conceitos: cwnd (congestion window), ssthresh (slow start threshold), AIMD (Additive Increase, Multiplicative Decrease).

5. Estabelecimento e Liberação de Conexão

• Estabelecimento TCP (Three-Way Handshake):
  Cliente → SYN (seq=x) → Servidor Cliente ← SYN+ACK (seq=y, ack=x+1) ← Servidor Cliente → ACK (ack=y+1) → Servidor
  Após três segmentos, estado ESTABLISHED em ambos os lados.

• Liberação TCP (Four-Way Handshake): Cada lado fecha independentemente com FIN/ACK, passando por estados FIN_WAIT_1, FIN_WAIT_2, TIME_WAIT, CLOSE_WAIT, LAST_ACK, CLOSED. O TIME_WAIT (2·MSL, tipicamente 60 s) garante que o ACK final chegue ao par e que pacotes antigos não ressurgam em novas conexões.

• UDP: não estabelece nem libera conexão. Cada datagrama é independente.

6. Garantia de Ordem e Entrega (Apenas TCP)

• Sequence numbers identificam cada byte do fluxo, permitindo reordenar segmentos que chegaram fora de ordem.
• ACKs cumulativos confirmam todos os bytes até determinado número.
• Retransmissão com timeout (RTO calculado dinamicamente via SRTT/RTTVAR) ou fast retransmit (3 dup ACKs).

7. Funcionalidades Suportadas por Protocolo

8. Serviços Auxiliares

• Portas well-known (0-1023): padronizam serviços como HTTP (80), HTTPS (443), SSH (22), DNS (53).
• Out-of-band data (URG flag): mecanismo pouco usado para dados prioritários.
• Keep-alive: detecção de conexões mortas (TCP_KEEPCNT, TCP_KEEPIDLE no Linux).
• Path MTU Discovery: descobrir a menor MTU do caminho para ajustar o MSS.

9. Limitações da Camada de Transporte

• Não cifra dados: TLS é necessário para confidencialidade (camada acima).
• Não garante disponibilidade: DDOS pode esgotar sockets (SYN flood).
• Não atravessa NAT sem state: o NAT mantém tabelas de tradução de porta, o que dificulta servidores atrás de NAT.
• Head-of-line blocking (TCP): perda de um segmento atrasa todos os seguintes, mesmo que já tenham chegado.

10. Inspeção Prática no Linux

# Ver sockets TCP/UDP em escuta
ss -tulnp

# Estatísticas da camada de transporte
nstat -az | grep -E 'Tcp|Udp'

# Ver opções TCP negociadas em uma conexão
ss -tie dst 93.184.216.34

# Ajustar buffer de recepção TCP (bytes)
sysctl net.ipv4.tcp_rmem      # min default max
sysctl net.ipv4.tcp_wmem      # min default max (tx)

# Habilitar SACK, Window Scaling, Timestamps
sysctl net.ipv4.tcp_sack
sysctl net.ipv4.tcp_window_scaling
sysctl net.ipv4.tcp_timestamps

Estados TCP

A tabela a seguir lista os estados possíveis de uma conexão TCP:

11. Comparativo Final: TCP vs UDP

A escolha entre os dois reflete o trade-off entre confiabilidade e latência. Aplicações que precisam de integridade total (HTTP/1, SMTP, FTP, SSH) usam TCP. Aplicações sensíveis a latência e tolerantes a perdas (VoIP, vídeo, jogos online, DNS, DHCP) usam UDP. Aplicações modernas como QUIC combinam o melhor dos dois: UDP no wire com confiabilidade customizada em userspace.