Якщо вас переводять через повільне посилання в загальнодоступному Інтернеті, то ваші єдині варіанти - насильницькі маршрути. Найпростіший спосіб зробити це - спробувати перенести файл між двома кінцевими точками, одна з яких - "точка А" (походження даних) та проміжний сайт, який географічно не розташований з пунктом призначення, "точка Б" .
Після того, як ви знайдете "точку С", що є сервером, який не проходить маршрутизацією через повільний маршрутизатор Інтернету, з яким ви стикаєтесь, ви можете встановити VPN між точкою A і точкою C, щоб трафік "перекидався" навколо повільний вузол.
Якщо ви маєте високу цінність для бізнесу ($$$$$$) або закриваєтесь з провайдером, ви також можете вирішити проблему безпосередньо на рівні 3. Однак L3 є провайдером першого рівня і може бути не особливо сприйнятливим до скарг на обслуговування якості або насиченості мережі, оскільки вони дуже мало можуть зробити для цього, якщо вони не можуть, не захочуть або не можуть розширити свої угоди про підключення до нижньої частини або інших постачальників першого рівня, які створюють суперечки на своєму вузлі.
Оскільки ви сказали, що посилання "офіс до сервера" швидше, ви можете спробувати встановити VPN на веб-сайті "офіс" із помітно потужним комп'ютером (двоядерна система серверного класу повинна бути добре).
О, також! Якщо затримка (від кінця до кінця) між "точкою A" та "точкою B" дуже велика (у світі сервера більше 100 мс), слід переконатися, що ви не використовуєте чаткий мережевий протокол . Samba (також відомий як SMB або Windows File Sharing) надзвичайно балакучий; інші "синхронізуючі" протоколи також можуть бути балаканими.
Протоколи чаті - це ті, для яких потрібно багато синхронних "туди-назад" зворотних поїздок для передачі даних. Якщо ваш протокол занадто балакучий, то лише затримка може перешкоджати передачі даних, незалежно від того, наскільки швидке посилання здатне.
Одне, що ви можете зробити, щоб визначити, чи дійсно балакучість впливає на вашу пропускну здатність, - це використовувати відомий протокол без чаті , наприклад HTTP, для тестової передачі. Отже, спробуйте звичайний старий HTTP від "точки A" до "точки B" через "повільний" маршрутизатор Level3, і якщо затримка висока, але пропускна здатність все-таки хороша, то ви знаєте, що причина вашої передачі повільна - це ваша протокол занадто балакучий, тому вам потрібно змінити протокол.
Тож дозвольте мені завершити дискусію, коротко визначивши та пояснивши три порушення мережі та чому будь-який з них може відповідати за це питання:
Затримка - скільки часу потрібна дейтаграмі, щоб дістатися від вашого кінця до іншого. Ви не можете безпосередньо покращити затримку в більшості випадків, якщо один із ваших комп'ютерів не перевантажений настільки, що його мережевий стек, ядро чи програми генерують значну додаткову затримку. Більшість затримок у загальнодоступному Інтернеті походить від інтернет-маршрутизаторів, а не від комп'ютера чи кінцевої точки.
Пропускна здатність - пропускна здатність - це максимальна пропускна здатність найповільнішого зв'язку між вашим комп'ютером та кінцевою точкою. У більшості сучасних мереж пропускна здатність не є справжнім обмеженням, оскільки інші порушення мережі, встановлені та сповільнюють мережу задовго до того, як пропускна здатність буде справжньою проблемою.
Втрата пакетів - втрата пакету може збільшити сприйняті затримки для надійних дейтаграм (наприклад, TCP), і часто є результатом сильно насичених посилань, які повинні викинути пакет з передачі TCP або приймати буфер через те, що буфер вже надто заповнений. Також втрата пакетів може статися з "чутливими до часу" пакетами, як це стосується майже всіх пакетів TCP, оскільки якщо пакет надходить після закінчення терміну, то він відкидається. Це відбувається, якщо більший пакет TCP фрагментований на кілька дейтаграм IP, і протокол TCP на стороні прийому може зачекати лише певний час, щоб усі фрагменти надійшли, перш ніж вирішити перервати отримання пакету. Отже втрата пакетів опосередковано випливає з питань насичення (що є проблеми з пропускною здатністю), а також із апаратними проблемами або відмовами.
Отримані від основних недоліків мережі - це пом'якшення, які ви можете вжити, щоб підвищити надійність ваших програм, не змінюючи основних погіршень, тому що більшу частину часу ви можете зробити мало, щоб нічого не контролювати:
Пом'якшення одного полягає в тому, щоб зробити ваш протокол менш балакучим (або, з точки зору системної інтеграції, використовувати існуючий протокол, який менш балакучий, ніж ваше поточне рішення). Чим менше потрібно "туди-назад", щоб синхронізувати дані між кінцевими точками, тим краще ви будете - період. Деякі протоколи можуть бути спроектовані таким чином, щоб вимагати змінної частоти синхронізації - якщо це так, вам слід динамічно відключати частоту синхронізації, наскільки це можливо, якщо ви виявите високу затримку або втрату пакету. Зменшення балачки допомагає зменшити затримку та втрати пакетів, але не має проблем зі стелею пропускної здатності.
Пом'якшення два - налаштувати всі ваші переходи (ті, якими ви безпосередньо керуєте на адміністративному та апаратному рівні), щоб використовувати найкращий доступний алгоритм управління активною чергою (AQM), який на даний момент є справедливою затримкою керованої черги AQM. Це доступно в Linux kernel 3.5 або пізнішої версії як реалізація fq_codelqdisc, і що він робить, це динамічно зменшуєтьсярозмір буферів для передачі та прийому, щоб зменшити затримку, яку ці буфери незмінно виробляють. Це може зменшити втрату пакету та допомогти впоратися із затримкою за допомогою протоколу TCP, оскільки ваші фрагментарні пакети мають меншу ймовірність, якщо ви мінімізуєте кількість очікування, яке повинен пройти пакет, перш ніж він буде надісланий по посиланню. Зауважте, що це пом'якшення має будь-яку різницю лише у тому випадку, якщо вузол "насичений" (тобто, якщо буфер TCP порожній, він не має ефекту). Вузол насичується всякий раз, коли швидкість запису даних у мережевий сокет перевищує швидкість передачі висхідної лінії зв'язку. Типова реакція стеку TCP на цю ситуацію полягає в збільшенні буфера, що насправді має негативний ефект, оскільки збільшує затримку, і це спричиняє всілякі проблеми - тому fq_codel допомагає пом’якшити це.
Обидва ці пом'якшення допомагають виконувати всі три основні порушення мережі, не прокладаючись по несправному вузлу і не змінюючи апаратного забезпечення або звертаючись до провайдера.