Чому спільний доступ до файлів через 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 поводитиметься як кабель локальної мережі.