Кратко — чередование "Dup ACK" и "fast retransmission" типично для ситуации, когда получатель многократно подтверждает один и тот же ожидаемый сегмент (dup ACK), а отправитель после 3-х dup‑ACK делает fast retransmit. Это поведение может быть вызвано разными причинами: реальные потери сегментов, переупорядочивание пакетов, ошибки на канальном уровне, проблемы с MTU/фрагментацией/PMTUD, асимметричной маршрутизацией, проблемами железа/оффлоада и т.д. Ниже — развернутый план: какие возможные причины, как их диагностировать (инструменты/метрики/эксперименты), и какие меры исправления/оптимизации применять.

1) Возможные причины (с коротким объяснением)

Потери пакетов в сети (перегрузка очередей роутеров/коммутаторов — tail-drop, RED и т.п.). При потере сегмента получатель продолжает присылать dup ACK для последующих сегментов.Канальные битовые ошибки / радиопроблемы (CRC/FCS, wifi retries): честные потерии на линке.Переупорядочивание пакетов (reordering). Данные приходят в другом порядке — получатель присылает dup ACK, отправитель может неправильно истолковать это как потерю.Асимметричная маршрутизация / loss на обратном пути ACK'ов. ACKы и данные идут по разным путям — может быть потеря именно в одну сторону.MTU / фрагментация / PMTUD failure: большие TCP сегменты "через" путь с меньшим MTU, ICMP Fragmentation Needed блокируется, крупные сегменты теряются/блокируются.Средние устройства / middleboxes (NAT, LB, DPI, WAN‑оптимизаторы) — могут менять/блокировать сегменты, портировать/ребейзить, вызывать рерайт и reordering.NIC/драйвер/оффлоад артефакты (GSO/GRO/TSO): tcpdump на интерфейсе может показывать "повторные" пакеты из‑за offload. Или сетевые платы с багами.Конфигурация TCP на хосте: отсутствие/наличие SACK, параметры RTO/rtt и т.п.Проблемы на серверном приложении/стеке (сильная загрузка CPU, прерывания, IRQ‑affinity) — задержки в отправке ACK/обработке пакетов.

2) Как диагностировать — пошагово, инструменты и что смотреть
A. Сбор трафика

Делайте захват на обоих концах потока (клиент и сервер) и, если возможно, на «точках» по пути (TAP/span) — только так различите loss/duplicate на пути туда/обратно и асимметрию.tcpdump примеры:
sudo tcpdump -i eth0 -s 0 -w capture_eth0.pcap tcp and host A and host Bпри проблемах отключить offload для корректного отображения: sudo ethtool -K eth0 gro off gso off tso offАнализ в Wireshark: Follow TCP stream, смотреть Sequence/ACK, Duplicate ACK count, SACK blocks, TCP Options (SACK, Timestamps, MSS), Expert Info.

Что искать в pcap:

где именно происходят потери: видны ли сегменты на одной стороне и отсутствуют ли на другой;последовательность seq/ack, SACK blocks (они показывают какие байты уже получены), метки времени (TCP TS) — помогают отличить reordering от loss;размер повторных сегментов — равны ли MSS/типично large segment dropped (hint на MTU).

B. Системные и сетевые метрики

На хостах:
ss -s, ss -ti dst IP:port — показатели retransmits, rtt, cwnd, rto, number of dupacks в сокетеnetstat -s | grep -i tcp (Linux) — счетчики retrans, out-of-order, etc.cat /proc/net/tcp, tcp_info via getsockopt (snd_cwnd, rtt, reord)/proc/net/dev или ip -s link show — интерфейсные ошибки, dropped, fifo errors, carrierethtool -S eth0 — аппаратные счетчики (rx_errors, tx_errors, rx_crc_errors)dmesg — ошибки драйвера, link flapsНа сетевых устройствах: counters интерфейсов, queue drops, tail drops, policers, buffer high watermarks.RTT/jitter: смотреть rtt и rttvar в ss -ti и в pcap (TCP timestamp/RTT estimation).

C. Специальные тесты / эксперименты

Проверка MTU/PMTUD:
tracepath host (Linux) — показывает path MTU;ping -M do -s SIZE host — искать максим size без фрагментации, чтобы найти PMTU blackhole.На пути проверить, не блокируются ли ICMP type 3 code 4 (Fragmentation Needed).Если есть firewall — включить MSS clamping (example: iptables mangle --clamp-mss-to-pmtu)Проверка на пакетную потерю/переупорядочивание:
iperf3/iperf с вариантами: tcp и udp, разными window sizes и потоками (-P), посмотреть retransmits, jitter, packet loss.mtr (комбинированный traceroute+ping) — показать потери на пути hop‑by‑hop.Проверка асимметрии: захваты на обоих концах и сравнить видимость пакетов (если не совпадает — асимметрия).Проверка link layer: на коммутаторах/switch посмотреть CRC/FCS, interface resets; тест смены кабеля/порта/SFP, изменение скорости/duplex.Отключение/включение TCP опций:
Временно отключить GSO/GRO/TSO для исключения артефактов;Включить/выключить SACK, timestamps (для теста).Локализация middlebox: временно обходить firewall/NAT/LB, прямое соединение для сравнения.Нагрузочные тесты/моделирование: использовать tc/netem для создания искусственного loss/reorder и посмотреть поведение (для воссоздания проблемы).

