Por qué compartir archivos por VPN parece lento: idas y vueltas, no Mbps
Los protocolos para compartir archivos dan por sentada la latencia de una LAN. Metadatos parlanchines, operaciones con archivos pequeños y problemas de MTU causan bloqueos que más ancho de banda no arreglará.
Abrir una carpeta compartida por la VPN y esperar mientras el listado del directorio se arrastra es una experiencia conocida, y el primer instinto es culpar al ancho de banda. Normalmente el enlace está casi inactivo. El protocolo pasa el tiempo esperando respuestas, y cada espera cuesta una ida y vuelta completa que la LAN nunca cobraba. Corrija la forma del trabajo y el recurso vuelve a ser usable.
La copia de trabajo remota tiene la forma equivocada
SMB abre archivos, lee metadatos y confirma en muchos intercambios pequeños. Una copia de trabajo de control de versiones en una unidad montada da por sentada la latencia del sistema de archivos local y lee muchos archivos pequeños. Una base de datos de escritorio extrae páginas mientras el usuario trabaja. Cada una de esas cosas convierte el retardo en un multiplicador, porque el coste crece con cuántos intercambios realiza la operación; por eso un túnel de 40 ms convierte unos cientos de operaciones en varios segundos. El tamaño de la carga útil es casi irrelevante en esa aritmética.
El coste del cifrado es una parte pequeña; la pérdida es peor, porque una retransmisión más una ventana de congestión colapsada cuesta mucho más que los bytes implicados.
Cuente idas y vueltas antes que megabytes
Mida el retardo antes de comprar capacidad. Un solo ping le dice lo que paga cada intercambio.
ping -c 10 fileserver.example.netEl resumen da los tiempos de ida y vuelta mínimo, medio y máximo, y la dispersión importa tanto como la media. Multiplique la media por el número de intercambios que realiza un listado de directorio y compárelo con el tiempo que observa realmente. Si un archivo grande se transfiere rápido mientras la navegación es lenta, la restricción son la latencia y el número de peticiones. Añadir diez veces más capacidad a un enlace que nunca se satura no cambia absolutamente nada.
Mueva el trabajo, no los bytes
Cambie dónde ocurre el trabajo en lugar de pagar por más tubería. Sirva el repositorio en vez de montarlo, y copie en bloque con una herramienta que solo envíe diferencias.
rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/Servir el repositorio, como hacen hgweb o un Git remoto, deja al cliente trabajar sobre un clon local, de modo que sus llamadas al sistema de archivos nunca cruzan el túnel. rsync recorre ambos lados y envía los bloques cambiados, eliminando la mayoría de los intercambios que paga una copia ingenua. Una base de datos de escritorio pertenece a un motor en el servidor con el cliente reducido a una interfaz, o todo el cliente se ejecuta en un host interno. Cada opción cambia a cuánta latencia se expone el protocolo, y de eso se trata.
Los bloqueos a la misma altura son síntoma de MTU
Las transferencias grandes que se atascan tras aproximadamente la misma cantidad de datos, mientras el ping y las páginas pequeñas funcionan, apuntan al tamaño del paquete y no al ancho de banda.
ping -M do -s 1400 -c 3 fileserver.example.netUna prueba correcta significa que un paquete IP de 1428 bytes cruza el camino sin fragmentarse, ya que las cabeceras ICMP e IP añaden 28 bytes. Un fallo con la marca de no fragmentar sugiere que la MTU utilizable del túnel es menor de lo que supone el servidor. Un servidor que envía búferes de 9000 bytes a un camino de 1500 bytes fuerza la fragmentación o descartes, y el descubrimiento de la MTU del camino puede fallar en silencio cuando se filtra ICMP. Baje la MTU del túnel, active mssfix en OpenVPN o reduzca los búferes del servidor, y luego repita la misma transferencia para confirmar.
Mida la brecha que importa
Ejecute la misma operación de tres maneras donde la política lo permita: en local, por el túnel y por una ruta directa de internet. Para cada una, anote el tiempo de ida y vuelta, la tasa de un flujo grande y cuánto tarda un listado de directorio o la apertura de una aplicación. Comparar la ejecución local con la del túnel muestra qué coste domina. Una copia que termina despacio sugiere un problema de tasa o de retardo, mientras que una copia que muere en un punto constante sugiere el tamaño del paquete o un dispositivo con estado en el camino.
Cuando solo se arrastran los primeros megabytes, mire la autenticación y los metadatos; cuando todo se arrastra, mire la capacidad y las pérdidas. Arregle la causa que corresponda y deje de esperar que un enlace WAN se comporte como un cable de LAN.