Frage zu OSI-Schichtenmodell

Hallo,

würde dem bedingt zustimmen. Hätte aber einen Einwand: Das heutige Standard-Protokoll ist TCP/IP und das ist in seiner Struktur nicht OSI-konform. Es hat nur 4 Schichten (wenn ich mich richtig erinnere).
Damit ist die Frage des Prüfers falsch.

Jürgen

Hi,

als Tipp für Prüfungen an der Stelle:
Wenn du auf so eine Frage die Antwort nicht weißt, dann versuche sie live herzuleiten.
Also in etwa: "Hmmm das kann ich so spontan nicht mit Sicherheit sagen, aber ich kann es eingrenzen. Layer 1 Physical sind nur 0 und 1, kann nicht sein; Layer 2 Datalink ist noch unter Routing, kann auch nicht sein..."
Naja und so weiter.
Damit zeigst du, dass du die Schichten kennst und auch grob weißt was da los ist und im Zweifel ist bei sehr vielen Problemen das Ausschließen von Dingen ein guter Weg.

Klappt natürlich nur, wenn du wirklich Ahnung hast und das entsprechend Herleiten kannst.

Gruß
Drohnald

Diese Diskussion hatte ich kürzlich, wenn auch aus einem anderen Grund.
Unabhängig von der verwendeten Programmiersprache ist HTTP erstmal Layer 5-7. Alles, was HTTP macht, passiert auf diesen Layern.
Es ist schwer bis unmöglich, irgendwas in dem Bereich konkret einzuordnen, da die Übergänge fließend sind und Schichten auch untereinander nicht strikt getrennt sind (das will OSI an der Stelle auch eigentlich nicht).
Korrekt wäre also "Alles von 5 bis 7" gewesen.

HTTP-Sitzungen, z.B. per Cookie, wären nach meiner Meinung tendenziell auf Layer 5.
Der Hintergrund ist, dass ein Proxyserver, der vor deinem HTTP-Server steht, anhand dieser Cookies z.B. ein Load-Balancing und Routing machen kann, ohne selbst irgendwelche Details zu der Sitzung wissen zu müssen.
Der sieht nur das Cookie-Value und bestimmt damit den Server, an den die Anfrage geleitet wird.
Das ist notwendig, damit du Anfragen zwar auf mehrere Server verteilen kannst, Nutzer aber nicht ständig die Sitzung verlieren - deshalb muss anhand des Session-Cookies eine Anfrage immer zum selben Server geroutet werden.

Eine richtig klare Antwort, welcher Teil der Software auf welchem Layer arbeitet, gibt es nicht.
Es ist allerdings unbestreitbar, dass wir den Bereich der "Anwendungs-Schichten" benutzen - und das sind die Schichten 5 bis 7.

Denn in deiner Java-Software hast du mit den darunter liegenden Schichten nichts zu tun.
Weder musst du dich um TCP-Sitzungen kümmern (das macht das Betriebssystem für dich), noch musst du IP-Pakete erzeugen (auch das kommt vom Kernel), noch musst du konkret in deiner Anwendung Ethernet II implementieren (das machen Kernel und Netzwerkkarte).
Du bekommst vom Betriebssystem, eventuell auch nur von einem davorgeschalteten Webserver, die Daten mit der Anfrage hereingereicht und hast - außer, dass du diese Informationen abfragen kannst - nichts mit IP-Adressen, Ports und anderen Dingen zu tun.
Deshalb befinden wir uns oberhalb von Layer 4



Dem würde ich überhaupt nicht zustimmen.
Klar, wenn man nur die Transport-Schichten betrachtet, haben wir nur 4 Layer. Und aus Netzwerker-Sicht ist natürlich alles, was hinter dem IP-Header kommt erstmal nur uninteressanter Payload.
Aber alleine schon eine simple TLS-Verbindung sehe ich auf Layer 5+6 (Session und Darstellung), da diese ja zum einen die TLS-Sitzung auf L5 umfasst (Cipher-Aushandlung, Sitzungsschlüssel), aber auf L6 auch die verschlüsselten Daten in ein lesbares Format bringt.
Und OSI bezieht sich ja nicht nur stumpf auf den Teil, der im Netzwerk stattfindet - sondern, wie man sieht, auch auf den Teil, der in den Server- und Client-Anwendungen stattfindet.


