Warum ist das Protokollfeld Teil eines IP-Headers?

Beachten Sie, dass dies kein Duplikat von Warum kennt die IP-Schicht höhere Schichten im Netzwerkstapel?

Die Notwendigkeit einer Protokollkennung (z. B. des Protokollfelds des IP-Headers) bei der paketbasierten Kommunikation ist klar: Es handelt sich entweder um diesen oder einen rechenintensiven Inferenzalgorithmus. Die Frage ist: Warum muss es als Teil des IP-Headers und nicht in den Headern der gekapselten Protokolle vorhanden sein?

Es scheint mir, dass dieser eine der Fälle, in denen theoretische Klarheit auf praktische Überlegungen trifft (AKA "Haskell meets Go" ...): Einerseits das Platzieren eines "Protokoll" -Feldes im IP-Header die konzeptionelle Trennung von Interessen bricht, die z . das angestrebte OSI-Modell; Andererseits ist es viel schwieriger, Protokolle höher im Stapel zu zwingen, ihren Typ auf konsistente Weise anzugeben, und würde schließlich ohnehin zu einer ähnlichen Situation führen (z. B. wenn jedes Protokoll höher im Stapel sein erstes Header-Byte verwendet, um seinen Typ anzugeben würde es so aussehen, als ob IP sein letztes Header-Byte verwendet hätte, um dasselbe zu tun).

Meine Frage ist also: Was war der Grund dafür, dass das Feld "Protokoll" im Paket-Header der IP platziert wurde und nicht irgendwo anders?

Bearbeiten : Als ich diese Frage schrieb, überlegte ich, ob ich das Wort " Original " vor "Argumentation" hinzufügen sollte , dh die Argumentation des Teams, das IP entwickelt hatte , hielt es jedoch für überflüssig, da die Frage in der Vergangenheitsform formuliert wurde ("Was war das ?") Argumentation..."). Dies scheint jedoch notwendig zu sein, da keine der Antworten diese Frage tatsächlich beantwortet. Einige wichtige Erkenntnisse:

• @immibis schlägt vor, dass jede andere Form die Modelle anderer Protokolle beschädigen würde (z. B. müssten verschlüsselte Kommunikationsprotokolle ein Klartext-Identifikationsfeld haben).
• @Eddie gibt im Wesentlichen an, dass der Grund die Konvention ist (Akzeptanz des Protokollkettendesigns , warum dies die Konvention ist, bleibt ein Rätsel)
• @ Ricky betont die Praktikabilität als übergeordnete Überlegung
• @Claudio schlägt vor, dass, wenn das Protokollfeld Teil des gekapselten Headers wäre, ein zusätzlicher Schritt zur Identifizierung des Headers erforderlich wäre , der im aktuellen Modell während der Analyse des IP-Headers stattfindet

Also werde ich umformulieren: Was ist falsch an einem Modell, bei dem anstelle jedes Headers, der den Typ des nächsten Headers identifiziert, jeder Header seinen eigenen Typ an einer vorbestimmten Stelle identifiziert (z. B. im ersten Header-Byte)? Warum ist ein solches Modell weniger wünschenswert als das aktuelle?

Edit # 2 : Es scheint, dass die Antwort eine Kombination aus mehreren der gegebenen Antworten ist (hauptsächlich die oben genannten zusammen mit @ Eddies zweitem Nachtrag):

1. Einfachheit: Wenn in diesem speziellen Fall das Prinzip der Schichtunabhängigkeit gebrochen wird, kann der Stapel (oder das Modell) als Ganzes einfacher sein:

   • Es gibt keine "Protokollidentifikations" -Phase, weder implizit noch explizit
   • Die Schichtunabhängigkeit wird verbessert (z. B. muss ein verschlüsselter Kommunikationshandler keine Schicht mit einem Hilfsprotokoll teilen).

   Die Regulierung wird ebenfalls stark vereinfacht, da keine Anforderungen an Client-Protokolle durchgesetzt werden müssen.

