Замеры на стенде (эмулятор Android 16, настоящий WebView и страница
моста, tproxy-server в режиме websocket за nginx, netem) показали, что
канал насыщают и upstream DrKLO (8ad4ac9ba), и 12f2a119f, а теряется
не скорость, а очередь: фиксированные 1 МиБ выгрузки и 2 МиБ кредита
ограничивали скорость на длинных RTT (300 мс: 2,7 против 4,1 МБ/с), а
без окон upstream держит перед чатом секунды данных. Узкое место
Desktop (base64 eval по одному кадру) на Android отсутствует.
- WebProxyEngine: один поток на селекторе вместо потока на сокет,
исполнителя носителя и общей блокировки. Сокет tgnet читается только
по гранту планировщика, прямо в пакет для страницы; приём пишется в
tgnet без блокировки, зависший читатель не держит остальные потоки.
- Все кадры прохода уходят странице одним сообщением (до 96 КиБ).
- Граница со страницей — WebMessagePort, когда WebView умеет: кадры
страницы не разбираются в UI-потоке. Иначе, или если порт не ожил за
15 с, — прежний слушатель; нонс и точный origin проверяются в обоих.
- Одно управление потоком: окно релея плюс адаптивные окна выгрузки и
загрузки (WebProxyFlow.AdaptiveWindow, как у Desktop, с отличиями по
замерам: запас очереди от 200 мс, рост как slow start, слив только
при подтверждённой очереди, пол min(2 МиБ, 0,8 с скорости)).
- Выгрузка снова по четырём соединениям, как в upstream.
- Медиа через MTProxy/WEB: знак DC в заголовке берётся по тому же
правилу, что и медиа-ключ (hasMediaAddress), иначе медиа-ключ мог
уйти в обычный кластер и получить -404 сразу после создания.
Итог против upstream на 24 сценариях: скорость в пределах ±1–2 %
(загрузка 128 КиБ×4 при 50 мс +7 %, смешанный трафик в шуме),
задержка чата при полной выгрузке 2,3–6,3 с → 0,37–0,88 с, при
загрузке 1,3–3,3 с → 0,42–0,89 с. Стенд — Tools/web_proxy_bench,
JVM-тесты движка — Tools/web_proxy_flow_tests.
loop-uh
78f4107005