☰

¿Cómo alojar un servidor local usando Heroku?

tag-icon • tag-icon networking router proxy reverse-proxy reverse-tunnel
¿Cómo alojar un servidor local usando Heroku?

Quiero alojar un sitio web Node.js ejecutándose en mi computadora portátil, para que otras personas puedan acceder a él. Yo he tratadoreenvío de puertosen mi enrutador, pero no funciona porque mi ISP dejó de proporcionar direcciones IP públicas a los usuarios domésticos. Otra solución que se me ocurre es utilizarhéroekualbergar algún tipo deproxy inverso, a través del cual sería posible acceder al sitio web.

He visto algunos proxies inversos escritos enIryNodo.jsenMNP, pero parecen utilizar puertos separados para un túnel y un servidor público, lo queHeroku no permite. Aunque Heroku solo permite un puerto, sigo pensando que hay algunas formas en que esto podría funcionar:

  • considere el primer usuario de websocket como cliente (sitio web).
  • considere al usuario de websocket con una URL específica como cliente (sitio web).

Como es posible que varios usuarios se conecten al mismo tiempo al proxy, puede que sea necesario incluir unidentificaciónen cada solicitud/respuesta al cliente (sitio web).

¿Existe algún paquete que proporcione esto, o de alguna otra manera, permita que un cliente esté detrás de NAT, mientras sigue usando un solo puerto?

Respuesta1

Creo que comencé, cuando era niño, a buscar formas de organizar unaServidor públicodeServidor localenMNP. Busqué palabras clave como:

  • proxy inverso
  • tunel ws
  • HTTP inverso
  • túnel TCP

Probé ws-tunnel:
Necesitaba unseparadopuerto paraConexión WebSockety un puerto independiente para alojar unServidor web. Aunque de esa manera podría funcionar,héroekupermitido solo1 puertopara ser usado, y no sabía si algún otroProveedor de nubepermitiría2 puertos públicos(Sentí que no era posible).

Probé http inverso:
Podría actuar como unCliente HTTP inverso. HTTP inverso es un protocolo proporcionado por IETF. Pero entonces necesitaba unServidor HTTP inverso. Sin embargo, todavía había un problema conHTTP inverso, ya que solo podía transmitiruna solicitud a la vez. Básicamente era una conexión HTTP a la inversa deServidor públicoaServidor local. Eso significaba que tendría que serializar de alguna manera las solicitudes de múltiples usuarios a una o múltiples conexiones (múltiplesConexiones HTTP inversastendría que configurarse entreServidor localyServidor público).

Intente usar paquetes TCP:
Luego me di cuenta de que era posible hacer esto usando una única conexión y un método de proxy más simple y sin búfer.HTTP inversopodría necesitar almacenamiento en búfer si hubiera una nueva conexión, y todoConexiones HTTP inversasestaban en uso. Considere utilizar paquetes simples, del siguiente formato:

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

Estaba buscando una manera de hacer esto usando WebSockets, si tuvieran alguna característica existente que pudiera usar, pero luego vi que Heroku estaba permitido.cualquierActualización de HTTP, así que decidí seguir adelante con una actualización de TCP. Lo sé, lo inventé. Así es como se ve el encabezado, verifiqué que Heroku lo acepta:

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

Bien, ahora surgió una idea de cómo actualizar la conexión entre el servidor local y el servidor público usando TCP y luego comunicarse mediante paquetes. Sin embargo, el formato del paquete no nos dice si el usuario se conectó o desconectó. Sólo nos dice qué datos envió el usuario. Entonces agregué otro campo al paquete:

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

Un problema que aún no estaba resuelto era distinguir entre la conexión de un usuario y un servidor local, ya que estamos usando el mismo puerto para ambos. Podría haber muchas formas de hacer esto, pero decidí optar por una específica User-Agentpara el servidor local.

Más dudas, si construir el código del servidor público usando el HTTP de Node o usando el TCP de Node. Esta vez, estaba leyendo sobre codificación fragmentada y avances, y decidí que sería mejor usar TCP. Por lo tanto, tendría que analizar la solicitud inicial de una conexión y, según el tipo determinado, procesar la solicitud como usuario o como servidor local. Pero imaginé que habría un problema de rendimiento ya que estaría analizando los encabezados HTTP de cada conexión. Pero si utilizamos un método HTTP poco común para una distinción rápida, como HEAD, solo tendríamos que leer 4 caracteres. Entonces ahora podemos hacer esto:

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.

También agregué soporte para múltiples canales a esto ahora, lo que ahora puede permitirme acceder como servidor SSH ejecutándose en otra máquina (ip privada). Movió el código y decoró el README:https://github.com/nodef/rhost.

Algunas páginas interesantes que encontré mientras buscaba:

información relacionada