Що може спричинити високу затримку кожного разу, коли трафік на WAN?

У мене є мережа, яка відчуває повільну швидкість Інтернету. Після великої кількості усунення несправностей я визначив, що будь-який потоковий вміст / завантаження призведе до витримки затримки WAN-трафіку.

Наприклад, без навантаження я записую 8.8.8.8 приблизно за 30 мс. Якщо я розпочну трансляцію YouTube на одному комп’ютері, затримка підскакує приблизно до 500 мс, з відхиленням близько 400 мс. Якщо я вимкну відео, затримка повернеться до 30 мс. Але, якщо у мене є користувач у тій же локальній мережі, що розпочинає потокову передачу пандори, проблема повертається.

У моїй мережі працює один комутатор 10/100. Перемикач підключається безпосередньо до маршрутизатора DSL. У мене зазвичай є 6Mb з'єднання.

У вирішенні проблем я виконав наступне:

• Відскановано за допомогою проводки з декількох робочих станцій, які шукають помилкові пакети. (Я б включив, але скани мають конфіденційну інформацію). Нічого навіть віддаленого від звичайного.
• Замінили роутер на оновлену модель, потім оновили прошивку.
• Якщо провайдер збільшував швидкість, яка вимірювалась правильно на speedtest.net (10 вниз, 1,5 вгору). Проблема була точно така ж.
• Якщо провайдер міняв картки на своєму кінці, на всякий випадок, якщо у них погана апаратура / порт.
• Тестували в іншому офісі з точно таким же провайдером / пакетом. Було кілька комп’ютерів, які передавали YouTube @ 1080p та пандору, не впливаючи на затримку.
• Вимкніть кожен комп'ютер, окрім одного, і бігайте вночі, коли там немає користувачів.
• Моніторинг трафіку локальної мережі, який ніколи не відчуває проблем із затримкою.

Я усвідомлюю, що якщо я досягнув межі пропускної здатності або швидкість обмеження місця на деякому обладнання, це спричинить цю проблему. Однак це зовсім не здається. Практично будь-який трафік через WAN призведе до затримки. Проблема була такою ж, навіть коли я майже подвоїв швидкість з'єднання. Коли я отримую двох користувачів на пандорі та пару серфінгу, Інтернет переходить у нічим (скинуті пакети, сторінки не завантажуються). У мене є половина зв'язку вдома, і наша одночасна трансляція netflix / youtube / pandora навіть не торкається моїх 5 Мб.

Питання: Що може спричинити велику затримку в будь-який час, коли трафік проходить через WAN?

Це звучить як деяка форма " буферного блоку ", ймовірно, з боку DSLAM / LNS, яка виконує обмеження швидкості 6 Мбіт.

Це може бути ваше поле CPE, але це трохи менше ймовірності.

Я би переконався, де відбувається затримка. Використовуйте такий інструмент, як MTR, який перевіряє затримку при кожному стрибку. MTR поєднує статистику ping для кожного скаку з маршрутом трасування, і може значно допомогти звузити подібний тип проблем.

У вікні linux ця команда була б mtr 8.8.8.8, також існує версія Windows цього інструменту.

Вихід покаже вам, де починається затримка. Якщо він знаходиться в мережі провайдера, ви можете переправити вихід до провайдера і допомогти їм використовувати його для усунення їхньої мережевої проблеми.

Якщо затримка розпочнеться всередині вашої мережі, ви зможете і самі усунути проблему.

Перевірте статистику ліній DSL. (переплетене проти швидкого шляху, лічильники помилок тощо)

Тест в іншому місці перевіряв іншу лінію , можливо, на іншому DSLAM. Це говорить про те, що інфраструктура провайдера не винна. Це настійно говорить про те, що ваша лінія DSL винна. Можливо, і сам DSLAM перевантажений, але навряд чи ви будете тим, хто проштовхує його по лінії передбачувано і повторно.