2. Leistung: Wenn das Protokoll eines gekapselten Pakets vor dem Paket selbst angegeben wird, können verschiedene Arten von Fast-Routing-Protokollen (Paketfilterung, QOS, Cut-Through-Switching) in die Netzwerkschicht (Internet) selbst integriert werden. Diese können dann Entscheidungen treffen, sobald auf eine Hash-Tabelle zugegriffen werden kann. Dies ist umso wichtiger, als die Hardware, auf der dieses Protokoll ausgeführt werden soll, begrenzt ist.

Dieses Modell hat seine Nachteile, aber es scheint, dass es für die gängigen Anwendungsfälle besser geeignet ist als die Alternativen.

Denken Sie daran, dass Bits als eine Reihe von Einsen und Nullen auf einer Netzwerkkarte ankommen. Es muss etwas existieren, um zu bestimmen, wie die nächsten Reihen von Einsen und Nullen interpretiert werden sollen.

Ethernet2 ist der Defacto-Standard für L2. Daher wird angenommen, dass die ersten 56 Bits als Präambel und die nächsten 8 Bits als Präambel und die nächsten 48 Bits als Ziel-MAC und die nächsten 48 Bits als Quelle interpretiert werden MAC und so weiter und so fort .

Die einzige Variation könnte der etwas veraltete 802.3 L2-Header sein , der vor dem aktuellen Ethernet2-Standard liegt, aber auch einen SNAP-Header enthält , der denselben Zweck erfüllt . Aber ich schweife ab.

Der Standard-Ethernet2-L2-Header verfügt über ein Typfeld, das dem empfangenden Knoten mitteilt, wie die folgenden Einsen und Nullen zu interpretieren sind:

Wie würde die empfangende Entität ohne dies wissen, ob der L3-Header IP oder IPv6 ist? (oder AppleTalk oder IPX oder IPv8 usw.)

Der L3-Header (im selben Frame wie oben) enthält das Feld Protokoll, das dem empfangenden Knoten mitteilt, wie der nächste Satz von Einsen und Nullen nach dem IP-Header zu interpretieren ist:

Wie würde die empfangende Entität ohne dies wissen, diese Bits als ICMP-Paket zu interpretieren? Es kann sich auch um TCP oder UDP oder GRE oder einen anderen IP-Header oder eine Vielzahl anderer handeln.

Dadurch wird eine Art Protokollkette erstellt , die der empfangenden Entität angibt, wie der nächste Satz von Bits zu interpretieren ist. Ohne dies müsste das empfangende Ende Heuristiken (oder eine ähnliche Strategie) verwenden, um zuerst den Headertyp zu identifizieren und dann die Bits zu interpretieren und zu verarbeiten. Dies würde einen erheblichen Overhead auf jeder Schicht und eine merkliche Verzögerung bei der Paketverarbeitung verursachen.

An diesem Punkt ist es verlockend, sich den TCP-Header oder den UDP-Header anzusehen und darauf hinzuweisen, dass diese Header kein Typ- oder Protokollfeld haben. Denken Sie jedoch daran, dass TCP / UDP nach der Interpretation der Bits seine Nutzdaten an weiterleitet die Anwendung. Was zweifellos wahrscheinlich eine Art Marker hat, um zumindest die Version des L5 + -Protokolls zu identifizieren. In HTTP ist beispielsweise eine Versionsnummer in die HTTP-Anforderungen integriert: (1.0 vs 1.1).

Bearbeiten, um mit der Bearbeitung des Originalplakats zu sprechen:

Was ist falsch an einem Modell, bei dem anstelle jedes Headers, der den Typ des nächsten Headers identifiziert, jeder Header seinen eigenen Typ an einer vorbestimmten Stelle identifiziert (z. B. im ersten Header-Byte)? Warum ist ein solches Modell weniger wünschenswert als das aktuelle?

Bevor ich mich auf eine Antwort einlasse, denke ich, dass es wahrscheinlich keine endgültige Millionen-Dollar-Antwort gibt, warum der eine oder andere Weg besser ist. In beiden Fällen könnte die empfangende Entität die Bits korrekt interpretieren, wenn sich das Protokoll selbst identifiziert und das Protokoll identifiziert, was es einkapselt.

Ich denke jedoch, dass es einige Gründe gibt, warum das Protokoll zur Identifizierung des nächsten Headers sinnvoller ist:

# 1

