Межсайтовая пропускная способность — TrueNAS ↔ Mac/TV

Контекст: после восстановления стека медиа/права на Taiga (см. family/documents/vault-sync/2026-09-02-restore-privilege-scope.md) Jellyfin запустился и файлы читаются, но прямое воспроизведение с ТВ «грузится кусками». Диагностика 2026-09-02 установила: это НЕ транскодинг и НЕ тариф, а ограничение сети между двумя физически разнесёнными локальными сетями.

Cетевой layout (фактический)

Узел	LAN	Шлюз	Egress IP	Провайдер
Mac / TV (дом)	`192.168.1.57`	`192.168.1.1`	динамический	ТТК (92.62.x / 185.20.x)
TrueNAS (Taiga)	`192.168.2.197`	`192.168.2.2`	`90.189.160.148` (`mallexxx.duckdns.org`)	Ростелеком (194.186.x → 217.107.x)

Ключевое: TrueNAS НЕ в локальной сети Мака/ТВ. Трафик ТВ→Jellyfin идёт целиком по интернету между двумя разными операторами/домохозяйствами.

Замеры (2026-09-02)

Задержка / маршрут

RTT Mac → TrueNAS: ~104 мс.
Traceroute: хопы 1–7 моего ISP (ТТК) — 3–6 мс ✅ чисто. На хопе 8 (194.186.168.65) прыжок до ~54 мс — межоператорская передача в сеть Ростелекома, где живёт TrueNAS. Хоп 10 (217.107.108.41) ~60 мс.
Этот +50 мс — физическое/пиринговое расстояние между региональными операторами, НЕ петля. Перенастройка маршрута полностью RTT не уберёт.
Примечание: дальние сети в целом (8.8.8.8 ~100 мс) у ТТК тоже идут через ~50 мс переход — деградация на стороне выхода, а не только до TrueNAS.

Пропускная способность (распутали про «тариф»)

Mac download с CDN: ~78 Мбит/с (линия Мака в порядке).
TrueNAS сторона: NIC enp3s0 1 Gb/s, до шлюза 0.2–0.8 мс 0% loss. NAS→Cloudflare: download ~184 Мбит/с, upload ~117 Мбит/с. → Лимита тарифа на TrueNAS НЕТ.
Mac → TrueNAS (SCP 200MB): ~28 Мбит/с одним потоком.
Mac → TrueNAS, 4 параллельных SCP потока: ~28 → ~51 Мбит/с (агрегат растёт с параллельностью).

Вывод (важно)

Ограничение — НЕ по суммарной полосе транзита, а по одному TCP-потоку из-за высокого RTT (~104 мс) + BDP / congestion-window. Доказательство: 4 потока дали рост ×1.8 (28→51) — при жёстком лимите линии рост не произошёл бы.

Почему Jellyfin дёргается прямо: Jellyfin отдаёт видео одним последовательным HLS-потоком (один TCP). Один поток душится RTT-штрафом до ~28–50 Мбит, а BluRay-файл в пиках идёт к 20+ Мбит → с 104 мс RTT сегменты не успевают → стоп-кары. Файл The.Jungle.Book.1967.720p.BluRay ≈ 7.1GB/~78мин → средний ~12 Мбит/с, пики выше.

Факты ИЗ ЛОГОВ Jellyfin (подтверждают: транскодинг не причина в этих тестах)

Реальный транскод с libx264 + reduce был только на "Snatch" (тестовые короткие старты каждые ~5 с — клиент переподключался).
"Один день в Стамбуле"/"Рождественские хроники" — ремукс -codec:v:0 copy в HLS (не перекодирование), стоп на ~2-3 сек.
В моменте (пока ТВ крутит 720p) — ffmpeg-дочерних процессов нет, папка transcodes пуста → прямой stream/direct, транскодинг не идёт.

Решение / направление

Правильное лекарство (не мультипоток ради мультипотока, а либо снижение латентности, либо запас по битрейту под single-flow): лимит транскода ~12–18 Мбит, ЛИБО гнать трафик ТВ→TrueNAS через xray tunnel (vpn.mallexxx.duckdns.org, смотри [[xray-reverse-tunnel-kraken-truenas]]) вместо прямого межоператорского пути.
Jellyfin не умеет штатно разбивать один плейбек на параллельные TCP. Параллельность (28→51 Мбит) достижима только поднятием файла способом «качалка в N коннектов» + прокси, либо через туннель.
Задача замера скорости через xray-test-client контейнер (teddysun/xray, SOCKS 127.0.0.1:1080) — НЕ завершена: команда замера была заблокирована юзером; способ/endpoint (стучались на внутренний 192.168.2.197:8096) предложен неверно.

Endpoint-факты для замера туннеля

Локальный тестовый xray-клиент на Mac: контейнер xray-test-client (127.0.0.1:1080->1080/tcp), конфиг /Users/admin/xray-test/config.json, оставлен на kraken-user.
Per-user egress на vpn.mallexxx.duckdns.org: user1 → direct TrueNAS 90.189.160.148; kraken-user → reverse через Kraken 92.62.70.41.
Конфиг клиента лежит на Mac отдельно (не в vault); бэкап direct-клиента: /Users/admin/xray-test/config.json.bak-user1-direct-20260902-1227.

6.6 KiB Raw Blame History Unescape Escape