UDP não é sempre mais rápido: escolher o transporte do OpenVPN

Todo guia diz que o UDP vence o TCP no OpenVPN, e esse conselho é um padrão, não uma medição. O transporte muda como os pacotes são entregues e o que acontece quando o caminho os descarta, não como o túnel é cifrado. Atrás de um portal cativo ou de um proxy que só permite a porta 443, a opção mais lenta é a que sequer se conecta. O que segue separa o que o protocolo faz do que a sua rede de acesso permite.

O que o transporte realmente muda

O TCP entrega um fluxo de bytes fiável e ordenado e retransmite tudo o que se perde, como especifica a RFC 9293. O UDP entrega datagramas à rede, e o OpenVPN executa a sua própria camada de fiabilidade sobre esse socket. Encapsular TCP dentro de TCP empilha dois ciclos de recuperação, pelo que um único segmento perdido pode retrair o fluxo interno até chegar a retransmissão exterior. Essa interação é o argumento real a favor do UDP, e manifesta-se como latência e não como débito.

O efeito cresce com as perdas e o tempo de ida e volta. Num caminho local limpo, os dois transportes parecem idênticos, e é por isso que um teste de laboratório raramente reproduz a queixa. Num link móvel congestionado, a diferença aparece em sessões interativas muito antes de uma transferência grande notar algo.

Nada disto toca a confidencialidade ou a integridade. O handshake TLS e a cifra do canal de dados são os mesmos para os dois transportes, pelo que trocar não salva um conjunto de cifras fraco.

Onde o TCP ganha o seu lugar

As redes de acesso são a razão habitual para escolher TCP. Um hotel, um aeroporto ou uma rede de convidados pode permitir o 443 de saída e descartar tudo o resto, e um ouvinte TCP nessa porta é o único perfil que funciona. Isso é alcançabilidade, não desempenho, e é razão suficientemente boa por si só.

O TCP também ajuda quando o caminho é estável mas os equipamentos intermédios são hostis. Algumas redes reiniciam fluxos UDP de longa duração enquanto toleram sessões TCP que se parecem com tráfego web comum. Se essa semelhança resulta é uma propriedade da rede concreta, e nenhum guia o pode prometer para todas. Teste dentro da rede que falha antes de culpar o protocolo.

Um início de sessão rejeitado não é um problema de transporte. Desativar a verificação do certificado para forçar uma ligação é outra alteração com um resultado muito pior.

Ter um perfil TCP pronto é o compromisso prático. A maioria dos clientes guarda os dois e deixa-o trocar quando uma rede recusa o caminho UDP, o que não custa nada até precisar. O que não deve fazer é distribuir dois perfis a apontar para pontos finais diferentes, porque então a sua comparação mede os servidores.

Verifique qual ouvinte tem realmente

Antes de comparar desempenho, confirme que as duas pontas concordam quanto ao transporte e à porta. Mudar proto udp para proto tcp num ficheiro de cliente não cria um ouvinte no servidor. O servidor tem de estar configurado para esse protocolo, e o perfil tem de corresponder.

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

O grep imprime o que foi dito ao servidor para usar, enquanto as duas listas de sockets mostram a que está ligado. Um ouvinte UDP aparece apenas na primeira lista e um ouvinte TCP apenas na segunda, pelo que uma linha ausente é a forma mais rápida de encontrar um perfil que nunca foi aplicado. Compare também a porta, porque um perfil TCP na 1194 comporta-se de forma diferente de um na 443 na maioria das redes de acesso. Reinicie o serviço após a alteração e leia a linha de registo que relata a ligação.

A confirmação do lado do cliente é barata: execute a ligação com --verb 4 e leia a linha de transporte no registo. Se o cliente diz UDP enquanto o servidor escuta em TCP, o handshake nunca começa e nenhum ajuste ajudará.

Compare a carga de trabalho, não o rótulo do transporte

Uma comparação justa mantém tudo constante exceto o transporte. O mesmo dispositivo, a mesma rede de acesso, o mesmo anfitrião de destino, a mesma aplicação e, idealmente, o mesmo servidor. Se os dois perfis apontam para anfitriões diferentes, também está a medir esses anfitriões.

Registe três resultados por execução: se o túnel se estabelece, se se mantém e se a tarefa termina. Pedidos pequenos que funcionam enquanto transferências grandes encravam apontam para o tamanho do pacote e o MTU, não para o transporte. Reconexões repetidas apontam para o caminho ou para um tempo limite de um equipamento intermédio.

Guarde o perfil que funciona nas condições que realmente encontra, e mantenha o outro. A escolha pertence à rede, não à pessoa, e é por isso que qualquer resposta padrão única está errada em algum lugar.