Klartextprotokolle - Platzverschwendung?

[@night@]

Guten Abend allerseits
Schon seit längerem überlege ich, warum viele Klartextprotokoll so populär geworden sind. Prinzipiell sind sie doch extrem unperformant aufgrund ihrer hohen Datenlast. FTP und POP3 sind als Beispiel sehr gut geeignet:
Schliesslich könnte man bestimmt alle existenten Befehle in ein oder zwei Bytes als Opcodes verstauen. Doch stattdessen verwendet man lesbare Wörter wie USER oder PASS. Dies ist doch theoretisch gesehen eine vervierfachung der Datenmenge. Der einzige Vorteil liegt darin, dass der Mensch das Protokoll besser nachvollziehen kann.

Bei FTP oder POP3 werden ja praktisch gesehen nur 3-4 Bytes pro Abfrage verschwendet. Doch selbst dies scheint extrem wenig, wenn man es mit HTTP vergleicht. Ein gewöhnlicher HTTP-Header besteht ja geschätzt aus ca. 100-300 Zeichen. In den allermeisten Fällen würde doch bestimmt 1/50 der Bytes ausreichen, um alle wichtigen Daten zu übermitteln. HTTP-Anfragen sind doch theoretisch und praktisch gesehen eine extreme Verschwendung von Traffic. Heutzutage surft ja fast jede Person einmal am Tag im Internet. Ausserdem werden über unauffällige AJAX-Requests auch noch massenhaft Bytes "verschwendet". Oftmals werden ja nur wenig Informationen darüber angefordert. Im Falle des Datums oder einer booleschen Abfrage ist der Header bis zu 100mal grösser als der eigentliche Inhalt.
Warum hat sich soetwas unperformantes durchgesetzt? Im Vergleich zum durchschnittlichen HTML-Code ist der Header natürlich klein, aber warum sollte man unnötig Platz verschwenden? Da werden sich doch bestimmt ein paar intelligente Leute was bei gedacht haben, nur ich komm einfach nicht drauf...

 

[enkore]

Allein schon die Tatsache, dass du diese Protokolle von Hand lesen und schreiben kannst ist ein sehr großer Vorteil. Die extrem einfach Struktur und die Tatsache das alles in ASCII kodiert ist, lassen BE/LE Probleme gar nicht erst aufkommen. Außerdem sind Plain-Text-Protokolle viel einfach erweiterbar. Schau dir nur mal HTTP an, da gibt es sehr sehr viele Erweiterungen von einzelnen Vendors, das Protokoll an sich wurde auch sehr stark erweitert. Als Binärprotokoll könnte man sich mit Browsern und Clienten von vor 15 Jahren keine einzige Website mehr aufrufen.
Traffic ist heute billig, dieser Overhead für den Vorteil den er bringt absolut vernachlässigbar.

/e: Natürlich sind solche Protokolle auch einfacher zu implementieren, Binärprotokolle haben halt die Angewohnheit meist recht stark auf eine Rechnerarchitektur evtl. sogar Programmiersprache zugeschnitten zu sein...

 

[bitmuncher]

Man sollte auch nicht vergessen, dass die Performance der Client-Rechner erst im Laufe der Jahre zugenommen hat. Als die Protokolle eingeführt wurden, hatten Client-Rechner nicht sonderlich viel Rechenleistung, so dass sie Klartext wesentlich schneller verarbeiten konnten als wenn sie erstmal irgendwelche Opcodes verarbeiten hätten müssen.

Auch die einfache Fehleranalyse und Automatisierungen hatte aber sicherlich einen nicht unbeträchtlichen Anteil an der Durchsetzung dieser Protokolle. Ich brauche eben nicht zwingend einen Browser um mit einem Webserver zu kommunizieren, sondern kann dafür auch einfach Telnet verwenden. Genauso sieht es bei Mailservern (POP, IMAP, SMTP) aus. Das vereinfacht sowohl die Analyse von Server-Problemen als auch die Automatisierung von Abläufen auf Servern und Clients.

 

[@night@]

