Bloquejos d'OpenVPN per TCP: rto_min no arregla el cap de línia

Una shell interactiva sobre el túnel es congela durant uns segons mentre s'executa una còpia de fitxers i després es reprèn com si no hagués passat res. La baixada és l'única cosa amb un problema, però la shell també espera, i les dues es recuperen al mateix moment. Aquest patró és la signatura d'un sol flux fiable que transporta moltes converses, i sobreviu a gairebé tots els ajustos que la gent prova primer.

Val la pena llegir el símptoma amb atenció perquè apunta a un mecanisme i no a un paràmetre: la pausa és compartida, així que la causa és compartida, i l'objecte compartit és la connexió externa. La resta del registre sembla normal mentre passa.

El símptoma: tot es para alhora

Dues connexions internes que es bloquegen alhora són la pista. Una baixada lenta i una shell lenta són converses TCP separades amb números de seqüència separats i estat de congestió separat, així que una fallada en una no hauria de tocar l'altra. Quan es paren al mateix ritme, alguna cosa per sobre d'elles ordena els seus bytes.

Aquesta cosa és el transport del túnel. En mode TCP, OpenVPN escriu els paquets encapsulats en una sola connexió TCP cap al parell, i el contracte de TCP és el lliurament en ordre d'un sol flux de bytes. Els bytes posteriors no es lliuren a l'aplicació abans dels que falten, sigui quina sigui la conversa interna a què pertanyin.

Fixeu-vos en què no diu el símptoma. No diu que el camí estigui trencat, que el servidor estigui sobrecarregat o que el xifrat sigui lent. Aquests produeixen formes diferents: rendiment baix uniforme, temps d'espera o fallades que afecten una direcció. Una pausa compartida que acaba quan es retransmet un segment perdut és específicament un efecte d'ordenació.

Un flux extern de bytes, moltes converses internes

Imagineu el túnel transportant una baixada i una shell alhora. Es perd un segment de la connexió externa. Els segments següents poden arribar a l'amfitrió receptor, i la pila TCP receptora els reconeixerà, però no els pot lliurar cap amunt fins que s'ompli el buit. OpenVPN, doncs, no té res per llegir per a la shell, tot i que els bytes propis de la shell van arribar fa estona.

Això és bloqueig de cap de línia dins d'una connexió, i no requereix que les dues aplicacions comparteixin una connexió interna. Comparteixen l'externa, i això n'hi ha prou.

L'efecte de segon ordre ho empitjora. Un emissor intern que no veu cap reconeixement pot retransmetre dades que la capa externa ja intenta lliurar. Aquesta retransmissió es converteix en trànsit addicional del túnel en un camí que acaba de demostrar que pot perdre segments, així que la feina de recuperació competeix amb la recuperació que importa.

Res d'això garanteix un col·lapse. En un camí net amb temps d'anada i tornada curts i cues generoses, la disposició pot ser perfectament utilitzable durant anys. La fallada apareix quan la pèrdua, el retard i la profunditat de la cua s'alineen, i per això els informes s'agrupen al voltant d'enllaços de pujada congestionats i enllaços mòbils i no d'oficines ben proveïdes.

Per què un temporitzador intern més llarg no pot ajudar

Apujar el temps d'espera mínim de retransmissió en una ruta, amb rto_min, ajorna la retransmissió per temporitzador del trànsit TCP generat localment que fa servir aquesta ruta. És un control real amb un efecte real, i aborda el problema de segon ordre i no el primer.

ip route show
ip route show cache 2>/dev/null | head
ss -tin dst 10.70.0.1

El que no pot fer és alliberar bytes externs fora d'ordre, recuperar el segment perdut més de pressa o fer que el servidor remot de l'aplicació adopti el mateix temporitzador. La pila receptora continua lliurant en ordre, i l'emissor de l'altre extrem continua utilitzant les seves pròpies mesures d'anada i tornada.

Tampoc no desactiva tots els altres mecanismes de recuperació de pèrdues. On una pèrdua real requereix recuperació per temporitzador, un mínim més gran fa que l'aplicació esperi més abans d'actuar, que és el contrari del que necessita una sessió sensible a la latència.

Un terra fix de dotze segons apareix en consells sobre aquest tema com si l'existència d'un túnel TCP l'imposés. El temporitzador de retransmissió descrit a RFC 6298 deriva del temps d'anada i tornada mesurat amb retrocés exponencial, així que un terra constant és una decisió de política per a una ruta concreta i no un requisit del protocol. Aplicat àmpliament, amaga el símptoma mentre canvia la recuperació de cada flux que la ruta cobreix.

Què fa i què no fa tcp-nodelay

L'opció del túnel que desactiva l'emmagatzematge a l'estil Nagle al sòcol de transport té un propòsit estret: impedeix que les escriptures petites esperin més dades abans de transmetre. Això ajuda el trànsit interactiu a evitar un retard extra en un camí saludable d'altra banda.

No converteix el transport en un desordenat, i no escurça la recuperació després d'un segment perdut. Una shell que es para per un temps d'espera de retransmissió es continuarà parant amb aquesta opció activada, perquè l'opció mai no va tocar la regla d'ordenació.

És fàcil confondre les dues coses perquè totes dues es descriuen com a correccions de latència. Una elimina una espera artificial introduïda per l'emmagatzematge; l'altra requeriria canviar el que garanteix el transport, cosa que cap opció de sòcol fa.

Com comparar transports amb justícia

Si l'operador ho permet i tots dos serveis existeixen, compareu un servei UDP i un servei TCP amb la mateixa càrrega de treball pel mateix camí d'accés al mateix servidor. Canviar de país, proveïdor o generació de servidor entre les dues proves introdueix una variable que dominarà el resultat.

Vigileu la pausa compartida i no un número de rendiment. Diverses aplicacions internes que es bloquegen alhora durant una pèrdua externa és l'observació que identifica el bloqueig de cap de línia; una sola xifra més baixa d'una prova de velocitat no ho fa.

Les captures autoritzades a la interfície del túnel i a la interfície física separen netament les dues capes, perquè les retransmissions internes i externes pertanyen a connexions diferents amb espais de seqüència diferents. Veure retransmissions internes mentre el flux extern mostra un buit és l'evidència directa.

Passar a UDP elimina el flux fiable addicional i deixa que el TCP intern faci la seva pròpia recuperació. No promet zero pèrdues ni latència baixa, i un enllaç de pujada saturat, cues massa grans o un problema d'MTU encara s'hauran d'arreglar. El trànsit fora del túnel no es reté mai darrere del buit de seqüència del túnel, tot i que encara pot patir quan tots dos camins comparteixen un enllaç congestionat, i aquest coll d'ampolla compartit mereix la seva pròpia investigació en lloc de ser inclòs en aquesta.