clkdiv
Goto Top

Bilder on demand: VPN nach Webserver nach Client. Wie?

Hallo und danke fürs Lesen!

Mein Problem: Ich habe ein VPN mit X Rechnern, die alle on demand Bilder herstellen und liefern sollen. Derzeit geht das so:

Das Web-Frontend schickt einen HTTP-Requests in das VPN, durch einen Router gelangt der Request dann zum richtigen Rechner, da läuft ein HTTP-Server. Der Rechner nimmt den Request entgegen, erzeugt schnell ein WebP, enkodiert es zu Base64, schickt es zum Webserver, der dekodiert es, speichert es als JPG, der Client bekommt die URL dazu und liest es vom Web-Server. Das ist zu lahm.

Ich suche nun eine Möglichkeit, wie das Bild wesentlich schneller zum Client kommt. Am schnellsten wäre ein direkter Download aus dem VPN, aber das ist wohl zu gefährlich.

Nun frage ich mich, ob der Web-Server nicht über file_get_content() das Bild binär aus dem VPN laden kann? Kann man ein VPN so öffnen, dass es das Adressieren über URLs erlaubt? Und würde es dadurch auch vulnerabel?

Oder besser: kann mir jemand einen Tipp geben, wie ich die Bilder schnellstmöglich aus dem VPN zum Client kriege?

Ganz herzlichen Dank!

Content-ID: 668653

Url: https://administrator.de/contentid/668653

Ausgedruckt am: 03.12.2024 um 17:12 Uhr

MirkoKR
MirkoKR 09.10.2024 um 05:46:56 Uhr
Goto Top
Moin.

Vorab:

Muss das Enkodieren/Dekodieren der Bilddatei innerhalb des VPN - Eh schon geschützt privat - sein?

Kann die Quelle nur WebP?

Ich würde schon an den multiplen Quelle-Webservern auf JPG umwandeln - Lastverteilung - und unverschlüsselt zum Gateway-Webserver via VPN ausliefern ...

Das spart sicher einen hohen Anteil Latenz ...

Wenn die Quell-Webserver IP-Kameras sind, wäre zu prüfen, ob dieser das Bild nicht direkt ein passendes Format und passende -gg. geringere - Auflösung liefern kann ...
... dazu dann - falls möglich - nicht benötigte Formate/Streams deaktivieren, was ebenfalls die Latenz auf dem Quell-Webserver - ? Kamera ? - deutlich reduzieren kann ...
kpunkt
kpunkt 09.10.2024 um 06:47:59 Uhr
Goto Top
Hm...keine Ahnung, was du da genau machst und was denn nun dein "VPN" ist, über das man Daten nicht direkt verschicken oder abholen kann bzw. sollte.
Ich halte schon mal die gesamte Codiererei für unnötig.
Ich würd halt erstmal den Befehl rausschicken, dass der Rechner ein Bild erstellen soll. Und dann einen weiteren Befehl, dass man vom Rechner das letzte erstellte Bild abholen soll. Ob geholt oder gesendet, je nachdem. Der Client soll dann eben schauen, dass er mit dem gerade gekommenen Bild umgehen kann.

Aber wie gesagt, ich weiß nciht, was du da genau machst.
Michi91
Michi91 09.10.2024 aktualisiert um 09:01:52 Uhr
Goto Top
Guten Morgen.

Hast du gemessen wo es genau lange dauert? Weißt du überhaupt was genau lahm ist?
Erstelle ein Protokoll mit Millisekundenzeitstempeln über folgendes Messpunkte:
- Start der Anfrage beim Webfrontend
- Ankunft beim "richtigen Rechner"
- Ende der Bearbeitung beim "richtigen Rechner",
- Vollständiger Empfang beim Webfrontend Server,
- Ende der Konvertierung auf dem Webserver, Aufruf durch den Client.


Bezüglich VPN's und file_get_content():
Ähnlich wie @kpunkt stehe ich ein wenig auf dem Schlauch und verstehe nicht ganz das Konstrukt und welchen Zweck es hat...

Beantworte doch bitte folgende Fragen:
- Wer administriert das VPN? Bist du der Betreiber?
- Wer betreut die Worker-Nodes (alias "richtige Rechner"), sind das deine oder irgendwelche Fremdrechner?
- Wer hat den HTTP-Service auf den Worker-Nodes programmiert?
- Warum sollte das VPN unsicher sind? Virtual Private Networks sind doch gerade dazu da, Inhalte privat zu halten...
- Wer oder was ist dieser Request Router? Eine Art Loadbalancer der schaut welche Worker-Node gerade frei ist?

