http relay server?

Может, я не до конца понял задачу, но чем обычный Squid не устраивает?

данные в реальном времени обновляются? или одно и тоже, но много раз?

Может быть и одно и то же по кругу. Но считай что обновляются всегда, т.к. могут начать обновляться в любой момент.

Подробнее можно? Кинься ссылкой на страничку документации где написано как зарелеиться?

Вот тебе технически аналогичный пример:

Видео- аудио- поток по какому-либо протоколу релеится именно так. Мастер-релей провайдит потоки, а слейв-релеи «смотрят/слушают» его как обычные клиенты, но в свой буфер, чтобы раздавать копию потока уже самим клиентам (плеерам). Таким образом снижается нагрузка на мастер-релей.

Т.е. какой-нить обратный прокси мне не подойдёт, т.к. он отдаёт соединение в бекенд. И апстрим не подойдёт — поставщик данных у меня один и может быть только один.

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

Squid конечно можно настроить, но думаю проще будет для данного случая - обычный nginx настроить https://www.nginx.com/resources/wiki/start/topics/examples/reverseproxycachin...

обратный прокси мне не подойдёт, т.к. он отдаёт соединение в бекенд

обратный прокси мне не подойдёт

у серверной части не устанавливаются заголовки по допустимому времени хранения?

Нет. В самом начале только заголовки, мол, принял, понял. А потом только поток. И так до разрыва соединения.

а зафиксировать принудительно? на том же nginx делается

Зафиксировать что? Время хранения? Для «постоянно изменяющегося» потока? Зачем?

Не мудри. Есть поток, который надо не кешировать, а пополнять его данными свой кольцевой буфер (one writer, many listeners), с которого раздавать данные клиентам. Ну да — сначала обменяться заголовками рукопожатия с клиентом, а потом слать поток из буфера. Вот прям с того места с какого получится. Главное — клиент начнет получать данные.

т.е. нужно промежуточное звено, которое знает структуру приходящего потока данных и умеющего в любой момент времени подключить нового клиента и посылать данные не с начала, а с текущего «условного байта»?
Тогда не знаю, это вероятно только собственная разработка нужна.

Тще, да. Ну давай подождём может кто знает приблуду такую. Вон, для звука и видео решения существуют. Чому для хттп не может быть?

Потому что для звука и видео всё заточено под звук и видео: прокси-серверы (мультиплексоры) звука или видео не просто данные ретранслируют, а анализируют поток, вставляют заголовки туда, где нужно (при подключении клиента, например), могут демуксить и обратно муксить его.

В общем случае — решения вашей проблемы не существует.

Более того видео правильней стримить по udp

Запили сам. Вот, например

import aiohttp
from aiohttp import web
import asyncio

CHUNK_SIZE = 1024
URL = 'http://ice3.somafm.com/deepspaceone-128-mp3'

clients = set()

async def reader(url):
    async with aiohttp.ClientSession() as session:
        async with session.get(url) as resp:
            while True:
                data = await resp.content.read(CHUNK_SIZE)
                if not data:
                    break
                for client in clients:
                    await client.write(data)

async def handle(request):
    response = web.StreamResponse()
    response.content_type = 'audio/mpeg'
    await response.prepare(request)
    clients.add(response)
    try:
        while True:
            await asyncio.sleep(1)
    finally:
        clients.remove(response)

async def on_startup(app):
    asyncio.create_task(reader(URL))

app = web.Application()
app.add_routes([web.get('/', handle)])
app.on_startup.append(on_startup)

не просто данные ретранслируют, а анализируют поток, вставляют заголовки туда, где нужно

Так а я про что?

свой кольцевой буфер (one writer, many listeners), с которого раздавать данные клиентам. Ну да — сначала обменяться заголовками

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

Найс!

Сейчас глянул на код, в reader при if not data надо не break, а падать. Или перезапускаться. Иначе при обрыве соединения с источником данных оно просто перестанет работать. Вообще это можно легко переписать на го или даже на си, но посколько оно нихрена не делает кроме пересылки данных, это должно достаточно хорошо работать и так. т.к. код асинхронный соединений может висеть очень много.