Transporte: TCP, UDP e QUIC

O Artigo 1 mostrou que a física fixa o piso. O Artigo 3 acompanhou o pacote até o próximo salto. Agora precisamos cobrar o que acontece nas pontas, quando uma aplicação exige ordem, confiabilidade e controle da taxa de envio.

O IP oferece entrega por melhor esforço, best effort. Ele aceita um datagrama, tenta entregá-lo e não confirma se falhou. Sobre essa simplicidade deliberada, justificada pelo argumento fim a fim discutido na Seção 1 do artigo anterior, a camada de transporte pode oferecer contratos diferentes para uma pergunta mais interessante: o que faremos quando um pacote se perder? O TCP oferece um fluxo confiável e ordenado, o UDP preserva mensagens sem acrescentar recuperação, e o QUIC combina confiabilidade, múltiplos fluxos e segurança sobre UDP. A escolha determina onde ficarão a ordem, a recuperação, o controle de congestionamento e boa parte do estado do sistema distribuído.

Por que o QUIC aparece aqui se ele não é um protocolo de transporte?

A rigor, o QUIC não ocupa a mesma posição que TCP e UDP na pilha. Ele é construído sobre UDP, no espaço de usuário, e não possui um número de protocolo próprio atribuído pela IANA para ser colocado ao lado dos outros dois na camada de transporte. Do ponto de vista do cabeçalho IP, o que existe é um datagrama UDP, e o QUIC vive dentro dele.

Ele aparece aqui por um motivo pragmático, um tanto egoísta, e um motivo arquitetural. O motivo pragmático é que, para quem escreve software, o QUIC compete diretamente com TCP na escolha do contrato de entrega. A decisão entre os dois é feita na mesma camada de abstração, mesmo que a implementação seja diferente. Essa é a minha praia.

O motivo arquitetural é que o QUIC relocaliza funções que o TCP mantém no núcleo do sistema operacional: confiabilidade, ordenação, controle de fluxo, controle de congestionamento e TLS. Compreender o que ele muda de lugar exige ter compreendido primeiro o que o TCP faz e onde o faz. Este artigo é sobre contratos de entrega, e o QUIC oferece um contrato novo, ainda que por um caminho não convencional.

O TCP resolve um problema que a aplicação não deveria precisar resolver outra vez: entregar bytes em ordem, sem lacunas nem duplicatas, sobre uma rede que não promete nenhuma dessas propriedades. O preço é estado. Esse estado aparece para a engenheira de software como conexões que demoram a abrir, fluxos que param atrás de um único byte perdido, encerramentos que deixam memória temporária e transferências limitadas a uma fração do enlace contratado. Vamos seguir uma conexão completa, da porta ao TIME-WAIT, antes de mostrar quais parcelas o QUIC remove e quais apenas desloca para o espaço de usuário.

A régua continua a mesma. Usaremos $\text{RTT}=76,65$ ms, o piso físico entre São Paulo e Ashburn calculado na Tabela 2 do artigo anterior, sempre que precisarmos de um número concreto para uma rota longa.

1. O que o transporte acrescenta ao IP

A camada de Internet entrega datagramas a uma máquina. Isso não basta, porque dezenas de processos podem compartilhar o mesmo endereço IP. O transporte acrescenta, no mínimo, a multiplexação: números de porta de origem e de destino, com dezesseis bits cada, permitem ao sistema operacional decidir a qual soquete entregar os dados. O caminho inverso chama-se demultiplexação: um pacote chega, o sistema consulta seus identificadores e o encaminha ao ponto de comunicação correto.

Um soquete é a abstração que a aplicação usa para acessar esse ponto de comunicação. Em UDP, a porta de destino costuma bastar para selecionar o soquete vinculado localmente. Em TCP, uma conexão estabelecida é distinguida pela quádrupla formada por endereço e porta de origemporta de origem, endereço e porta de destino, além do protocolo que participa da consulta. Assim, dois clientes podem falar ao mesmo IP:porta do servidor sem compartilhar o estado da conexão.

Porta, soquete e conexão são três coisas diferentes

Uma porta é um número de 16 bits no cabeçalho do transporte. Ela existe no protocolo, não no sistema operacional.

Um soquete é a abstração que a aplicação usa para acessar um ponto de comunicação. Ele vive no sistema operacional e é identificado, no mínimo, por um endereço IP e uma porta.

Uma conexão TCP é identificada pela quádrupla formada por endereço e porta de origem, endereço e porta de destino. Dois clientes podem falar ao mesmo IP:porta do servidor sem compartilhar estado, porque as quádruplas são diferentes.

Confundir os três produz diagnósticos errados. Dizer que a porta está aberta não garante que há um soquete escutando, e dizer que o soquete existe não garante que a conexão está estabelecida.

A Figura 1 separa as duas decisões que costumam ser fundidas na expressão endereço do servidor. O endereço IP leva os três segmentos até a mesma máquina. As portas permitem que o sistema entregue cada um ao processo correto.