Wenn der Standard darin besteht, dass sich das erste Byte jedes Headers identifiziert, würde dies einen Standard für jedes Protokoll auf jeder Ebene festlegen. Das heißt, wenn nur ein Byte dediziert ist, könnten wir immer nur 256 Protokolle haben. Selbst wenn Sie zwei Bytes reserviert haben, werden Sie auf 65536 begrenzt. In beiden Fällen wird die Anzahl der Protokolle, die entwickelt werden könnten, willkürlich begrenzt.

Wenn ein Protokoll nur für die Interpretation des nächsten verantwortlich war und selbst wenn nur ein Byte für jedes Protokollidentifikationsfeld reserviert war, skalieren Sie mindestens dieses Maximum von 256 auf jede Schicht.

# 2

Protokolle, die ihre Felder so anordnen, dass empfangende Entitäten die Option haben, nur das Nötigste zu überprüfen, um eine Entscheidung zu treffen, sind nur vorhanden, wenn das nächste Protokollfeld im vorherigen Header vorhanden ist.

Ethernet2 und " Cut-Through " -Schalten kommen in den Sinn. Dies wäre unmöglich, wenn die ersten (wenigen) Bytes gezwungen wären, ein Protokollidentifikationsblock zu sein.

#3

Schließlich möchte ich keine Anerkennung finden, aber ich denke, dass die Antwort von @reirab im Kommentar in den Kommentaren der ursprünglichen Frage äußerst realisierbar ist:

Denn dann ist es praktisch nur das letzte Byte des IPv4-Headers (oder eines beliebigen Protokolls auf niedrigerer Ebene) in allen außer dem Namen. Es ist ein "Huhn oder Ei" Problem. Sie können einen Header nicht analysieren, wenn Sie nicht wissen, um welches Protokoll es sich handelt.

_{Zitiert mit Reirabs Erlaubnis}

Sie können auch fragen, warum ein Ethernet-Header ein Feld für den Ethertyp enthält. Der Netzwerkstapel muss wissen, welches Protokoll in der nächsthöheren Schicht die Nutzlast der aktuellen Schicht erhält.

Bearbeiten 1:

Der Grund, warum jedes Datagramm das Protokoll der nächsten oberen Schicht hat, besteht darin, die Schichtunabhängigkeit zu erzeugen. Jeder Schicht ist es egal, was sich in der Nutzlast befindet, und sie sollte nicht in der Nutzlast nachsehen müssen, um zu bestimmen, wohin die Nutzlast geliefert werden soll. Stellen Sie sich die Protokollnummer im Header als eine Adresse vor, an die die Nutzdaten geliefert werden sollen. Ähnlich wie TCP-Portnummern TCP-Adressen sind, teilen sie TCP mit, wohin die Nutzdaten geliefert werden sollen.

Die Ziel-MAC-Adresse teilt dem Netzwerk-Switch mit, welche Switch-Schnittstelle den Frame liefern soll. Das Feld Ether Type teilt Schicht 2 mit, wohin die Nutzdaten geliefert werden sollen, das Feld Protocol im IP-Header teilt Schicht 3 mit, wohin die Nutzdaten geliefert werden sollen, und die Portnummern in TCP und UDP geben Schicht 4 an, wo die Nutzdaten geliefert werden sollen.

Stellen Sie sich einen 18-Rad-Lkw-Fahrer vor, der sich an einen Anhänger anschließt, um ihn irgendwohin zu bringen. Er muss sich keine Sorgen machen, was sich im Trailer befindet oder wofür er verwendet wird. er schaut sich nur seine Unterlagen an und liefert sie an die Stelle in den Unterlagen.

Sie müssen sich daran erinnern, dass jedes der Protokolle unabhängig entwickelt wurde, ohne zu wissen, welche neuen Protokolle der oberen Schicht verwendet werden würden. Das primäre Ethernet-Protokoll der Schicht 3, das im Ethernet verwendet wurde, war lange Zeit IPX. Wäre Ethernet speziell für IPX erstellt worden, wäre es heute so allgegenwärtig? Ethernet wurde für die Übertragung eines beliebigen Layer-3-Protokolls entwickelt, indem das Feld Ether Type verwendet wird, anhand dessen der Netzwerkstapel entscheiden kann, wohin die Ethernet-Nutzdaten gehen. IP macht dasselbe, ebenso wie TCP und UDP. Es ist eine einfache und logische Methode, weshalb jede unabhängig entwickelte Schicht im Netzwerkstapel ein Äquivalent hat. Sie und alle anderen Interessierten können Ihre eigenen Protokolle für jede der Schichten entwickeln, die sich aus diesem Grund problemlos in den Netzwerkstapel einbinden lassen.

