❧ Camada de Transporte Completa: UDP e TCP ❧

Introdução10.1

Hoje você vai ver por que a comunicação na Internet não termina quando um pacote IP chega ao host correto. A camada de rede entrega pacotes entre máquinas, mas uma máquina executa muitos programas ao mesmo tempo. O problema da camada de transporte é levar os dados ao processo correto e, quando necessário, transformar uma rede de melhor esforço em uma comunicação confiável.

Na aula anterior, o IP apareceu como um protocolo sem conexão e de melhor esforço. Isso é suficiente para encaminhar datagramas entre redes, mas não garante entrega, ordem, ausência de duplicação nem controle de velocidade. A camada de transporte existe justamente acima desse ponto frágil.

Esta aula usa como base o Forouzan, capítulo 23, páginas 703 a 735, excluindo a parte de SCTP, e o Tanenbaum, capítulo 6, principalmente as seções 6.1 a 6.5, páginas 310 a 365.

Mapa de leitura dos livros10.2

Antes de entrar nos detalhes, vale deixar claro de onde a aula está saindo nos dois livros.

No Forouzan, o capítulo 23 aparece dentro da parte de Camada de Transporte e se chama Comunicação entre Processos: UDP, TCP e SCTP. Para esta aula, usamos as seções 23.1 a 23.3.

No Tanenbaum, o capítulo 6 se chama A camada de transporte. Ele organiza a discussão de forma mais conceitual, começando pelo serviço de transporte e depois entrando nos elementos que qualquer protocolo de transporte precisa resolver.

O problema que a camada de transporte resolve10.3

Imagine que seu computador esteja acessando uma página Web, sincronizando arquivos, recebendo mensagens e fazendo uma consulta DNS quase ao mesmo tempo. Do ponto de vista da camada de rede, todos esses dados chegam ao mesmo endereço IP da sua máquina. Mas isso não basta.

O IP identifica o host. Ele não identifica diretamente qual processo deve receber cada pedaço de dado. Sem a camada de transporte, o sistema operacional receberia pacotes IP e ainda teria de adivinhar se aquele conteúdo pertence ao navegador, ao cliente de e-mail, ao serviço de sincronização ou a outro programa.

Falta o endereço da camada de transporte. Na Internet, esse endereço é o número de porta. O par formado por endereço IP e porta identifica um ponto de comunicação em um host.

Forouzan apresenta essa diferença como três níveis de comunicação.

O Tanenbaum reforça a mesma ideia por outro caminho. A camada de transporte roda nas máquinas finais e pode compensar limitações da camada de rede. Se a rede perde, atrasa, duplica ou reordena pacotes, a entidade de transporte pode implementar mecanismos para tornar o serviço mais adequado às aplicações.

A figura do Tanenbaum ajuda a visualizar a mudança de ambiente. Na camada de enlace, dois dispositivos vizinhos conversam por um canal físico direto. Na camada de transporte, as pontas conversam através de uma rede inteira, com roteadores, filas, caminhos alternativos, perdas e atrasos.

Por isso, problemas que eram simples no enlace ficam mais difíceis no transporte. Não basta saber que há um vizinho do outro lado do fio. É preciso endereçar processos, abrir conexões quando necessário, detectar duplicatas antigas, lidar com perda e decidir quanto enviar sem destruir o receptor ou congestionar a rede.

Portas, multiplexação e demultiplexação10.4

Um número de porta tem 16 bits. Portanto, os valores possíveis vão de 0 a 65.535. Em uma comunicação cliente-servidor, o servidor normalmente usa uma porta conhecida, enquanto o cliente usa uma porta temporária, também chamada porta efêmera.

Essa separação resolve um problema prático. O cliente precisa saber onde encontrar o serviço. Por isso, serviços padronizados costumam usar portas bem conhecidas. Já o cliente só precisa de uma identificação temporária para receber a resposta.

Multiplexar na origem, demultiplexar no destino10.4.1

Na origem, vários processos podem querer enviar dados pela rede. A camada de transporte recebe dados desses processos, coloca cabeçalhos com portas e entrega os segmentos ou datagramas ao IP. Esse lado é a multiplexação.

No destino, acontece o inverso. A camada de transporte recebe dados vindos do IP, observa as portas no cabeçalho e entrega o conteúdo ao processo adequado. Esse lado é a demultiplexação.

Origem: 10.0.0.8:53144
Destino: 200.10.1.5:443

Origem: 200.10.1.5:443
Destino: 10.0.0.8:53144

Aba 1: 10.0.0.8:53144 -> 200.10.1.5:443
Aba 2: 10.0.0.8:53145 -> 200.10.1.5:443

