Пришвидшити завантаження SFTP в мережу з високою затримкою?

Я намагаюся перенести набір великих файлів на міжнародному рівні за допомогою SFTP, але я знаходжу, що мій міжнародний партнер не може досягти швидкості завантаження вище ~ 50k, незважаючи на дуже хороші зв'язки з обох сторін. Ми можемо отримати кілька завантажень підключень із такою швидкістю (значить, не пропускну здатність?), Але жодне завантаження не покращує швидкість, що є проблемою, оскільки багато файлів мають розмір декількох Гбіт.

SFTP розміщується за допомогою стандартної системи SFTP Apple "Віддалений вхід" Apple OSX.

Чи є спосіб покращити швидкість завантаження чи є інший хост SFTP, який би допоміг? Мені не зрозуміло, чи це проблема конфігурації чи властиве обмеження протоколу.

(З міркувань безпеки мені потрібно використовувати зашифроване кінцеве однорангове з'єднання - немає хмарних служб).

З клієнтом OpenSSHsftp (який, здається, ви використовуєте), ви можете використовувати:

• -Rпереключити для збільшення довжини черги запиту (за замовчуванням - 64)
• -Bпереключити для збільшення розміру запиту на читання / запис (за замовчуванням - 32 КБ)

Для початку спробуйте подвоїти обидва:

sftp -R 128 -B 65536 user@host

Напевно, не має великого значення, на кого з них ти збільшуєшся.

Збільшення або повинно сприяти насиченню вашого високої затримки зв'язку. З урахуванням вищезазначених налаштувань, дані зберігатимуть у трубі 8 Мб у будь-який час (128 * 64 К = 8 М).

Зауважте, що це допомагає лише при передачі великих файлів. При передачі безлічі невеликих файлів це не матиме жодного ефекту.

Для ознайомлення з інформацією про інші клієнти (GUI) SFTP, див. Розділ "Затримка / затримка мережі" в моїй відповіді на " Чому обмеження передачі файлів FileZilla SFTP максимум у 1,3 Мбіт / сек замість насичення доступної пропускної здатності? rsync та WinSCP ще повільніші .

Ви можете спробувати ввімкнути стиснення та побачити, чи це допомагає.

Від man sftp:

-C Вмикає стиснення (через прапорець ssh -C).

І від man ssh:

-C Потрібно стиснути всі дані (включаючи stdin, stdout, stderr та дані для переадресованих X11, TCP та UNIX-доменів з'єднань). Алгоритм стиснення той самий, що використовується gzip (1), і "рівень" можна керувати параметром CompressionLevel для версії протоколу 1. Стиснення бажано на модемних лініях та інших повільних з'єднаннях, але лише уповільнить роботу в швидких мережах . Значення за замовчуванням можна встановити на основі хоста за хостом у файлах конфігурації; див. Параметр стиснення.

Це швидше звучить так, ніби з'єднання може бути обмеженим швидкістю в якийсь момент на його шляху (а точніше, це здається мені найпростішим поясненням для ваших 50 кБ / с на з'єднання, але можливе кілька таких з'єднань), хоча це може бути не погана ідея переконатися, що диски з обох сторін не є фактором.

Ви також можете запустити швидкий pcap, щоб побачити, чи є якісь "очевидні" проблеми (наприклад, велика кількість повторних передач) - але якщо ви не маєте певної впевненості, ви зможете вирішити це, я, мабуть, просто побачу, чи дозволить компресія допомогу.

Я намагаюся передати набір великих файлів у міжнародному масштабі за допомогою SFTP

Це ще не було згадано як відповідь, але при передачі декількох файлів через високо затримкове посилання є одне дійсно просте рішення для підвищення продуктивності:

Передача декількох файлів паралельно.

І це рішення , яке ви навіть згадали у своєму запитанні. Використай це.

В основному протокол TCP не дуже добре обробляє з'єднання з великим продуктом із затримкою пропускної здатності - одне з'єднання не може одночасно тримати достатню кількість даних. Дивіться https://en.wikipedia.org/wiki/TCP_tuning

Оскільки кожне з'єднання обмежено протоколом TCP, просто використовуйте більше з'єднань.

Прискорити передачу sftp

Припустимо, що вашими проблемами є налаштування мережі та / або дроселювання за підключенням TCP, погляньте на sftp за допомогою підсистеми дзеркала lftp

Налаштування мережі на кожному кінці є набагато більшою темою, і вона потребує багато назад і вперед, висуваючи тему поза сферою ServerFault. Для окремих підключень компресія, згадана iwaseatenbyagrue, може допомогти будь-яким способом. Це передбачає, що віддалений кінець дозволяє стиснути.

(Ви згадуєте "високу затримку" в заголовку запитання, але не в тексті тексту. Чи вимірювали ви фактичну затримку та які результати?)

Існує патч до OpenSSH, який явно покращує пропускну спроможність по мережевому посиланню з високою затримкою: HPN-SSH : (акцент мій)

Реалізація SCP і базовий протокол SSH2 у OpenSSH є продуктивністю мережі, обмеженою статично визначеними буферами внутрішнього потоку управління. Ці буфери часто діють як вузьке місце для пропускної здатності мережі SCP, особливо на довгих і високих пропускних мережах. Зміна коду ssh, щоб дати змогу визначати буфери під час виконання, усуває це вузьке місце. Ми створили виправлення, яке видалить вузькі місця у OpenSSH і повністю взаємодіє з іншими серверами та клієнтами. Крім того, клієнти HPN зможуть швидше завантажуватись із серверів, які не є HPN, а сервери HPN зможуть швидше отримувати завантаження від клієнтів, які не є HPN.

Отже, спробуйте скласти та використовувати HPN-SSH на стороні, що приймає, і подивіться, чи покращує це швидкість передачі.

Не впевнені, чи це варіант для вас, але ви намагалися перетягнути дані на міжнародний сайт? А також або в різний час, щоб побачити, чи це проблема із суперечкою мережевих ресурсів?

Ми можемо отримати кілька завантажень підключень із такою швидкістю (так не пропускну здатність?)

Це звучить як проблема конфігурації - або навмисно (як спосіб поповнення послуг, не вимагаючи додаткових послуг), або випадково (наприклад, розбиття масштабування вікон або надмірний контроль трафіку). Хоча ви могли б паралелізувати передачі, ви нічого не говорили нам про те, що знаходиться на іншому кінці з'єднання, або якщо варто розробити декілька простих сценаріїв для обробки заточування / відновлення файлів.

Настроювання розміру черги та стиснення навряд чи матиме суттєвий вплив, якщо тільки причина не дуже написане програмне забезпечення (а openSSH не належить до цієї категорії - не так багато сенсу використовувати Opensh з довшою чергою запитів / більшим розміром блоку, якщо затримка не буде понад 250 мс. Ви можете спробувати з різними клієнтами з різних локацій, щоб виключити проблему з сервером.

Першим моїм дзвінком було б визначити, хто в цій проблемі винен провайдер, попросити їх усунути проблему або перейти до іншого постачальника.