Чрезмерное количество «TCP Dup ACK» и «TCP Fast Retransmission» вызывает проблемы в сети. Что вызывает это?

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

Прокрутив немного вниз после открытия этого файла в Wireshark, мы увидим несколько кадров другого цвета. Выглядит очень плохо, правда? Что ж, не все так плохо. Постой, мы туда доберемся.

Проверяя пакет SYN (кадр 37), мы видим SACK и масштабирование окна в параметрах TCP. Хорошо. То же самое в масштабировании SYN / ACK (кадр 38), SACK и Windows. Потрясающие. Не вижу ничего странного в отношении SACK.

Оценка незагруженного RTT - это время между SYN-пакетом и первым ACK (кадр 39). Это примерно 9,3 мс, что соответствует вашим результатам. Обратите внимание, что время между SYN / ACK и ACK (кадры 38 и 39) намного меньше, чем между SYN и SYN / ACK (37 и 38). Это означает, что этот файл захвата принимается в приемнике, и чтобы понять, почему это не идеально, нам придется вернуться в школу.

Между отправителем и получателем есть одна часть сетевого пути, которая является наименьшей, что ограничивает пропускную способность. Оценка RTT, которую мы только что получили из рукопожатия, дает нам оценку длины этого сетевого пути. Мера того, сколько пакетов мы можем поместить в эту трубу, - это Пропускная способность трубы или произведение на задержку полосы пропускания - PC [биты] = R [бит / с] * RTT [с], где R - наименьшая полоса пропускания. Пропускная способность трубы тогда является мерой объема.

Представьте себе садовый шланг. Его объем измеряется одинаково по его длине и ширине, верно? Чтобы извлечь из него как можно больше воды, его нужно полностью заполнить водой, иначе возникнут воздушные прослойки, ограничивающие поток воды. Если нам удастся заполнить его полностью, он может переполниться. Мы можем использовать ведро, чтобы не намочить пол, и если ведро переполнится, это не повлияет на поток воды.

Оказывается, в сетевом пути точно так же. Нам нужно заполнить трубу ... Другими словами, емкость трубы - это наименьшие байты в полете (сколько воды у нас в трубе + ведро) между отправителем и получателем, который полностью использует наименьшую пропускную способность (не вызывает воздушные зазоры). Так что если байты в полете> ПК, тогда все хорошо!

Глядя на трассировку TCP Статистика -> TCP StreamGraph -> График временной последовательности (tcptrace) мы можем видеть байты по оси Y и время по оси X. Производная этой кривой - байты в секунду или пропускная способность. Обратите внимание на ровную черную «линию», что означает стабильную пропускную способность! Пару раз он прерывается синими линиями (это диапазоны SACK в дублированных ACK), но, как можно видеть, это не влияет на пропускную способность.

Видите, как нижняя правая серая сплошная линия (немного увеличьте масштаб, это ACK) действительно близка к черным сегментам TCP? Время между сегментом TCP и ACK - это RTT, здесь почти 0! Это означает, что через эту точку захвата не так много сегментов в полете. Это, в свою очередь, означает, что мы не можем использовать это для оценки байтов в полете, и поэтому захват пакетов на стороне отправителя намного лучше.

Пакеты здесь естественно теряются до точки захвата. Каждый сегмент данных, который находился в передаче на момент потери, запускает дублирующий ACK. Поэтому мы можем использовать количество повторяющихся ACK, чтобы оценить количество байтов в полете на момент потери пакета. Здесь мы видим примерно 9, 16 и 23 сегмента. Каждый сегмент содержит 1448 байтов данных, так что это дает нам количество байтов от 13 до 33 КБ. Пропускная способность здесь была около 3 Мбит / с (с График ввода-вывода) и с помощью RTT, которое мы измерили до того, как мы получим пропускную способность канала менее 3e6 [бит / с] * 10e-3 [с] / 8 байтов = 3750 байтов, или менее 3 сегментов.

Поскольку байты в полете во время этих потерь на самом деле не совпадают (трудно сказать здесь с таким небольшим количеством выборок), я не могу точно сказать, являются ли они случайными потерями (которые плохо плохи плохими) или потерями, возникающими из-за очереди / bucket переполняется, но они возникают, когда байты в пути> ПК, поэтому пропускная способность не влияет.

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

Только сейчас выкладываю то, что узнала. Провайдер MetroEthernet приехал в наш главный офис в одну субботу. Отключили там сеть, а еще кто-то был в филиале поблизости. Они подключили оборудование для тестирования сети на обоих концах и быстро смогли определить, действительно ли проблема. Через несколько часов им удалось изолировать проблему. Это была проблема с медными линиями от центрального офиса провайдера до нашего главного офиса. Они сказали, что кадры падали как сумасшедшие, что и было причиной повторных передач. Они исправили проблему с медным проводом в своем центральном офисе (они сказали, что им приходилось разъединять каждый провод по одному. Для меня это звучит как чушь), но после того, как они сделали это в своем центральном офисе, проблема была решена.

Глядя на предоставленный вами захват (спасибо за это!), Я вижу довольно классический образец ретрансляции ближе к началу. Вы можете увидеть это вокруг пакета 50. Отсутствует пакет между 51 и 52. Что происходит:

1. -> Пакет 50 данных
2. <- Пакет 51 ACK пакет 50.
3. -> Пакет 52 данных
4. <- Пакет 53 ACK пакет 50.
5. -> Пакет 54 данных
6. <- Пакет 55 ACK пакет 50.

Пакет данных был отброшен, и получатель указывает на это, продолжая подтверждать пакет до того, что он видел до сих пор. Интересно то, что обе стороны TCP SACK Permitted Option = True устанавливается при согласовании соединения, поэтому в пакете 55 должен быть заголовок SACK, а его нет. Селективные подтверждения позволяют получателю указать: «Я видел все до 51, но также и от 53 до 55», что уменьшает количество повторных передач, необходимых для восстановления полной скорости.

Что происходит, поскольку он не может использовать SACK, так это то, что он возвращается к стандартному методу повторной передачи TCP, повторяя «я видел до 50», пока другая сторона не выяснит это и повторно не передаст все 50 и позже.

В пакете 66 есть повторная передача, за которой сразу следует ACK до пакета 56. После второй повторной передачи (пакет 72) соединение снова на ходу.

Во-первых, похоже, что заголовки SACK удаляются звуковыми стенками, что препятствует восстановлению повторных передач с той же скоростью, с какой они согласовывались. Лично я считаю, что удаление SACK бессмысленно, но другие могут не согласиться.

Из того, что я могу сказать по этому снимку, вы наблюдаете случайную потерю пакетов, из-за которой TCP-соединения проходят через обычные протоколы повторной передачи. Межсетевые экраны мешают, поскольку метод повторной передачи, о котором договорились обе стороны, не допускается.