Чрезмерный 'Дубликат TCP ACK' и 'TCP Быстрая Повторная передача' порождение проблем о сети. Что вызывает это?

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

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

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

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

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

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

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

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

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

I realize that this answer is simplified, and not as explicit as I'd like it to be, so if you have questions about a step, please ask!

Scrolling down a bit after opening this file in Wireshark we see some frames in different color. Looks really bad, right? Well, it's not that bad. Hold on, we'll get there.

Checking the SYN packet (frame 37) we see SACK and Window Scaling in the TCP Options. Good. Same thing in in the SYN/ACK (frame 38), SACK and Windows scaling. Awesome. Don't see anything weird regarding SACK.

An estimate of the unloaded RTT is the time between the SYN packet and the first ACK (frame 39). It's about 9.3 ms, which matches your findings. Note that the time between SYN/ACK and ACK (frames 38 and 39) is much lower than between SYN and SYN/ACK (37 and 38). This means that this capture file is taken at the receiver, and to see why that's not ideal, we'll have to go back to school.

Between the sender and the receiver there is one part of the network path that is the smallest, which limits the bandwidth. The RTT estimate we just got from the handshake gives us an estimate of the length of this network path. A measurement of how many packets we can fit in this pipe is the Pipe Capacity or the Bandwidth Delay Product - PC [bits] = R [bits/s] * RTT [s], where R is the smallest bandwidth. Pipe Capacity is then a measurement of volume.

Imagine a garden hose. Its volume is measured is defined by its length and its width in the same way right? To get the most water out of it, it needs to be completely filled with water, otherwise there will be air gaps limiting the water flow. In case we manage to fill it completely, it might overflow. We can use a bucket so that we won't get the floor wet, and if the bucket overflows that doesn't affect the water flow.

Turns out that it's exactly the same in the network path. We need to fill the pipe... In other words, Pipe Capacity is the smallest bytes in flight (how much water we have in the pipe + bucket) between the sender and the receiver that fully utilizes the smallest bandwidth (doesn't cause air gaps). So if the bytes in flight > PC then we're good!

Looking at the TCP trace Statistics -> TCP StreamGraph -> Time Sequence Graph (tcptrace) we can see bytes on the Y-axis, and time on the X-axis. The derivative of this curve is bytes/second, or throughput. Note how the black "line" is flat, meaning throughput is stable! It's interrupted by blue lines a couple of times though (those are the SACK ranges in the duplicate ACKs), but as can be seen it does not affect throughput.

See how the lower right gray solid line (zoom in a bit, that's the ACKs) is really close to the black TCP segments? The time between the TCP segment and the ACK is the RTT, here's it's almost 0! It means that there are not many segments in flight passed this capture point. This in turns means that we can't use that to estimate the bytes in flight, and this is why a sender side packet capture is way better.

Packets here are naturally lost before the capture point. Each data segment that was in flight at the time of the loss triggers a duplicate ACK. Therefore we can use the number of duplicate ACKs to estimate the bytes in flight at the time of the packet loss. Here we see about 9, 16 and 23 segments. Each segment has 1448 bytes of data, so that's gives us a bytes in flight between 13k and 33k. The throughput here was about than 3 Mbit/s (from IO graph) and with the RTT we measured before we get a Pipe Capacity less than 3e6 [bits/s] * 10e-3 [s] / 8 bytes = 3750 bytes, or less than 3 segments.

Because the bytes in flight at the time of these losses are not really the same (hard to tell here with so few samples) I can't really say if these are random losses (that are bad bad bad) or losses occurring because a queue/bucket overflows, but they are occurring when bytes in flight > PC so throughput is not affected.

Your answer seems to indicate that they were indeed random, but not so many to cause low throughput.