Internet-Protokolle, Teil 2: Anwendungsprotokolle im Vergleich
Seite 3: Protokollstapel und Übersicht
Modul oder Monolith
Das OSI-Modell sieht einen modularen Ansatz für Anwendungsprotokolle vor. Funktionen auf verschiedenen Ebenen sind gegeneinander austauschbar und klar abgegrenzt. Im TCP/IP-Modell enthält ein Anwendungsprotokoll unter Umständen alle Funktionen der OSI-Ebenen 5 bis 7 in einer monolithischen Implementierung. Da TCP bereits über umfangreiche Funktionen verfügt, sind Anwendungsprotokolle schnell und einfach zu implementieren. Eine Aufteilung in kleinere Module erscheint daher nicht sinnvoll. Tatsächlich nutzen Anwendungen die TCP/IP-Socket-Schnittstelle häufig direkt. Genaue Überlegungen dazu, ob die beschriebenen Protokollfunktionen für die eigene Socket-Umsetzung nötig sind, erlauben eine bessere Einschätzung des Entwicklungsaufwands und lohnt daher in jedem Fall.
Anwendungsprotokolle stapeln
Auf den Anwendungsschichten 5 bis 7 des OSI-Modells sind modular einsetzbare, spezialisierte Protokolle vorgesehen. Im TCP/IP-Modell bildet die Anwendungsschicht einen soliden Block, der die Funktionen der Protokolle nicht weiter unterteilt. Eine Modularität wird durch das Stapeln von Anwendungsprotokollen erreicht. So ist beispielsweise SOAP für den Transport über verschiedene Anwendungsprotokolle definiert. Das jeweils darunter liegende Protokoll kommt auf OSI-Schicht 5 für den Transport zum Einsatz, bleibt jedoch im TCP/IP-Modell, der Anwendungsebene zugeordnet.
Abbildung 3 zeigt den Aufbau des Protokollstapels für einige Beispiele. Das jeweils für den Datentransport verwendete Protokoll schränkt die Möglichkeiten des darauf aufsetzenden Anwendungsprotokolls ein. Nutzt eine Applikation für den Transport ein Client/Server-Protokoll wie HTTP, ist beispielsweise Peer-to-Peer-Kommunikation keine Option.
Die Protokolle
Die bisher beschriebenen Eigenschaften sind in folgender Tabelle für eine Auswahl von Anwendungsprotokollen gegenüber gestellt. Nicht immer sind die Ausprägungen der Eigenschaften identisch. Ein Blick in die Spezifikation des jeweiligen Protokolls ist daher stets zu empfehlen.
| BEEP | CoAP | FTP | HTTP/1.1 | HTTP/2 | |
| Transport | TCP | UDP | TCP | TCP | TCP |
| Session | ✔ | ✔ | ✔ | ||
| Authentication | ✔ | ✔ | ✔ | ✔ | |
| Synchron | ✔ | ✔ | ✔ | ✔ | ✔ |
| Pipelining | ✔ | ✔ | ✔ | ||
| Asynchron | ✔ | ✔ | ✔ | ||
| Kanäle | ✔ | ✔ | |||
| Request/Response | ✔ | ✔ | ✔ | ✔ | ✔ |
|
Single call, Multiple Answer |
✔ | ||||
|
Unacknowledged Message |
✔ | ✔ | |||
| Multicast | ✔ | ||||
| Peer-to-Peer | ✔ | ||||
| Client/Server | ✔ | ✔ | ✔ | ✔ | ✔ |
| Distributed Client/Server | ✔ | ||||
| Publish/Subscribe | ✔ | ✔ | push | ||
| Message Broker | |||||
| Message Data | Binary* | Binary | Text* | Text | Binary |
| MQTT |
RPC |
SMTP |
SOAP |
XMPP |
|
| Transport | TCP | HTTP*** | TCP | HTTP*** | TCP |
| Session | ✔ | ✔ | ✔ | ✔ | |
| Authentication | ✔ | ✔ | ✔ | ✔ | |
| Synchron | ✔ | ✔ | ✔ | ✔ | ✔ |
| Pipelining | ☑ | ☑ | |||
| Asynchron | ☑ | ☑ | |||
| Kanäle | |||||
| Request/Response | ✔ | ✔ | ✔ | ✔ | |
| Single Call, Multiple Answer | |||||
| Unacknowledged Message | ✔ | ✔ | |||
| Multicast | |||||
| Peer-to-Peer | ☑ | ✔ | |||
| Client/Server | ✔ | ✔ | ✔ | ✔ | ✔ |
| Distributed Client/Server | ✔ |
✔ |
|||
| Publish/Subscribe | ✔ | ✔ | |||
| Message Broker | ✔ | ||||
| Message Data | Binary* | Text** | MIME | XML | XML |
* ist Default, kann aber angepasst werden
** je nach RPC-Typ unterschiedlich (zum Beispiel XML für XML-RPC)
*** kann beliebe Nachrichtenprotokolle verwenden
☑ abhängig vom Transport oder der jeweiligen Anwendung
- BEEP: Die IETF veröffentlichte das Blocks Extensible Exchange Protocol 2001 in RFC 3080 als Standard. BEEP ist unabhängig vom Transportprotokoll definiert und ermöglicht den gleichberechtigten Austausch von Nachrichten zwischen Netzknoten. Das Verwenden von TCP als Transportprotokoll für BEEP ist in RFC 3081 beschrieben.
- CoAP: Das Contrained Application Protocol (CoAP) ist für die speziellen Anforderungen von Anwendungen vorgesehen, die Geräte mit geringer Leistung wie Sensoren, Schaltern, Ventilen oder Ähnlichem miteinander vernetzen und steuern. Der CoAP-Standard ist in RFC 7252 beschrieben. Eine einfache Anwendung, vielseitige Einsetzbarkeit, ein sparsamer Umgang mit Ressourcen und die Möglichkeit, das Internet als Transportweg zu nutzen, waren Designziele des Protokolls.
- FTP: Bereits 1985 veröffentlicht die IETF das File Transfer Protocol (FTP) als Standard in RFC 959. Ziel des Protokolls ist es, die Freigabe und den Austausch von Dateien auf unterschiedlichen Plattformen zu ermöglichen.
- HTTP/1.1: Das Hypertext Transfer Protocol (HTTP) ermöglicht den Austausch von Textnachrichten zwischen Client und Server. Version 1.1 führt neben strengeren Richtlinien für die Implementierung eine bessere Unterstützung von Proxies, Caching und die Wiederverwendbarkeit von Transportverbindungen ein. Die IETF veröffentlichte 1999 den bis heute verwendeten Standard in RFC 2616.
- HTTP/2: Auch wenn HTTP/2 als Nachfolger von HTTP/1.1 gilt, gibt es erhebliche Unterschiede, die eine gesonderte Betrachtung erfordern. Eine Transportverbindung lässt sich für asynchrone Kommunikation nutzen, was Head-of-line Blocking vermeidet. Eine binäre Darstellung der Nachrichten erhöht die Effizienz der Datenübertragung. Mit der Push-Technik können Server Antworten aktiv an Clients schicken.
- MQTT: Das Message Queue Telemetry Transport Protocol (MQTT) ist ein OASIS-Standard, der ähnlich wie CoAP für verteilte Anwendungen in Netzen mit geringer Bandbreite und mit Geräten, deren Ressourcen eingeschränkt sind, entwickelt wurde. Oft verwenden Anwendungen im sogenannten Internet of Things (IoT) MQTT.
- RPC: Das Remote Procedure Call Protocol (RPC) legt fest, wie eine Funktion auf einem entfernten Server mittels einer Nachricht, die einen Namen oder eine ID enthält, aufgerufen wird und das Ergebnis des Aufrufs zurückliefert. Seit der Veröffentlichung des ersten Standards im Jahre 1976 sind viele Varianten entstanden. Der aktuelle Standard für RPC ist in RFC 5531 definiert. Eine Variante ist XML-RPC, das als Standard mit BEEP als Transportprotokoll in RFC 3529 definiert ist. RPC ist weitgehend unabhängig vom Transportprotokoll und daher modular einsetzbar.
- SMTP: Eine der wichtigsten Anwendung des Internet ist das Senden und Weiterleiten von E-Mails. Für diesen Zweck wurde das Simple Mail Transfer Protocol (SMTP) entwickelt. Wie FTP dient es einem speziellen Zweck. Da die ursprüngliche Version aus einer Zeit stammt, in der es noch keine Spam-Mails gab, war eine Authentifizierung nicht vorgesehen. Ein entsprechender Mechanismus wurde in einer Erweiterung hinzugefügt.
- SOAP stand ursprünglich für Simple Object Access Protocol und bietet wie RPC die Möglichkeit, Funktionen im Netz aufzurufen. Das Nachrichtenformat setzt auf XML auf. Für den Transport von SOAP eignen sich nachrichtenbasierte Protokolle wie HTTP oder BEEP. Entwickler nutzten SOAP häufig für den Datenaustausch mit Webservices, aktuell bevorzugen viele mit JSON arbeitende Dienste.
- XMPP: Das Extensible Messaging and Presence Protocol (XMPP) verwendet XML-Nachrichten für Echtzeitkommunikation. XMPP ist als Standard in RFC 6120 und RFC 6122 veröffentlicht. Typische Anwendungen sind Instant Messaging und Online-Konferenzen. Die Netzarchitektur ähnelt der des SMTP-Protokolls.