Здравствуйте.

У меня есть маленькая задачка. Есть веб-сервер, который кроме того что отдает статику еще и стирмит некоторые данные. Данных в рамках одного потока очень мало, но поток отдается очень долго (1-2 часа) и желающих все это получить может быть много. В итоге имеем очень много открытых tcp-оединений одновременно. Так вот, для уменьшения нагрузки на веб-сервер и прочего масштабирования нужно соорудить что-то вроде реверс прокси, который бы позволял реализовать такую схему.

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

Каким софтом это можно было реализовать?

Стримит бинарные данные под видом бинарного файла бесконечной длинны. Но. Данные генерируются по ходу дела веб-сервером (есть специальный бекенд), т.ч. вариант с файлом не катит. Там по идее что-то вроде COMET сервера нужно было сделать, но мне было лень это все программировать, к тому же данные идут медленно но постоянно и соединение не закрывается по таймауту. Сейчас в качестве фронтенда работает nginx, но сервер у меня дохленький и поэтому nginx перестают уже справляться. Думаю чем бы его заменить, чтобы работало быстрее и чтобы позволило построить такую архитектуру при которой фронтендов могло бы быть несколько.
Пока читаю ману по HAProxy, но похоже он не умеет делать то что мне нужно.

Ну, вам конечно виднее, как у меня там на самом деле. :)

Ладно если непонятно объяснил словами, то нарисую.
Сейчас работает так:


А должно так:


Но nginx (помимо того что потребляет 100% CPU при большем количестве соединений) не умеет делать второй вариант. Точнее умеет, если включить кеширование, но тогда он сначала все закеширует и только потом начнет отдавать клиентам. А мне нужно чтобы клиенты получали данные сразу же, без задержек, и при этом прокси должен еще и кешировать.

Андрей ПанфиловG@rry_,

мультикаст изобретаете чтоли?
Да, с поправкой на жизненные реалии. Все это работает в Инете и в качестве транспорта, по разным причинам, приходится использовать HTTP.

netwindИ хотя в squid есть некий collapsed forwarding : http://www.squid-cache.org/Versions/v2/2.7/cfgman/collapsed_forwarding.html
но подобная настройка подразумевает, что новый подключившийся клиент резко получит все, что старый клиент скачал ранее.
Стриминга, то есть так чтобы прокси начал отдавать с "середины", не будет.

Так мне и не нужно "с середины". Как раз нужно чтобы с самого начала.

Спасибо за наводку попробую.