Daten im VPN-Tunnel komprimieren um Durchsatz zu steigern?

[maltris]

Harro,

mal eine ganz theoretische Frage.

Ist es mit aktueller Software möglich, Daten am Anfangspunkt (Client) sowie am Endpunkt (VPN-Exit-Server) zu packen und wieder zu entpacken um so einen höheren Durchsatz zu erreichen? Sodass im Grunde alle Daten im Tunnel komprimiert werden und am Ende bei einem reellen Durchsatz von 2 Mbit vielleicht 2,5 Mbit zu schaffen sind? Gibt es solche Überlegungen oder ist das womöglich schon umgesetzt? Wäre das sinnvoll oder denkt sich mein Hirn wieder nur Knete aus?

Hoffe auf rege ITler-Diskussion.

[Natureshadow]

Das kann so ziemlich jedes seit 1990 erfundene Tunnel-Protokoll...

-nik

[wanne]

Ja klar. OpenVPN kann das direkt:
comp-lzo Heißt die Option. (In der server.conf und in der client.conf)

[uname]

Ist nur dumm wenn man im Tunnel bereits verschlüsselte Daten wie z.B. SSH hat. Dann verschlüsselt man nicht nur doppelt sondern komprimiert auch noch schlecht. Früher hat man dann gerne auf Komprimierung verzichtet, weil das neben der (doppelten) Verschlüsselung weitere CPU-Zeit gekostet hat.

[wanne]

Sowohl ssh wie auch OpenVPN verschlüsseln natürlich die komprimierten Daten und komprimieren nicht die Verschlüsselten. Das manko der CPU-Lastigkeit ist meine Meinung nach mittlerweile nicht mehr so schlimm. Die CPUs sind mittlerweils stark genug (Zumindest für übliche Übrtragungsraten.). Bleibt das es natürlich trotzdem noch Zeit kostet. Sprich man kauft sich die höhere Übertragungsrate durch höhere Latenz. (Die bei den meisten Tunnelverbindungen sowieso das viel größere Problem ist.)

[uname]

Sowohl ssh wie auch OpenVPN verschlüsseln natürlich die komprimierten daten und komprimieren nicht die verschlüsselten.

Sicher? Ich meinte es so. Bei Schachtelung stimmt deine Aussage nur zum Teil.

Code: Alles auswählen

OpenVPN [ SSH [ Klartext ] ] 

SSH verschlüsselt Klartext
OpenVPN komprimiert SSH
OpenVPN verschlüsselt komprimierte Daten

Natürlich könnte SSH auch komprimieren, welches die Sache dann noch etwas komplizierter macht.

SSH komprimiert Klartext
SSH verschlüsselt komprimierte Daten
OpenVPN komprimiert SSH
OpenVPN verschlüsselt komprimierte Daten

[feltel]

In solchen speziellen Anwendungsfällen kann man ja auch die SSH-eigene Komprimierung entweder generell oder hostbasierend deaktivieren.

[wanne]

@uname: Ah Ok, jetzt habe ich ein problem verstanden für solche Fälle deaktiviert man natürlich die Kompression oder man "verschlüsselt" SSH mit plain. (Wenn man die verschlüsslung von SSH nicht braucht.)

[dufty]

Komprimierung von bereits verschlüsselten Daten sollte sich schwierig gestalten,
da das Auffinden von "Mustern" natürlich erschwert wurde.

Eine _wahre_ Zufallsfolge (one-time-pad) lässt sich überhaupt nicht mehr komprimieren,
wenn ich das noch richtig im Kopfe habe ....

[maltris]

Hm, wenn man mal von SSH absieht und als Beispiel eine Datei, sagen wir 4,7 GB Bildarchiv (an sich unkomprimiert, Bilder sind in unterschiedlichen Formaten) hat:

- wie lange wuerde es etwa dauern, bis die Daten bei einer Verbindung von 1Mbit (also die ganz normale Leitung) uebertragen sind?

- wie lange wuerde es etwa dauert, bis die Daten bei Punkt A komprimiert, dann ueber die 1Mbit Leitung verschickt und bei Punkt B wieder dekomprimiert werden?

Die Frage ist also nun eigentlich: Kostet es mehr Zeit, die Daten zu komprimieren und wieder zu dekomprimieren oder sie unkomprimiert zu uebertragen? Ausgegangen von einer durchschnittlichen CPU (zB nen E8400) und durchschnittlich gut komprimierbaren Daten.
Latenzen sind bei einer solchen Uebertragung ja eigentlich nicht besonders wichtig, korrekt?

[uname]

Viele Bilder sind natürlich bereits komprimiert wie z.B. JPG, 1 Mbit/s ist natürlich ziemlich langsam und insgesamt hängt es natürlich auch von dem Grad der Komprimierung ab.

Moderne oder auch etwas ältere Rechner können z.B. komprimierte MP4-HD-Videos in Echtzeit abspielen. Der Engpass wäre auch dort nur das Netzwerk. Somit würde ich sagen, dass der Zeitaufwand für das komprimieren fast zu vernachlässigen wäre. Aber vielleicht ja jemand einen kleinen VPN-Tunnel und kann es mal ausprobieren.

[dufty]

- wie lange wuerde es etwa dauern, bis die Daten bei einer Verbindung von 1Mbit (also die ganz normale Leitung) uebertragen sind?

- wie lange wuerde es etwa dauert, bis die Daten bei Punkt A komprimiert, dann ueber die 1Mbit Leitung verschickt und bei Punkt B wieder dekomprimiert werden?

Kann Du alles selber stoppen und ausrechnen:
http://en.wikipedia.org/wiki/Bandwidth-delay_product

[wanne]

Die CPU lastest du nicht aus mit der Kompression. Selbst bei meinen 100MBit/s ist der mehrverbrauch zu crypto only nicht zu merken. Insofern würde ich sagen das die Bandbreite bestimmt hoch geht - sei es nur weil Sich die Header der Pakete Gut komprimieren lassen.

[Natureshadow]

sei es nur weil Sich die Header der Pakete Gut komprimieren lassen.

Tun sie?