3) Как отличить loss от reordering/артефактов

Если dup ACK'и идут без реального отсутствия сегментов на capture ближе к ресиверу — вероятно reordering или артефакт offload.SACK: если SACK показывает что "пропущенные" данные уже получены (SACK blocks покрывают их), это reordering.Если retransmit появляется и затем пришёл оригинал тоже — это spurious retransmit (признак reordering).Проверить tcpdump при выключенном offload — часто снимки меняют картину.

4) Какие меры по устранению и оптимизации (по причинам)
A. Потери из‑за перегрузки (конгестия)

Короткий список мер:
Увеличить полосу/пропускную способность канала или перераспределить трафик.Включить ECN (если поддерживается) и современные алгоритмы CC (BBR, CUBIC + pacing).Настроить AQM (CoDel, PIE) вместо глубоких буферов на пути (во избежание bufferbloat).Тонкая настройка TCP (initcwnd, window, rcv_buf, snd_buf) — но это вторично по отношению к устранению реальной перегрузки.Rate‑limit агрессивных потоков или QoS для приоритизации.

B. Битовые ошибки / канальные проблемы

Проверить/заменить кабели, SFP, порты; проверить качество радиосигнала и retries (для беспроводного).На линке включить/проверить FEC (если доступно), снизить скорость линка как временная мера.Исправить конфигурацию дуплекса/скорости (они должны совпадать).Обновить прошивки/драйверы NIC.

C. MTU / PMTUD

Включить или восстановить прохождение ICMP Fragmentation Needed; если это невозможно — настроить MSS clamp на граничных устройствах.Установить правильный MTU на интерфейсах, избегать фрагментации.Проверять, что не используются слишком большие сегменты (offload может собрать большие пакеты), и при необходимости ограничить GSO/TSO или MSS.

D. Ассиметричная маршрутизация / отказ ACK пути

Согласовать маршруты так, чтобы важные потоки были симметричными, или улучшить мониторинг обеих сторон.Захват трафика на обоих концах и анализ — единственный способ установить, где теряется/задерживается.Если невозможно выравнивание маршрутов — рассмотреть использование прокси/сопровождение сессий, которые гарантируют симметрию.

E. Middleboxes / Load balancers / NAT

Проверить и обновить конфигурацию middlebox, исключить модификацию TCP заголовков/разделение сегментов.При необходимости — bypass или обновить ПО/аппарат, включить/выключить функции оптимизации, которые ломают TCP.

F. Offload/драйверы/софт

Для диагностики и если артефакты — временно отключить GRO/GSO/TSO в ethtool.Обновить драйверы/прошивки NIC.Если проблемы из‑за offload при больших TPS — настроить capture/мониторинг корректно, но не оставлять offload выключенным в продакшне без причины.

G. TCP‑настройки и оптимизация

Включить SACK и timestamps (если не включены).Рассмотреть смену алгоритма управления перегрузкой на более подходящий (BBR для высокопараметричных сетей с потерями? — но тестировать).Enable pacing в стеке (уменьшает burstiness).Для долгих каналов — увеличить snd/rcv buffers и window scaling.

5) Практический порядок действий (рекомендации)

Собрать pcap на обеих сторонах, выключив offloads для корректности (ethtool -K ...).Проанализировать pcap в Wireshark: какие сегменты теряются, SACK, timestamps, seq/ack gap.Сравнить интерфейсные/коммутаторные/маршрутизаторные счетчики (errors, drops, retries).Провести MTU/ping tests и traceroute/tracepath.Сделать целенаправленные тесты iperf3 (tcp/udp), mtr, эмуляции netem (reorder/loss) для воспроизведения.На основании результата — применять соответствующие исправления (сначала физический канал и MTU/ICMP, затем конфигурации сетевых устройств, затем TCP/поведение приложений).После изменений — снова захват и сравнение до/после.

6) Полезные команды (Linux)

Захват: sudo tcpdump -i eth0 -s 0 -w cap.pcap host A and host BОтключение offloads: sudo ethtool -K eth0 gro off gso off tso offИнтерфейс/счётчики: ip -s link show eth0; ethtool -S eth0TCP статистика: netstat -s | grep -i tcp; ss -s; ss -ti dst IP:PORTMTU/ping: ping -M do -s 1472 host; tracepath hostНагрузочное тестирование: iperf3 -c server -P 10 -w 1MОчереди qdisc: tc -s qdisc show dev eth0Просмотр tcp_info (пример на python/C) или ss -m для подробностей.

7) Небольшие практические подсказки

Если в pcap видите, что после retransmit приходит оригинальный сегмент — велика вероятность reordering; если оригинальный сегмент вовсе не появляется — реальный loss на пути.Если при захвате на хосте видите много "retransmission" но на wire (TAP) нет — вероятно offload‑артефакт.Обязательно смотреть SACK: включённый SACK гораздо упрощает recovery при потере нескольких сегментов.В продакшне избегайте «лечения симптомов» (увеличение RTO/cwnd) — лучше искать и устранять корень (phys link, MTU, congestion).

Если хотите, могу:

разобрать один конкретный pcap (пришлите) и показать, где именно теряются пакеты и какие шаги применить;подготовить чек‑лист для пошаговой проверки в вашей инфраструктуре.