webSocket ws user hinter Proxy (Proxy Erweiterung)

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • webSocket ws user hinter Proxy (Proxy Erweiterung)

    Hallo Forum,

    da sich der Server langsam der ersten nutzbaren Version nähert, nun zum Thema Proxy :)
    Proxy-Agent schaut ja schon mal gut aus aber nur um es klar zu stellen, diese Erweiterung ist doch dazu da, damit User die hinter einem Proxy sitzen ebenfalls mit dem WS-Server kommunizieren können, ja?

    Dokumentation schrieb:

    This module provides an http.Agent implementation that connects to a specified HTTP or HTTPS proxy server, and can be used with the built-in https module.

    Specifically, this Agent implementation connects to an intermediary "proxy" server and issues the CONNECT HTTP method, which tells the proxy to open a direct TCP connection to the destination server.

    Since this agent implements the CONNECT HTTP method, it also works with other protocols that use this method when connecting over proxies (i.e. WebSockets). See the "Examples" section below for more.

    Ja was soll ich sagen, ist wie alles etwas kompliziert und für Jemand der von Proxys keine Ahnung hat eher schwer zu verstehen.
    Dieses Modul verbindet sich mit einem bestehenden Proxy, hier muss ich jetzt aber nicht extra einen Proxyserver aufsetzten oder? Ich gehe mal davon aus, das dies wohl http/https übernimmt, in diesem Protokoll ist ja i.d.R. ein Proxymechanismus vorhanden, so das wenn dieses Protokoll über den Client von einem Proxy aus angesteuert wird dieses Modul quasi einen Tunnel zwischen Client und Server herstellt, so das eben trotz Proxy die Kommunikation gewährleistet ist?

    Falls ja, werde ich aus dem Beispielcode nicht schlau, ich kommentiere einfach mal meine Fragen in den Code...

    JavaScript-Quellcode

    1. var url = require('url');
    2. var WebSocket = require('ws');
    3. var HttpsProxyAgent = require('https-proxy-agent');
    4. // HTTP/HTTPS proxy to connect to
    5. var proxy = process.env.http_proxy || 'http://168.63.76.32:3128';
    6. // process.env.http_proxy ? Was ist hier drin?
    7. // Und welche IP wird dort als alternative gesetzt die des Websocketservers mit port?
    8. // bei https kann man einfach mit dem fehlenden s ergänzen?
    9. console.log('using proxy server %j', proxy);
    10. // WebSocket endpoint for the proxy to connect to
    11. var endpoint = process.argv[2] || 'ws://echo.websocket.org';
    12. // Die selben Unklarheiten wie zuvor
    13. var parsed = url.parse(endpoint);
    14. console.log('attempting to connect to WebSocket %j', endpoint);
    15. // create an instance of the `HttpsProxyAgent` class with the proxy server information
    16. var options = url.parse(proxy);
    17. var agent = new HttpsProxyAgent(options);
    18. // finally, initiate the WebSocket connection
    19. var socket = new WebSocket(endpoint, { agent: agent });
    Alles anzeigen
    Was gänzlich fehlt ist die Anwendung des SSL-Zertifikats, http/https, wird ja nicht mehr so angesteuert wie es zuvor war, als das ich dort wieder mein Zertifikat rein packen könnte.
    Finde die Doku hätte dort etwas mehr ins Detail gehen können und vor allem welche Adressen dort angegeben werden müssen, aus den Beispielen werde ich nicht schlau.


    MfG: Paykoman
  • Neu

    Eigentlich wäre es Sinvoll hier noch mal zu den Grundlagen zu kommen, da es alles sehr verwirrend ist.

    Ich möchte gern noch mal auf den proxy-agent eingehen, da bist Du leider nicht näher drauf eingegangen.
    Ich habe dort heute auch schon einigie missglückte Versuche gestartet aber wenn ich es richtig verstehe, sollte dieses Modul doch eine Verbindung zu nginx der Webseite aufbauen und für proxys einen tunnel zum ws-Server schaffen?

    1) Dazu müsste doch der ganz normale host der Webseite ausreichen (also nginx) der als proxy gesetzt werden muss?
    var proxy = process.env.http_proxy || 'http://89.163.255.9:3128'; wobei ich nicht weiß was für ein port hier verwendet werden muss.
    und seltsamer weiße ist process.env.http_proxy immer 'undefined', warum auch immer.

    2) Der entpunkt des Tunnels, ist natürlich der ws-Server var endpoint = process.argv[2] || 'ws://www.sample.com';
    seltsamerweise wird in der Doku kein Port verlangt, und wie zuvor ist process.argv[2] stets 'undefined'

    Da fragt man sich echt warum so Beispiele/Einführungen nicht ein klein wenig umfangreicher gemacht werden :(

    3) wird das ganze nicht argh kompliziert sobald die Webseite hinter einem loadbalancer läuft oder stört den Tunnel das nicht?


    Naja also aktuell fehlt mir jeglicher Ansatz das Problem in den Griff zu bekommen.
    PS: auch dein nginx Vorschlag habe ich erfolglos getestet, ich werde jetzt mal eine subdomain mit SSL erstellen und versuchen den Server darüber laufen zu lassen.

    ::EDIT::
    Wie gesagt dieses Thema ist mir sehr wichtig, da ich den Server sonst nicht nutzen kann.
    Wie ich oben bereits erwähnt nutze ich ja http bzw. das https -Modul, diese Protokolle verfügen bereits über einen Umgang wenn der User proxy nutzt, so habe ich gerade noch dieses hier in stackoverflow gefunden.


    The communication channel is already established by the time the WebSocket protocol enters the scene. The WebSocket is built on top of TCP and HTTP so you don't have to care about the things already done by these protocols, including proxies.

    When a WebSocket connection is established it always starts with a HTTP/TCP connection which is later "upgraded" during the "handshake" phase of WebSocket. At this time the tunnel is established so the proxies are transparent, there's no need to care about them.
    Wenn ich das richtig verstehe, sagt er doch genau das was ich eingangs schon erwähnt, der server läuft über das http(s)-modul und daher sollte doch eigentlich nichts weiter nötig sein?

    Dieser Beitrag wurde bereits 4 mal editiert, zuletzt von Paykoman ()

  • Neu

    Paykoman schrieb:

    Ich möchte gern noch mal auf den proxy-agent eingehen, da bist Du leider nicht näher drauf eingegangen.
    Weil ich nicht weiß, wozu das gut sein soll. Wenn ich einen Reversproxy auf Nodebasis verwenden sollte, dann wäre das wohl eher Redbird.


    Paykoman schrieb:

    Ich habe dort heute auch schon einigie missglückte Versuche gestartet aber wenn ich es richtig verstehe, sollte dieses Modul doch eine Verbindung zu nginx der Webseite aufbauen und für proxys einen tunnel zum ws-Server schaffen?
    Glaube ich nicht und ist auch nicht nötig. Du kannst die Proxyverbindung doch auch mit NginX direkt konfigurieren. Hier mal ein Beispiel, dass für mich funktioniert:

    Quellcode: nginx.conf

    1. events {
    2. }
    3. http {
    4. server_tokens off;
    5. gzip on;
    6. sendfile off;
    7. include mime.types;
    8. default_type application/octet-stream;
    9. client_max_body_size 0;
    10. map $http_upgrade $connection_upgrade {
    11. default upgrade;
    12. '' close;
    13. }
    14. upstream socket {
    15. server 127.0.0.1:8081;
    16. keepalive 16;
    17. }
    18. server {
    19. listen 80;
    20. listen 443 ssl;
    21. ssl_certificate ../cert.cer;
    22. ssl_certificate_key ../cert.key;
    23. server_name socket.my.domain;
    24. if ($scheme = http) {
    25. return 301 https://$server_name$request_uri;
    26. }
    27. location / {
    28. proxy_pass http://socket;
    29. proxy_http_version 1.1;
    30. proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    31. proxy_set_header X-Real-IP $remote_addr;
    32. proxy_set_header X-Forwarded-Proto $scheme;
    33. proxy_set_header Host $http_host;
    34. proxy_set_header X-NginX-Proxy true;
    35. proxy_set_header Upgrade $http_upgrade;
    36. proxy_set_header Connection $connection_upgrade;
    37. proxy_max_temp_file_size 0;
    38. proxy_redirect off;
    39. proxy_read_timeout 120s;
    40. }
    41. error_page 404 /404.html;
    42. location = /404.html {
    43. root ../html;
    44. }
    45. error_page 500 502 503 504 /50x.html;
    46. location = /50x.html {
    47. root ../html;
    48. }
    49. }
    50. }
    Alles anzeigen

    Paykoman schrieb:

    wobei ich nicht weiß was für ein port hier verwendet werden muss.
    und seltsamer weiße ist process.env.http_proxy immer 'undefined', warum auch immer.
    Der Port müsste der sein, auf dem dein WebSocket sitzt und process.env.http_proxy ist wohl deshalb undefined, weil du es nicht in den Umgebungsvariablen definiert hast.




    Paykoman schrieb:

    und wie zuvor ist process.argv[2] stets 'undefined'
    process.argv sind Argumente, die du beim Programmstart manuell übergeben kannst.


    Paykoman schrieb:

    Wenn ich das richtig verstehe, sagt er doch genau das was ich eingangs schon erwähnt, der server läuft über das http(s)-modul und daher sollte doch eigentlich nichts weiter nötig sein?
    Wenn du den WebSocket nicht auf einen anderen Server/Port laufen lässt und das Protokollupgrade eingerichtet ist nicht.