UDP como transporte mínimo10.5

O UDP, ou User Datagram Protocol, é o protocolo de transporte mais simples da Internet. Ele oferece comunicação processo a processo usando portas, mas quase não acrescenta controle ao serviço do IP.

O UDP é sem conexão. Isso significa que ele não estabelece uma conexão antes de enviar dados. Cada datagrama UDP é independente.

O UDP também é não confiável no sentido técnico. Ele não confirma recebimento, não retransmite perdas, não reordena datagramas e não controla a velocidade do emissor. Isso não significa que ele seja inútil. Significa que ele deixa essas responsabilidades para a aplicação quando elas forem necessárias.

Porque nem toda aplicação precisa do mesmo tipo de garantia dentro da camada de transporte. Uma consulta curta pode ser repetida pela própria aplicação. Uma aplicação em tempo real pode preferir perder uma pequena parte do áudio a esperar uma retransmissão atrasada. Um protocolo simples pode ganhar desempenho evitando o custo de uma conexão TCP.

O cabeçalho UDP10.5.1

O cabeçalho UDP tem apenas 8 bytes.

O campo de checksum usa também um pseudocabeçalho com informações do IP, como endereços de origem e destino e o número do protocolo. A razão é importante. O UDP precisa detectar não apenas erros no conteúdo UDP, mas também situações em que o datagrama poderia ser entregue ao host ou protocolo errado.

Os campos são pequenos e o formato é enxuto. A porta de origem pode ser zero se o transmissor não esperar resposta. A porta de destino é essencial para a demultiplexação. O comprimento mínimo é 8 bytes (só cabeçalho, sem dados).

O checksum do UDP inclui também um pseudocabeçalho com campos do IP.

A inclusão do pseudocabeçalho é uma defesa contra erros de roteamento. Se o datagrama IP for entregue ao host errado, o checksum detectará a inconsistência entre os endereços IP do pseudocabeçalho e o que o host realmente recebeu.

O que o UDP não faz10.5.2

O UDP não cria relação entre datagramas sucessivos. Se uma aplicação envia três mensagens, o UDP não trata isso como um fluxo único. São três datagramas independentes.

Isso tem consequências diretas.

TCP como fluxo confiável de bytes10.6

O TCP, ou Transmission Control Protocol, resolve um problema diferente. Ele foi projetado para oferecer um fluxo de bytes fim a fim confiável sobre uma rede IP que pode perder, atrasar, duplicar ou reordenar datagramas.

O TCP é orientado a conexão. Antes da transferência de dados, as duas pontas estabelecem uma conexão virtual. Depois, os dados fluem. Ao final, a conexão é encerrada.

Essa conexão não é um fio físico reservado. Ela é um estado mantido nas pontas. O IP continua encaminhando datagramas individualmente. O TCP é quem numera bytes, confirma recebimentos, retransmite perdas e entrega os dados em ordem para a aplicação.

O cabeçalho TCP é maior que o cabeçalho UDP porque carrega mais responsabilidade. Além das portas, ele precisa de números de sequência, números de confirmação, flags de controle, janela, checksum e opções. Cada campo existe porque o TCP tenta criar uma abstração mais forte que a oferecida pelo IP.

Fluxo de bytes, não mensagens10.6.1

Uma das ideias mais importantes do TCP é que ele entrega um fluxo de bytes. Ele não preserva necessariamente as fronteiras das escritas feitas pela aplicação.

Se uma aplicação escreve quatro blocos de 512 bytes, a outra ponta pode ler quatro blocos de 512 bytes, dois blocos de 1024 bytes, um bloco de 2048 bytes ou outra divisão. Para o TCP, os dados são uma sequência contínua de bytes.

GET
 /index.html
 HTTP/1.1

GET /index.html HTTP/1.1

Sockets e a visão da aplicação10.6.2

O Tanenbaum apresenta sockets de Berkeley para mostrar como a aplicação enxerga a camada de transporte. A aplicação não manipula diretamente cada detalhe de SYN, ACK, janela e retransmissão. Ela usa primitivas do sistema operacional.

Segmentos e numeração de bytes10.6.3

O TCP recebe bytes da aplicação, armazena em buffers e agrupa partes desse fluxo em segmentos TCP. Cada byte tem um número de sequência. O número de sequência de um segmento é o número do primeiro byte transportado naquele segmento.

As confirmações são cumulativas. O número de confirmação indica o próximo byte esperado, não o último byte recebido.

Conexão TCP e handshake de três vias10.7

Antes de transferir dados, o TCP estabelece uma conexão com o handshake de três vias. Esse processo sincroniza os números de sequência iniciais e confirma que as duas pontas estão prontas.