Wichtig: VPN ist regelt den Transport von Datenpaketen und hat nichts mit file_get_content() oder URL's am Hut... Das passiert eher in der Anwendungsschicht (OSI-Modell) und musst du gedanklich relativ strikt trennen!

Vielleicht zeichnest du uns mal das Konstrukt mit mehr Details auf
aqui
aqui 09.10.2024 aktualisiert um 09:57:18 Uhr
Goto Top
Am schnellsten wäre ein direkter Download aus dem VPN, aber das ist wohl zu gefährlich.
Was sollte daran denn "gefährlich" sein?? Genau dafür ist ein VPN ja gemacht und bezieht sich, wie oben von den Kollegen schon richtig gesagt, rein auf die Netzwerk Infrastruktur. Natürlich nur wenn man es auch, wie üblich, selber betreibt!
kpunkt
kpunkt 09.10.2024 um 10:01:16 Uhr
Goto Top
Vielleicht ists ja eine der nördlicheren VPNs.....
aqui
aqui 09.10.2024 um 12:39:49 Uhr
Goto Top
Sowas machen ja nichtmal mehr Dummies heutzutage! face-wink
clkdiv
clkdiv 14.10.2024 aktualisiert um 07:05:23 Uhr
Goto Top
Hallo und danke für die Antworten.

Im Moment ist ein Flaschenhals das Base64 en- und dekodieren. Das kriege ich geregelt.

Aber eine weitere Optimierungsmöglichkeit wäre eben, wenn das vom Client angeforderte Bild nicht über den Web-Server zum Client käme, sondern direkt aus dem VPN. Richtig?

Bist jetzt ist das VPN nicht offen für Downloads, nur für HTTP Requests. Es gibt also keine URLs, die direkt ins VPN weisen.

Das würde ich gerne ändern, weil ich mir davon verspreche, dass diese Bilder schneller zum Client kommen. Ich habe die Zeiten gemessen, ja, es geht aber nicht darum, wie lange es jetzt dauert, sondern wie es am schnellsten geht.

Das VPN besteht aus selbst betriebenen Rechnern, die alle hinter einem Router hängen. Der Router hat Ports geöffnet, die dem Web-Server bekannt sind, durch diese Ports gelangen die Requests zu den Render-Stationen. All das kann ich konfigurieren (lassen), es ist in der direkten Obhut des Administrators.

Und welche Sicherheitsaspekte sind da involviert? Die Bilder sind Public, aber wird das VPN vulnerabel? Was würdet ihr machen?

Vielen Dank!
kpunkt
kpunkt 14.10.2024 aktualisiert um 07:19:56 Uhr
Goto Top
Zitat von @clkdiv:

Was würdet ihr machen?
Vernünftige Site-to-Site-VPN und feddich. Da kannste von deinen Servern/Clients rauf- oder runterladen wie du lustig bist.

An deiner Stelle würde ich mir da so gar keinen Kopf drüber machen (weil Wissen bzw. Möglichkeit über das, was da gemacht wird ist eh nicht recht groß), sonden dein Anliegen dem Admin vortragen.
clkdiv
clkdiv 14.10.2024 um 08:51:26 Uhr
Goto Top
Der ist leider weg. Und ich möchte das auch selber verstehen. Mir geht es darum, dass ich das Thema, wenn ich es denn aufbringe, selber auch einigermaßen untermauern kann.

Ich habe nicht verstanden, was Site-to-Site-VPN ist. Das hört sich so an, als ob der Web-Server, der den initialen Request bekommt, Zugriff auf das VPN hat, von da das Bild bekommt, und es dann an den Client durchreicht. Wenn es das ist, das ist es ja gerade, was ich abkürzen will. Oder habe ich Site-to-Site falsch verstanden?
kpunkt
kpunkt 14.10.2024 um 09:03:41 Uhr
Goto Top
https://surfshark.com/de/blog/site-to-site-vpn

Da du es aber schon gar nicht schaffst zu sagen, was denn bei euch vorhanden ist, ist das reines Kristallkugellesen und dementsprechend kann man auch keine wirkliche Empfehlung oder Erklärung abgeben.

Warte, bis der Admin wieder da ist.
clkdiv
clkdiv 14.10.2024 aktualisiert um 09:35:58 Uhr
Goto Top
Ich hatte mir Mühe gegeben, zu sagen, was da ist. Es gibt einen Router, der geöffnete Ports hat, dahinter PCs, die Requests annehmen. Alles steht hier physisch vor Ort.

