UDP e QUIC por proxies

Um proxy pode passar em uma verificação web e ainda não conseguir transportar o tráfego de que seu programa precisa. Por exemplo, um jogo pode fazer login pelo proxy, mas falhar ao trocar atualizações da partida. Um site pode abrir normalmente enquanto o navegador usa HTTP/2 em vez de HTTP/3. Essas operações usam recursos de rede diferentes.

Para a escolha mais ampla de protocolo, veja Proxies SOCKS ou HTTP. Este artigo explica como UDP chega a um destino por um proxy, o que QUIC precisa desse caminho e como verificar se seu aplicativo usa o transporte e o IP de saída pretendidos.

O que UDP, QUIC e HTTP/3 fazem

TCP entrega um fluxo ordenado de bytes. Se alguns dados se perdem, ele providencia a retransmissão e retém os bytes posteriores do aplicativo até que a lacuna seja preenchida. UDP envia mensagens separadas, chamadas datagramas. O próprio UDP não garante entrega, ordem nem proteção contra duplicatas; o software que o usa decide como lidar com essas situações.

Isso dá aos aplicativos espaço para escolher comportamentos diferentes. Um aplicativo de voz pode descartar um pacote de áudio que chegou tarde demais para ser reproduzido. Um jogo pode preferir uma atualização recente de posição a uma antiga. Uma troca DNS pode consistir em uma pergunta e uma resposta curtas. O transporte real depende do programa: esses exemplos não significam que toda chamada, jogo ou solicitação DNS usa UDP.

QUIC é um protocolo de transporte construído sobre UDP. Ele acrescenta estabelecimento de conexão, recuperação de dados perdidos, controle de congestionamento e fluxos confiáveis. Um arquivo transferido por um fluxo QUIC confiável pode chegar completo e em ordem. O fato de seus pacotes viajarem dentro de datagramas UDP não elimina a confiabilidade fornecida por QUIC.

QUIC também permite que vários fluxos compartilhem uma conexão. Quando os dados de um fluxo se perdem, outros fluxos cujos dados chegaram podem continuar. Isso pode reduzir a espera em comparação com transportar todos os fluxos por uma conexão TCP ordenada. O resultado ainda depende da rota, da perda de pacotes, do servidor e do cliente; escolher QUIC, por si só, não garante um aplicativo mais rápido.

HTTP/3 transporta HTTP sobre QUIC. HTTP/1.1 e HTTP/2 normalmente usam TCP. Os três podem atender um site HTTPS; por isso, https:// no endereço não identifica a versão de HTTP nem confirma que UDP foi usado.

Criptografia é uma propriedade separada. UDP não criptografa dados. QUIC usa TLS 1.3 para estabelecer a proteção do tráfego do aplicativo. Um aplicativo UDP comum pode usar outro mecanismo de segurança ou transmitir seu conteúdo sem criptografia; encaminhá-lo por um proxy não acrescenta essa proteção automaticamente.

Como SOCKS5 transporta UDP

SOCKS5 define uma retransmissão UDP: um serviço que aceita datagramas do cliente, envia seu conteúdo ao destino e retorna as respostas. O cliente primeiro estabelece esse encaminhamento por TCP. A conexão de controle e o caminho dos datagramas então existem lado a lado.

1. O cliente se conecta ao servidor SOCKS5 por TCP e conclui o procedimento de autenticação acordado.
2. Ele solicita UDP ASSOCIATE. Se o proxy aceita, a resposta fornece o endereço e a porta UDP da retransmissão.
3. O cliente envia datagramas à retransmissão com um cabeçalho SOCKS que identifica o destino. A retransmissão remove esse cabeçalho antes de encaminhar o conteúdo. Para as respostas, acrescenta um cabeçalho SOCKS antes de enviar o datagrama de volta ao cliente.
4. O cliente mantém a conexão TCP de controle aberta enquanto usa a retransmissão. Fechá-la encerra o encaminhamento UDP estabelecido por essa conexão. Esse vínculo entre a conexão de controle e o encaminhamento UDP é chamado de associação UDP.

A retransmissão pode usar um endereço ou porta diferente do ponto de conexão TCP inserido nas configurações de proxy. Enviar UDP bruto para esse ponto de conexão conhecido não realiza a troca SOCKS5. Um cliente que implementa apenas CONNECT pode usar SOCKS5 para TCP, mas não tem o procedimento necessário aqui. SOCKS4 não define esse recurso de retransmissão UDP.

Isso explica um sucesso parcial comum: um firewall permite a conexão TCP e a autenticação, mas bloqueia datagramas para a retransmissão negociada. A senha funciona; o aplicativo ainda não recebe respostas UDP. As duas partes da rota precisam estar disponíveis.

Um proxy HTTP pode encaminhar UDP?

Uma solicitação HTTP CONNECT comum pede ao proxy que abra uma conexão TCP com o destino e transporte um fluxo de bytes. Ela não estabelece encaminhamento UDP. Usar TLS na conexão com um proxy HTTPS protege essa conexão sem mudar o tipo de túnel solicitado.

