Verwendet ICMP Prozesse über Schicht 3?

Question 1

Es verwendet die Anwendungsschicht (7 oder 4, je nach Modell) sowie 3 und darunter. ICMP ist kein so flexibles Protokoll wie TCP oder UDP und bietet daher einen eher eingeschränkten Funktionsumfang.ICMPunterstützt bis zu255 Befehlsnachrichtentypen, und tut dies intern, anstatt ein Protokoll der oberen Schicht zu verwenden, um Netzwerk-E/A an Prozesse zu verteilen.

Die Anwendung steuert also die Verwendung von Befehlsnachrichten zur Steuerung des Netzwerks. Ping ist beispielsweise eine Anwendung, die eine für ein ICMP-Paket geeignete Datenstruktur erstellt und diese an das Betriebssystem übermittelt, um sie an eine IP zu senden. Anschließend wartet sie auf die Rückkehr der IO. Wenn der IP-Stapel die Echoantwort empfängt, leitet er diese IO an das Programm weiter, das dann Nachrichten an den Benutzer ausgeben kann.

Genau wie TCP/IP steuert und koordiniert die Anwendungsschicht alle vom Netzwerkstapel bereitgestellten Grundoperationen, um für moderne Benutzer wertvolle Funktionen zu schaffen.

Wenn Sie ein Code-orientierter Mensch sind, denken Sie darüber nachdieser Codeausschnittdrüben auf SO. Es wartet auf eine ICMP-Nachricht und gibt sie in der Programmausgabe aus. Sie können sehen, dass es einen „Raw Socket“ für ICMP einrichtet, diesen Socket an eine IP-Schnittstelle bindet (beides Layer-3-Operationen), einige Datenstrukturen einrichtet und vom Socket-IO liest, um nach einer Antwort zu suchen. Wenn eine ICMP-Nachricht empfangen wird, erscheint ihr Datenbereich im IO-Stream des Programms und wird auf dem Bildschirm ausgegeben. Das ist ziemlich übersichtlich.

Wie gewünscht bearbeiten:

Das OSI-Modell ist also eine abstrakte Darstellung einer Möglichkeit, über Verantwortlichkeiten nachzudenken, so dass Aufgaben Voraussetzungen (die Eigenschaften der in den darunterliegenden Schichten verwendeten Protokolle) und Nachbedingungen haben, die sie erfüllen müssen. Außerdem legt das Modell Mittel fest, um die Daten durch jede dieser Aufgaben zu leiten.

Das Hauptziel des OSI-Modells besteht darin, eine Beschreibung einer Methode bereitzustellen, mit der Anwendungen problemlos Netzwerknachrichten senden und empfangen können, und zwar auf eine Weise, die von der Systemkonfiguration abstrahiert ist und so systemübergreifend portierbar ist. Früher mussten Anwendungen neu geschrieben werden, damit sie auf anderen Plattformen und Konfigurationen funktionierten, da die Anwendung alles selbst erledigen musste. Durch die Trennung der Verantwortlichkeiten kann sich das Programm ganz auf seine Aufgabe konzentrieren, und diese wird sich zwischen den Systemen kaum unterscheiden. Darüber hinaus können die System- und Netzwerkadministratoren die Art und Weise ändern, wie das System Verbindungen zu anderen Systemen herstellt, ohne dass dies Auswirkungen auf die Anwendung hat.

An der Basis des OSI-Stacks dreht sich alles um grundlegende Netzwerkstandards für die Systemverbindung. Jeder muss diese Dinge auf die gleiche Weise tun, sonst funktioniert nichts. Alle Hersteller sind verpflichtet, diese Regeln einzuhalten, um Produkte zu haben, die sie verkaufen können.

Betriebssystemanbieter sind jedoch weniger begeistert von starren Regeln und Strukturen, die verhindern, dass ihre Plattform aus der Masse hervorsticht. Der Grund, warum es nie ein vollständig OSI-kompatibles System gegeben hat, ist, dass kein Betriebssystemanbieter eines schreiben möchte.

Die OSI-Schichten 1 bis 4 sind also solide, vorhersehbar und unverzichtbar. Die Schichten 5 und 6 sind jedoch völlig optional. Je nachdem, was sie benötigen, schreiben Anwendungen entweder den Code, um sie zu nutzen, oder sie tun es nicht.

Die meisten modernen Anwendungen lesen Daten einfach aus dem Transportprotokollsegment. In diesen Fällen gibt es keine gekapselten Datagramme für L5/L6. Die Daten in der Segmentnutzlast sind die Anwendungsdaten, daher hängt die Anwendung einfach IO-Streams an den L4-Port an und liest/schreibt von/zu ihm.