Dann gibt es einen Web-Server, der bei einem Provider läuft, der hostet eine Webseite und schickt Requests durch die Ports an die PCs im VPN. Von da bekommt er dann die on demand hergestellten Bilder, gibt sie weiter an den Client. Die Bilder gehen also erst zum Provider, dann an den Client. Da würde ich gerne herausfinden, ob und wie man das abkürzen kann.

Es gibt derzeit keinen Administrator, und darum geht es auch nicht. Es geht mir darum, herauszufinden, wie die Technologie aussehen könnte, um die Bilder so schnell wie möglich zum Client zu bekommen.

Was musst du noch wissen? Was fehlt noch, damit du einen Vorschlag machen kannst? Habe ich Site-to-Site-VPN verstanden? Das Bild geht dann, so wie bis jetzt, zum Host der Webseite, also zum Provider, und dann zum Client? Vielleicht sollte ich noch dazu sagen, dass es keinen Authentifizierungsmecanismus geben darf. Die Bilder sollen von jedem angefragt werden können, also wirklich Public sein.

Vielen Dank!
kpunkt
kpunkt 14.10.2024 aktualisiert um 09:58:08 Uhr
Goto Top
Ich versteh jetzt überhaupt nix mehr.

Es gibt also eine Website, die ihr nicht selber hosted und euch auch nicht gehört(?). Auf die kann man öffentlich vom Internetcafe aus zugreifen und man kann irgendwelche Bilder anfordern.
Der Webserver schickt dann also die Anfrage an eure Firma. Dort wird das gewünscht Bild dann als WebP erzeugt (was immer das auch meint) und wird in Base64 kodiert und an den Webserver geschickt. Der Webserver nimmt dann das Bild, dekodiert es, wandelt das WebP in JPG um und veröffentlicht es dann, sodass man das Bild im Internetcafe ansehen kann.
Heißt also eure Firma ist das Backend zum Webserver, der als Frontend dient.

Erster Ansatz von mir wär die Clients bei euch komplett rauszunehmen und alles auf den (oder die) Server zu packen. Muss euch halt gehören. Da fällt dann das hin und her weg.
Ihr liefert dann nur noch die Rohdaten und packt die gleich auf den Server.
clkdiv
clkdiv 14.10.2024 aktualisiert um 11:15:56 Uhr
Goto Top
Hallo danke für die Nachricht. Du hast schon richtig verstanden, glaube ich. face-smile

Die Webseite gehört uns, läuft halt ganz regulär bei einem Provider, aber nicht auf einem virtuellen Server. Stinknormaler Provider, NGinx, PHP. Sie ist öffentlich vom Internetcafé aus erreichbar. Kein Login, nichts.

Die clients bei uns, also die Render-Nodes, können nicht rausgenommen werden, es sind physische Rechner und das muss auch so bleiben, das sind extrem leistungsstarke Dinger, die halt on demand 3D-Bilder erzeugen. Die müssen hier sein. Sonst hätten wir auch kein VPN. Ja, sie erzeugen WebP, wenn du fragst, was das meint, was kann ich dazu noch beantworten? Ganz normale WebP halt.

Die Bilder entstehen also on demand und können nicht vorher generiert werden.

Um ein Hinundher kommen wir nicht herum.

Vielen Dank!
kpunkt
kpunkt 14.10.2024 um 11:14:37 Uhr
Goto Top
Zitat von @clkdiv:

Um ein Hinundher kommen wir nicht herum.
Das ist dann auch deine Antwort und der Grund, wieso es eben so läuft bei euch.
Da wird man auch um die Base64-Codiererei eher nicht drumrumkommen. Und die Umwandlung in JPG wird aus Kompatibilitätsgründen wohl auch noch immer benötigt werden.

Schneller wirds halt nur, wenn die Verbindung zwischen Frontend und Webend wegfällt oder halt aufgebohrt wird. Aber ich vermute fast, dass da auch schon was vernünftges da sein wird.
clkdiv
clkdiv 14.10.2024 aktualisiert um 11:21:13 Uhr
Goto Top
Base64 ist nur nötig, weil die Bilder als Bestandteil von JSONs verschickt werden. Aber darum geht's ja nicht.