Schau dir nur mal HTTP an, da gibt es sehr sehr viele Erweiterungen von einzelnen Vendors, das Protokoll an sich wurde auch sehr stark erweitert.

Auch ein Binärprotokoll lässt sich erweitern. Man könnte sich zum einfacheren Lesen ja eine Art Programm basteln, welches bestimmte Bytes durch lesbare Wörter ersetzt (so ähnlich wie ein Assembler eben).

Als Binärprotokoll könnte man sich mit Browsern und Clienten von vor 15 Jahren keine einzige Website mehr aufrufen.

Natürlich hast du recht, dass ein Klartextprotokoll viel einfacherer zu erweitern ist. Allerdings könnte man auch bei Binärformaten mit Versionsnummern/Erweiterungsnummern rumexperimentieren.

Natürlich sind solche Protokolle auch einfacher zu implementieren, Binärprotokolle haben halt die Angewohnheit meist recht stark auf eine Rechnerarchitektur evtl. sogar Programmiersprache zugeschnitten zu sein...

Naja, dass sehe ich jetzt nicht so eng. Ich verstehe da nicht so den Unterschied, ob ich ein Protokoll in Windows oder Linux implementiere...
Und Programmiersprachen machen jetzt auch nicht so den Unterschied. Schliesslich sollte es mit jeder Sprache möglich sein, Binärcode zu vergleichen und zu interpretieren.

Traffic ist heute billig, dieser Overhead für den Vorteil den er bringt absolut vernachlässigbar.

Das ist natürlich das absolute Totschlagargument:wink: Wahrscheinlich hast du allerdings recht... Nur wenn ich mir allein schon die gewaltige Anzahl an Exabyte vorstelle, die man durch effektivere Protokolle einsparen könnte...

€dit: Ich habe euren Standpunkt ja schon längst kapiert, aber ich spinne das einfach mal nen bisschen weiter ^^

Ich brauche eben nicht zwingend einen Browser um mit einem Webserver zu kommunizieren, sondern kann dafür auch einfach Telnet verwenden.

Zur Fehleranalyse könnte man sich ja, wie oben geschrieben, einen "Konverter" programmieren, welcher einfach Bytecodes in Klartext umwandelt. Bei einfachen Protokollen ist dies ohnehin leicht zu realisieren.

Im Prinzip geht es mit ja nur um die gewaltige Anzahl an Personen, welche an Fehleranalyse gar nicht interessiert sind. Es geht bei Protokollen wie HTTP ja nicht um kleine Softwarefirmen, sondern um absolut jeden Internetbenutzer...
Da fällt schon eine ziemlich große Datenlast an. Es wirkt irgendwie so "unelegant".

 

[Chakky]

ich finde Klartext ganz praktisch und von der Abwärtskompatibilität ganz zu schweigen

Klar kannst du eine Art komprimierung drauf setzen auf das Protokoll nur welche folgen hätte es? Updatewahn und dann sind wieder ein Teil der sachen ausgeschlossen etc pp....

Datenlast hin oder her. Einen normalen Internetuser ist es völlig egal, wieviel Last entsteht und dafür den "aufwand" zu machen einen Konverter oder ähnliches zu Programmieren und flächendeckend zu nutzen halte ich für rausgeschmissene Zeit und Geld. Ich denke auch größere Firmen haben da schonmal dran geforscht und beschäftigen sich regelmäßig damit. Einfach so an einen Standard "rumfuschen" ohne dabei das laufende System zu beeinträchtigen halte ich für unmöglich.


//arg heute wieder mal Ausdrucksmäßig völlig daneben, Sry ^^

 

[xblax]

Also meiner Meinung nach sind Text Protokolle überholt. Aus historischer Sicht mögen sie zwar verständlich sein, aber im Endeffekt bringen sie doch mehr Probleme als sie lösen.

Textprotkolle sind:
- fehleranfälliger (string verarbeitung)
- haben overhead
- gegenüber neuen technologien unflexibel (z.B. UTF-8 )

Einziger Vorteil ist die Menschenlesbarkeit, was aber durch die Verfügbarkeit moderner Hilfsmitel, wie z.B. Wireshark, eigentlich keine Relevanz mehr hat.