Man darf nicht den Fehler machen anzunehmen, dass alle Schichten bei OSI strikt getrennt sind und keine Gemeinsamkeiten haben dürfen. Oder dass immer grundsätzlich alle Schichten in exakt der Reihenfolge durchlaufen werden.
Funktioniert ja schon bei IP-Protokoll 4 (IPIP) nicht: Da wird hinter einen IPv4-Header (L3) einfach ein weiterer IPv4-Header angeklebt.
Oder man denke an PPPoE (L2), welches eine Session-ID im Header trägt (L4).
Das OSI-Modell soll lediglich eine Orientierung sein, an welchen Stellen die Software oder Hardware eine Abstraktionsschicht ziehen sollte

Hallo LordGurke.



Ich will dir ja nicht zu nahe treten, aber da solltest du noch mal in deine alten Schulbücher schauen!!

Das TCP/IP-Protokoll wurde vor dem OSI-Modell entwickelt und kann somit rein zeitlich gar nicht der OSI-Struktur entsprechen strukturiert sein, weil es schlicht dieses Strukturmodell noch gar nicht gab!

Der TCP/IP (korrekt eigentlich TCP-UDP/IP) gliedert sich in die Schichten

Netzzugang
Internet
Transport
Anwendung

siehe Bild unten.
javascript:void(0);

Die korrekte Antwort des TO wäre also:

Der TCP/IP-Stack ist nicht OSI-konform. Er gliedert sich in 4 und nicht 7 Schichten. Die von ihnen genannten Funktionen sind in der Anwendungs-Schicht des TCP/IP-Protokoll-Stacks anzusiedeln.

https://de.wikipedia.org/wiki/Internetprotokollfamilie

"Für das Internet und die Internetprotokollfamilie ist dabei die Gliederung nach dem sogenannten TCP/IP-Referenzmodell, welches 4 aufeinander aufbauende Schichten beschreibt, maßgebend."

https://de.wikipedia.org/wiki/OSI-Modell

"Die Ebenen des verbreiteten Netzwerk-Systems „TCP/IP über Ethernet“ entsprechen nicht exakt dem OSI-Modell und sind daher teilweise OSI-Schichten-übergreifend."

http://www.netzmafia.de/skripten/netze/netz8.html#8.1

Jürgen

Da würde ich als Prüfer antworten: "Das war nicht die Frage. Ich möchte wissen auf welcher OSI Schicht Sie die genannten Technologien verordnen."

Jup, chiefteddy wäre durch die Frage gefallen, wenn er mit dem DoD-Modell auf eine Frage zum OSI-Modell antwortet.

Hallo,

1. Ich war lange Jahre Prüfer bei der IHK für IT-Systemelektroniker und -Fachinformatiker-Systemintegration

2. Nochmal: Der TCP/IP-Protokollstack ist nicht nach dem OSI-7 Schichten-Referenzmodell strukturiert! Man hat später, nachdem dieses Modell entwickelt war, die 4 Schichten auf die neuen 7 Schichten abgebildet, was aber nur bedingt funktioniert.
Auch wenn ein Prüfer vermeintlich etwas behauptet, ist das ja kein Beweis für die Richtigkeit dieser Behauptung.

3. Wenn die Frage (auch des Prüfers) Fehler oder Ungereimtheiten enthält, kann der Gefragte ja durchaus um Klarstellung bitten. Und die diskutierte Frage ist zumindest ungenau formuliert.

Ich als Prüfer hätte diese Frage genau so formuliert, wenn ich einen 1-Kandidaten bei der Prüfung auf den Zahn fühlen wollte. Und ich hätte genau darauf gewartet, dass der Prüfling darauf hinweist, dass das TCP/IP-Protokoll nicht OSI-konform ist!
Einen Kandidaten, der ums Durchkommen kämpft, hätte ich natürlich nicht mit dieser spitzfindigen Frage konfrontiert.

Jürgen

PS: Ihr könnt mir aber gerne eine offizielle Quelle zeigen, in der der TCP/IP-Protokollstack als OSI-konform deklariert wird.

Moin,

ich werfe mal meinen Hut als aktueller Prüfer in den Ring

LordGurke hat recht. Ende

nee Scherz beiseite. Osi ist ein Modell und alleine die Tatsache, dass das TCP/IP-Protokoll exisitert zeigt, dass OSI halt nur ein Modell ist. Nach Modell ist TCP L4 und IP L3. Und wie man an Chiefteddys Wikipedia Tabelle sehr gut sieht, ist eine Trennung zwischen 5 bis 7 nicht mehr sauber möglich. Bei TCP/IP kann man es noch auseinander dröseln, aber aber L5 geht das nicht mehr sauber. Das fänkt auch bei TLS-Verbindungen wie LordGurke schreibt an:

