А есть какой-то протокол, полностью аналогичный IBM Aspera, но без энтерпрайз-тупака?

BitTorrent пробовал? Конечно, из коробки потоков нет, но при необходимости можно допилить — отдельные клиенты уже имеют фичу «получать части последовательно».

Были малоуспешные потуги ввиде UDT и UFTP. Ещё есть фейсбуковский WDT, но не пробовал.

HTTP 3 /thread

https://habr.com/ru/company/ibm/blog/274807/

Одна маркетинговая вода - какие мы замечательные, но тохда почему ибм это похоронил? А по теме да - в quic/http3 много чего есть и даже больше. https://github.com/litespeedtech/lsquic в докере развернуть и попробовать - 20 минут.

А можно ли сказать про задачу в более общем виде? Это стриминг видео, или что?

присоединяюсь к вопросу.

слишком долго битторрент раскочегаривается
У меня хоть и не realime, но ждать доставки файла через 30 секунд - неприемлимо

Фейсбуковый WDT выглядит неплохо, хотя там ни слова нет про поведение протокола в ситуации когда большой пакетлосс

малоуспешные потуги ввиде UDT и UFTP

А что с ними не так?

Вполне вероятно, что всё так, но развитие мало активное. В UFTP, например, есть поддержка ECDSA, но нет Ed25519.

Одна маркетинговая вода - какие мы замечательные, но тохда почему ибм это похоронил?

Он не похоронил, он понял что это нужно очень крупным клиентам, которых мало. Также он выделил этот проект в какой-то клауд (не совсем понимаю какой, не вникал)

ЕМНИП mail.ru для видеостриминга у себя использует

А по теме да - в quic/http3 много чего есть и даже больше. https://github.com/litespeedtech/lsquic в докере развернуть и попробовать - 20 минут.

Спасибо, гляну на QUIC

HTTP 3 /thread

Он на бумаге, а реализации выглядят сыроватыми

Стриминг аудио, но НЕ realtime и НЕ VOIP

Конечному приложению нужно хорошо работать в условиях сети с большой задержкой (типично для 4G/HSDPA/3G), т.е. мы не ждём на каждый пакет ACK. Кроме того мне лично важно как можно более быстро получить первый блок из файла, т.е. bittorrent явно в пролёте

Ответил

HTTP/3 is used by 19.9% of all the websites. Через HTTP/3 идет большинство трафика к фейсбуку и ютубу, а это огромный кусок.

Со временем отшлифуют, это неизбежное будущее, для нового проекта можно на это закладываться.

если точек входа для множества слушателей мало - HLS, тебе нужна только реалтайм резалка или предварительная резалка, и отдавать нжинксом. работает поверх хттп, много фич, посмотри возможности.

Тут вот например говорят, что fdt может быть вполне альтернативой.

а у плееров всегда есть предварительный буфер, так, они в запас качают и на несколько сек в прошлом звучат.

https://news.ycombinator.com/item?id=21898072

Думаю, под такую задачу можно свой протокол попробовать изобрести, как вот тут https://habr.com/ru/company/oleg-bunin/blog/413479/ например описывают.

Можно например предусмотреть, чтобы клиент сообщал серверу о проценте потерянных пакетов, и чтобы сервер как-то при этом менял размеры пакетов и/или добавлял избыточность. Например, может оказаться, что если пакеты размером в 300 байт, то потерь 50% а если размеры 100 байт - 10%, это можно как-то предварительно измерять и выбрать оптимальный размер. И уровень избыточности выбирать исходя из таких-то потерь.

https://github.com/xtaci/kcptun

Спасибо за ссылку!

Никоим образом не хочу как-то понизить значимость этой работы или еще что-то подобное, но я по своему опыту нахожу некую корреляцию между:

1. В ридми есть всё кроме самого главного - ЧТО ЭТО ТАКОЕ, зачем оно нужно, и чем оно отличается от других
2. Автору глубоко насрать на свою работу в любом контексте помимо повышения собственного ЧСВ

UPD: А, там китайщина и golang, это сразу 🗑🗑🗑

ЧТО ЭТО ТАКОЕ

Это туннель на базе протокола KCP. Протокол KCP — это надстройка над UDP для работы в совсем уж убогих сетях с большими потерями, типа сотового модема на грани приёма или тропосферной радиорелейной связи. https://habr.com/ru/post/358126/

Трафик через него можно завернуть с помощью Shadowsocks.

А есть реализация на C?

Вот список реализаций: https://github.com/skywind3000/kcp/blob/master/README.en.md#related-applications

xkcptun: C language implementation of kcptun, embedded-friendly for LEDE and OpenWrt projects.
https://github.com/liudf0716/xkcptun