L’UDP no sempre és més ràpid: triar el transport d’OpenVPN

Totes les guies diuen que l’UDP supera el TCP per a OpenVPN, i aquest consell és un valor predeterminat, no un mesurament. El transport canvia com es lliuren els paquets i què passa quan el camí els deixa caure, no com s’encripta el túnel. Al darrere d’un portal captiu o d’un proxy que només permet el port 443, l’opció més lenta és la que es connecta de debò. El que segueix separa què fa el protocol del que permet la vostra xarxa d’accés.

Què canvia realment el transport

El TCP lliura un flux de bytes fiable i ordenat i retransmet tot el que es perd, tal com especifica l’RFC 9293. L’UDP entrega datagrames a la xarxa, i OpenVPN executa la seva pròpia capa de fiabilitat sobre aquest sòcol. Encapsular TCP dins de TCP apila dos bucles de recuperació, així que un sol segment perdut pot retenir el flux intern fins que arriba la retransmissió exterior. Aquesta interacció és l’argument real a favor de l’UDP, i apareix com a latència i no com a cabal.

L’efecte creix amb les pèrdues i el temps d’anada i tornada. En un camí local net els dos transports es noten idèntics, i per això una prova de laboratori poques vegades reprodueix la queixa. En un enllaç mòbil congestionat la diferència es veu en sessions interactives molt abans que una transferència gran noti res.

Res d’això no toca la confidencialitat ni la integritat. La negociació TLS i el xifratge del canal de dades són els mateixos per als dos transports, així que canviar no pot salvar un joc de xifratge feble.

On el TCP guanya el seu lloc

Les xarxes d’accés són la raó habitual per triar TCP. Un hotel, un aeroport o una xarxa de convidats poden permetre el 443 de sortida i descartar tota la resta, i un oient TCP en aquest port és l’únic perfil que funciona. Això és abastabilitat, no rendiment, i és una raó prou bona per si sola.

El TCP també ajuda quan el camí és estable però els equips intermediaris són hostils. Algunes xarxes restableixen fluxos UDP de llarga durada mentre toleren sessions TCP que semblen trànsit web ordinari. Que aquesta semblança tingui èxit és una propietat de la xarxa concreta, i cap guia no ho pot prometre per a totes. Proveu-ho dins de la xarxa que falla abans de culpar el protocol.

Un inici de sessió rebutjat no és un problema de transport. Desactivar la verificació del certificat per forçar una connexió és un canvi diferent amb un resultat molt pitjor.

Tenir un perfil TCP a punt és el compromís pràctic. La majoria de clients desen tots dos i us deixen canviar quan una xarxa refusa el camí UDP, cosa que no costa res fins que la necessiteu. El que no hauríeu de fer és enviar dos perfils apuntant a punts finals diferents, perquè llavors la vostra comparació mesura els servidors.

Comproveu quin oient teniu realment

Abans de comparar el rendiment, confirmeu que els dos extrems coincideixen en el transport i el port. Canviar proto udp per proto tcp en un fitxer de client no crea un oient al servidor. El servidor s’ha de configurar per a aquest protocol, i el perfil s’hi ha de correspondre.

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

La comanda grep imprimeix què se li ha dit al servidor que faci servir, mentre que els dos llistats de sòcols mostren a què està lligat. Un oient UDP només apareix al primer llistat i un oient TCP només al segon, així que una línia absent és la manera més ràpida de trobar un perfil que mai no es va aplicar. Compareu també el port, perquè un perfil TCP al 1194 es comporta de manera diferent que un al 443 a la majoria de xarxes d’accés. Reinicieu el servei després del canvi i llegiu la línia del registre que informa de l’enllaç.

La confirmació al costat del client és barata: executeu la connexió amb --verb 4 i llegiu la línia de transport del registre. Si el client diu UDP mentre el servidor escolta en TCP, la negociació no comença mai i cap ajustament no hi ajudarà.

Compareu la càrrega de treball, no l’etiqueta del transport

Una comparació justa manté tot constant excepte el transport. El mateix dispositiu, la mateixa xarxa d’accés, el mateix amfitrió de destinació, la mateixa aplicació i, idealment, el mateix servidor. Si els dos perfils apunten a amfitrions diferents, també mesureu aquests amfitrions.

Anoteu tres resultats per a cada execució: si s’estableix el túnel, si es manté i si la tasca es completa. Les peticions petites que funcionen mentre les transferències grans s’encallen assenyalen la mida dels paquets i l’MTU, no el transport. Les reconnexions repetides assenyalen el camí o un temps d’espera d’un equip intermediari.

Conserveu el perfil que funciona en les condicions que trobeu de debò, i guardeu l’altre. L’elecció pertany a la xarxa, no a la persona, i per això qualsevol resposta predeterminada única falla en algun lloc.