Почему общий доступ к файлам через VPN кажется медленным: круги, а не Mbps

Открыть общую папку через VPN и ждать, пока список каталога еле ползёт, — знакомый опыт, и первый инстинкт — винить пропускную способность. Обычно канал почти простаивает. Протокол проводит время в ожидании ответов, и каждое ожидание стоит целого круга, который локальная сеть никогда не начисляла. Исправьте форму работы, и общий доступ снова станет пригодным.

Удалённая рабочая копия имеет неправильную форму

SMB открывает файлы, читает метаданные и подтверждает во множестве мелких обменов. Рабочая копия системы контроля версий на подключённом диске рассчитывает на задержку локальной файловой системы и читает много мелких файлов. Настольная база данных тянет страницы, пока пользователь работает. Каждое из этого превращает задержку в множитель, потому что стоимость растёт с числом обменов, которые выполняет операция; поэтому туннель с 40 мс превращает несколько сотен операций в несколько секунд. Размер полезной нагрузки в этой арифметике почти не важен.

Накладные расходы на шифрование — малая часть этого; потери хуже, потому что одна повторная передача плюс обвалившееся окно перегрузки стоят гораздо больше, чем затронутые байты.

Считайте круги раньше мегабайтов

Измерьте задержку, прежде чем покупать пропускную способность. Один ping показывает, за что платит каждый обмен.

ping -c 10 fileserver.example.net

Сводка даёт минимальное, среднее и максимальное время круга, и разброс важен не меньше среднего. Умножьте среднее на число обменов, которые делает список каталога, и сравните с временем, которое вы действительно наблюдаете. Если один большой файл передаётся быстро, а просмотр медленный, ограничением являются задержка и число запросов. Добавить вдесятеро больше пропускной способности каналу, который никогда не насыщается, не меняет ровно ничего.

Переносите работу, а не байты

Измените место, где выполняется работа, вместо того чтобы платить за более широкую трубу. Отдавайте репозиторий, а не монтируйте его, и копируйте массово инструментом, который передаёт только различия.

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

Когда репозиторий отдаётся, как это делает hgweb или удалённый Git, клиент может работать на локальном клоне, поэтому его вызовы файловой системы никогда не пересекают туннель. rsync проходит обе стороны и передаёт изменённые блоки, устраняя большинство обменов, за которые платит наивное копирование. Настольная база данных должна находиться на серверном движке, а клиент сводиться к интерфейсу, либо весь клиент работает на внутреннем хосте. Каждый вариант меняет то, какой задержке подвергается протокол, и в этом суть.

Зависания около одного размера — симптом MTU

Крупные передачи, которые останавливаются примерно после одинакового объёма данных, когда ping и мелкие страницы работают, указывают на размер пакета, а не на пропускную способность.

ping -M do -s 1400 -c 3 fileserver.example.net

Успешная проверка означает, что IP-пакет размером 1428 байт проходит путь без фрагментации, так как заголовки ICMP и IP добавляют 28 байт. Неудача с флагом запрета фрагментации говорит о том, что используемый MTU туннеля меньше, чем предполагает сервер. Сервер, отправляющий буферы по 9000 байт на путь в 1500 байт, вынуждает фрагментацию или отбрасывание, а обнаружение MTU пути может тихо провалиться, когда ICMP фильтруется. Снизьте MTU туннеля, включите mssfix в OpenVPN или уменьшите буферы сервера, затем повторите ту же передачу для подтверждения.

Измерьте разрыв, который имеет значение

Выполните ту же операцию тремя способами там, где позволяет политика: локально, через туннель и по прямому интернет-пути. Для каждого отметьте время круга, скорость одного большого потока и сколько занимает список каталога или открытие приложения. Сравнение локального запуска с запуском через туннель показывает, какая стоимость преобладает. Копия, которая завершается медленно, указывает на проблему скорости или задержки, а копия, которая умирает в постоянной точке, — на размер пакета или устройство с состоянием на пути.

Когда тормозят только первые мегабайты, смотрите на аутентификацию и метаданные; когда ползёт всё, смотрите на пропускную способность и потери. Исправьте соответствующую причину и перестаньте ждать, что канал WAN будет вести себя как кабель локальной сети.