Пересылать весь трафик на сервер узла HTTPS другому процессу узла таким образом, чтобы другой процесс мог ответить напрямую клиенту?

Question

Я только что закончил работу над моим веб-приложением, которое будет иметь множество быстрых взаимодействий между клиентом и сервером по HTTP. Я только что настраивал сервер / слушатель узла https для работы с логинами / регистрациями через SSL, когда понял, что у меня проблема. Мой http-сервер (также узел, но не https) - это то место, где происходит вся магия в моем программном обеспечении, и по соображениям скорости это не может быть https. Он использует систему сеансов для отслеживания клиентов, и во время разработки логины были проверены в http. Теперь, когда я пытаюсь сделать вход в систему безопасным, система сеанса будет нарушена, поскольку вход в систему будет происходить в отдельном процессе.

Я полагаю, что не должно быть слишком сложно просто заставить мой https-сервер перенаправлять весь трафик, поступающий в него, на http-сервер. Однако я не уверен, как это сделать таким образом, чтобы, когда http-сервер делал свое дело и вызывал response.end (), ответ возвращался клиенту, который первоначально общался с https-сервером. Кто-нибудь знает, как это сделать?

В качестве альтернативы, есть ли у кого-нибудь более знающего, чем я, какие-либо другие предложения? Может быть, ответ будет возвращен на сервер https, а затем переслан обратно клиенту?

Лучше всего, и заранее спасибо, что прочитали это,
Сами

Answer 1

Если вы просто ищете HTTPS-прокси, вы должны использовать nginx или стержень перед haproxy, а не node -> node.

Answer 2

Это работа для технологии очереди сообщений, такой как ZeroMQ.В частности, было бы неплохо использовать такой веб-сервер, как Mongrel2, который делает очереди сообщений своим ядром.

Ваша проблема на самом деле может быть решена, если http-сервер откроет другое окно или iframe с httpsсервер, и пусть https-сервер связывается с http-сервером на бэкэнде после аутентификации клиента.Поскольку один процесс веб-сервера может обрабатывать как трафик http, так и http, это может быть сделано даже внутри сервера, используя что-то такое же грубое, как PHP, но его невозможно масштабировать для объединения всего в один процесс на одном сервере.

Как только вы начинаете работать с несколькими серверами на бэкэнде, каждый из которых выполняет часть работы, хорошей идеей будет начать работать с коммуникационной технологией, которая является одновременно гибкой и масштабируемой.Это то, что вы получаете с ZeroMQ и Mongrel2.