Camada de Transporte e o Papel no SSH

1. Definição

A Camada de Transporte (camada 4 no modelo OSI ou camada Host-to-Host no TCP/IP) é responsável por fornecer comunicação lógica fim-a-fim (end-to-end) entre processos de aplicação executados em hosts diferentes. Enquanto a Camada de Rede (IP) é responsável por mover os pacotes de um dispositivo a outro através da internet, a Camada de Transporte entrega esses dados ao processo específico (aplicação) que os solicitou.

A Camada de Transporte atua como uma "rede dentro da rede", abstraindo a complexidade da infraestrutura subjacente e oferecendo serviços de comunicação direta e confiável (ou não confiável, conforme a necessidade) para as aplicações de software. Ela é a camada que eleva o nível de abstração de "endereçar computadores" (IP) para "endereçar conversas" (portas/sockets).

No contexto do SSH, o protocolo de aplicação (RFC 4251) define uma subcamada interna também chamada "Transport Layer" (RFC 4253), que roda sobre TCP e provê confidencialidade, integridade e autenticação de servidor — não confundir com a Camada 4 OSI, mas complementá-la.

2. Comunicação entre Processos vs. Comunicação entre Hosts

Para compreender a Camada de Transporte, é fundamental distinguir seu papel da Camada de Rede (camada 3).

• Camada de Rede (IP): Foca na entrega hop-a-hop (salto a salto) de um roteador para outro. Sua responsabilidade é fazer o pacote cruzar o globo de um endereço IP de origem até um endereço IP de destino. Não se importa com qual aplicação vai usar os dados, apenas com onde o computador está.
• Camada de Transporte: Foca na entrega process-to-process (processo a processo). Uma vez que o pacote chega ao host de destino (graças ao IP), a Camada de Transporte direciona os dados para a aplicação correta (ex: navegador web vs. cliente SSH).

3. Multiplexagem e Desmultiplexagem

A funcionalidade mais básica e crítica da Camada de Transporte é a multiplexagem no lado do transmissor e a desmultiplexagem no lado do receptor.

• O Problema: Um computador pode rodar dezenas de aplicações de rede simultaneamente (navegador, Spotify, Dropbox, cliente de jogos, sessões SSH). Se todos usam o mesmo endereço IP e os mesmos cabos, como o sistema operacional sabe qual pacote pertence a qual aplicação?
• A Solução (Portas): A Camada de Transporte adiciona um cabeçalho com números de porta (16 bits, 0-65535).

Operação

Faixas de Portas (RFC 6335)

4. Os Dois Paradigmas de Serviço

A Camada de Transporte é dividida em dois protocolos dominantes que oferecem filosofias opostas de serviço, refletindo a diversidade de necessidades das aplicações.

A. TCP (Transmission Control Protocol) — RFC 9293

O TCP é o protocolo de transporte "de alta qualidade". Cria uma conexão lógica entre remetente e receptor antes de enviar qualquer dado (three-way handshake: SYN → SYN/ACK → ACK).

Uso típico: Web (HTTP/HTTPS), e-mail (SMTP), transferência de arquivos (FTP), SSH, bancos de dados. Todos exigem entrega confiável e ordenada.

B. UDP (User Datagram Protocol) — RFC 768

O UDP é o protocolo "enxuto" (lean). Não estabelece conexão e envia dados sem cerimônia.

• Best-Effort: Não garante entrega. Se um pacote se perde, o UDP não retransmite.
• Cabeçalho mínimo: 8 bytes (vs. mínimo 20 bytes do TCP).
• Baixa latência: Ausência de handshakes e verificações de erro complexas.
• Sem controle de congestionamento: Envia o mais rápido possível. Pode ser perigoso para a rede se mal usado, mas é vital para aplicações de tempo real.

Uso típico: Streaming de vídeo (WebRTC), VoIP, jogos online, DNS (consultas rápidas), DHCP, SNMP, NTP, QUIC (HTTP/3).