Performancetechnisch sehe ich für Binärprotokolle nur Vorteile. Wenn man z.B. einen Integer oder Float direkt laden kann ist das wesentlich schneller und weniger Fehleranfällig.
Maschinenlesbare Formate waren auch vor 20 Jahren schon spezifiziert, also sehe ich da erst recht keine Inkompabilitäten. Ansonsten kann man durch Typisierung neue Datentypen in ein Binärprotokoll problemlos einbinden.

Viele Sicherheitslücken durch Buffer Overflows hätte man vermeiden können, wenn man Daten, wenn möglich, durch ein Längenfeld mit nachfolgenden Nutzdaten kodiert und sich nicht auf einen Zeilenumbruch verlässt, der nur neue Probleme schafft.

In E-Mails beispielsweise muss alles in ASCII umkodiert werden, woran man sehen kann, dass man sich beim ursprünglichen Design des Protkolls keine großen Gedanken über Anforderungen in der Zukunft gemacht hat. Dass es immer noch funktioniert verdankt man vielen "Hacks" und Protokoll Erweiterungen, die alles aber kein gutes Protokolldesign sind.

Für mich sind Text Protokolle eine Altlast mit der man nun leben muss. Bei neuen Protkollen sollte man die Finger davon lassen.

 

[enkore]

Performancetechnisch sehe ich für Binärprotokolle nur Vorteile. Wenn man z.B. einen Integer oder Float direkt laden kann ist das wesentlich schneller und weniger Fehleranfällig.
Maschinenlesbare Formate waren auch vor 20 Jahren schon spezifiziert, also sehe ich da erst recht keine Inkompabilitäten. Ansonsten kann man durch Typisierung neue Datentypen in ein Binärprotokoll problemlos einbinden.

Grade Floats dürfen und werden nie, nie, niemals übers Netzwerk binär transportiert. Da gibt es so viele Pitfalls wie bei HTTP, SMTP und POP3 zusammmen. Ints sehen auch wieder unterschiedlich aus, bei normalen Strings hast du besonders Überlaufprobleme nicht. Wäre HTTP ein Binärprotokoll, hätte das Längenfeld vermutlich 16 Bit, was für... 65 kB reicht...

Viele Sicherheitslücken durch Buffer Overflows hätte man vermeiden können, wenn man Daten, wenn möglich, durch ein Längenfeld mit nachfolgenden Nutzdaten kodiert und sich nicht auf einen Zeilenumbruch verlässt, der nur neue Probleme schafft.

Der erste doppelte Zeilenumbruch trennt Header und Nutzdaten, wo ist das Problem? Alles andere ist nicht im geringsten standardkonform und kann getrost ignoriert werden. Buffer Overflows hätten eh immer genug Gelegenheit und kommen nur bei schlampigen Programmieren zum Tragen.

In E-Mails beispielsweise muss alles in ASCII umkodiert werden, woran man sehen kann, dass man sich beim ursprünglichen Design des Protkolls keine großen Gedanken über Anforderungen in der Zukunft gemacht hat. Dass es immer noch funktioniert verdankt man vielen "Hacks" und Protokoll Erweiterungen, die alles aber kein gutes Protokolldesign sind.

Joar, aber diese Erweiterungen sind nur möglich, weil du eben die Protokolle gut erweitern kannst. Binärprotokolle und Versionierung? Das ich nicht lache, dass haben genug Leute versucht und sind kläglich gescheitert. Es hat gute Gründe, warum heutzutage auf Techniken wie SOAP (XML via HTTP) und REST (Meist auch XML via HTTP, nur eben ohne direkten Standard und weiter weg von RPC) gesetzt wird.

Für mich sind Text Protokolle eine Altlast mit der man nun leben muss. Bei neuen Protkollen sollte man die Finger davon lassen.

Nein. Ein neues Protokoll würde ich möglichst immer als Textprotokoll auslegen. Man verhindert damit so viele Probleme mit der Zukunft...

 

[xblax]

