OpenVPN sobre TCP: rto_min non corrixe o bloqueo na cabeza da cola

Unha shell interactiva sobre o túnel conxélase durante varios segundos mentres se executa unha copia de ficheiros, e despois continúa coma se nada pasase. O problema só o ten a descarga, pero a shell tamén espera, e ambas se recuperan no mesmo instante. Ese patrón é a sinatura dun único fluxo fiable que leva moitas conversas, e sobrevive a case calquera axuste que a xente proba primeiro.

Paga a pena ler o síntoma con coidado porque apunta a un mecanismo e non a unha configuración: a pausa é compartida, así que a causa é compartida, e o obxecto compartido é a conexión exterior. Todo o demais no rexistro parece normal mentres ocorre.

O síntoma: todo se detén á vez

Dúas conexións interiores que se atascan xuntas son a pista. Unha descarga lenta e unha shell lenta son conversas TCP separadas con números de secuencia e estado de conxestión separados, así que un fallo nunha non debería tocar a outra. Cando se deteñen ao mesmo ritmo, algo por riba delas está a ordenar os seus bytes.

Ese algo é o transporte do túnel. En modo TCP, OpenVPN escribe os paquetes encapsulados nunha única conexión TCP cara ao par, e o contrato de TCP é a entrega en orde dun único fluxo de bytes. Os bytes posteriores non se entregan á aplicación antes dos que faltan, a calquera conversa interior que pertenzan.

Fíxese no que o síntoma non di. Non di que a ruta estea rota, que o servidor estea sobrecargado ou que o cifrado sexa lento. Eses producen outras formas: rendemento uniformemente baixo, tempos de espera ou fallos que afectan unha soa dirección. Unha pausa compartida que remata cando se retransmite un segmento perdido é especificamente un efecto de ordenación.

Un fluxo exterior de bytes, moitas conversas interiores

Imaxine o túnel levando á vez unha descarga e unha shell. Pérdese un segmento da conexión exterior. Os segmentos seguintes poden chegar ao host receptor, e a pila TCP receptora confirmaraos, pero non pode entregalos cara arriba ata que se encha o oco. Por iso OpenVPN non ten nada que ler para a shell, aínda que os bytes da propia shell chegaron hai moito.

Isto é bloqueo na cabeza da cola dentro dunha conexión, e non require que as dúas aplicacións compartan unha conexión interior. Comparten a exterior, e iso abonda.

O efecto de segunda orde empeórao. Un emisor interior que non ve confirmacións pode retransmitir datos que a capa exterior xa está tentando entregar. Esa retransmisión convértese en tráfico adicional do túnel nunha ruta que acaba de demostrar que pode perder segmentos, así que o traballo de recuperación compite coa recuperación que importa.

Nada disto garante un colapso. Nunha ruta limpa con viaxes de ida e volta curtas e colas amplas, este arranxo pode ser perfectamente utilizable durante anos. O fallo aparece cando perda, atraso e profundidade de cola coinciden, e por iso os informes agrúpanse arredor de enlaces ascendentes congestionados e conexións móbiles e non de oficinas ben dotadas.

Por que un temporizador interior máis longo non pode axudar

Elevar o tempo mínimo de retransmisión nunha ruta con rto_min adía a retransmisión por temporizador para o tráfico TCP xerado localmente que usa esa ruta. É un botón real cun efecto real, e aborda o problema de segunda orde en lugar do primeiro.

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

O que non pode é liberar bytes exteriores fóra de orde, recuperar o segmento perdido máis rápido ou facer que o servidor de aplicacións remoto adopte o mesmo temporizador. A pila receptora segue entregando en orde, e o emisor do extremo afastado segue usando as súas propias medidas de ida e volta.

Tampouco desactiva todos os demais mecanismos de recuperación de perdas. Onde a perda real require recuperación por temporizador, un mínimo maior fai que a aplicación espere máis antes de actuar, o que é o contrario do que necesita unha sesión sensible á latencia.

Un chan fixo de doce segundos aparece nos consellos sobre este tema coma se a existencia dun túnel TCP o implicase. O temporizador de retransmisión descrito no RFC 6298 derívase do tempo de ida e volta medido con retroceso exponencial, así que un chan constante é unha escolla de política para unha ruta concreta e non un requisito do protocolo. Aplicado de forma ampla, oculta o síntoma á vez que cambia a recuperación de cada fluxo que cubre esa ruta.

Que fai e que non fai tcp-nodelay

A opción de túnel que desactiva o almacenamento en búfer estilo Nagle no socket de transporte ten un propósito estreito: impide que as escrituras pequenas esperen máis datos antes de transmitir. Iso axuda ao tráfico interactivo a evitar un atraso adicional nunha ruta por demais saudable.

Non converte o transporte nun sen orde e non acurta a recuperación despois dun segmento perdido. Unha shell que se detén por un tempo de espera de retransmisión seguirá deténdose coa opción activada, porque a opción nunca tocou a regra de orde.

Confundir as dúas cousas é doado porque ambas se describen como correccións de latencia. Unha elimina unha espera artificial introducida polo búfer, a outra requiriría cambiar o que o transporte garante, e ningunha opción de socket fai iso.

Como comparar transportes con xustiza

Se o operador o permite e ambas as dúas servizos existen, compare un servizo UDP e un servizo TCP que leven a mesma carga de traballo pola mesma ruta de acceso ao mesmo servidor. Cambiar de país, provedor ou xeración de servidor entre as dúas probas introduce unha variable que dominará o resultado.

Fíxese na pausa compartida en lugar de nunha cifra de rendemento. Varias aplicacións interiores atascándose xuntas durante unha perda exterior é a observación que identifica o bloqueo na cabeza da cola; unha soa cifra máis baixa nunha proba de velocidade non o fai.

As capturas autorizadas na interface do túnel e na interface física separan as dúas capas con claridade, porque as retransmisións interiores e exteriores pertencen a conexións distintas con espazos de secuencia distintos. Ver retransmisións interiores mentres o fluxo exterior mostra un oco é a proba directa.

Pasar a UDP elimina o fluxo fiable adicional e deixa que o TCP interior faga a súa propia recuperación. Non promete perda cero nin baixa latencia, e un enlace ascendente saturado, colas sobredimensionadas ou un problema de MTU seguirán necesitando arranxo. O tráfico fóra do túnel nunca queda retido detrás do oco de secuencia do túnel, aínda que pode seguir sufrindo cando ambas as rutas comparten unha única ligazón congestionada, e ese estrangulamento compartido merece a súa propia investigación en lugar de ser dobrado nesta.