Bearbeiten 2:

Es ermöglicht verschiedenen Layer-3-Protokollen, sich bei Layer-2 zu registrieren. Sie können gleichzeitig die Protokolle IPX (0x8137), IPv4, (0x0800), ARP (0x0806), IPv6 (0x86DD) usw. ausführen, und Layer-2 erkennt, welche Protokolle sich bei ihm registriert haben, und leitet die Nutzdaten an die entsprechende Layer-Datei weiter. 3 Protokoll, ohne etwas über die Nutzlast zu wissen (oder Pakete zu verwerfen, die kein registriertes Protokoll haben). Sie möchten nicht für jede Kombination von Layer-3-Protokollen ein anderes Layer-2-Protokoll installieren müssen. Dies wäre erforderlich, wenn das Layer-2-Protokoll mehr über die Layer-3-Protokolle wissen muss ), um die Paket-Header lesen zu können. Sogar IPv4- und IPv6-Paket-Header sind sehr unterschiedlich.

Hier ist eine unvollständige Liste von Werten für verschiedene Layer-3-Protokolle, die sich bei Layer-2 registrieren können.

Layer-4-Protokolle registrieren sich auch bei verschiedenen Layer-3-Protokollen, und Anwendungen registrieren sich bei Layer-4-Protokollen.

Ihre ursprüngliche Frage ging davon aus, dass die Ebenen unabhängig voneinander sein sollten, und diese Art von Dingen fördert tatsächlich die Ebenenunabhängigkeit, anstatt sie zu brechen, wie Sie vorschlagen. Layer-2 weiß nicht, dass die Nutzlast IPv4 ist, es weiß nur, dass der Ethertyp 0x0800 ist, und es sollte die Payload an das Layer-3-Protokoll übergeben, das diesen Ethertyp registriert hat.

Keine direkte Antwort auf Ihre Frage, aber:

Einerseits bricht das Platzieren eines "Protokoll" -Felds im IP-Header die konzeptionelle Trennung der Interessen, die das OSI anstrebte.

TCP / IP wurde ohne Bezugnahme auf das OSI-Modell entwickelt. Obwohl sie einige Gemeinsamkeiten aufweisen, war dies eine separate Entwicklungsanstrengung.

Der einfachste Grund besteht darin, das Parsen zu unterstützen, wenn ein Paket empfangen wird.

Wenn Sie wissen, welches Protokoll folgt, können Sie strengere Einschränkungen entwickeln. Der einzige dynamische Aspekt im IP-Paket ist die Größe (das Vorhandensein von IP-Optionen erhöht diese Größe um ein Vielfaches von vier Bytes).

In der Analysephase können Sie die Länge des IP-Headers und das Protokoll überprüfen. Dann werden bei der Paketvalidierung auf niedriger Ebene die Paketdaten durch eine Datenstruktur (normalerweise icmp-, tcp-, udp-Header) gelesen und mit einfachem Paket validiert.

Lesen Sie einfach den Titel:

Wenn das IP-Paket TCP-Daten enthält, enthält das Protokollnummernfeld den Wert 6, sodass die Nutzdaten an den TCP-Stapel gesendet werden. TCP verwendet dann die Portnummern, um die Daten an die richtige Anwendung zu senden. Gleiches gilt für UDP mit Protokollnummer 17.

Eine andere Möglichkeit, das Feld für die IP-Protokollnummer zu betrachten, besteht darin, dass IP, wenn wir dieses Feld nicht im IP-Paket-Header hätten, nur einen Datentyp übertragen könnte, während das Hinzufügen dieses Felds es der IP ermöglichte, mehrere Arten von Daten zu übertragen Daten, die durch die Protokollnummer differenziert sind, gelten auch für TCP / UDP über TCP / UDP-Ports, um mehrere Anwendungen und Ethernet über den Ethertyp zu bedienen, und so weiter.