Grade Floats dürfen und werden nie, nie, niemals übers Netzwerk binär transportiert. Da gibt es so viele Pitfalls wie bei HTTP, SMTP und POP3 zusammmen. Ints sehen auch wieder unterschiedlich aus, bei normalen Strings hast du besonders Überlaufprobleme nicht. Wäre HTTP ein Binärprotokoll, hätte das Längenfeld vermutlich 16 Bit, was für... 65 kB reicht...

Nun man muss natürlich immer gemäß den gegebenen Anforderungen entscheiden. Ein Binärprotokoll kann natürlich auch ASCII Text senden wenn man möchte.
Allerdings sehe ich die Problematik nicht. Maschinenlesbare Darstellungen sind genauso spezifiziert wie die Darstellung in einer menschenlesbaren Form spezifiziert werden muss. Welche Formen man konvertiert ist wohl egal.

Der erste doppelte Zeilenumbruch trennt Header und Nutzdaten, wo ist das Problem? Alles andere ist nicht im geringsten standardkonform und kann getrost ignoriert werden. Buffer Overflows hätten eh immer genug Gelegenheit und kommen nur bei schlampigen Programmieren zum Tragen.

Dieses Verhalten kann man in Binärprotokollen genauso erzeugen wie in einem Textprotokoll.

Joar, aber diese Erweiterungen sind nur möglich, weil du eben die Protokolle gut erweitern kannst. Binärprotokolle und Versionierung? Das ich nicht lache, dass haben genug Leute versucht und sind kläglich gescheitert. Es hat gute Gründe, warum heutzutage auf Techniken wie SOAP (XML via HTTP) und REST (Meist auch XML via HTTP, nur eben ohne direkten Standard und weiter weg von RPC) gesetzt wird.

Nein. Ein neues Protokoll würde ich möglichst immer als Textprotokoll auslegen. Man verhindert damit so viele Probleme mit der Zukunft...

Ich sehe hier die Problematik nicht. Man muss einfach zwischen Syntax und Semantik abstrahieren. Es ist möglich zu jedem Textprotokoll ein binäres Äquivalent aufzustellen, welches außer in der Menschenlesbarkeit in allen Belangen überlegen ist.

 

[enkore]

Nun man muss natürlich immer gemäß den gegebenen Anforderungen entscheiden. Ein Binärprotokoll kann natürlich auch ASCII Text senden wenn man möchte.
Allerdings sehe ich die Problematik nicht. Maschinenlesbare Darstellungen sind genauso spezifiziert wie die Darstellung in einer menschenlesbaren Form spezifiziert werden muss. Welche Formen man konvertiert ist wohl egal.

Floats werden grundsätzlich nicht übers Netzwerk übertragen, weil es zum einen da wieder die üblichen Format-Probleme gibt (bei Floats kann das Umrechnen zwischen Standards sehr rechenaufwendig sein) und zum anderen ähnliche Problematiken wie beim direkten Vergleich von Floats auftreten.

Dieses Verhalten kann man in Binärprotokollen genauso erzeugen wie in einem Textprotokoll.

Ja also, der Sicherheitsaspekt is also schonmal wurscht.

Ich sehe hier die Problematik nicht. Man muss einfach zwischen Syntax und Semantik abstrahieren. Es ist möglich zu jedem Textprotokoll ein binäres Äquivalent aufzustellen, welches außer in der Menschenlesbarkeit in allen Belangen überlegen ist.

Hm? Die beste Trennung von Syntax und Semantik bieten doch gerade Textprotokolle. Die üblichen Verdächtigen arbeiten nach einer einfachen aber sehr mächtigen Syntax:

[Protokollspezifika]
name: wert\n
name2: wert2\n
\n
Inhalt

Syntax und Semantik perfekt getrennt.

Schönes Beispiel für ein sehr perfomantes und sehr schlechte erweiterbares Protokoll: IP. Das einzige was im Header gleich geblieben ist... das Versionsfeld, 4-Bit breit. Kompatibilität: null. Damals hat man sich eben für Perfomance entschieden, dafür haben wir heute halt die Probleme. Damals hat man das gigantische Wachstum nicht vorhergesehen.

 

[bad_alloc]

