Що викликає повторювані записи ACK?

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

Вони показані на наступному знімку екрана. .26 - клієнт, а .252 - сервер.

Що викликає повторювані записи ACK?

Більше інформації, якщо це допомагає:

Ми досліджуємо проблеми з пропускною здатністю мережі на одному конкретному сайті клієнта. Проблема, сприйнята з точки зору користувальницького інтерфейсу, полягає в тому, що дані передаються повільно, незважаючи на недостатнє використання WAN-з'єднання 1 Гбіт / с.

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

Ми спробували змінити налаштування TcpMaxDupAcks на сервері, але значення, яке нам дійсно потрібно, становить 5, а допустимий діапазон - лише 1-3.

Сервер - це Windows Server 2003. Клієнтами є всі ОС Windows XP, якими керує підприємство. На всіх клієнтах, включаючи двох працюючих, встановлено антивірус Symantec.

Це єдиний клієнтський сайт із сотні, який виявив цю проблему.

pathping показує 56 мс RTT та послідовну втрату пакетів 0/100 навіть із проблемних машин.

Спасибі,

Сем

Примітка. Я припускаю, що це захоплення зроблено на клієнтській машині.

Короткий підсумок послідовності TCP: TCP надійно забезпечує потоки байтів між двома програмами. "Надійно" в цьому випадку означає, що, крім іншого, TCP гарантує, що ніколи не доставлятимуть дані з порядку в програму прослуховування.

На замовлення надійна доставка здійснюється за допомогою використання порядкових номерів. Кожному пакету в кожному потоці присвоюється 32-бітний послідовний номер (пам'ятайте, що TCP фактично є двома незалежними потоками даних, A-> B і B-> A). Якщо A посилає ACK B, значення в полі ACK є наступним порядковим номером A, яке очікується побачити від B.

З вищесказаного виходить, що принаймні один сегмент TCP, що надсилається з сервера клієнту, був втрачений. Три повторювані ACK послідовно є спробою клієнта викликати швидку повторну передачу . Коли відправник TCP отримує 3 дублікати підтвердження для одного і того ж фрагмента даних (тобто 4 ACK для того самого сегмента, який не є самим недавно надісланим фрагментом даних), можна обгрунтовано припустити, що сегмент одразу після того, як сегмент ACKed був втрачений в мережі та призводить до негайної повторної передачі.

У цьому випадку повторна передача проходить через Wireshark і ідентифікується як позачергова.

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

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

Яке WAN-з'єднання використовується тут? Це виділений рядок? MPLS VPN-посилання? IPsec VPN через загальнодоступний Інтернет? Щось ще?

Поки ви ізолюєте проблему, подумайте про відвал пакету як про один із симптомів ... Як аналогія, якщо хтось заходить до кабінету лікаря з болями в грудях, лікар не витратить три години на дослідження природи біль. Він витрачає на це близько двох хвилин, а потім знає, що 95% причин - це печія або стенокардія ... Таким же чином, якщо ви побачите дублікати АКК, не одразу щурячись на бур’янах сліду. .

Після встановлення з'єднання повільна продуктивність TCP не завжди виникає через проблеми з транзитною мережею; іноді це відбувається як результат обмеження процесорного сервера або диска ... а іноді через певну проблему на клієнтському ПК. Я тижнями переслідував свій хвіст, копаючись у бур'янах слідів проводів, лише щоб здатись та знайти проблему порівняно швидко з mtr , або переглянувши інші показники хоста, такі як процесор і диск вводу / виводу.

Ваше перше завдання - довести, чи це проблема в мережі або на рівні хоста. Сфокусуйтесь на надсиланні реального трафіку через вашу мережу та доведіть, чи ви в черзі / втраті / перезамовленні ^{Примітки 1} це; що завжди є підсумком для такої потенційної мережі .

Я б робив pingвибірку протягом тривалого періоду часу (зазвичай для мене годину) між клієнтом і сервером, поки виникає проблема пропускної здатності; ви можете використовувати mtr або ping плотер безкоштовно для цього. Якщо ви послідовно втрачаєте пакети на якомусь хопі, а всі хмелі згодом втрачаєте стільки чи більше , то у вас є потенційний підозрюваний у мережі. Майте на увазі, що обмеження швидкості ICMP на пристрої може спричинити появу деяких хмелів, що вони втрачають пакети ... саме тому ви хочете шукати тенденцію, починаючи з цього переходу, і тих, що передують нижче.

^{Примітка 1.} Якщо ви замовляєте трафік, він відображатиметься досить швидко в інформаційному полі для експертів, яке надає проводка

Бачачи безліч [сегмент TCP перекомпонованого PDU] без ACK, я б сказав, що ці ACK, ймовірно, відображаються як [TCP Dup ACK ...] через поведінку селективного підтвердження (він же SACK) .

Приклад:

• клієнт надсилає частини даних (..., 0,1,2,3,4,5,6, ...)

• сервер атакований (0), потім отримував (2,4,3), потім (5), потім (6) і ніколи не отримував (1)

У наведеному вище сценарії - сервер може законно вибрати спочатку діапазон (2-4), потім (2-5), потім (2-6). Формуючи пакет "(AB) діапазон ack", сервер повинен вказати останню анкетну частину (0) у заголовку TCP. Wireshark позначає діапазон-acks (SACK) як [TCP Dup ACK ...], оскільки всі ці діапазони-аки мають однакове значення останньої частини в заголовку TCP (Ack = 872619 у вашому випадку).

Дублювання ACK у поєднанні з повільною продуктивністю мережі для мене звучить як проблема перевантаженості мережі. Подивіться на об'єм та швидкість трансляції в мережі. Не забудьте подивитися на трансляції фізичного рівня та мережевого рівня, а також на багатоадресні повідомлення.