O primeiro segmento tem SYN ativo. Ele não carrega dados de aplicação, mas consome um número de sequência. O segundo segmento tem SYN e ACK ativos. Ele confirma o primeiro SYN e sincroniza o número de sequência da outra direção. O terceiro segmento confirma o SYN do servidor.

Repare no consumo de números de sequência. O primeiro SYN do cliente usa seq = 8000. O servidor responde com seq = 15000 e ack = 8001, confirmando o byte "fantasma" do SYN. O cliente então envia ack = 15001. A partir desse ponto, o primeiro byte de dados do cliente terá sequência 8001, e o primeiro byte do servidor terá sequência 15001.

Por que três vias são necessárias10.7.1

O Tanenbaum dedica atenção ao problema de duplicatas atrasadas. Em uma rede real, um segmento antigo pode ficar preso, aparecer depois e ser confundido com uma nova tentativa de conexão. O handshake de três vias, combinado com números de sequência iniciais adequados, reduz esse risco.

Se bastasse enviar “quero conectar” e receber “aceito”, uma duplicata antiga poderia criar confusão. Com três etapas, as duas pontas confirmam explicitamente que estão falando da mesma tentativa atual de conexão.

Controle de fluxo, erro e congestionamento10.8

O TCP oferece confiabilidade porque combina vários mecanismos. Três deles precisam ficar bem separados.

Controle de fluxo10.8.1

O controle de fluxo protege o receptor. O receptor anuncia uma janela de recepção, normalmente chamada rwnd, indicando quantos bytes ainda consegue receber. O transmissor deve respeitar esse limite.

Se a janela anunciada for zero, o transmissor deve parar de enviar novos dados. Mais tarde, quando a aplicação receptora consumir dados do buffer, o receptor pode anunciar uma janela maior.

Controle de erro10.8.2

Revela que a confiabilidade é estrutural no TCP, não um extra. O TCP não pode abrir mão da detecção de corrupção porque sua tarefa é justamente entregar um fluxo confiável. Se um segmento silenciosamente corrompido fosse aceito, toda a abstração de "fluxo de bytes confiável" ruiria. No UDP sobre IPv4, o checksum pode ser enviado como zero, deixando essa proteção fora do UDP; no UDP sobre IPv6, o checksum é obrigatório. O ponto conceitual continua sendo que o TCP não tem essa liberdade.

O controle de erro protege a confiabilidade do fluxo. O TCP usa checksum para detectar corrupção, confirmações para indicar progresso, temporizadores para detectar ausência de resposta e retransmissões para reenviar dados provavelmente perdidos.

Um segmento corrompido é descartado e tratado como perdido. Um segmento fora de ordem pode ser armazenado temporariamente, mas não deve ser entregue à aplicação antes dos bytes faltantes.

ACK = 701

Temporizadores e retransmissão10.8.3

O TCP não pode esperar para sempre por uma confirmação. Quando envia dados, ele acompanha o tempo de espera por ACKs. Se a confirmação não chega dentro do prazo estimado, o transmissor presume perda e retransmite.

Esse prazo não pode ser fixo demais. Uma rede local pode responder em poucos milissegundos. Uma conexão atravessando continentes pode demorar muito mais. Por isso, implementações TCP estimam o tempo de ida e volta, chamado RTT, e ajustam o temporizador de retransmissão.

Entrega ordenada e buffer de recepção10.8.4

Quando segmentos chegam fora de ordem, o TCP receptor pode guardá-los temporariamente. Mas ele só entrega à aplicação a parte contínua do fluxo, sem buracos.

Essa regra preserva a promessa central do TCP: a aplicação recebe bytes em ordem, sem duplicatas e sem lacunas.

Controle de congestionamento10.8.5

O controle de congestionamento protege a rede. Mesmo que o receptor tenha buffer disponível, a rede pode estar sobrecarregada. O TCP considera esse cenário usando uma janela de congestionamento, normalmente chamada cwnd.

Na prática, a quantidade de dados que o transmissor pode manter em trânsito depende de dois limites.

$$ janela\ efetiva = \min(rwnd, cwnd) $$

O primeiro limite vem do receptor. O segundo vem da condição percebida da rede. Se houver sinais de congestionamento, como perdas, o TCP reduz sua taxa de envio.

Encerramento de conexão TCP10.9

Porque o outro lado precisa saber que a transmissão acabou e não está apenas em silêncio temporário. Sem um sinal explícito, o receptor poderia esperar indefinidamente por dados que nunca chegarão. É por isso que o TCP dedica flags, números de sequência e temporizadores ao encerramento da conexão.

