☰

Como hospedar um servidor local usando Heroku?

tag-icon • tag-icon networking router proxy reverse-proxy reverse-tunnel
Como hospedar um servidor local usando Heroku?

Quero hospedar um site Node.js em execução no meu laptop, para que seja acessível a outras pessoas. eu tenteiencaminhamento de portano meu roteador, mas não funciona porque meu ISP parou de fornecer endereços IP públicos para usuários domésticos. Outra solução que consigo pensar é usarHerokupara hospedar algum tipo deproxy reverso, através do qual seria possível acessar o site.

Eu vi alguns proxies reversos escritos emIreNode.jsemNPM, mas eles parecem usar portas separadas para um túnel e um servidor público, o queHeroku não permite. Mesmo que o Heroku permita apenas uma porta, ainda acho que isso ainda pode funcionar de algumas maneiras:

  • considere o primeiro usuário do websocket como cliente (site).
  • considere o usuário do websocket com uma URL específica como cliente (site).

Como é possível que vários usuários estejam se conectando ao mesmo tempo ao proxy, pode ser necessário incluir umeu iaem cada solicitação/resposta ao cliente (website).

Existe algum pacote que forneça isso, ou de alguma outra forma, permita um cliente atrás de NAT, embora ainda use apenas uma porta?

Responder1

Eu comecei, quando era criança, eu acho, procurando maneiras de hospedar umServidor públicodeServidor localnoNPM. Pesquisou palavras-chave como:

  • Proxy reverso
  • Túnel Ws
  • HTTP reverso
  • Túnel TCP

Tentei o túnel ws:
Precisava de umseparadoporta paraConexão WebSockete uma porta separada para hospedar umservidor web. Mesmo que assim pudesse funcionar,Herokupermitido apenas1 portapara ser usado, e eu não sabia se havia algum outroProvedor de nuvempermitiria2 portas públicas(senti que não era possível).

Tentei http reverso:
Poderia funcionar como umCliente HTTP reverso. HTTP reverso é um protocolo fornecido pela IETF. Mas então eu precisava de umServidor HTTP reverso. No entanto, ainda havia um problema comHTTP reverso, já que só poderia transmitirum pedido de cada vez. Era basicamente uma conexão HTTP ao contrárioServidor públicoparaServidor local. Isso significava que eu teria que serializar de alguma forma as solicitações de vários usuários para uma ou várias conexões (múltiplasConexões HTTP reversasteria que ser configurado entreServidor localeServidor público).

Tente usar pacotes TCP:
Então percebi que era possível fazer isso usando uma única conexão e um método de proxy mais simples e sem buffer.HTTP reversopode precisar de buffer se houver uma nova conexão, e todosConexões HTTP reversasestavam em uso. Considere usar pacotes simples, no seguinte formato:

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

Eu estava procurando uma maneira de fazer isso usando WebSockets, se eles tivessem algum recurso existente que eu pudesse usar, mas então vi o Heroku permitidoqualquerAtualização HTTP, então decidi prosseguir com uma atualização TCP. Eu sei, eu inventei. Esta é a aparência do cabeçalho, verifiquei se o Heroku o aceita:

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

Ok, agora havia uma ideia de como você poderia atualizar a conexão entre o servidor local e o servidor público usando TCP e depois se comunicar usando pacotes. Ainda assim, porém, o formato do pacote não nos diz se o usuário conectou ou desconectou. Ele apenas nos informa quais dados o usuário enviou. Então adicionei outro campo ao pacote:

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

Um problema que ainda não foi resolvido foi distinguir entre a conexão de um usuário e um servidor local, já que estamos utilizando a mesma porta para ambos. Poderia haver muitas maneiras de fazer isso, mas decidi usar uma específica User-Agentpara o servidor local.

Mais dúvidas, se construir o código do servidor público usando HTTP do Node ou usando TCP do Node. Desta vez, eu estava lendo sobre codificação em partes, trailers e decidi que seria melhor usar TCP. Então, eu teria que analisar a solicitação inicial de conexão e, com base no tipo determinado, processar a solicitação como usuário ou como servidor local. Mas imaginei que haveria um problema de desempenho, pois estaria analisando os cabeçalhos HTTP de cada conexão. Mas se usarmos um método HTTP raro para distinção rápida, como HEAD, teríamos que ler apenas 4 caracteres. Então agora podemos fazer isso:

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.

Também adicionei suporte para vários canais agora, o que agora pode me permitir acessar como servidor SSH rodando em outra máquina (ip privado). Movi o código e decorei o README:https://github.com/nodef/rhost.

Algumas páginas interessantes que encontrei durante a pesquisa:

informação relacionada