Якщо комірки банкоматів пошкоджуються (транспорт для більшості DSL), ви побачите значні уповільнення, такі як ця, оскільки весь кадр повинен бути обурений.

У будь-який час у мене є випадки, коли у замовника спостерігається затримка в мережі, перше, що потрібно зробити, це перевірити кожне окреме з'єднання в мережі. Зазвичай є один пристрій, де виникає вузьке місце.

Якщо це мережа з низьким рівнем використання, я б повністю відключив QoS на всьому, окрім підключеного до Інтернету пристрою (оскільки QoS сповільнить трафік у комутаційному середовищі).

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

Я також перевірявму процесор кожного пристрою, коли у вас є проблема. Якщо ви бачите, як процесор підскакує, то, ймовірно, ваш проблемний пристрій. Перевірте також журнали, щоб побачити, чи є помилки.

Також я був би впевнений, що всі з'єднання узгоджуються на повній швидкості (швидкість 100 повний дуплекс).

Спробуйте також відключити будь-який брандмауер або служби безпеки.

Інша річ, на яку слід звернути увагу, - це з'єднання між вашим комутатором та DSL-модемом. Симптоми, які ви описуєте, майже звучать так, ніби між ними є дуплексна невідповідність.

Ще один спосіб виключити комутатор - це повністю зняти комутатор і протестувати з'єднання з однією машиною, приєднаною безпосередньо до DSL-модему.

Висока затримка / погана пропускна здатність при великому трафіку іноді вказує на проблему L1 (невідповідність дуплексу / поганий кабель / брудне волокно). Ви перевіряли, що це не так?

Чи може це бути вузьким місцем вище? Не впевнені, де ви знаходитесь у світі, але, можливо, ISP має жахливу міжнародну пропускну здатність. Speedtest.net за замовчуванням буде найближчим сервером.

Простий метод, який я використав, - це функція traceroute, яка шукає великі часи відгуку в слідах і перевіряє, чи не працює система на відмову від апаратних засобів, DOS-атаки, неправильної класифікації QoS тощо. звичайно, вам потрібен доступ до всього обладнання на шляху. Мені було легко в ті часи, коли я працював у телекомунікації.

На якій операційній системі ви це тестуєте? Якщо це Windows, за замовчуванням встановлено службу "QoS Packet Scheduler" та прив'язано до мережного інтерфейсу. Це запускається залежно від базових налаштувань мережевого стеку та активно затримує будь-який трафік, який не класифікується як "мультимедіа".

Спробуйте видалити його з інтерфейсу та перевірте свої результати.

Або ще краще, переконфігуруйте його належним чином: http://www.dslreports.com/faq/3688

Додаю зі свого досвіду, що деякі провайдери розглядають пакет ICMP з найнижчим пріоритетом. Це сталося один раз, кожного разу, коли я запускаю youtube, навіть "запити вичерпані".

Опублікуйте winmtr перед початком відео та під час відтворення відео. Почніть другу трансляцію, і давайте подивимось, як це вплине як на пакети ICMP, так і на перше відео.

Якщо ви підключаєтесь через перемикач 10/100 і автономізуєте частину, у вас може виникнути невідповідність дуплексу. Це спричинить часті зіткнення, коли в мережі є навантаження, яка не з’явиться, коли справи відносно спокійні. Зіткнення спричинить повторне повторення, як і примушення комунікацій до перешкод, і може спричинити, здавалося б, необгрунтоване уповільнення.

Вибачте за відродження старої нитки. В ОП написано:

... Практично будь-який трафік через WAN призведе до затримки ...

Це точні симптоми Bufferbloat. Маршрутизатор, ймовірно, в черзі надто багато трафіку та голодує невеликими потоками (які необхідні для забезпечення чуйності)

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

Стан техніки просунувся з часів OP, тому шукайте Bufferbloat, AQM, CoDel, fq_codel, Cake, PIE або інші методи.