HTTP tem um mecanismo adicional de tunelamento UDP, comumente chamado de CONNECT-UDP e desenvolvido como parte de MASQUE. Com cliente e servidor compatíveis, o cliente solicita um túnel para um destino UDP. O proxy encaminha os datagramas a esse destino e transporta as respostas de volta. Isso exige suporte explícito nos dois lados.

Na conexão entre cliente e proxy, HTTP Datagrams podem ser transportados em quadros QUIC DATAGRAM quando há suporte a HTTP/3 e às extensões necessárias. Também podem ser transportados em cápsulas: mensagens delimitadas dentro de um fluxo HTTP confiável, incluindo HTTP/2 sobre TCP. Nesse caso, o proxy ainda envia UDP ao destino, embora a primeira parte da rota use TCP.

Essa escolha afeta os tempos. Se a conexão TCP perde dados, os bytes posteriores podem esperar pela recuperação, atrasando os datagramas transportados dentro deles. O túnel pode funcionar e ainda ser inadequado a uma carga de trabalho específica em tempo real. Apenas inserir um endereço de proxy http:// em um programa não habilita nenhum desses mecanismos UDP adicionais.

Qual conexão usa QUIC?

A expressão “proxy QUIC” precisa de contexto. Ela pode descrever o transporte usado para alcançar o proxy ou a conexão do aplicativo com o destino. Essas são partes separadas da troca.

Na retransmissão UDP comum, o proxy não precisa encerrar a conexão QUIC do aplicativo. Ele encaminha pacotes enquanto o aplicativo e o destino continuam sendo as extremidades dessa troca criptografada. O proxy ainda sabe para onde encaminha o tráfego e pode observar seu volume e seus horários.

Por que o suporte no aplicativo importa

Um programa precisa implementar o método de encaminhamento que o serviço oferece. Uma caixa de seleção SOCKS5 não informa se ele oferece suporte a UDP ASSOCIATE. Da mesma forma, um programa pode oferecer suporte a HTTP/3 em conexões diretas e disponibilizar apenas conexões de proxy TCP.

O Chrome oferece um exemplo concreto: seu suporte integrado a SOCKS5 encaminha pelo proxy solicitações de URL baseadas em TCP e não retransmite UDP por SOCKS5. Carregar uma página com essa configuração não pode testar a retransmissão UDP do serviço. Essa limitação se refere a esse modo específico do cliente; outros clientes ou softwares externos de roteamento podem ter recursos diferentes.

Verifique também o alcance da configuração. Login, downloads de arquivos, voz e partidas podem usar componentes de rede diferentes dentro de um aplicativo. Um proxy configurado para solicitações web pode abranger apenas alguns deles. Uma configuração de proxy do sistema também depende de cada programa segui-la.

Um programa que redireciona o tráfego de outro aplicativo pode enviar seu UDP por um proxy, desde que ofereça suporte a UDP e ao método de encaminhamento do serviço. Redirecionar apenas TCP é insuficiente. Se o programa usa uma interface de rede virtual, suas regras de roteamento decidem qual tráfego entra nela. Teste a combinação completa: o aplicativo, o programa de roteamento e o ponto de conexão do proxy.

Alternativa de transporte, falha e conexão direta

Quando o caminho necessário está indisponível, o resultado depende dos recursos e da política do aplicativo. Três resultados podem parecer semelhantes se a única pergunta for se algo abriu:

Mudar para uma versão de HTTP baseada em TCP é chamado de fallback. Isso pode preservar a navegação normal quando QUIC está indisponível. O cliente abre outra conexão; QUIC em si não se transforma em TCP. Portanto, desativar QUIC pode ajudar um aplicativo web a usar um caminho TCP disponível, mas não pode fornecer UDP a um recurso que o exige.

Ir diretamente ao destino é uma decisão de roteamento. UDP sem suporte não é enviado diretamente em todos os casos: o software pode parar, tentar outro transporte ou seguir uma regra de exceção configurada. Se todo o tráfego da tarefa deve passar pelo proxy, use um modo que pare quando essa rota falhar e verifique seu comportamento com o proxy indisponível.

Por que UDP pode parar de funcionar após o estabelecimento

Regras de porta e o caminho de retorno

A porta TCP 443 e a porta UDP 443 pertencem a transportes diferentes. Permitir uma não abre a outra. Para SOCKS5, o cliente deve alcançar o ponto de conexão de retransmissão UDP retornado; a retransmissão também deve ter permissão para alcançar a porta UDP do destino. HTTP/3 pode usar portas diferentes de 443; por isso, verifique o ponto de conexão que o aplicativo realmente usa.

As respostas devem retornar pela retransmissão, pelo firewall e por qualquer NAT, que traduz endereços e frequentemente portas entre redes. Um datagrama enviado, sozinho, não mostra que esse caminho de retorno funciona. Uma mudança de rede pode alterar o IP público ou o mapeamento de portas do cliente. Retransmissores SOCKS5 devem rejeitar datagramas de um IP de origem diferente daquele registrado para a associação UDP; por isso, um endereço alterado pode exigir uma nova associação.

Pausas e estado expirado

