UDP non sempre é máis rápido: escoller o transporte de OpenVPN

Todas as guías din que UDP supera a TCP para OpenVPN, e ese consello é un valor predeterminado, non unha medición. O transporte cambia como se entregan os paquetes e que ocorre cando a ruta os descarta, non como se cifra o túnel. Detrás dun portal cativo ou dun proxy que só permite o porto 443, a opción máis lenta é a que se conecta sequera. O que segue separa o que fai o protocolo do que permite a túa rede de acceso.

Que cambia realmente o transporte

TCP entrega un fluxo de bytes fiable e ordenado e retransmite todo o que se perde, como especifica a RFC 9293. UDP entrega datagramas á rede, e OpenVPN executa a súa propia capa de fiabilidade sobre ese socket. Encapsular TCP dentro de TCP apila dous bucles de recuperación, así que un só segmento perdido pode reter o fluxo interno ata que chega a retransmisión exterior. Esa interacción é o argumento real a favor de UDP, e aparece como latencia en lugar de como caudal.

O efecto medra coas perdas e o tempo de ida e volta. Nunha ruta local limpa ambos os transportes séntense idénticos, por iso unha proba de laboratorio raramente reproduce a queixa. Nunha ligazón móbil congestionada a diferenza nótase en sesións interactivas moito antes de que unha transferencia grande advirta nada.

Nada disto toca a confidencialidade nin a integridade. O handshake TLS e o cifrado da canle de datos son os mesmos para ambos os transportes, así que cambiar non pode salvar un conxunto de cifrado feble.

Onde gaña TCP o seu sitio

As redes de acceso son a razón habitual para escoller TCP. Un hotel, un aeroporto ou unha rede de convidados poden permitir o 443 de saída e descartar todo o demais, e un oínte TCP nese porto é o único perfil que funciona. Iso é accesibilidade, non rendemento, e é unha razón suficientemente boa por si soa.

TCP tamén axuda cando a ruta é estable pero os equipos intermedios son hostís. Algunhas redes restablecen fluxos UDP de longa duración mentres toleran sesións TCP que parecen tráfico web normal. Que ese parecido teña éxito é unha propiedade da rede concreta, e ningunha guía pode prometelo para todas. Proba dentro da rede que falla antes de culpar o protocolo.

Un inicio de sesión rexeitado non é un problema de transporte. Desactivar a verificación do certificado para forzar unha conexión é outro cambio cun resultado moito peor.

Ter un perfil TCP listo é o compromiso práctico. A maioría dos clientes gardan ambos e déixanche cambiar cando unha rede rexeita a ruta UDP, o que non custa nada ata que o necesitas. O que non deberías facer é distribuír dous perfís apuntando a puntos finais distintos, porque entón a túa comparación mide os servidores.

Comproba que oínte tes realmente

Antes de comparar o rendemento, confirma que ambos os extremos coinciden no transporte e no porto. Cambiar proto udp por proto tcp nun ficheiro de cliente non crea un oínte no servidor. O servidor debe estar configurado para ese protocolo, e o perfil debe coincidir con el.

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

grep imprime o que se lle dixo ao servidor que usase, mentres que as dúas listas de sockets mostran a que está vinculado. Un oínte UDP só aparece na primeira lista e un oínte TCP só na segunda, así que unha liña ausente é a forma máis rápida de atopar un perfil que nunca se aplicou. Compara tamén o porto, porque un perfil TCP no 1194 compórtase de forma distinta a un no 443 na maioría das redes de acceso. Reinicia o servizo despois do cambio e le a liña do rexistro que informa da vinculación.

A confirmación do lado do cliente é barata: executa a conexión con --verb 4 e le a liña de transporte no rexistro. Se o cliente di UDP mentres o servidor escoita en TCP, o handshake nunca comeza e ningún axuste axudará.

Compara a carga de traballo, non a etiqueta do transporte

Unha comparación xusta mantén todo constante agás o transporte. O mesmo dispositivo, a mesma rede de acceso, o mesmo host de destino, a mesma aplicación e, idealmente, o mesmo servidor. Se os dous perfís apuntan a hosts distintos, tamén estás medindo eses hosts.

Rexistra tres resultados por execución: se o túnel se establece, se se mantén e se a tarefa se completa. As solicitudes pequenas que funcionan mentres as transferencias grandes se atascan apuntan ao tamaño de paquete e ao MTU, non ao transporte. As reconexións repetidas apuntan á ruta ou a un tempo de espera dun equipo intermedio.

Conserva o perfil que funciona nas condicións que realmente atopas e garda o outro. A escolla pertence á rede, non á persoa, e por iso calquera resposta predeterminada única falla nalgún lugar.