Краткий итог-рекомендация
- Использовать QUIC (UDP‑на основе) / WebTransport в браузерах как основной транспорт: сочетание надёжного и ненадёжного каналов, быстрая установлата соединения, миграция при смене сети. TCP/WebSocket — проще, но страдает head‑of‑line и хуже в мобильных сетях с высокой потерей пакетов.

Почему QUIC/UDP вместо TCP/WebSocket
- Head‑of‑line: TCP блочит при потере, что увеличивает задержку интерактивных обновлений — критично для рисования.
- QUIC даёт: мультиплексированные потоки без HoL, возможность ненадёжной доставки (datagrams), быструю повторную установку соединения при смене IP/сети (полезно в мобильных сетях).
- WebSocket полезен если нужна совместимость со старыми браузерами/инфраструктурой, но он всё равно поверх TCP и имеет ограничение HoL.
Разделение каналов по типам сообщений (архитектура транспорта)
1. Контрольные/критические сообщения (подключение, сохранение состояния, undo/redo, авторизация, snapshots): использовать надёжный поток QUIC (или надежные сообщения).
2. Высокочастотные позиционные/интерактивные данные (курсор, точки штриха): использовать ненадёжные QUIC datagrams с порядковыми номерами и локальной интерполяцией/экстраполяцией.
3. Средней важности (начало/конец штриха, стилевые метаданные): посылать сначала надёжно (чтобы гарантировать семантику), затем инкременты ненадёжно.
Механизмы для устойчивости в мобильных сетях
- FEC: для ненадёжных пакетов добавлять селективную FEC (например, схему Reed‑Solomon) на блоки из $N$ пакетов с избыточностью адаптивно отстраиваемой ($10\%$–$30\%$ при высокой потере).
- Селективные ретрансляции: важные контрольные пакеты ретранслируются по надёжному каналу при обнаружении потерь.
- Нумерация и NACK: ненадёжные datagrams имеют seq, клиент может попросить перезапрос ключевых сегментов через надёжный канал.
- Адаптивная избыточность: измерять потерю ($p$); при $p>5\%$ увеличивать FEC / уменьшать частоту отправки. (например порог $>5\%$).
- Jitter buffer и интерполяция на клиенте: небольшая задержка воспроизведения для сглаживания потерь, например цель буфера $\sim 50\mathrm{ms}$ (адаптивно).
Согласованность данных: CRDT vs OT
- Рекомендация: CRDT (operation‑based или state‑based) для рисования: обеспечивает конвергенцию без сложной центральной трансформации, лучше для оффлайна и репликации.
- OT можно использовать для линейных документов, но для произвольных графических операций CRDT проще и надёжнее.
- Структура: редуцируйте данные до операций «add stroke», «append points to stroke», «finish stroke», каждая операция имеет уникальный ID и causal metadata (vector clock или Lamport). CRDT гарантирует eventual convergence.
Формат пакетов и компрессия
- Квантование координат (fixed‑point) и delta‑encoding точек; пакетировать до MTU ($1500\mathrm{B}$) для уменьшения фрагментации.
- Бэтчинг: группировать точки в пакеты с таймаутом, баланс latency vs throughput (например отправка не реже чем каждые $16\mathrm{ms}$ при высокой частоте, или снижение до $50\mathrm{ms}$ на мобильных).
Архитектура сервера
- Горизонтально масштабируемые фронтенды (stateless) принимают соединения QUIC/WebTransport и маршрутизируют в комнаты.
- Per‑room state node: держит актуальное CRDT‑состояние в памяти для низкой задержки и транслирует операции; периодически снапшотит в durable storage (S3/DB).
- Event sourcing: операции логируются (append‑only) для реплея/восстановления.
- Репликация: активные узлы держат копии комнат для отказоустойчивости; согласование через CRDT или raft для метаданных (не для операций).
- Edge/relay: поддержка edge нод близко к пользователям (меньше RTT), полезно для мобильных.
Клиентская логика
- Optimistic локальное применение всех операций немедленно (instant feedback).
- Локальные операции идут сразу в ненадёжный канал + копия в надёжный для критичных метаданных (start/finish stroke).
- При потере пакетов: интерполяция по старым точкам; если обнаружен пробел в последовательности и пакет важен — запрос через NACK по надёжному потоку.
- Периодические full‑state checkpoint: клиент получает и применяет snapshots для исправления накопленных расхождений (например при join/reconnect).
- Смена сети: полагаться на QUIC connection migration и re‑establish через token.
Пропускная способность и задержка
- Приоритеты: низкая задержка для позиционных обновлений, экономия трафика через квантование и бэтчинг.
- Ограничения: на мобильных сетях снижать частоту обновлений (с $60\mathrm{Hz}$ до $20\mathrm{Hz}$ или меньше) и увеличивать агрегацию.
- Конгестион‑контроль: полагаться на встроенный алгоритм QUIC для дружелюбного поведения в сети.
Безопасность и аутентификация
- Использовать TLS над QUIC (встроено), проверка токенов/ACL на сервере, шифрование трафика, авторизация при join комнаты.
Итого (практическая схема)
1. Транспорт: QUIC/WebTransport (UDP).
2. Каналы: ненадёжные datagrams для точек; надёжные потоки для метаданных, snapshots и ретраев.
3. Консистентность: CRDT операций для гарантии eventual convergence; операции логируются.
4. Устойчивость в мобильных сетях: adaptive FEC, NACK+reliable retry для критичных данных, edge‑nodes, connection migration, локальная интерполяция и snapshot‑sync.
Это сочетание даёт низкую интерактивную задержку, управляемое потребление полосы и сильную сходимость состояния при высоких потерях в мобильных сетях.