Retransmissores e dispositivos NAT mantêm registros temporários das trocas UDP. Esses registros podem expirar durante uma pausa. Uma chamada ou sessão pode funcionar no início e depois perder seu caminho UDP até que o cliente o estabeleça novamente. Manter o mesmo IP de saída não impede isso: o estado necessário para encaminhar UDP e a atribuição de IP do serviço são coisas separadas.

Tamanho do datagrama e MTU

MTU é o maior pacote IP que um enlace de rede pode transportar sem fragmentação. O tamanho utilizável ao longo de uma rota é limitado pelo menor desses limites, conhecido como MTU do caminho. IP, UDP e cabeçalhos adicionais de túnel ocupam espaço no pacote. Uma mensagem pequena de teste pode passar enquanto datagramas maiores são descartados; por isso, o aplicativo deve levar em conta o caminho completo e seus cabeçalhos adicionais.

Um caminho QUIC deve transportar pelo menos 1 200 bytes de conteúdo UDP, sem contar os cabeçalhos IP e UDP. O cliente preenche datagramas UDP que transportam seus pacotes QUIC Initial até pelo menos esse tamanho de conteúdo. Os cabeçalhos de proxy na parte entre cliente e proxy precisam de espaço adicional. Isso não é uma recomendação para definir a MTU de uma interface como 1 200: explica por que uma solicitação e resposta DNS pequenas podem funcionar enquanto o handshake QUIC maior não consegue passar.

Atraso, perda e carga

Para uma chamada ou um jogo, o tempo de entrega pode importar tanto quanto a própria entrega. Atraso variável, perda de pacotes e limites de taxa de pacotes podem prejudicar uma retransmissão UDP que funciona nos demais aspectos. A largura de banda, sozinha, não descreve essas condições. Um proxy acrescenta outra parte à rota; ele pode melhorar ou piorar o desempenho, dependendo das redes e da carga de trabalho.

Como verificar UDP e HTTP/3 por um proxy

Teste o aplicativo que pretende usar ou um cliente que implemente o mesmo método de encaminhamento. Um teste útil verifica a resposta, o transporte e o endereço de saída para a mesma troca.

1. Escolha um destino que responda ao tráfego necessário. Use o servidor real do aplicativo ou um respondedor UDP controlado. Para HTTP/3, escolha um destino que sabidamente ofereça suporte. O silêncio de uma porta UDP arbitrária não informa qual parte falhou.
2. Confirme que a retransmissão ou o túnel foi aceito. Com SOCKS5, examine o resultado de UDP ASSOCIATE e o endereço e a porta de retransmissão retornados. Com um túnel UDP HTTP, confirme a aceitação desse túnel. A autenticação, por si só, não cobre essa etapa.
3. Conclua uma solicitação e uma resposta. Um respondedor controlado pode retornar um identificador de solicitação e registrar o IP de origem que viu. Isso verifica a saída usada nessa troca UDP. Uma verificação web de IP separada abrange apenas sua própria solicitação.
4. Para HTTP/3, confirme o protocolo na troca com o destino. Procure HTTP/3 ou h3 no log de conexão do cliente ou do servidor, junto com evidências da rota pelo proxy. Se o cliente de teste tiver um modo somente HTTP/3, ele poderá revelar uma falha que o fallback automático ocultaria.
5. Repita nas condições relevantes: tamanhos realistas de datagrama, tráfego contínuo e uma pausa seguida de atividade. Se o tráfego direto for proibido para a tarefa, teste também o que acontece quando o proxy fica indisponível. Guarde a versão do cliente e as configurações de conexão junto com o resultado.

Uma captura de pacotes pode ajudar a identificar a rota. O encaminhamento UDP SOCKS5 padrão envia datagramas à retransmissão negociada. Um túnel UDP HTTP pode usar uma conexão TCP externa; por isso, a ausência de UDP nessa primeira parte da rota não é evidência suficiente de falha.

DNS remoto e ping testam coisas diferentes. Um proxy pode resolver um nome de host para uma conexão TCP sem retransmitir o tráfego UDP do aplicativo. O ping comum usa ICMP. Nenhum dos testes substitui uma solicitação e resposta UDP observadas na rota de proxy pretendida.

Quando vale a pena escolher suporte a UDP

Comece pelo tráfego que sua tarefa exige. Trabalho com sites e APIs que funciona sobre HTTP/1.1 ou HTTP/2 pode ser totalmente atendido por um proxy somente TCP. Testes de HTTP/3, mídia UDP e outros recursos que dependem de UDP exigem uma retransmissão ou um túnel adequado, além de um cliente que consiga usá-lo.

Pergunte ao serviço qual método de encaminhamento UDP e qual configuração de cliente são compatíveis. Depois, verifique destinos e portas permitidos, limites de tamanho de datagrama, comportamento em inatividade e quaisquer limites de tráfego ou taxa de pacotes relevantes para a carga de trabalho. Se TCP e UDP precisarem usar o mesmo IP de saída ou localização, verifique esse requisito no aplicativo real. Uma conta em comum ou uma verificação web bem-sucedida não comprova um comportamento de saída idêntico.