☰

Как разместить локальный сервер с помощью Heroku?

tag-icon • tag-icon networking router proxy reverse-proxy reverse-tunnel
Как разместить локальный сервер с помощью Heroku?

Я хочу разместить сайт Node.js на моем ноутбуке, чтобы он был доступен другим людям. Я пробовалПеренаправление портана моем маршрутизаторе, но он не работает, потому что мой провайдер прекратил предоставлять публичный IP-адрес домашним пользователям. Другое решение, которое я могу придумать, это использоватьГерокучтобы разместить какой-то типобратный прокси, через который можно будет получить доступ к сайту.

Я видел несколько обратных прокси, написанных наИдтииNode.jsвНПМ, но они, похоже, используют отдельные порты для туннеля и публичного сервера, чтоHeroku не позволяет. Несмотря на то, что Heroku допускает только один порт, я все же думаю, что есть несколько способов, с помощью которых это может работать:

  • рассматривать первого пользователя веб-сокета как клиента (веб-сайт).
  • рассматривать пользователя веб-сокета с определенным URL как клиента (веб-сайт).

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

Есть ли какой-то пакет, который обеспечивает это или каким-то другим способом позволяет клиенту находиться за NAT, используя при этом только один порт?

решение1

Я начал, еще когда был ребенком, искать способы провести вечеринкуПубличный серверотЛокальный сервервНПМ. Поиск по ключевым словам:

  • Обратный прокси
  • туннель Ws
  • Обратный HTTP
  • TCP-туннель

Попробовал ws-туннель:
Это было необходимоотдельныйпорт дляWebSocket-соединение, и отдельный порт для размещениявеб сервер. Хотя это могло бы сработать,Герокуразрешено только1 портдля использования, и я не знал, есть ли какие-либо другиеПоставщик облачных услугпозволит2 общественных порта(я чувствовал, что это невозможно).

Попробовал обратный http:
Он мог бы действовать какОбратный HTTP-клиент. Обратный HTTP — это протокол, предоставленный IETF. Но, тогда мне нужен былОбратный HTTP-сервер. Однако все еще оставалась проблема сОбратный HTTP, так как он мог транслировать толькоодин запрос за раз. По сути, это было HTTP-соединение наоборот.Публичный серверкЛокальный сервер. Это означало, что мне придется как-то сериализовать запросы нескольких пользователей в одно или несколько подключений (несколькоОбратные HTTP-соединениянеобходимо будет настроить междуЛокальный сервериПубличный сервер).

Попробуйте использовать TCP-пакеты:
Затем я понял, что это можно сделать, используя одно соединение и более простой небуферизованный метод проксирования.Обратный HTTPможет потребоваться буферизация, если возникло новое соединение, и всеОбратные HTTP-соединениябыли в использовании. Рассмотрите возможность использования простых пакетов следующего формата:

--------------------------------------
| Packet Size | Connection ID | Data |
--------------------------------------

Я искал способ сделать это с помощью WebSockets, если у них есть какая-то существующая функция, которую я мог бы использовать, но потом я увидел, что Heroku разрешаетлюбойОбновление HTTP, поэтому я решил вместо этого перейти на обновление TCP. Я знаю, я это придумал. Вот как выглядит заголовок, я проверил, что Heroku его принимает:

GET / HTTP/1.1
Upgrade: tcp
Connection: Upgrade
Origin: XXX

Итак, теперь появилась идея, как можно обновить соединение между локальным сервером и публичным сервером с помощью TCP, а затем общаться с помощью пакетов. Однако формат пакета не сообщает нам, подключился ли пользователь или отключился. Он сообщает нам только, какие данные отправил пользователь. Поэтому я добавил еще одно поле в пакет:

----------------------------------------------
| Packet Size | Event | Connection ID | Data |
----------------------------------------------

Одна из проблем, которая пока не была решена, заключалась в различении соединения от пользователя и локального сервера, поскольку мы используем один и тот же порт для обоих. Для этого может быть много способов, но я решил использовать специальный User-Agentдля локального сервера.

Еще больше сомнений, следует ли создавать код публичного сервера с использованием HTTP Node или TCP Node. На этот раз я читал о фрагментированном кодировании, трейлерах и решил, что лучше использовать TCP. Итак, мне придется разобрать первоначальный запрос на соединение и на основе определенного типа обработать запрос как пользователь или как локальный сервер. Но я представлял себе, что возникнут проблемы с производительностью, так как мне придется разбирать заголовки HTTP каждого соединения. Но если мы используем редкий метод HTTP для быстрого различения, например HEAD, нам придется читать только 4 символа. Так что теперь мы можем сделать это:

1. If first 4 characters not HEAD, process as User.
2. Parse all the HTTP headers.
3. If User-Agent is special value, process as Local server
4. Process as User.

Я также добавил поддержку нескольких каналов, что теперь позволяет мне получить доступ как к SSH-серверу, запущенному на другой машине (частный IP). Переместил код и украсил README:https://github.com/nodef/rhost.

Несколько интересных страниц, которые я нашел во время поиска:

Связанный контент