--- title: Многопоточный стриминг и обход single-flow лимита (Jellyfin / webOS / TorrServer) created: '2026-09-21' updated: '2026-09-22' type: research namespace: personal status: research-complete tags: - jellyfin - webos - streaming - tcp - lampa - torrserver - bandwidth related: - '[[personal/tech/inter-site-throughput-taiga-to-mac]]' - '[[personal/tech/xray-reverse-tunnel-kraken-truenas]]' - '[[family/how-to/kraken-network]]' --- # Многопоточный стриминг — что реально существует > **Контекст:** Jellyfin на TrueNAS (Новосибирск) тормозит при просмотре из Бишкека. > Speedtest через reverse-туннель показывает **до 120 Мбит/с**, но видео дёргается. > Разбор: почему, и какие пути обхода существуют. Дата: 2026-09-21. --- ## 1. Почему speedtest 120 Мбит, а видео тормозит **Speedtest открывает 8+ параллельных TCP-сессий.** Каждая независимо разгоняется своим congestion window. 8 сессий × ~15 Мбит = 120 Мбит. Это доказывает, что **канал физически пропускает 120 Мбит**. **Но одна TCP-сессия не берёт 120 Мбит.** Скорость ≈ окно / RTT. При RTT ~104 мс для 120 Мбит нужно окно ≈ 1.5 МБ «в полёте», не подтверждённых. Одна сессия разгоняется не сразу, при потерях окно режется вдвое, на межоператорском стыке потери почти всегда есть. **Замеры межсайтовой пропускной способности (2026-09-02):** | Режим | Пропускная способность | |---|---| | Mac → TrueNAS, 1 SCP-поток | ~28 Мбит/с | | Mac → TrueNAS, 4 параллельных | ~51 Мбит/с (×1.8) | | Speedtest (8 потоков) | до 120 Мбит/с | Рост ×1.8 при 4 потоках **доказывает**: ограничение — не полоса транзита, а **один TCP-поток при высоком RTT**. **Аналогия (уточнена Alex):** не «узкая труба», а **8 касс, где канал пропустит 120 чел/мин — если открыты все 8. Один покупатель с одной корзиной в одной кассе уедет не быстрее этой кассы.** Узкое — не канал, а **одно соединение на длинном пути**. --- ## 2. Почему туннели не помогают **Замеры 2026-09-02 через `xray-test-client`:** | Режим | Egress | Down | Стабильность | |---|---|---|---| | `kraken-user` (reverse) | `92.62.70.41` (Kraken) | ~45 Мбит | нестабилен, падал к 2 МБ/с | | `user1` (direct/REALITY) | `90.189.160.148` (TrueNAS) | ~37 Мбит | 3.67–5.63 МБ/с | | Контроль (Mac → Cloudflare напрямую) | — | ~55 МБ/с | — | **VLESS/REALITY идёт через тот же маршрут** ТТК → Ростелеком (хоп 8, +50 мс). Меняется инкапсуляция, не физика. REALITY/Vision добавляет обёртки → обычно **чуть хуже** прямого, не лучше. ### 🔴 Несколько xray-туннелей НЕ дадут скорости Это MPTCP/bonding — он агрегирует **разные физические пути**. Путь **один**. N туннелей по одному пути разделят тот же congestion window — суммарно не больше одного, плюс оверхед. Подтверждено замерами: reverse 45 и direct 37 — один коридор, не ×2. **Реальная агрегация требует второго независимого линка** (мобильный 4G/5G как backup-WAN). --- ## 3. Многопоточный HLS — существует, но не реализован | Решение | Статус | |---|---| | **Jellyfin** feature request «multiple parallel connections» | ✅ **Planned**, 230 голосов (features.jellyfin.org/posts/2171). Issue #3206 (2020) закрыт как stale. **5 лет, кода нет** | | **hls.js** issue #6753 (multi-segment prefetch) | Открыт Oct 2024, milestone 1.8.0, «Top priorities». **Кода нет, PR отсутствует** | | **ExoPlayer** #5978 (parallelize DASH/HLS) | Android, не webOS | **Механизм, которого все ждут:** клиент тянет N сегментов одновременно → N независимых TCP-окон → 120 Мбит. **Ровно то, что нужно. Но нигде не реализовано.** ⚠️ **На webOS это безнадёжно:** приложения используют **нативный media pipeline** (Starfish / HTML5 `