Meine Frage ist, ob man das VPN sozusagen so öffnen kann, dass die Besucher der Seite die Bilder aus dem VPN bekommen, nicht mehr vom Web-Server beim Provider. Und wenn ja, wie man das am besten angeht.
kpunkt
kpunkt 14.10.2024 um 11:30:49 Uhr
Goto Top
Nö. Die Bereitstellung erfolgt ja auf dem Webserver. Außerdem würdest du die komplette VPN aushebeln.
Wie gesagt, Backend und Frontend zusammenlegen.
Wenn das Backend nicht zum Frontend darf, muss halt das Frontend zum Backend.
Aber es wird schon einen Grund haben, wieso ihr da nicht selber als Webserver/Hoster auftretet.

Nochmal: Lass das dem Admin machen. Der führt das aus, was die Geschäftsleitung angewiesen hat. Oder mach dich erstmal darüber schlau, wieso es jetzt bei euch so ist, wie es ist. Auf technischer und auch auf wirtschaftlicher Ebene. Und was da sonst noch alles reinpfeifft, was man beachten muss.
Nur weil etwas mit IT realisiert wird, heißt das nicht, dass die IT die vorgebende Stelle ist.
clkdiv
clkdiv 14.10.2024 aktualisiert um 12:16:59 Uhr
Goto Top
Vielen Dank für deine Antwort.

Irgendwie kann ich mir nicht vorstellen, dass ein VPN nicht öffentlich gemacht werden kann. Und wie gesagt, es gibt derzeit keinen Admin. Deshalb kann ich mich auch nicht schlau machen. Es ist, wie ich es beschrieben habe, mehr habe ich nicht.

Ich will das auch nicht selber aufbauen, ich will nur verstehen, was man machen kann, um das doppelte Verschicken der Bilder zu vermeiden.

Die Bereitstellung erfolgt derzeit über den Webserver, ja. Genau das ist eben meine Frage: Kann man eine direkte Bereitstellung vom VPN erreichen? Das sollte doch gehen. Wieso würde ich das VPN "aushebeln", es würde doch im Gegenteil weiter ganz wesentlich zum Flow beitragen, nein?

Das Hosten der Webseite auf einem eigenen Server kommt auch nicht in Frage, das soll definitiv da bleiben, wo es ist. Die Idee, das zusammenzulegen, ginge nur in einer Richtung: Web-Seite auf eigenem Server hosten, ja, aber das ist, wie gesagt, nicht gewünscht. Aber danke für den Vorschlag.

Noch eine Idee, wie man das VPN dem Client direkt zugänglich machen könnte?

Vielen Dank!
kpunkt
kpunkt 14.10.2024 um 12:52:01 Uhr
Goto Top
Natürlich kannst du die VPN "öffentlich" machen.
Ist dann halt wie eine sicherheitstechnisch gut ausgestattete Haustür, bei der der Schlüssel von außen steckt.

Die VPN ist auch so rein gar nicht dein Problem. Es ist die Verbindung Backend zum Frontend. Aber nicht, dass ich das jetzt schon zigmal geschrieben hätte.
Wie gesagt, such dir jemand der zumindest ansatzweise etwas Ahnung hat. Du träumst hier von irgendwelchen völlig komischen Sachen, die nicht mal das Problem sind.

Ich bin da jetzt raus.
clkdiv
clkdiv 14.10.2024 aktualisiert um 17:27:40 Uhr
Goto Top
Ja, trotzdem vielen Dank.

Ich habe allerdings nicht verstanden, warum mein Problem die Verbindung Backend zum Frontend sei. Ich habe eigentlich kein Problem, ich will nur herausfinden, ob ein Optimierungspotential nutzbar gemacht werden könnte.

Mich interessieren deshalb gerade die Maßnahmen, die man ergreifen müsste und könnte, um das geöffnete Netz möglichst unangreifbar zu machen. Eine Idee wäre, es komplett vom Firmennetz zu trennen, also wirklich derart, dass es von public nur über einen einzigen Port eines extra dafür aufgestellten Routers erreichbar wäre, und dahinter einen möglichst wenig angreifbaren Dienst zu betreiben, der nichts anderes macht, als die Requests zu verteilen. Einen Dispatcher, der alles überwacht.

In dem Netz wären dann weder Firmendaten noch sonst was wirklich Interessantes. Nur Windows-Rechner ohne was anderes als der kompilierten Software, die Bilder on demand herstellt. Sonst Leere und öffentlich zugängliche Bilder.

Man könnte das Netz wirklich komplett vom Firmennetz trennen, so weit gehend, dass neue Software nur per Anstecken einer Festplatte aufgespielt werden könnte. Über das Netz also auch unzugänglich für alle Mitarbeiter.