5. SSH sobre a Camada de Transporte

O SSH (RFC 4251) define uma arquitetura em três subcamadas internas:

A subcamada de transporte do SSH estabelece a sessão criptografada sobre TCP na porta 22. Após o handshake de transporte (identificação de versão, algoritmo KEX, troca Diffie-Hellman, geração de chave de sessão), todas as mensagens subsequentes — inclusive as de autenticação de usuário — já trafegam criptografadas.

Por que SSH usa TCP e não UDP?

• Confiabilidade: comandos interativos (shell remoto) não toleram perda de pacotes. Reenvio manual seria inviável.
• Ordem: a sequência de comandos e respostas deve ser preservada.
• Controle de fluxo: sessões SSH em links lentos (modem, satélite) precisam adaptar-se à capacidade do canal.
• Handshake TCP estabelecido: o SSH aproveita o three-way handshake TCP antes de iniciar seu próprio handshake, evitando reinventar essa lógica.

6. O Conceito de Socket (Endpoint)

Na arquitetura TCP/IP, uma comunicação na Camada de Transporte é definida pelo par (Endereço IP, Porta). Essa combinação é chamada de Socket.

• Socket Local: IP_origem:Porta_origem
• Socket Remoto: IP_destino:Porta_destino
• 5-tupla única: (IP_origem, Porta_origem, IP_destino, Porta_destino, Protocolo)

Esta unicidade permite múltiplas abas do navegador no mesmo site, cada uma em conexão TCP separada (portas de origem diferentes), conectando-se ao mesmo servidor (IP e porta de destino iguais). Para SSH, permite múltiplas sessões simultâneas ao mesmo servidor.

7. Segmentação e Reassemblagem

A Camada de Transporte lida com a limitação de tamanho de pacotes:

• Segmentação: A aplicação gera um fluxo contínuo de dados. O TCP corta esse fluxo em pedaços menores chamados segmentos, atribuindo um número de sequência (32 bits) para cada pedaço. Tamanho máximo determinado por MSS (Maximum Segment Size), tipicamente 1460 bytes em Ethernet.
• Reassemblagem: No destino, a Camada de Transporte reúne os segmentos na ordem correta antes de passá-los à aplicação. No caso do UDP, a aplicação recebe datagramas brutos e deve lidar com a ordenação se necessário.

Anatomia de um Segmento TCP

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Source Port          |       Destination Port         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Acknowledgment Number                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Data |           |U|A|P|R|S|F|                               |
| Offset| Reserved  |R|C|S|S|Y|I|            Window             |
|       |           |G|K|H|T|N|N|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Checksum              |   Urgent Pointer              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Options (variable)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

8. Auditoria e Diagnóstico

# Listando conexões TCP/UDP ativas com processo associado
ss -tulpn

# Capturando handshake TCP de uma conexão SSH
sudo tcpdump -i any -n 'port 22 and (tcp[tcpflags] & tcp-syn != 0)' -vv

# Inspecionando uma conexão SSH ativa com strace
sudo strace -p $(pgrep -f sshd | head -1) -e trace=read,write

# Verificando MSS, MTU e caminho TCP de uma conexão SSH
sudo tcpdump -i any -n 'port 22' -A | grep -i SSH

# Medindo latência TCP com tcptraceroute
sudo tcptraceroute host.com 22

9. Resumo Técnico

10. Conclusão

A Camada de Transporte é a interface que permite que desenvolvedores de software escrevam aplicações de rede sem se preocupar com roteadores, cabos, MTU ou erros de transmissão física. Ela oferece uma API limpa (portas e conexões) que abstrai o caos da rede subjacente. No caso do SSH, a escolha do TCP como substrato garante a confiabilidade essencial para sessões interativas de shell remoto, túneis e transferências de arquivos — sobre as quais a subcamada de transporte do próprio SSH adiciona criptografia ponta-a-ponta, integridade e autenticação de servidor.