Im Fall von ICMP liest die Anwendung einfach den Roh-IP-Socket, da Layer 4 nicht verwendet wird. Dasselbe Konzept.

Schicht 5wird nur für Anwendungen verwendet, die Netzwerk-Proxying oder Tunneling erfordern. Die Nutzlast dieses Datagramms ist häufig ein anderer Frame oder ein anderes Paket, das durch einen Tunnel gesendet wird, oder ein Segment, das durch einen SOCKS-Proxy geproxied wird. Die Anwendung weiß normalerweise entweder nicht, dass ein Proxy im Spiel ist, oder sie nutzt das Betriebssystem zur Handhabung von Layer 5, wenn dies für das System anwendbar ist, obwohl einige Anwendungen auf einigen Betriebssystemen tatsächlich die Entkapselung von L5-Datagrammen steuern können. Häufig werden L5-Operationen im Kernel mithilfe eines Treibers (virtueller VPN-Netzwerkadapter, Systemproxy usw.) gehandhabt.

Es ist bemerkenswert, dass die meisten Protokolle der Schicht 5 zur Steuerung von Interaktionen verwendet werden, die nichts mit dem Wunsch der Anwendungen zu tun haben, Nachrichten zu senden/empfangen, und normalerweise auch für die an der Kommunikation beteiligten Systeme bedeutungslos sind. Normalerweise werden sie zur Steuerung des Netzwerks verwendet, damit diese beiden Systeme kommunizieren KÖNNEN. Tatsächlich wird der Datenstrom der Anwendungen die meiste Zeit vom Betriebssystem abgefangen, und eine Systemanwendung übernimmt die Kapselung des äußeren Datagramms, nimmt also die Anwendungspakete und fügt sie in andere Pakete ein, von deren Existenz die Anwendung nicht einmal weiß. Die Systemanwendung hat an diesem Punkt die Kontrolle über die Daten.

Schicht 6wird wirklich nicht verwendet. In allen von mir verwendeten Programmierframeworks wird die Kodierung mithilfe der entsprechenden Bibliotheken in der Anwendung gehandhabt. Anwendungen können bei Bedarf Operationen der Schicht 6 schreiben und dabei die Kodierer/Dekodierer des Betriebssystems verwenden oder eigene bereitstellen. Meiner Erfahrung nach wird dies jedoch normalerweise von der Anwendung gehandhabt und hat keine Auswirkungen auf die Datagramm-Kapselung.

Letztendlich dient all dies dazu, einer Anwendung IO-Streams bereitzustellen, die sie lesen und schreiben kann, um Nachrichten über das Netzwerk zu senden und zu empfangen, ohne dass sie vorher wissen muss, wie das Netzwerk funktioniert. Das ist zu 100 % das, worum es bei modernen Netzwerken geht.

Wenn ein System einen systemweiten Proxy oder ein VPN verwendet, wird das L5-Datagramm normalerweise automatisch gekapselt, sodass die sendende Anwendung nicht einmal weiß, dass es da ist. Auf der Empfängerseite ist der L5-Header zum Zeitpunkt des Empfangs bereits entfernt, da er vom Proxyserver oder VPN-Endpunkt verarbeitet wurde. Das Remote-Betriebssystem leitet die Daten also einfach aus der Layer-4-Nutzlast an die Anwendung weiter.

Ein bestimmtes Paket wird also nur in so viele Schichten gekapselt, wie nötig sind, um die Aufgabe zu erledigen. Es gibt Low-Level-Anwendungen, die nur auf Schicht 2 arbeiten und keine L3+-Komponenten enthalten. Es gibt Internetwork-Schicht-Anwendungen, die L4+ nicht verwenden, also nichts Höheres kapseln (wie ICMP). Sie müssen alle Schichten unterhalb der Schicht haben, auf der Sie arbeiten möchten, aber Sie brauchen keine darüber. Die meisten gängigen Anwendungen konzentrieren sich auf das Lesen und Schreiben auf Schicht 4 und überlassen dem Betriebssystem nach Bedarf die Schichten 5 und 6.

Abschließend kann ich verstehen, warum Sie verwirrt sind und warum es schwierig ist, gute Informationen zu diesem Thema zu finden. Um alles wirklich zu verstehen, müssen Sie sich mit Netzwerken, Anwendungsprogrammierung und Betriebssystemdesign auskennen. Daher hat es viele Jahre gedauert, bis ich das Gefühl hatte, ausreichend zu verstehen, wie das Ganze funktioniert.

Answer