Краткий анализ по уровням TCP/IP и практические меры (что менять в приложении и на сервере) для мобильного приложения, теряющего пакеты в беспроводной сети с высокой задержкой.
Физический / Канальный уровень
- Что влияет: радиошум, адаптивная скорость, повторные передачи на канале (link-layer ARQ), фрагментация/агрегация (802.11 A-MPDU), RTS/CTS.
- Что можно сделать: использовать надежную Wi‑Fi конфигурацию (агрегацию включена, разумные retry limits), на стороне сервера — нет прямого контроля; в приложении — уменьшать чувствительность к кратковременным сбоям (буферизация, повторные попытки с экспоненциальной задержкой), использовать FEC на прикладном уровне для критичных данных.
Сетевой уровень (IP)
- Что влияет: MTU/фрагментация, маршрутизация, QoS (DiffServ), ECN.
- Рекомендации: избегать фрагментации (правильный MSS/PMTUD), помечать приоритет трафика (DSCP) если сеть поддерживает, включить ECN на сервере и в стеке ОС (если клиент/сеть поддерживают) для сигнализации перегрузки без потерь.
Транспортный уровень (TCP/UDP/QUIC)
- Ключевая формула для TCP‑throughput при потерях:
$$\text{Throughput}\approx C\cdot \frac{\text{MSS}}{RTT\sqrt{p}}$$ где $p$ — вероятность потери, $C$ — константа (≈1.22 для Reno).
- BDP (для размер буферов):
$$\text{BDP}=\text{bandwidth}\times RTT$$ Буферы должны быть ≳ BDP.
- Что можно включить/настроить на сервере / в стеке ОС:
- Включить SACK, window scaling, timestamps, ECN: $tcp\_sack=1$, $tcp\_window\_scaling=1$.
- Подобрать/сменить алгоритм управления перегрузкой: TCP Westwood/Westwood+ (лучше в беспроводных сетях), или BBR (если потери не означают снижение пропускной способности канала).
- Увеличить размер сокетных буферов (net.ipv4.tcp_{r,w}mem) до ≳ BDP.
- Настроить initial congestion window (IW) и уменьшить агрессивное снижение cwnd при ложных потерях (только по необходимости).
- Включить TCP Fast Open, TLS с resume, keepalive для уменьшения затрат на установку соединений.
- Включить пакетную обработку/оффлоадинг (GRO/GSO/TSO) на сервере для повышения пропускной способности.
- Что менять в приложении:
- Рассмотреть переход от TCP к QUIC (UDP+TLS+полный контроль над потерями/мультиплексированием) — часто лучше в высоко‑латентных/потеряных средах.
- Реализовать application-level ACK/RETRY и FEC (Reed‑Solomon или Raptor) для потокового/критичного контента.
- Мультиплексировать логические потокы поверх одного соединения (уменьшает влияние head‑of‑line).
- Использовать адаптивную отправку/битрейт (ABR) и экспоненциальную политику повторных попыток.
- Уменьшать размер пакетов/сообщений при небольшой полезной нагрузке, отключить Nagle (TCP_NODELAY) только если это действительно нужно для интерактивности.
Прикладной уровень
- Что изменить в приложении:
- Кеширование, предзагрузка и локальное восстановление (retry из кэша).
- Механизмы деградации качества (adaptive bitrate, progressive fetch).
- Пакетирование/репликация критичных сообщений, idempotent операции, видимые пользователю прогресс‑индикаторы.
- Использовать CDN/edge‑серверы, чтобы сократить RTT и вероятность потерь по «последней миле».
Операционные рекомендации и мониторинг
- Собирать метрики: RTT, RTO, retransmits, duplicate ACKs, cwnd, rcv_wnd, p99 latency.
- Тестировать разные CC (CUBIC/WESTWOOD/BBR) и протоколы (TCP vs QUIC) в реальных сценариях.
- Размеры буферов выставлять по формуле BDP; пример: если канал $2\text{Mbps}$ и $RTT=200\text{ms}$, то
$$\text{BDP}=2\text{Mb/s}\times 0.2\text{s}=0.4\text{Mb}=50\text{kB}.$$ - По возможности перенести логику и данные ближе к мобильному пользователю (edge/CDN) и минимизировать число RTT‑зависимых кругов (handshakes).
Короткое резюме
- Наилучшие эффекты дают: переход на QUIC (или оптимизированный TCP с SACK+window scaling), правильный размер буферов по BDP, использование CC, FEC/приложенческие ретра‑менты и CDN/edge.
- Физический/канальный слой решает многое, но сервер/приложение должны быть устойчивы к потерям: адаптивность, мультиплексирование, уменьшение числа RTT и локальные восстановители.
Если нужно, могу предложить конкретные параметры ядра Linux и пример настроек для сервера или пример архитектуры приложения с QUIC + FEC.