4
WAN-Accelerator - warum nicht als Service anbieten?
Hallo Forum.
Ich habe wieder mal eine von meinen komischen Ideen :P
Die Bandbreite bei den xDSL-Angeboten sind ja in letzter Zeit ganz schön in die Höhe gegangen ... bei uns in der Schweiz gibt es in ein paar Städten schon 100Mb/7Mb Anschlüsse ...
Ich jedoch tümple immernoch mit meinem ADSL5000/500 Anschluss herum, effektiv bekomme ich gerade mal 2400Kb/280Kb ... dies liegt leider an den schlechten Leitungen zu unserem Haus.
Von verschiedenen Firmen gibt es ja WAN Accelerator und WAN Optimizer, die verschiedene Algorythmen anwenden um den Datendurchsatz und die Latzenzeit zu erhöhen / verringern. (z.B. verspricht die Firma Riverbed je nach Art der Daten bis zu 200-fache(!!) Kompression) ... leider sind fast alle diese Produkte nur kommerziell erhältlich
Ausser diesem noch in der Entwicklungsphase steckenden Projekt habe ich nichts gefunden, was free oder Opensource wäre: http://www.trafficsqueezer.org/
Jetzt aber zu meiner Frage:
Wenn ich nichts falsch verstanden habe, sollte es ja kein Problem sein den Datendurchsatz der ADSL-Leitung so zu erhöhen ... bei mir zu Hause dass eine Ende, beim ISP das andere Ende ... zumindest in der Theorie :P der ISP wird da glaub nicht so begeistert sein :P
Nun bin ich ja wohl nicht der einzige, der noch auf langsam xDSL-Anschlüssen herumsitzt ...
Folgendes Szenario:
Root-Server beim ISP mit 100MBit-Anschluss
z.B. 10 User mit ADSL5000/500-Anschlüssen ...
Jeder richtet sich zu Hause ein PC oder etwas ein, dass als zusätzlicher Gateway fungiert und auf dem das eine Ende dieses WAN-Accelerators läuft ... der ganze Netzwerkverkehr zum ISP geht zusätzlich über diesen Gateway und wird dort komprimiert. Von dort wird der Netzwerkverkehr normal über den Router durchs WAN (ADSL-Anschluss) zum ISP geleitet, aber anstatt dort ins Internet geroutet zu werden, wird der Verkehr weitergeleitet zum Root-Server. Dort findet die Dekomprimierung statt und das Routing ins I-Net.
Also etwa so:
"Normal": Client<---LAN--->Router<---WAN--->ISP<---WAN--->I-Net
"WAN-Acc.": Client<---LAN--->Acc. Gateway<---XXX--->Router<---WAN--->ISP<---WAN--->Root-Server<---WAN--->I-Net
Spricht grundsätzlich etwas gegen dieses Konzept?
Klar macht es vieleicht weniger Sinn wenn jemand eine 25MBit-Leitung hat, diese zusätzlich zu komprimieren & co, aber langsamere Leitungen wäge es sicher ein interessantes Projekt.
Wenn man das Ganze noch kommerziell machen will, kann man dies ja als Service anbieten ... der Kunde bekommt eine vorgefertigte Appliance (z.B. ein ALIX) oder ein Image zum installieren, dann kann er sich mit einem Account zum Root-Server verbinden ...
Das Ganze ist halt nur mal ein "Hirngespinst" von mir :P Aber ich ärgere mich darüber, dass sie in den Städten die Leitungen immer weiter ausbauen und wir auf dem Land nichts davon haben.
Meinungen und Kritik ist erwünscht ;)
Gruss
Lousek
Ich habe wieder mal eine von meinen komischen Ideen :P
Die Bandbreite bei den xDSL-Angeboten sind ja in letzter Zeit ganz schön in die Höhe gegangen ... bei uns in der Schweiz gibt es in ein paar Städten schon 100Mb/7Mb Anschlüsse ...
Ich jedoch tümple immernoch mit meinem ADSL5000/500 Anschluss herum, effektiv bekomme ich gerade mal 2400Kb/280Kb ... dies liegt leider an den schlechten Leitungen zu unserem Haus.
Von verschiedenen Firmen gibt es ja WAN Accelerator und WAN Optimizer, die verschiedene Algorythmen anwenden um den Datendurchsatz und die Latzenzeit zu erhöhen / verringern. (z.B. verspricht die Firma Riverbed je nach Art der Daten bis zu 200-fache(!!) Kompression) ... leider sind fast alle diese Produkte nur kommerziell erhältlich
Ausser diesem noch in der Entwicklungsphase steckenden Projekt habe ich nichts gefunden, was free oder Opensource wäre: http://www.trafficsqueezer.org/
Jetzt aber zu meiner Frage:
Wenn ich nichts falsch verstanden habe, sollte es ja kein Problem sein den Datendurchsatz der ADSL-Leitung so zu erhöhen ... bei mir zu Hause dass eine Ende, beim ISP das andere Ende ... zumindest in der Theorie :P der ISP wird da glaub nicht so begeistert sein :P
Nun bin ich ja wohl nicht der einzige, der noch auf langsam xDSL-Anschlüssen herumsitzt ...
Folgendes Szenario:
Root-Server beim ISP mit 100MBit-Anschluss
z.B. 10 User mit ADSL5000/500-Anschlüssen ...
Jeder richtet sich zu Hause ein PC oder etwas ein, dass als zusätzlicher Gateway fungiert und auf dem das eine Ende dieses WAN-Accelerators läuft ... der ganze Netzwerkverkehr zum ISP geht zusätzlich über diesen Gateway und wird dort komprimiert. Von dort wird der Netzwerkverkehr normal über den Router durchs WAN (ADSL-Anschluss) zum ISP geleitet, aber anstatt dort ins Internet geroutet zu werden, wird der Verkehr weitergeleitet zum Root-Server. Dort findet die Dekomprimierung statt und das Routing ins I-Net.
Also etwa so:
"Normal": Client<---LAN--->Router<---WAN--->ISP<---WAN--->I-Net
"WAN-Acc.": Client<---LAN--->Acc. Gateway<---XXX--->Router<---WAN--->ISP<---WAN--->Root-Server<---WAN--->I-Net
Spricht grundsätzlich etwas gegen dieses Konzept?
Klar macht es vieleicht weniger Sinn wenn jemand eine 25MBit-Leitung hat, diese zusätzlich zu komprimieren & co, aber langsamere Leitungen wäge es sicher ein interessantes Projekt.
Wenn man das Ganze noch kommerziell machen will, kann man dies ja als Service anbieten ... der Kunde bekommt eine vorgefertigte Appliance (z.B. ein ALIX) oder ein Image zum installieren, dann kann er sich mit einem Account zum Root-Server verbinden ...
Das Ganze ist halt nur mal ein "Hirngespinst" von mir :P Aber ich ärgere mich darüber, dass sie in den Städten die Leitungen immer weiter ausbauen und wir auf dem Land nichts davon haben.
Meinungen und Kritik ist erwünscht ;)
Gruss
Lousek
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 132207
Url: https://administrator.de/contentid/132207
Ausgedruckt am: 25.11.2024 um 20:11 Uhr
4 Kommentare
Neuester Kommentar
Moin,
mal vielleicht ein Gedankenanstoß
auf Webseiten sind die *Trafficbringer* - also Bilder und Videos bereits komprimiert - da ist nix mehr zu komprimieren
Was um alles auf der Welt willst Du komprimieren - die dürre HTML/CSS Seite?
Gruß
24
mal vielleicht ein Gedankenanstoß
auf Webseiten sind die *Trafficbringer* - also Bilder und Videos bereits komprimiert - da ist nix mehr zu komprimieren
Was um alles auf der Welt willst Du komprimieren - die dürre HTML/CSS Seite?
Gruß
24
Sali
Ja, das stimmt wohl, Bilder und Videos sind schon komprimiert.
HTML/CSS ... warum nicht? Es schadet zumindest niemandem, und soviel ich weiss lassen sich gerade Textdateien ziemelich gut komprimieren.
Aber wenn ich nichts falsch verstanden habe, kann man z.B. beim Overhead der Protokolle extrem viel machen ... nicht dass man ihn irgendwie komprimiert, sondern dass man sagt, warum soll der genau gleiche Header 100 mal übertragen werden? Er kann ja auch gecached werden auf der anderen Seite und nur noch einen Verweis darauf gesendet werden der einen Bruchteil der Grösse hat ...
Wie gesagt, ich bin noch zu wenig in diesen tiefen der Netzwerktechnik um das wirklich zu verstehen, aber man lernt ja nicht aus und es wäre sicher einen interessanten Versuch (vieleicht nicht gerade mit 10 Members und einem Root-Server :P)
Ja, das stimmt wohl, Bilder und Videos sind schon komprimiert.
HTML/CSS ... warum nicht? Es schadet zumindest niemandem, und soviel ich weiss lassen sich gerade Textdateien ziemelich gut komprimieren.
Aber wenn ich nichts falsch verstanden habe, kann man z.B. beim Overhead der Protokolle extrem viel machen ... nicht dass man ihn irgendwie komprimiert, sondern dass man sagt, warum soll der genau gleiche Header 100 mal übertragen werden? Er kann ja auch gecached werden auf der anderen Seite und nur noch einen Verweis darauf gesendet werden der einen Bruchteil der Grösse hat ...
Wie gesagt, ich bin noch zu wenig in diesen tiefen der Netzwerktechnik um das wirklich zu verstehen, aber man lernt ja nicht aus und es wäre sicher einen interessanten Versuch (vieleicht nicht gerade mit 10 Members und einem Root-Server :P)
effektiv bekomme ich gerade mal 2400Kb/280Kb ...
hätte ich gerne...
Was um alles auf der Welt willst Du komprimieren - die dürre HTML/CSS Seite?
Auch die wird heute von gut konfigurierten Servern mit defalte oder gzip komprimiert.
Also wenn ich dein Konzept richtig verstehe willst du Multilink PPPoE machen ohne dafür auf einen ISP angewiesen zu sein und ohne, dass du selbst mehrere Leitungen brauchst?
Sprich du willst ein WLAN-Backbone bauen über das alle Nutzer und deren einzelne DSL-Anschlüsse mit einem Gateway verbunden sind, der dann die Daten splittet und über die einzelnen Verbindungen zum Server schickt?
Spricht technisch natürlich nix dagegen (außer dass du dann doppeltes NAT hast), aber bekannt ist mir dafür keine Lösung.
Grüße
Max
hoi dog
Hast du wirklich noch weniger wie 2400Kbit/s down und 280KBit/s up?
Entweder habe ich das Multilink PPPoE falsch verstanden oder du mich ein bisschen ;)
Meinst du, dass alle User per WLAN miteinandern verbunden sind und über einen gemeinsamen Gateway ins Internet gehen?
Und dass der Gateway mehrere DSL-Leitungen ins Internet besitzt und den Traffic darauf aufteilt? Also WAN-Loadbalacing?
Ich habe jedoch gemeint, dass der Netzwerkverkehr auf der Internetverbindung zusätzlich zu den "üblichen" Komprimierungsverfahren (HTTP-Komprimierung, Komprimierte Video- und Bilddateien) zusätzlich komprimiert wird, in dem z.B. sich wiederholenden Informationen wie Headers gecached werden und nicht mehr komplett gesendet werden.
Dies benötigt auf beiden Seiten der Verbindung ein Gerät, dass die Daten (ent-)komprimiert.
Gruss
Lousek
Hast du wirklich noch weniger wie 2400Kbit/s down und 280KBit/s up?
Entweder habe ich das Multilink PPPoE falsch verstanden oder du mich ein bisschen ;)
Meinst du, dass alle User per WLAN miteinandern verbunden sind und über einen gemeinsamen Gateway ins Internet gehen?
Und dass der Gateway mehrere DSL-Leitungen ins Internet besitzt und den Traffic darauf aufteilt? Also WAN-Loadbalacing?
Ich habe jedoch gemeint, dass der Netzwerkverkehr auf der Internetverbindung zusätzlich zu den "üblichen" Komprimierungsverfahren (HTTP-Komprimierung, Komprimierte Video- und Bilddateien) zusätzlich komprimiert wird, in dem z.B. sich wiederholenden Informationen wie Headers gecached werden und nicht mehr komplett gesendet werden.
Dies benötigt auf beiden Seiten der Verbindung ein Gerät, dass die Daten (ent-)komprimiert.
Gruss
Lousek
