Socket RPC с Tornado в установленной среде Apache/PHP

Question

У нас есть сайт Apache/PHP с интерфейсом Flash с интерфейсом Flash. Нам нужно будет внедрить какую-то сокетную связь или «длительный опрос», чтобы выталкивать обновления для Flash-приложения. Поскольку это, очевидно, не будет хорошей ситуацией для Apache или PHP, я бы хотел использовать Tornado для этого аспекта функциональности, но я также не хочу запускать Tornado на другом порту, поскольку приложение Flash будет работать на клиентской машине, мы не хотим иметь дело с ограничительными брандмауэрами, блокирующими соединения сокетов.

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

Я думал, почему нет использования Tornado в качестве первого контакта для порта 80 и вернуть его обратно в Apache? Я ничего не мог найти по этому поводу, и мне интересно, возможно ли это?

Другим вариантом было бы использовать что-то вроде lighttpd в качестве прокси-сервера и решить, передавать ли оно вещи Apache или Tornado, но имеет ли смысл такая настройка? Или как насчет Nginx?

Любые предложения, рекомендации или поправки по моему пониманию вещей были бы очень благодарны!

Answer 1

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

документация Торнадо имеет example nginx configuration

Одно замечание при использовании обратного прокси-сервера является то, что соединение с вышестоящим сервером теперь будет происходящий от прокси-сервера, а не клиента. Стандарт de facto заключается в том, чтобы размещать информацию об исходном запросе в определенных заголовках http. В примере из документов торнадо заголовок X-Real-IP установлен на IP исходного клиента, а X-Scheme установлен на схему исходного запроса (например, http/https).

Возможно, для вашего восходящего сервера могут потребоваться некоторые изменения. С торнадо это делается путем построения HTTPServer с аргументом xheaders, установленным в True. Это даст указание серверу попытаться вытащить IP-адрес и схему из X-заголовков. Обратите внимание, что если вы используете это с сервером, который не находится за обратным прокси-сервером, который устанавливает соответствующие заголовки, чем вы открыты для подмены IP-адресов.