Como uma conexão TCP é full-duplex, cada direção pode ser encerrada separadamente. Um lado pode parar de enviar e ainda continuar recebendo. Esse comportamento é chamado semi-encerramento.

O encerramento usa a flag FIN. Quando uma ponta envia FIN, ela informa que não tem mais dados para transmitir naquela direção. A outra ponta confirma com ACK. Depois, quando a outra direção também terminar, ela envia seu próprio FIN, que também deve ser confirmado.

O encerramento normal consome números de sequência de forma parecida com a abertura. O FIN do cliente e o FIN + ACK do servidor consomem um número de sequência cada um, mesmo sem transportar dados.

No semi-encerramento, o cenário é assimétrico.

O cliente envia FIN e o servidor confirma com ACK. A partir desse momento, o cliente não envia mais dados, mas continua recebendo e confirmando os dados que o servidor ainda transmite. Quando o servidor termina, ele envia seu próprio FIN, que o cliente confirma. Esse padrão é útil quando o servidor precisa processar antes de responder, como em uma ordenação remota.

UDP e TCP lado a lado10.10

UDP e TCP não são versões “boa” e “ruim” da mesma coisa. Eles resolvem problemas diferentes.

Critérios de escolha10.10.1

Uma forma prática de escolher entre UDP e TCP é perguntar o que acontece se houver perda, atraso ou reordenação.

Essa tabela não substitui projeto de protocolo, mas evita a resposta automática de que “TCP é sempre melhor”. Em redes, melhor depende do serviço exigido pela aplicação.

Relação com a próxima aula10.10.2

Na próxima aula, a camada de aplicação vai mostrar essas escolhas acontecendo em protocolos reais.

Perceba o ponto: UDP não significa ausência de protocolo sofisticado. HTTP/3 usa UDP, mas não porque abriu mão de confiabilidade. Ele usa UDP para implementar outro transporte, o QUIC, no espaço de aplicação.

Mini-laboratório no Linux10.11

Os comandos abaixo servem para transformar a discussão conceitual em observação prática durante a aula. Eles não dependem de Internet externa quando usam 127.0.0.1, pois tudo acontece na própria máquina pelo loopback.

. Ver portas e sockets abertos10.11.1

ss -tulpen

O que observar:

Esse comando conecta a ideia de porta à implementação real do sistema operacional. A porta não é apenas um número no slide; ela aparece em uma tabela mantida pelo kernel para demultiplexar dados para processos.

. Enviar uma mensagem UDP local10.11.2

Em um terminal, abra um receptor UDP.

nc -u -l 9999

Em outro terminal, envie uma mensagem.

printf 'consulta\n' | nc -u -w1 127.0.0.1 9999

O ponto didático é observar que não há abertura de conexão antes da mensagem. O datagrama é enviado diretamente para 127.0.0.1:9999. Se o receptor não estiver escutando, o UDP não cria uma sessão persistente esperando que alguém apareça.

. Abrir uma conexão TCP local10.11.3

Em um terminal, abra um servidor TCP simples.

nc -l 9998

Em outro terminal, conecte no servidor.

nc -v 127.0.0.1 9998

Enquanto a conexão estiver aberta, observe o estado com ss.

ss -tn '( sport = :9998 or dport = :9998 )'

O estado ESTAB mostra a diferença prática em relação ao UDP. O TCP mantém estado de conexão nas pontas.

. Observar o handshake e o encerramento10.11.4

Se houver tcpdump instalado e permissão de sudo, rode antes de abrir a conexão TCP.

sudo tcpdump -i lo -nn 'tcp port 9998'

Depois abra a conexão com nc como no exemplo anterior. Na saída do tcpdump, procure as flags:

Esse exemplo é útil para reforçar que o handshake não é uma metáfora. Ele aparece como segmentos TCP reais passando pela interface de loopback.

Fechando a ideia10.12

A camada de transporte existe porque a comunicação real acontece entre processos, não apenas entre máquinas. O UDP resolve o problema com o mínimo de controle: portas, checksum e nada mais. O TCP resolve o mesmo problema com uma abstração mais rica: conexão virtual, numeração de bytes, confirmações, retransmissões, controle de fluxo e reação a congestionamento.

A escolha entre os dois não é questão de "qual é melhor". É questão de qual combinação de simplicidade, confiabilidade, ordem e controle a aplicação realmente precisa.

Questões10.13

Próximos passos10.14

Na próxima aula, o passo natural é subir para a camada de aplicação e observar como protocolos como DNS, HTTP e e-mail usam UDP e TCP para oferecer serviços concretos aos usuários.

Você verá que muitas decisões da aplicação dependem diretamente do transporte escolhido.