Vielleicht hat jemand dazu eine Meinung und Tips? Wenn es nicht geht, dann bleibt die Architektur eben wie sie ist, mit WebP zum Web-Server und dann zum Client. Geht auch, aber ich würde es doch gerne mal rausfinden, ob und wie man den Doppelversand vermeiden kann.

Vielen Dank!
aqui
aqui 14.10.2024 aktualisiert um 17:31:56 Uhr
Goto Top
clkdiv
clkdiv 14.10.2024 um 17:40:02 Uhr
Goto Top
Ah, super! Client-VPN! Nie gehört.

OK, lese ich mir durch. Der Dispatcher, den ich mit Node-RED schon programmiert habe, läuft unter Linux etc. Da sollte man das doch einigermaßen nutzbar machen können.

Vielen Dank!
Michi91
Michi91 17.10.2024 um 12:13:29 Uhr
Goto Top
Viel Erfolg!

Wenn die Working-Nodes bei euch stehen, warum kann dann auf den Nodes nicht direkt zur JPG konvertiert und dann als Base64 weitergeleitet werden? Bin mir sehr sicher, dass das schon einiges bringen wird, da man sich den ganzen overhead und lastsharing auf dem Webserver spart.

Eventuell ist es sogar möglich den Base64 direkt an den Client auszuliefern und diesen das dann falls nötig in Binärcode wieder umwandeln zu lassen? Kommt halt drauf an, was dieser Client ist. Wenn es eine Website ist, ist das easy mit JS machbar...

Ich glaube nicht, dass es einen bedeutenden Geschwindigkeitsvorteil gibt, wenn man auf VPN verzichtet, zumindest nicht, wenn das durchschleifen sauber umgesetzt wurde...
Durch den fehlenden Doppelversand spart man sich allerdings Traffic und Bandbreite(was dann eventuell doch zu besserer Geschwindigkeit führen könnte...)

Im Moment ist ein Flaschenhals das Base64 en- und dekodieren. Das kriege ich geregelt
Das hoffe ich, wie gesagt, eventuell ist das dekodieren durch den Client ja schon eine Variante. Eventuell kann ja sogar das konvertieren von WEBP zu JPG durch den Client erfolgen: https://github.com/tomaszs/webp-to-jpg
Alternativ könntest du dir auch anderen Kodierungen als Base64 ansehen, da gibts auch ein paar die flotter sind face-smile

Grüße face-smile
clkdiv
clkdiv 19.10.2024 aktualisiert um 20:42:43 Uhr
Goto Top
Hallo und danke. Ich habe die Idee des Client-VPN im Unternehmen vorgestellt und das wird wohl so gemacht.

Mir geht es bei der Lösung ja eben auch darum, dass der Client die Bilder nicht über den Umweg Webserver bekommt. Und Base64 will ich auch ganz vermeiden. Ich habe die Render-Nodes mit Unreal Engine jetzt mit einem selbst geschriebenen Plugin dazu gebracht, den rohen Pixel-Buffer auf eine Ramdisk auszuspucken, der kann dann nahtlos in WebP gewandelt werden. Das ist extrem schnell und muss nun asap zum Client, eben am besten ohne Konvertierungen und ohne Umwege. Das war ja der Inhalt meiner Frage hier.

Da nochmal vielen Dank an euch, insbesondere an aqui, der mich auf den hoffentlich richtigen Weg gebracht hat.

Vielen Dank!
aqui
aqui 20.10.2024 um 11:09:26 Uhr
Goto Top
Mit der Entscheidung machst du nichts falsch!

Wenn es das denn nun war bitte deinen Thread dann auch als erledigt markieren!
Wie kann ich einen Beitrag als gelöst markieren?
clkdiv
clkdiv 22.10.2024 um 18:16:05 Uhr
Goto Top
Hallo und danke. Inzwischen hat sich herausgestellt, dass das VPN tatsächlich schon mit OpenVPN betrieben wird und dass es mal als Client-VPN gedacht war, aber dann im Laufe der Zeit doch mehr und mehr mit dem eigentlichen Firmennetz verschmolzen ist.

Wenn es gestattet ist, würde ich den Fred aber noch eine Weile offen lassen, weil ich glaube, dass da noch was kommt. Oder dann lieber einen anderen starten?

Danke nochmal!
aqui
aqui 23.10.2024 um 10:15:12 Uhr
Goto Top
Kannst hier dann weitermachen. Das macht ja am meisten Sinn... face-wink