Краткий разбор причин и план действий.
Причины низкой TCP-пропускной способности (кратко)
- Высокий RTT → TCP долгое окно роста, низкая заполненность канала (BDP ограничивает). Формула: $\text{BDP}=\text{bandwidth}\times \text{RTT}$. Пример: для $\text{bandwidth}=100\text{Mbps}$ и $\text{RTT}=0.1\text{s}$ $\Rightarrow \text{BDP}=100\times 10^6\times 0.1=10^7\text{bits}\approx 1.25\times 10^6\text{bytes}$.
- Фрагментация/MTU mismatch и сломанная PMTUD → большие TCP-сегменты теряются/не доставляются, повторные передачи, «black hole» (когда ICMP unreachable блокируется).
- Неправильный MSS → TCP сегменты превышают реальный MTU: $\text{MSS}=\text{MTU}-20(\text{IP})-20(\text{TCP})$. Для $\text{MTU}=1500$ $\Rightarrow \text{MSS}=1500-20-20=1460$.
- Потери/перегруз на граничном маршрутизаторе (tail-drop, переполненные очереди, ACL/фильтрация ICMP).
- Неподходящие TCP-параметры (без window scaling, без SACK), неэффективный алгоритм управления перегрузкой.
- QoS/приоритизация мешает real-time, буферизация увеличивает задержку и джиттер.
Последовательность тестов (порядок, что смотреть)
1) Проверка задержки и PMTUD
- ping до локального шлюза и до удалённого хоста: `ping `; для MTU/DF-тестов:
- `ping -M do -s $1472$ ` (выполняет DF с полезной нагрузкой $1472$ байт — для MTU $1500$\).
- уменьшать размер до тех пор, пока не проходит, чтобы найти path MTU.
- Что смотреть: успешные/ошибочные ответы ICMP type 3 code 4, латентность, вариацию RTT.
2) Маршрутизация и локализация потерь
- traceroute / mtr (tcp/udp варианты): `traceroute -T ` или `mtr -T `
- Что смотреть: где растёт RTT, где появляются потери/высокие задержки.
3) Пропускная способность и поведение TCP/UDP
- iperf3:
- TCP: `iperf3 -c -P 1 -t $30$`
- UDP: `iperf3 -c -u -b 100M -t $30$`
- варьировать TCP window: `iperf3 -c -w 1M`
- Что смотреть: реальные Mbps, количество потерянных UDP-пакетов, TCP retransmits, влияние window на пропускную способность.
4) Сниффинг/логирование на границе
- tcpdump/tshark на входящем/исходящем интерфейсе, фильтры на фрагментацию, ICMP unreachable, TCP retransmits:
- `tcpdump -i eth0 'icmp or tcp' -w capture.pcap`
- Анализ: есть ли ICMP type 3 code 4, есть ли фрагменты, MSS в SYN, повторные передачи, dup ACKs, RST.
5) Проверка счётчиков устройств
- show interface counters, drops, queue drops, NPUs; системные логи ACL/conntrack/iptables drops.
Методы исправления (практически, в порядке применения)
1) Восстановить PMTUD/ICMP или компенсировать
- Разрешить ICMP Type 3 Code 4 через FW/ACL между сетями.
- Если ICMP фильтруется/невозможно менять — включить MSS-clamping на граничном NAT/Firewall:
- на iptables: `--clamp-mss-to-pmtu` (примерно: `iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu`).
- Альтернатива: снизить MTU на туннельных/интерфейсных концах до реального PF MTU.
2) Избежать фрагментации
- Установить корректный MTU на интерфейсах/туннелях; убедиться, что DF/PMTUD работают.
- На IPv6 PMTUD обязательна — проверить ICMPv6 blocking.
3) TCP tuning
- Включить window scaling и SACK (обычно по умолчанию):
- sysctl: `net.ipv4.tcp_window_scaling=1`, `net.ipv4.tcp_sack=1`
- Увеличить буферы: `net.ipv4.tcp_rmem` и `tcp_wmem` — пример параметров: `tcp_rmem = $4096$ $87380$ $6291456$` (старт/деф/макс).
- Использовать современные алгоритмы: CUBIC или BBR (в зависимости от ОС/ядра).
4) QoS и управление очередями
- На граничных интерфейсах применять shape/queue discipline: fq_codel/fq, HTB + fq_codel, приоритет для real-time.
- Избежать tail-drop на критичных очередях — использовать AQM (fq_codel) для уменьшения задержки.
5) Ограничение MSS и NAT/NAT64/translation-aware настройки
- MSS-clamp при NAT; при NAT44/NAT64 учесть дополнительные заголовки и уменьшить MSS ещё на размер инкапсуляции.
6) Инфраструктурные правки
- Исправить перегруженные линейки, шардирование трафика, балансировка, апгрейд буферов/CPU на маршрутизаторе если drops на уровне HW.
- Логи/мониторинг: включить SNMP, sFlow, экспорт метрик очередей и drops.
Влияние на приложения реального времени (VoIP, WebRTC, видео)
- Задержка (RTT) и джиттер: ухудшают качество речи/видео, увеличивают буферизацию; интерактивность падает.
- Потери: UDP-пакеты теряются без повторной передачи → потеря речи/артефакты видео; TCP переносит потерю ценой задержек и буферизации (не подходит для real-time).
- Фрагментация/PMTUD-failure: большие RTP-пакеты фрагментируются и теряются → существенно ухудшение качества.
- Митигирование для real-time:
- Приоритизация RTP/SRTP пакетов (QoS DSCP, QoS на WAN).
- FEC/PLC, адаптивный битрейт кодека, jitter-buffer tuning.
- Использование UDP+FEC/ retransmit-less design; уменьшение MTU или MSS чтобы избежать фрагментации.
Короткий план действий для инженера (пошагово)
1) ping DF MTU-тесты до проблемного хоста и до следующего хопа.
2) traceroute/mtr для локализации хопа с проблемой.
3) iperf3 TCP/UDP тесты с и без изменения window/MSS.
4) tcpdump на границах — искать ICMP unreachable, фрагменты, retransmits.
5) исправить: открыть ICMP, включить MSS-clamp или снизить MTU, включить window scaling/увеличить tcp буферы, настроить QoS/AQM.
6) ретестировать (iperf + реальное приложение) и мониторить.
Если нужно — могу прислать конкретные команды/скрипты для диагностики и примерные sysctl-значения для Linux.