https://www.security-insider.de/was-ist-tls-transport-layer-security-a-6 ...
Demnach ist TLS eindeutig der Schicht 5 zugeordnet.
Aber laut Wikipedia gilt:
Daraus folgt: Wenn TLS Verschlüsselung macht, dann gehört es (auch) zur Schicht 6.

Die Frage des TOs finde ich als Prüfer durchaus legitim, unabhängig um welche Note es geht. Unabhängig davon welche Schicht genannt worden wäre, wäre dann meine Frage gewesen "Warum gehört es zu dieser Schicht?" und auch hier sehe ich es wie LordGurke. 5 bis 7 ist mit der richtigen Begründung möglich.

Wir merken es immer wieder (grade bei den späteren Prüfungen), dass die Prüflinge einfach die Frage des Prüfers nicht verstehen. Das ist dann natürlich ausschließlich die Schuld des Prüflings und niemals nie nicht die Schuld des Prüfers. In dem Fall wird dann die Frage auch gerne ein zweites oder drittes mal formuliert. Wenn der Prüfling dann immer noch die Frage nicht versteht, dann kann es im Nachgang durchaus vorkommen, dass die Frage bei der Bewertung gestrichen wird.
Und wie Cheifteddy gesagt hat, auch Prüfer machen Fehler und wissen nicht alles. Es kommt auch vor, dass eine Frage gestellt wird und der Prüfer dann in der Besprechung der Ansicht ist, dass die Antwort falsch war, die anderen beiden Prüfer aber der Meinung sind, dass die Antwort durchaus richtig war. Das ist ja auch genau der Grund wieso da in der Prüfung 3 Leute sitzen und nicht nur einer.

Aber die wichtigste Frage ist ja noch offen:
Kann mit denn zur bestandenen Prüfung gratulieren?

Hallo @Enrixk

die aus meiner Sicht korrekte Antwort lautet:

"Die benannten Funktionen sind in der Anwendungsschicht nach DoD angesiedelt. Der TCP/IP-Protokollstack ist nicht im OSI-Referenzmodell definiert. Die Anwendungsschicht des DoD-Modells entspricht in etwa den Schichten 5 bis 7 des OSI-Modells"

Jürgen

Hallo @Doskias,

die Erläuterungen von @LordGurke teile ich vollumpfänglich.

Was mich stört, ist die aus der Fragestellung suggerierte Zuordnung des TCP/IP-Protokollstacks zum OSI-Referenzprotokoll. Das ist schlichtweg falsch.

TCP/IP entstand fast 10 Jahre vor der Definition des OSI-Modells und wurde nach dem DoD-Modell strukturiert.

Nachdem das OSI-Modell das Licht der Welt erblickt hatte, hat man nachträglich versucht, den TCP/IP-Protokollstack auf dem OSI-Modell abzubilden.

In alten Schulungsunterlagen fand ich noch nachfolgende Darstellung. Sie zeigt meiner Meinung nach sehr anschaulich die von @LordGurke beschriebenen Schwierigkeiten bei der eindeutigen Zuordnung von Funktionen zu den Schichten. Gerade bei den höheren Schichten sind bestimmte Funktionen eines Protokolls in verschiedenen Schichten anzuordnen. Es gibt häufig keine harten Grenzen.

Jürgen


javascript:void(0);

Wo liest du aus der Frage "[...] auf welcher Schicht/welchen Schichten des OSI-Schichtenmodells [sind] die Technologien Java HttpAuthenticationMechanism und IdentityStoreHandler aus der Java Security API verortet[...]" TCP/IP Protokollstack heraus?

Hallo @Drohnald,

Punkt für dich.

Aber fragen wir den TO doch mal, ob er bei "Java HttpAuthenticationMechanism und IdentityStoreHandler aus der Java Security API" an TCP/IP gedacht hat oder an SNA, AppleTalk, ProfiNet, BACnet, ModbusTCP.

Jürgen

Hi @chiefteddy,

klar wird das alles mit TCP/IP realisiert sein, schon alleine weil Http verwendet wird, aber das spielt für die Frage doch keine Rolle.
TCP/IP kann nicht einer einzigen OSI Schicht zugeordnet werden, völlig richtig. Und gleichzeitig: Na und?
Wir sprechen doch über "HttpAuthenticationMechanism und IdentityStoreHandler aus der Java Security API" und nicht über TCP/IP.
Dass eine HTTP-Verbindung TCP/IP nutzt mag ja sein, ist aber meines Erachtens nicht wichtig für die Frage.

