uTorrent змушує DNS періодично припиняти роботу

Під час використання uTorrent DNS періодично припиняє реагувати.

Здається, проблема не пов’язана із занадто великим використанням пропускної здатності (як це видно з маршрутизатора на комп'ютер), але може бути пов'язана з деякою формою захисту від повені, яку надає маршрутизатор (більше вхідних з'єднань з маршрутизатором, ніж приймає Windows).

Як змусити мережу працювати належним чином (звичайно, поки все ще можна використовувати uTorrent)?

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

Відкрийте підключення

Коли завантажується uTorrent, а завантаження / завантаження призупинено (не припиняється), він підтримує відкриті зв'язки з вашими колегами. Тим часом легіони Інтернет-ровесників все ще намагатимуться зв’язатися з вами, щоб дізнатися, чи є у вас потрібні біти.

Зрештою ви досягнете ліміту відкритого підключення, накладеного вашою ОС (в Windows 7 це 10 підключень), і з'єднання нових клієнтів почнуть чергувати на вашому маршрутизаторі.

Клієнти в черзі будуть агресивно перевіряти, чи є з'єднання вільним. Це агресивне опитування може трактуватися маршрутизатором як атака синхронного потопу.

Рішення

• опустіть свій напіввідкритий ліміт підключення у вашому програмному забезпеченні bittorent нижче межі з'єднання, встановленої вашою ОС
• відключити захист від повені IP на маршрутизаторі / модемі.

Насичення пропускної здатності

Крім того, якщо з’єднання uTorrent (або будь-який масовий трафік) працює без обмежень, труба завантаження (і, можливо, завантаження) досягає повного використання, змушуючи деякий "утримувати" трафік на заднє місце, що призводить до зменшення корисності мережі.

Ось приклад:

1. Високошвидкісне завантаження (торрент або іншим чином) насичує низхідне посилання.
2. Користувач намагається перейти на недавно відвідуваний сайт. Комп'ютер генерує запит на інформацію про DNS для потрібного сайту. "Завантаження" запиту на сервер DNS успішно (не оскаржується для доступу до потокової труби).
3. DNS-сервер реагує (або намагається), але відповідь затримується на спробі потрапити на машину користувача, оскільки труба завантаження насичена вмістом для завантаження, а оскільки щось потрібно скинути, а завантаження агресивно ставиться до підтримки швидкості, Відповідь DNS падає (в певний момент, перш ніж потрапити на локальний маршрутизатор).

Те ж саме може статися, якщо завантаження не обмежується. З насиченим завантаженням пакети, відомі як TCP-ACK (які надсилаються як відповіді типу "Ей, я успішно отримав пакет xyz"), зависають, тому завантаження переривається на зупинку, внаслідок чого веб-перегляд стає дуже нескінченним.

Рішення

• З’ясуйте, які максимальні можливості вашого з'єднання (вгору та вниз, окремо), і встановіть максимальну швидкість своїх клієнтів масового перекладу не використовувати більше 80% цієї швидкості. Це дозволить залишити простір для таких речей, як пакети DNS та TCP-ACK, щоб обійти основний трафік і швидко вирішити його.
• Використовуйте маршрутизатор, який може керувати формуванням трафіку таким чином, щоб певний трафік (DNS, IMCP Ping, TCP-ACK) мав пріоритет перед іншими формами трафіку, а деякі форми трафіку (зокрема торент) можуть бути визначені пріоритетними. Це мій кращий метод. Це може дати додаткову перевагу, що дозволить повноцінній трубі використовуватись для поточного потоку, коли трафік більш високого пріоритету не викликає цього.
• Використовуйте деяку комбінацію 1 і 2, щоб стримувати «недобре поведінку» трафіку.

Якщо вас цікавить додаткова інформація про формування трафіку дистрибутивів Linux / BSD, MonoWall та IPCop мають хорошу інформацію.

Коли у мене є щось подібне, Wireshark - мій найкращий друг.

Але спочатку добре усвідомити ці три речі:

• Те, що ping працює, не означає, що DNS (або будь-яка інша служба) працює, а навпаки.

  Це тому, що ping використовує абсолютно інший протокол (ICMP, тоді як DNS використовує IP та комбінацію UDP і TCP) на абсолютно іншому рівні мережевої моделі. Що завгодно, від вашого особистого брандмауера через кількість маршрутизаторів до фактичного хоста, на якому працює служба, потенційно може бути налаштовано викинути один з них, а не інший (будь то параноя адміністратора чи якийсь випадок відмови), хоча зазвичай це трапляється з ICMP, ніж з іншими

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

  Ну, конкретна програма, яку ви використовуєте, повинна зробити це зрозумілою для вас, але, як правило, її легше побачити в GUI Wireshark :)

• Як я вже згадував, DNS зазвичай використовує UDP як спосіб доставки вмісту запиту та відповіді.

  На відміну від брата TCP, UDP визначається таким чином, що немає гарантії того, що пакет буде доставлений взагалі, і немає нічого, що маршрутизатор повинен (і не може) зробити, щоб повідомити про помилку. (Це жертва для іншої функції UDP: це неймовірно швидко. Маршрутизаторам не потрібно зберігати інформацію про відправника та замовлення пакетів, вони просто швидко передають її та забувають. Вони навіть цілком безпечно можуть дати їм більший пріоритет, ніж TCP.)

Зазвичай перше, що я зробив би:

1. Почніть Wireshark
2. Клацніть Параметри зйомки
3. Для фільтра "Захоплення" встановіть, host 1.2.3.4щоб ви переховували лише трафік між вами та 1.2.3.4
4. Почніть захоплення
5. Після того, як ви все запустили таким чином, спробуйте свої команди

Однак, виходячи з останнього оновлення: я не знаю цього програмного забезпечення, але я точно підозрюю клієнта uTorrent. Додаток може надсилати занадто багато UDP, що, наприклад, досягнуто певного обмеження на вашому домашньому маршрутизаторі, і воно починає викидати пакети UDP.

Я б спробував інструмент DNS Benchmark від GRC . Він тестує DNS-сервери, які ви налаштовані для використання, а також безліч інших DNS-серверів. Це не тільки тестує їх швидкість, але і їх надійність. Він безкоштовний і його не потрібно встановлювати (хоча це тільки Windows). На цій сторінці також багато хорошої інформації про DNS.

Мені хотілося б знати, в якій частині світу ви перебуваєте, і це допомогло б отримати результат tracert / traceroute для google.com та для 8.8.8.8.

Можливу проблему може спричинити або ваш маршрутизатор, або ваш зв’язок із серверами Google. Переривчастий характер вашої проблеми має запах поганого зв’язку, але при аналізі проблем з підключенням до Інтернету просто занадто багато факторів, щоб дати вам негайну відповідь.

Мережа Google може періодично перевантажуватись. У мене є щоденні випадки, коли запит на google.com закінчується та потребує перезавантаження, і я використовую його локальний сервер для своєї країни. Частково питання удачі до того, до якого сегмента мережі Google спрямовується запит, і навіть можуть бути неефективні внутрішні алгоритми розподілу запитів Google.

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

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

Не кажучи вже про будь-які «оптимізації» або можливі недоліки вашого провайдера або будь-які оптимізації, які Google, можливо, зробила, щоб розділити тягар у всьому світі на своїх серверах.

Використання далекого DNS-сервера може накладати штрафи іншими способами. Подивитися :

Чому використання DNS / OpenDNS Google є поганою ідеєю?
Чи слід використовувати DNS мого провайдера або 8.8.8.8 Google?

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

Як я вже згадував у додатку до питання, uTorrent був пов'язаний з проблемою, оскільки закриття uTorrent вирішило проблему. Я вирішив з'ясувати, як це виправити без необхідності закривати uTorrent. У цій темі і в цій (це було дуже актуально, тому що там люди мають однаковий провайдер і маршрутизатор), я знайшов пропозиції про те, що мені слід відключити захист від повені IP на моєму маршрутизаторі, і це зробило трюк! Проблема та рішення були екзотичними, можливо, специфічними для маршрутизатора Cisco EPC3925 або навіть для певного провайдера (популярний в Європі, тому важко було гугнути щось англійською).