Websocket auf Port 80 bzw. 443 legen ohne Workaround möglich? Sonst Wunsch! :D

[givemeone]

Hallo zusammen,

ich schaffe es nicht, den Websocket ebenfalls auf Port 80 bzw. 443 am Edomi-Server zu legen.
Da ich das für den externen Zugriff jedoch benötige (ich lasse nur 443 mit Client-Zertifikat durch!), muss ich dies im Moment mit einem Workaround über einen zweiten Host und Docker machen, der mir den Webport und den Websocket-Port zusammenführt. Klappt so auch wunderbar.
Apache sowie NGINX können ja problemlos Websocket und normales HTTP[s] über den selben Port handeln, daher wäre das gerade für EDOMI eine feine Sache
und würde zudem die Administration deutlich vereinfachen, da ab dann eine abweichende Portdefinition für den Websocket eher die Ausnahme wäre.

Gibt es dazu etwas, was ich übersehen habe, oder könnte man das als Feature, das sicher mit kaum Aufwand implementierbar wäre, einbinden?

Joe

[wintermute]

Das ist technisch nicht machbar, da dann zwei verschiedene Prozesse denselben Socket (so nennt man die Kombination aus IP und Port) auf demselben Host belegen wuerden und das geht nicht. Also entweder ein anderer Port oder eine andere IP...

[givemeone]

Danke für die Antwort. Dazu kenne ich eben die Architektur von EDOMI noch nicht gut genug.
Ich kenne das nur von anderen Systemen, die zB in PERL entwickelt wurden, wo Websocket und HTTP-Server am selben Port hören.
Aber diese nutzen dafür soweit ich weiß keinen eigenen Prozess.
Da mein Workaround recht gut funktioniert und dieser sich leicht mit Edomi-Docker umsetzen lässt, werde ich dort mal mich um eine Aufnahme
dieser Möglichkeit bemühen.

[wintermute]

Aber diese nutzen dafür soweit ich weiß keinen eigenen Prozess.

Ja klar, wenn es derselbe Prozess ist, dann ist das natuerlich kein Problem, aber bei Edomi sieht es so aus:

[root@edomi ~]# netstat -tulpen | grep :80
tcp        0      0 192.168.1.200:8080          0.0.0.0:*                   LISTEN      0          16715917   31876/php
tcp        0      0 0.0.0.0:80                  0.0.0.0:*                   LISTEN      0          10081      1475/httpd

Fuer die Websockets laeuft ein PHP-Prozess (mit pid 31876), auf Port 80 lauscht der Webserver (1475)...

[givemeone]

Fuer die Websockets laeuft ein PHP-Prozess (mit pid 31876), auf Port 80 lauscht der Webserver (1475)...

Und den o PHP eingebauten Webserver kann man für EDOMI nicht nutzen? Da ich ja davor noch einen NGINX setze, bräuchte ich hier keinen APACHE....,
also auch keinen separaten Prozess....

[starwarsfan]

Hi

Nein, das wird nicht funktionieren, da Edomi direkt mit dem Websocket-Port "spricht". Dort ist kein Webserver oder dergleichen dazwischen. Ob sich das umbauen lässt resp. sich überhaupt lohnt, kann nur gaert beantworten.

[wintermute]

PHP eingebauten Webserver kann man für EDOMI nicht nutzen

Das widerspricht diametral deiner Aussage von oben

das sicher mit kaum Aufwand implementierbar wäre

Deutlich weniger Aufwand ist es sicher dem Edomi-Host eine zweite IP zu geben, Nginx drauf zu installieren und den an diese IP zu binden. Und Nginx kann dann anhand der Daten unterscheiden ob es ein Websocket-Request oder normales HTTP ist?

[givemeone]

Ja kann es. Werde später hier bzw. Im Docker-Thread ein Beispiel posten

[wintermute]

Cool, danke schonmal!

[givemeone]

Hier ein Konfigurationsbeispiel im Docker-Thread.
Habe es dort gepostet, da ich eben docker einsetze und dieses mir schon automatisch die zweite interne IP liefert, die ich dann intern mit NGINX zusammenfasse
zu einer externen IP mit nur einem externen Port (443).

https://knx-user-forum.de/forum/proj...39#post1304239

@gaert , schön wäre es, wenn man den Websocket-Port für die Visu separat konfigurieren könnte, also zu welchem Port die Visu die Verbindung aufbaut.
Dann benötigt man intern nicht 2 separate IPs, sondern könnte schlicht EDOMI an Port 7080 horchen lassen, diesen über NGINX auf 443 "mappen" und von der Visu her die Verbindung eben auch auf 443 aufbauen...

[wintermute]

Err... diese nginx CFG erkennt aber keine Websocket Verbindungen, die leitet nur alle was nachweislich keine WS-Verbindungen entsprechend um?

[givemeone]

Sie leitet alles was ohne Dateinamen und Unterverzeichnis, also nur das korrekte, auf den websocket um. Edomi hat fur den Rest alles Dateinamen und Unterverzeichnisse, (/admin, /visu) ...
hast du es schon Mal versucht?

[wintermute]

hast du es schon Mal versucht?

Nein, ich habe keinen Reverse Proxy in Benutzung. Mich hat die Loesung aus rein akademischem Interesse interessiert weil ich es so verstanden hatte, dass Nginx anhand des Traffic (also auf Layer 7 oder 4 oder auf welchem ISO-Modell man sich grad bewegt) feststellt ob es eine HTTP oder eine WS Verbindung ist. Dem ist ja aber anscheinend nicht so.
Trotzdem ein netter Workaround, gefaellt mir, danke fuers teilen!

[givemeone]

... dass Nginx anhand des Traffic (also auf Layer 7 oder 4 oder auf welchem ISO-Modell man sich grad bewegt) feststellt ob es eine HTTP oder eine WS Verbindung ist.

Etwas wie das hier würde in NGINX ebenfalls funktionieren und wäre das, was Du suchst...

      if ($http_upgrade = "websocket") {
        set $my_http_upgrade $http_upgrade;
        set $my_connection "upgrade";
      }
                proxy_set_header Upgrade $my_http_upgrade;
                proxy_set_header Connection $my_connection;
                proxy_pass http://127.0.0.1:7080; # my existing websocket

das IF ist jedoch ein Performance-killer (wobei wohl jedoch eher bei deutlich mehr klicks), weshalb es nicht empfohlen wird.
Durch das obere Konstrukt ist es einfach nicht notwendig ;-)

sG
Joe