Проксирующий/кэширующий "сервер"

Приветствую!
Задачка создать проксирующий/кэширующий "сервер".
А именно - есть девайс который неуправляемо запрашивает медиаконтент. И запрашивает его например часто малыми порциями. Т.е. на сервер с данными идет такой себе DDOS и серверу это не нравится.
Как вариант возникла мысль сделать такой себе кэширующий прокси, который стоит посередине и запросы принимает на себя, собирает какуюто часть гэтов, забирает инфу с сервера данных одним запросом (или меньшим колвом запросов), а потом отдает ее девайсу так как он хочет получать - малыми порциями и часто. Все это на php.
Возможно есть такие решения готовые? Или похожие по смыслу..

А конкретно проблема текущая в том что скажем $_SERVER не дает полную инфу о запросе со стороны девайса.. только тип запроса, что запрашиваем, а например кол-во запрошенной информации конкретным GET не дает. В apache2 access.log видно что была кучка GET 200 GET 206 с таким то объемом то ли переданной то ли запрошенной инфы. А как в коде php проксисервера на php узнать сколько инфы запросили что бы знать сколько запросить с сервера данных или сколько отдать закэшированных данных в этот момент, под текущий GET запрос от девайса.

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

Спасибо.

Varnish и/или nginx limit_req

-----
Шта? Репозиторий?

Ну прикол в том что сам " проксирующий сервер" будет запускаться на самом же девайсе а там ограниченный в расширениях апач и пхп.
А намек на то что php в коде php-проксисервера не скажет мне всю подноготную происходящего на низком уровне запросов?
Да, нестандартная задача.. Но неужели.. )

А что за медиаконтент? Не видео?

Как раз видео в основном.
Вот его нужно забирать с медиасервера не таким варварским методом, которым пытается его брать девайс. Потому нужен посредник, т.к. на девайс влиять (на процесс запроса) не получится. Посредник на php смотрит.. ага запросил 10 гетов подряд по 5кб.. - подожди, я заберу с медиасервера одним 50кб (или вообще впрок 5мб (но не все 5Гиг - некуда)) и тебе отдам 10 раз по 5 как хотел, но медсервер при этом не страдает от множественных запросов.
Вот как бы в коде сервера-посредника не хватает механизма контроля - а что запросили в каком объеме то.. Видно через $_SERVER что GET, можно увидеть что именно хочет с медиасервера, но сколько конкретно в данный момент хочет, как получить?
Или GET (со стороны девайса) так не работает вообще.. а запрашивает все но потом дропается аппаратно на каком то этапе и перезапрашивается по новой. Скажем так на начальном этапе девайс видимо получает контент малыми порциями пытаясь определить что именно ему подсунули и после 20 таких миниопросов он определяется и потом уже дозабирает оставшееся большим куском. Вот нужно от этих 20 както избавиться кэшируя контент на начальном этапе и не пуская напрямую на медиасервер кот думает что его пытаются досить

(Отредактировано автором: 19 Мая, 2015 - 09:48:37)

Если ты уже залез в администрирование серваков, то будь добр -- реализуй нормально на том, на чем я тебе подсказал, а не лепи костыли.

-----
Шта? Репозиторий?

Еще раз.
На девайсе работают простенькие апач и пхп и он же будет выступать сам для себя в роли "проксисервера". Т.е. полноценного стороннего сервера-посредника не будет (это самый крайнейший вариант, кот рассматривается только теоретически).
На девайс Varnish не поставить (компилить нужно под его архитектуру) и на nginx apache не поменять.
limit_req насколько я понял предназначение скорее как раз применяется на стороне сервера хранящего медиаконтент и управлять им нет возможности. Я представляю сторону не медиапровайдера у которого проблемы с ддосом, а сторону девайса - который нужно отучить делать множественные запросы.
Все что можно - создать на девайсе на php (можно и на си но это уж черезчур) прослойку (уж ладно не буду называть это "сервером" - потому в кавычках и писал) кот будет перезапрашивать контент не так часто как это делает движок девайса напрямую. Так что нужен именно самописный костыль на девайсе.
И пока смотрю всё идет к тому что php такого вдруг не может дать сам по себе? Странно...

(Отредактировано автором: 19 Мая, 2015 - 10:44:27)

В hosts файле укажите для удаленного домена IP 127.0.0.1 и создайте хост в апаче для него. После этого можете написать свой прокси на PHP.
Не думаю что результат оправдывает такие костыли.

Так я и пишу свой прокси на 127.0.0.1 на девайсе..
И задаю вопрос - как в коде php узнать сколько данных с меня запросили сейчас что бы столько и отдать.. Я через $_SERVER или $_GET вижу только тип запроса и там например что именно спрашивают а размер не вижу.. Как увидеть?
Как узнать сколько "клиент-девайс" запросил сейчас что бы эхом или passthru выплюнуть ему то что запросил но с медиасервера при этом забрать заранее один раз и побольше.. При этом еще следующую паритию отдать с нового места.. и так до тех пор пока не запросит наконец большой кусок..

(Отредактировано автором: 19 Мая, 2015 - 14:36:33)

А покажите _SERVER запроса.

-----
self-banned

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

По сути есть 3 варианта.
1. По стандарту HTTP передается заголовок Range
2. Где-то в get параметрах
3. Сам бекенд отдает кусками

Наиболее очевидный все же 1-й способ, так что смотрите HTTP_RANGE

-----
self-banned

Ok, и где его смотреть?
в $_SERVER не заявлен такой

Завялен - это вы про документацию? В документации только стандартные значения, которые сам интерпретатор пхп ставит. Но кроме того там еще все HTTP заголовки, а они могут быть произвольные. К ним ставится префикс HTTP_, т.е. смотреть $_SERVER['HTTP_RANGE']

(Отредактировано автором: 19 Мая, 2015 - 15:42:04)

-----
self-banned

Спасибо, проверю, видимо в этом и заключался всего навсего вопрос новичка