TCP, UDP e portas

Um número de porta tem 16 bits, então vai de 0 a 65535. Os servidores web que usam HTTPS escutam na porta 443.

Primeiro, dois enigmas. Em uma videochamada, um pedacinho da voz do seu amigo se perde no caminho. O seu aplicativo deve pedi-lo de novo? Agora você está baixando um arquivo de lição de casa, e um pedaço do arquivo se perde. Mesma pergunta. Decida as duas antes de continuar lendo.

Dois pedaços perdidos, duas respostas diferentes

Se você disse não para a chamada e sim para o arquivo, já escolheu entre os dois transportes. Um pedaço de som que chega meio segundo atrasado é inútil. A conversa já seguiu em frente, então é melhor pular esse pedaço e tocar o próximo. Um arquivo com um pedaço faltando está quebrado, então vale a pena esperar por esse pedaço. A internet tem um transporte para cada caso: o TCP espera e reenvia, o UDP envia e segue em frente. Antes que qualquer um deles possa ajudar, porém, o pacote precisa chegar ao programa certo.

Qual programa recebe o pacote: portas

Um endereço IP leva o pacote ao computador certo. Mas um computador roda muitos programas ao mesmo tempo: um navegador com várias abas, um aplicativo de chat, um aplicativo de música. Os cabeçalhos TCP e UDP levam uma porta de origem e uma porta de destino, cada uma um número de 16 bits de 0 a 65535, e a porta diz para qual programa é o pacote. Um programa servidor escuta em uma porta combinada: 80 para HTTP simples, 443 para HTTPS, 53 para DNS, 25 para e-mail entre servidores. A RFC 6335 divide a faixa em portas de sistema de 0 a 1023, portas de usuário de 1024 a 49151 e portas dinâmicas de 49152 a 65535. O seu computador escolhe uma porta de origem temporária para cada conversa, muitas vezes da faixa dinâmica. Um endereço e uma porta juntos, como 198.51.100.20:443, identificam exatamente uma ponta de uma conversa.

O TCP confere cada byte

O TCP (RFC 9293) transforma um fluxo de pacotes não confiável em algo como uma linha telefônica para bytes. Primeiro os dois lados estabelecem uma conexão com um handshake de três vias: o cliente envia SYN, o servidor responde SYN-ACK e o cliente responde ACK. A partir daí, cada byte tem um número de sequência. O receptor envia confirmações (ACKs) dizendo até onde chegou e põe de volta no lugar os pedaços fora de ordem. Se o remetente não recebe um ACK dentro de um tempo limite, envia os dados de novo. A RFC 6298 fixa o primeiro tempo limite em 1 segundo e depois o ajusta ao tempo de ida e volta medido. O TCP também desacelera quando percebe perdas, para que uma ligação ocupada não fique inundada.

O UDP envia e segue em frente

O UDP (RFC 768, 1980) faz muito menos. O cabeçalho dele tem só 8 bytes: duas portas, um comprimento e uma soma de verificação. Não há handshake, nem número de sequência, nem reenvio. Para a videochamada do primeiro enigma, é exatamente o certo. Perguntas curtas de DNS também usam UDP, porque uma pergunta e uma resposta são mais rápidas sem handshake. O QUIC, o transporte por baixo do HTTP/3, roda sobre UDP e constrói o próprio reenvio por cima.

Quatro números mantêm duas abas separadas

Quatro números juntos identificam uma conexão TCP: endereço de origem, porta de origem, endereço de destino e porta de destino. É assim que um servidor na porta 443 consegue conversar com milhares de navegadores ao mesmo tempo sem misturá-los, e é assim que o seu notebook mantém separadas duas abas do mesmo site, porque a conexão de cada aba usa uma porta de origem diferente. Toque em um pacote no simulador e leia o cabeçalho. Antes do roteador de casa, a origem é 192.168.0.12 porta 51000. Depois dele, o NAT mudou os dois números, e o roteador lembra a troca para que as respostas voltem à aba certa.