Dazu gibt es im Buch "The Pragmatic Programmer" eine sehr gute Abhandlung im Kapitel "The Power of Plain Text". Kurz gesagt sagen sie, dass man anstatt von Binärdaten Plaintext bevorzugen sollte, sofern es nicht die Leistung des Systems massiv einschränkt. Da im Internet eher Videostreams und Downloads von Binärdateien den Datenverkehr bestimmen, kann man davon ausgehen, dass HTML, POP3 usw. nicht ins Gewicht fallen.

Der Vorteil der Plaintextprotokolle liegt darin, dass sie nicht obsolet werden: Auch in einiger Zeit wird man rekonstruieren können, was einem der alte Server da zusendet. Kämen nur obskure Zahlenkommandos hätte man ein Problem. Zudem kann auch ein User verstehen was Schiefgeht. Anstatt dem User "Fehler 63 aufgetreten" vorzuhalten, kann die Anwendung einfach den Plaintextfehler wie "418: I'm a Teapot" anzeigen, ohne selbst jeden Fehlertext mit sich rumzuschleppen. Das erleichtert auch die Suche nach einer Lösung, da Fehlermeldungen vom Protokoll aus einheitlich sind.

 

[xblax]

Floats werden grundsätzlich nicht übers Netzwerk übertragen, weil es zum einen da wieder die üblichen Format-Probleme gibt (bei Floats kann das Umrechnen zwischen Standards sehr rechenaufwendig sein) und zum anderen ähnliche Problematiken wie beim direkten Vergleich von Floats auftreten.

Das Format in welchem Floats übertragen werden ist ja ansich unabhängig von der Frage ob Binär- oder Textprotokoll.
Man könnte bspw. eine binäre Festkommadarstellung wählen wenn man möchte. Ich sehe allerdings keinen sinn darin, eine binär vorliegende Zahl zunächst ins dezimal System zu konvertieren und anschließen wieder zurück.

Ja also, der Sicherheitsaspekt is also schonmal wurscht.

Man kann ein Protokoll immer unsicher gestalten. Es geht darum welche Möglichkeiten man hat um ein Protokoll sicher zu gestalten.

Hm? Die beste Trennung von Syntax und Semantik bieten doch gerade Textprotokolle. Die üblichen Verdächtigen arbeiten nach einer einfachen aber sehr mächtigen Syntax:

[Protokollspezifika]
name: wert\n
name2: wert2\n
\n
Inhalt

Syntax und Semantik perfekt getrennt.

Nein das ist ja gerade keine Trennung von Syntax und Semantik.
Semantisch gesehen hast du n Tupel (Name, Wert) und Inhalt. Name, Wert und Inhalt sind mit einer Bedeutung verknüpft.

Wie ich das nun kodiere ist Syntax. Wir können das nun als ASCII kodieren oder eben auch Binär.
Man benutze Typisierung und kann dann Selbstverständlich als Wert oder Name auch ASCII übertragen wenn man möchte. Aber eben paralell zu anderen Formaten.

Schönes Beispiel für ein sehr perfomantes und sehr schlechte erweiterbares Protokoll: IP. Das einzige was im Header gleich geblieben ist... das Versionsfeld, 4-Bit breit. Kompatibilität: null. Damals hat man sich eben für Perfomance entschieden, dafür haben wir heute halt die Probleme. Damals hat man das gigantische Wachstum nicht vorhergesehen.

Wenn man absolute Performance will, dann muss man immer auch Abstriche bei der Erweiterbarkeit machen. Das liegt aber nicht an daran, dass es sich dabei um ein Binärprotokoll handelt, sondern sondern an dem statischen Aufbau der Dateneinheiten, der notwendig ist um diese schnell in Hardware zu verarbeiten.

@bad_alloc
Nun also normalerweise sollte ein Protokoll ja spezifiziert werden. Wenn man nun fremde Serversoftware benutzt deren Protokoll weder in einer Spezifikation nachzulesen ist noch deren Verhalten bekannt ist, dann ist das imho eh bedenklich.

Und man kann auch mit einem Binärprotokoll Text versenden. Die Fehlernachrichten müssen nicht zwingend nur duch eine Konstante kodiert werden.