Ich habe das Gefühl du vertrittst die Auffassung: Schicht ist Schicht und sobald ein Protokoll mehr als eine Schicht benutzt, ist das Schichtenmodell nicht mehr anwendbar.

Das sehe ich allerdings anders. Warum darf man das OSI-Modell(!) nicht benutzen, sobald es Protokolle gibt die auf mehr als einer Schicht angesiedelt sind?

Hallo @Drohnald


Da hast du mich völlig falsch verstanden.

Das Schichten-Modell - egal ob OSI oder DoD - ist wichtig und hat nicht nur eine theoretische/akademische Bedeutung, wie @LordGurke andeutet:


Hier strukturiert man Schnittstellen zwischen Funktionen und Diensten, egal ob in Hardware (Stecker, Treiber-Schaltkreise usw) oder in Software (Treiber, Dienste). Und das ist wiederum Voraussetzung für zB. Lastenhefte für entsprechend Entwicklungsaufträge mit dem ganzen Rattenschwanz am ökonomischen und juristischen Verantwortlichkeiten.

Gerade im Sinne der Interoperabilität ist das ein entscheidender Punkt.


Das ist doch gar nicht die Frage. Sondern benutzt man das "richtige" Modell.

Wenn ich den TCP/IP-Protokollstack beschreibe und die darin definierten Funktionen und Dienste, muss nach meiner Meinung das DoD-Modell genutzt werden. TCP/IP ist auf Grundlage dieses Modells entwickelt und beschrieben worden. Erst viel später hat man dann versucht, TCP/IP durch das viel detailliertere OSI-Modell zu beschreiben, was nur bedingt funktionierte. Es musste nämlich nachträglich der Block "Anwendung" (DoD) in die Schichten "Sitzung", "Darstellung" und "Anwendung" (OSI) aufgeteilt werden.

Natürlich kannst du eine heute entwickelte Netzwerk-Funktion mH. des OSI-Modells viel kleinteiliger strukturieren und beschreiben. Aber spätestens wenn du bei Transport und Verteilung auf TCP/IP setzt, musst du die nach dem DoD-Modell für dieses Protokoll definierten Schnittstellen berücksichtigen.

Jürgen

Und um diese Diskussion zu beenden: Wo ist denn der funktionelle Unterschied, ob "HttpAuthenticationMechanism und IdentityStoreHandler aus der Java Security API" in den Schichten 5 bis 7 nach OSI oder in Schicht 4 nach DoD beschrieben wird? Nach oben kommt in beiden Fällen die Anwendung und nach unten der Transport.

Hallo @Enrixk

darum geht es nicht.

Wie schon geschrieben, ist das TCP/IP-Protokoll 10 Jahre vor Veröffentlichung des OSI-Modells entwickelt worden. Es entspricht dem damals definierten DoD-Modell. Das DoD-Modell hat 4 und das OSI-Modell 7 Schichten. Die Anwendungs-Schicht des DoD-Modells wurde mit dem OSI-Modell feiner strukturiert (Schichten 5 - 7).

Ich bin der Meinung, auf die Frage: "Verorten sie den HttpAuthenticationMechanism im Schichten-Model des TCP/IP-Protokollstacks." lautet die Antwort: "Der HttpAuthenticationMechanism ist in Schicht 4 des DoD-Modells angesiedelt." (denn TCP/IP ist nach DoD strukturiert und nicht nach OSI)

Lautet die Frage: "Verorten sie den HttpAuthenticationMechanism im Schichten-Model des CANOpen-Protokollstacks.", ist die Antwort: "Der HttpAuthenticationMechanism ist in den Schichten 5 bis 7 des OSI-Modells angesiedelt." (denn CANOpen ist nach OSI strukturiert)

(Keine Ahnung, ob es den HttpAuthenticationMechanism bei CANOpen gibt Dient ja auch nur als Beispiel)

Ansonsten gilt natürlich die Aussage von @LordGurke über die schichtübergreifende Funktionalität einzelner Dienste.

Was haben denn Cookies mit dem Transport von Daten über das Netzwerk zu tun?
Das HTTP-Protokoll ist stateless , d.h., es werden keine Statusinformationen gespeichert. Um dies Statusinformationen dennoch speichern zu können, wurden "Cookies" erfunden. Sie sind nicht Bestandteil von HTTP und meiner Meinung nach oberhalb von Schicht 7 (OSI) anzusiedeln.

http://www.tcpipguide.com/free/t_HTTPStateManagementUsingCookies.htm

Jürgen