☰

Wie hoste ich einen lokalen Server mit Heroku?

tag-icon • tag-icon networking router proxy reverse-proxy reverse-tunnel
Wie hoste ich einen lokalen Server mit Heroku?

Ich möchte eine Node.js-Website auf meinem Laptop hosten, damit sie für andere zugänglich ist. Ich habe versuchtPort-Weiterleitungauf meinem Router, aber es funktioniert nicht, weil mein ISP keine öffentlichen IP-Adressen mehr für Privatanwender bereitstellt. Eine andere Lösung, die mir einfällt, ist die Verwendung vonHerokueine Art vonReverseproxy, über die der Zugriff auf die Website möglich wäre.

Ich habe einige Reverse-Proxys gesehen, die inGehenUndNode.jsInNPM, aber sie scheinen separate Ports für einen Tunnel und einen öffentlichen Server zu verwenden, wasHeroku erlaubt nicht. Auch wenn Heroku nur einen Port zulässt, denke ich, dass es dennoch einige Möglichkeiten gibt, wie dies funktionieren könnte:

  • Betrachten Sie den ersten WebSocket-Benutzer als Client (Website).
  • Betrachten Sie einen WebSocket-Benutzer mit einer bestimmten URL als Client (Website).

Da es möglich ist, dass mehrere Benutzer gleichzeitig eine Verbindung zum Proxy herstellen, kann es notwendig sein, einenAusweisin jeder Anfrage/Antwort an den Client (Website).

Gibt es ein Paket, das dies bereitstellt oder auf andere Weise einen Client hinter NAT zulässt und dabei weiterhin nur einen Port verwendet?

Antwort1

Ich glaube, ich habe schon als Kind damit begonnen, nach Möglichkeiten zu suchen,Öffentlicher ServerausLokaler ServerbeiNPM. Gesucht wurde nach Stichwörtern wie:

  • Reverseproxy
  • Ws-Tunnel
  • Umgekehrtes HTTP
  • TCP-Tunnel

Habe ws-tunnel ausprobiert:
Es brauchte eineseparatePort fürWebSocket-Verbindungund einen separaten Port zum Hosten einesWebserverAuch wenn es auf diese Weise funktionieren könnte,Herokuerlaubt nur1 Anschlussverwendet werden, und ich wusste nicht, ob andereCloud-Anbieterwürde erlauben2 öffentliche Häfen(ich hatte das Gefühl, dass das nicht möglich war).

Habe Reverse-HTTP versucht:
Es könnte alsReverse-HTTP-Client. Reverse HTTP ist ein Protokoll, das von der IETF bereitgestellt wird. Aber dann brauchte ich einReverse-HTTP-Server. Es gab jedoch immer noch ein Problem mitUmgekehrtes HTTP, da es nur streamen konntejeweils eine Anfrage. Es handelte sich im Grunde genommen um eine umgekehrte HTTP-Verbindung vonÖffentlicher ServerZuLokaler Server. Das bedeutete, dass ich entweder die Anfragen mehrerer Benutzer irgendwie auf eine oder mehrere Verbindungen serialisieren musste (mehrereUmgekehrte HTTP-Verbindungenmüsste eingerichtet werden zwischenLokaler ServerUndÖffentlicher Server).

Versuchen Sie es mit TCP-Paketen:
Dann wurde mir klar, dass dies mit einer einzigen Verbindung und einer einfacheren, nicht gepufferten Proxy-Methode möglich war.Umgekehrtes HTTPmuss möglicherweise gepuffert werden, wenn eine neue Verbindung besteht, und alleUmgekehrte HTTP-Verbindungenim Einsatz waren. Erwägen Sie die Verwendung einfacher Pakete im folgenden Format:

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

Ich suchte nach einer Möglichkeit, dies mit WebSockets zu tun, wenn sie eine vorhandene Funktion hatten, die ich verwenden könnte, aber dann sah ich, dass Heroku erlaubtebeliebigHTTP-Upgrade, also habe ich mich stattdessen für ein TCP-Upgrade entschieden. Ich weiß, ich habe es mir ausgedacht. So sieht der Header aus, ich habe überprüft, ob Heroku ihn akzeptiert:

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

Ok, also jetzt gab es eine Idee, wie man die Verbindung zwischen lokalem und öffentlichem Server mit TCP verbessern und dann über Pakete kommunizieren könnte. Das Paketformat sagt uns jedoch immer noch nicht, ob der Benutzer eine Verbindung hergestellt oder getrennt hat. Es sagt uns nur, welche Daten der Benutzer gesendet hat. Also habe ich dem Paket ein weiteres Feld hinzugefügt:

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

Ein Problem, das noch nicht gelöst wurde, war die Unterscheidung zwischen der Verbindung eines Benutzers und eines lokalen Servers, da wir für beide denselben Port verwenden. Es könnte viele Möglichkeiten geben, dies zu tun, aber ich habe mich für eine spezielle Verbindung User-Agentfür den lokalen Server entschieden.

Weitere Zweifel, ob der öffentliche Servercode mit Nodes HTTP oder mit Nodes TCP erstellt werden soll. Dieses Mal habe ich über Chunked Encoding und Trailer gelesen und entschieden, dass es einfach besser wäre, TCP zu verwenden. Ich müsste also die ursprüngliche Verbindungsanforderung analysieren und die Anforderung je nach ermitteltem Typ als Benutzer oder als lokaler Server verarbeiten. Ich stellte mir jedoch vor, dass es ein Leistungsproblem geben würde, da ich die HTTP-Header jeder Verbindung analysieren würde. Wenn wir jedoch eine seltene HTTP-Methode zur schnellen Unterscheidung verwenden, wie HEAD, müssten wir nur 4 Zeichen lesen. Also können wir jetzt Folgendes tun:

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.

Ich habe jetzt auch die Unterstützung für mehrere Kanäle hinzugefügt, wodurch ich nun auf einen SSH-Server zugreifen kann, der auf einem anderen Rechner (private IP) läuft. Habe den Code verschoben und die README-Datei ergänzt:https://github.com/nodef/rhost.

Einige interessante Seiten, die ich bei meiner Suche gefunden habe:

verwandte Informationen