Kapitel 1. Einführung in die Vernetzung

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

"Schuldig, bis die Unschuld bewiesen ist." Das ist das Mantra von Netzwerken und den Ingenieuren, die sie betreuen. In diesem Eröffnungskapitel gehen wir auf die Entwicklung von Netzwerktechnologien und -standards ein, geben einen kurzen Überblick über die vorherrschende Netzwerktheorie und stellen unseren Golang-Webserver vor, der die Grundlage für die Netzwerkbeispiele in Kubernetes und der Cloud im gesamten Buch sein wird.

Fangen wir an... am Anfang.

Geschichte der Vernetzung

Das Internet , wie wir es heute kennen, ist riesig, mit Kabeln, die Ozeane und Berge überspannen und Städte mit einer geringeren Latenzzeit als je zuvor verbinden. Barrett Lyons "Mapping the Internet" ( Abbildung 1-1) zeigt, wie groß es wirklich ist. Das Bild zeigt alle Verbindungen zwischen den Netzwerken, aus denen das Internet besteht. Der Zweck eines Netzwerks ist es, Informationen von einem System zu einem anderen System auszutauschen. Das ist eine enorme Anforderung an ein verteiltes globales System, aber das Internet war nicht immer global; es begann als konzeptionelles Modell und wurde im Laufe der Zeit langsam zu dem Giganten in Lyons visuell beeindruckendem Kunstwerk aufgebaut. Es gibt viele Faktoren, die man berücksichtigen muss, wenn man etwas über Netzwerke lernt, z. B. die letzte Meile, die Verbindung zwischen dem Haus eines Kunden und dem Netzwerk seines Internetanbieters - bis hin zur geopolitischen Landschaft des Internets. Das Internet ist in das Gefüge unserer Gesellschaft integriert. In diesem Buch erfahren wir, wie Netzwerke funktionieren und wie Kubernetes sie für uns abstrahiert.

Tabelle 1-1 gibt einen kurzen Überblick über die Geschichte des Netzwerks, bevor wir uns mit einigen wichtigen Details von beschäftigen.

Tabelle 1-1. Eine kurze Geschichte der Vernetzung
Jahr	Veranstaltung
1969	Der erste Verbindungstest des ARPANET
1969	Telnet 1969 Request for Comments (RFC) 15 verfasst
1971	FTP RFC 114 verfasst
1973	FTP RFC 354 verfasst
1974	TCP RFC 675 von Vint Cerf, Yogen Dalal und Carl Sunshine verfasst
1980	Beginn der Entwicklung des Open Systems Interconnection Modells
1981	IP RFC 760 verfasst
1982	NORSAR und das University College London verließen das ARPANET und begannen, TCP/IP über SATNET zu nutzen
1984	Veröffentlichung des ISO 7498 Open Systems Interconnection (OSI)-Modells
1991	Gesetzentwurf zur Nationalen Informationsinfrastruktur (NII) mit Hilfe von Al Gore verabschiedet
1991	Erste Version von Linux veröffentlicht
2015	Erste Version von Kubernetes veröffentlicht

In den Vereinigten Staaten förderte das Verteidigungsministerium (DOD) das Advanced Research Projects Agency Network (ARPANET), lange vor Al Gores Zeit in der Politik, auf die wir gleich noch zu sprechen kommen werden. 1969 wurde das ARPANET an der University of California-Los Angeles, dem Augmentation Research Center am Stanford Research Institute, der University of California-Santa Barbara und der University of Utah School of Computing in Betrieb genommen. Die Kommunikation zwischen diesen Knotenpunkten wurde erst 1970 abgeschlossen, als sie das Network Control Protocol (NCP) einsetzten. NCP führte zur Entwicklung und Nutzung der ersten Computer-zu-Computer-Protokolle wie Telnet und File Transfer Protocol (FTP).

Der Erfolg des ARPANET und von NCP, dem ersten Protokoll für das ARPANET, führte zum Untergang von NCP. Es konnte mit den Anforderungen des Netzwerks und der Vielfalt der angeschlossenen Netzwerke nicht mithalten. 1974 begannen Vint Cerf, Yogen Dalal und Carl Sunshine mit dem Entwurf von RFC 675 für das Transmission Control Protocol (TCP). (In ein paar Absätzen erfährst du mehr über RFCs.) TCP sollte später der Standard für Netzwerkverbindungen werden. TCP ermöglichte den Austausch von Paketen über verschiedene Arten von Netzwerken. Im Jahr 1981 half das Internetprotokoll (IP), das in RFC 791 definiert wurde, dabei, die Aufgaben von TCP in ein separates Protokoll auszugliedern und die Modularität des Netzwerks zu erhöhen. In den folgenden Jahren übernahmen viele Organisationen, darunter auch das Verteidigungsministerium, TCP als Standard. Im Januar 1983 war TCP/IP das einzige zugelassene Protokoll im ARPANET und löste das frühere NCP aufgrund seiner Vielseitigkeit und Modularität ab.

Eine konkurrierende Normungsorganisation, die Internationale Organisation für Normung (ISO) , entwickelte und veröffentlichte die Norm ISO 7498, "Open Systems Interconnection Reference Model", in der das OSI-Modell beschrieben wurde. Mit der Veröffentlichung kamen auch die Protokolle, die es unterstützen. Leider konnten sich die Protokolle des OSI-Modells nie durchsetzen und wurden von der Popularität von TCP/IP verdrängt. Das OSI-Modell ist aber immer noch ein hervorragendes Lernmittel, um den mehrschichtigen Ansatz von Netzwerken zu verstehen.

1991 erfand Al Gore das Internet (in Wirklichkeit half er bei der Verabschiedung des National Information Infrastructure [NII] Bill), was zur Gründung der Internet Engineering Task Force (IETF) führte. Heutzutage werden die Standards für das Internet von der IETF verwaltet, einem offenen Konsortium aus führenden Experten und Unternehmen im Bereich der Netzwerktechnik, wie Cisco und Juniper. RFCs werden von der Internet Society und der Internet Engineering Task Force veröffentlicht. RFCs werden in erster Linie von einzelnen Personen oder Gruppen von Ingenieuren und Informatikern verfasst und beschreiben ihre Prozesse, Abläufe und Anwendungen für das Funktionieren des Internets.

Ein IETF RFC hat zwei Zustände:

Vorgeschlagener Standard: Eine Protokollspezifikation hat genügend Unterstützung in der Gemeinschaft erreicht, um als Standard zu gelten. Die Entwürfe sind stabil und werden gut verstanden. Ein vorgeschlagener Standard kann eingeführt, implementiert und getestet werden. Er kann jedoch von der weiteren Betrachtung zurückgezogen werden.
Internet Standard: In RFC 2026 heißt es: "Im Allgemeinen ist ein Internetstandard eine stabile Spezifikation, die gut verstanden wird, technisch kompetent ist, mehrere unabhängige und interoperable Implementierungen mit beträchtlicher Betriebserfahrung hat, eine bedeutende öffentliche Unterstützung genießt und in einigen Teilen des Internets erkennbar nützlich ist."

Hinweis

Der Standardentwurf ist eine dritte Klassifizierung, die 2011 eingestellt wurde.

Es gibt Tausende von Internet-Standards, die festlegen, wie Protokolle für alle Aspekte der Vernetzung implementiert werden, z. B. für drahtlose Kommunikation, Verschlüsselung und Datenformate. Jeder dieser Standards wird von Open-Source-Projekten und von großen Unternehmen wie Cisco umgesetzt.

In den fast 50 Jahren seit diesen ersten Verbindungstests hat sich viel getan. Die Netzwerke sind komplexer geworden und abstrakter, also fangen wir mit dem OSI-Modell an.

OSI-Modell

Das OSI-Modell ist ein konzeptioneller Rahmen, der beschreibt, wie zwei Systeme über ein Netzwerk kommunizieren. Das OSI-Modell unterteilt die Verantwortung für die Datenübertragung in Netzwerken in Schichten. Es eignet sich gut für Bildungszwecke, um die Beziehungen zwischen den Zuständigkeiten der einzelnen Schichten und die Art und Weise, wie Daten über Netzwerke gesendet werden, zu beschreiben. Interessanterweise war es als Protokollsuite für die Stromversorgung von Netzwerken gedacht, ging aber an TCP/IP verloren.

Hier sind die ISO-Normen, die das OSI-Modell und die Protokolle umreißen:

ISO/IEC 7498-1, "Das Grundmodell"
ISO/IEC 7498-2, "Sicherheitsarchitektur"
ISO/IEC 7498-3, "Benennung und Adressierung"
ISO/IEC 7498-4, "Management Framework"

Die ISO/IEC 7498-1 beschreibt, was das OSI-Modell zu vermitteln versucht:

5.2.2.1 Die grundlegende Strukturierungstechnik im Referenzmodell für die Zusammenschaltung offener Systeme ist die Schichtung. Nach dieser Technik wird jedes offene System als logisch aus einer geordneten Menge von (N)-Subsystemen zusammengesetzt betrachtet... Benachbarte (N)-Subsysteme kommunizieren über ihre gemeinsame Grenze. (N)-Subsysteme desselben Ranges (N) bilden gemeinsam die (N)-Schicht des Referenzmodells für die Verbindung offener Systeme (Open Systems Interconnection). Es gibt nur ein einziges (N)-Subsystem in einem offenen System für die Schicht N. Ein (N)-Subsystem besteht aus einer oder mehreren (N)-Einheiten. Entitäten gibt es in jeder (N)-Schicht. Entitäten in derselben (N)-Schicht werden als Peer-(N)-Entitäten bezeichnet. Beachte, dass die höchste Schicht keine (N+l)-Schicht über sich hat und die niedrigste Schicht keine (N-1)-Schicht unter sich hat.

Die Beschreibung des OSI-Modells ist eine komplexe und genaue Art zu sagen, dass Netzwerke Schichten haben wie Kuchen oder Zwiebeln. Das OSI-Modell unterteilt die Aufgaben des Netzwerks in sieben verschiedene Schichten, die jeweils unterschiedliche Funktionen haben, um die Übertragung von Informationen von einem System zum anderen zu unterstützen (siehe Abbildung 1-2). Die Schichten kapseln die Informationen der jeweils darunter liegenden Schicht ein; diese Schichten sind Anwendung, Präsentation, Sitzung, Transport, Netzwerk, Datenverbindung und Physik. Auf den nächsten Seiten werden wir die Funktionen der einzelnen Schichten und die Art und Weise, wie sie Daten zwischen zwei Systemen übertragen, näher erläutern.

Jede Schicht nimmt die Daten von der vorherigen Schicht und kapselt sie auf zu einer eigenen Protokolldateneinheit (PDU). Die PDU wird verwendet, um die Daten auf jeder Schicht zu beschreiben. PDUs sind auch Teil von TCP/IP. Die Anwendungen der Sitzungsschicht werden als "Daten" für die PDU betrachtet und bereiten die Anwendungsinformationen für die Kommunikation vor. Der Transport verwendet Ports, um zu unterscheiden, welcher Prozess auf dem lokalen System für die Daten zuständig ist. Die PDU derNetzwerkschicht ist das Paket. Pakete sind einzelne Datenstücke, die zwischen Netzwerken weitergeleitet werden. Die Datenübertragungsschicht ist der Rahmen oder das Segment. Jedes Paket wird in Frames aufgeteilt, auf Fehler geprüft und an das lokale Netzwerk gesendet. Die physikalische Schicht überträgt den Rahmen in Bits über das Medium. Im Folgenden werden wir jede Schicht im Detail beschreiben:

Bewerbung: Die Anwendungsschicht ist die oberste Schicht des OSI-Modells und diejenige, mit der der Endnutzer jeden Tag interagiert. Auf dieser Schicht befinden sich keine eigentlichen Anwendungen, aber sie bietet die Schnittstelle für Anwendungen, die sie nutzen, wie z. B. ein Webbrowser oder Office 365. Die größte Schnittstelle ist HTTP; du liest dieses Buch wahrscheinlich auf einer Webseite, die von einem O'Reilly-Webserver gehostet wird. Andere Beispiele für die Anwendungsschicht, die wir täglich nutzen, sind DNS, SSH und SMTP. Diese Anwendungen sind für die Anzeige und Anordnung von Daten verantwortlich, die über das Netzwerk angefordert und gesendet werden.
Präsentation: Diese Schicht bietet Unabhängigkeit von der Datendarstellung, indem sie zwischen Anwendungs- und Netzwerkformaten übersetzt. Man kann sie auch als Syntaxschicht bezeichnen. Diese Schicht ermöglicht es zwei Systemen, unterschiedliche Kodierungen für Daten zu verwenden und trotzdem Daten zwischen ihnen auszutauschen. Auch die Verschlüsselung findet auf dieser Schicht statt, aber das ist eine kompliziertere Geschichte, die wir uns für "TLS" aufheben .
Sitzung: Die Schicht Session ist für den Duplex der Verbindung zuständig, also dafür, ob Daten gleichzeitig gesendet und empfangen werden. Außerdem legt sie Verfahren für das Checkpointing, das Anhalten, den Neustart und die Beendigung einer Sitzung fest. Sie baut die Verbindungen zwischen der lokalen und der entfernten Anwendung auf, verwaltet und beendet sie.
Transport: Die Transportschicht überträgt Daten zwischen Anwendungen und stellt den oberen Schichten zuverlässige Datenübertragungsdienste zur Verfügung. Die Transportschicht kontrolliert die Zuverlässigkeit einer bestimmten Verbindung durch Flusskontrolle, Segmentierung und Desegmentierung sowie Fehlerkontrolle. Einige Protokolle sind zustands- und verbindungsorientiert. Diese Schicht verfolgt die Segmente und überträgt diejenigen, die fehlschlagen, erneut. Sie liefert auch die Bestätigung für die erfolgreiche Datenübertragung und sendet die nächsten Daten, wenn keine Fehler aufgetreten sind. TCP/IP hat zwei Protokolle auf dieser Schicht: TCP und User DatagramProtocol (UDP).
Netzwerk: Die Netzwerkschicht ermöglicht die Übertragung von Datenströmen mit variabler Länge von einem Host in einem Netzwerk zu einem Host in einem anderen Netzwerk bei gleichzeitiger Aufrechterhaltung derDienstqualität. Die Netzwerkschicht führt Routing-Funktionen aus und kann auch Fragmentierung und Neuzusammensetzung vornehmen sowie Zustellungsfehler melden. Router arbeiten auf dieser Schicht und senden Daten durch die benachbarten Netzwerke. Zur Netzwerkschicht gehören mehrere Verwaltungsprotokolle, darunter Routing-Protokolle, die Verwaltung von Multicast-Gruppen, Informationen der Netzwerkschicht, die Fehlerbehandlung und die Zuweisung von Adressen der Netzwerkschicht, die wir im Abschnitt"TCP/IP" näher erläutern werden.
Datenverbindung: Diese Schicht ist verantwortlich für die Host-zu-Host-Übertragungen im selben Netzwerk. Sie definiert die Protokolle für den Aufbau und die Beendigung der Verbindungen zwischen zwei Geräten. Die Datenverbindungsschicht überträgt Daten zwischen Netzwerkhosts und stellt die Mittel zur Verfügung, um Fehler der physikalischen Schicht zu erkennen und möglicherweise zu korrigieren. Data Link Frames, die PDU der Schicht 2, überschreiten nicht die Grenzen eines lokalen Netzwerks.
Physisch: Die physikalische Schicht wird visuell durch ein Ethernet-Kabel dargestellt, das an einen Switch angeschlossen ist. Diese Schicht wandelt Daten in Form von digitalen Bits in elektrische, Funk- oder optische Signale um. Man kann sich diese Schicht als die physischen Geräte wie Kabel, Switches und drahtlose Zugangspunkte vorstellen. Auf dieser Schicht werden auch die Signalisierungsprotokolle für die Leitungen definiert.

Hinweis

Es gibt viele Mnemotechniken, um sich die Schichten des OSI-Modells zu merken; unser Favorit ist All People Seem To Need Data Processing.

Tabelle 1-2 fasst die OSI-Schichten zusammen.

Tabelle 1-2. Details zur OSI-Schicht
Schichtnummer	Name der Ebene	Protokolldateneinheit	Funktionsübersicht
7	Bewerbung	Daten	High-Level-APIs und Anwendungsprotokolle wie HTTP, DNS und SSH.
6	Präsentation	Daten	Zeichenkodierung, Datenkomprimierung und Verschlüsselung/Entschlüsselung.
5	Sitzung	Daten	Hier wird der kontinuierliche Datenaustausch zwischen den Knotenpunkten verwaltet: wie viele Daten gesendet werden sollen und wann mehr gesendet werden sollen.
4	Transport	Segment, Datagramm	Übertragung von Datensegmenten zwischen Endpunkten in einem Netzwerk, einschließlich Segmentierung, Quittierung und Multiplexing.
3	Netzwerk	Paket	Strukturierung und Verwaltung von Adressierung, Routing und Verkehrssteuerung für alle Endpunkte im Netzwerk.
2	Datenverbindung	Rahmen	Übertragung von Datenrahmen zwischen zwei Knotenpunkten, die durch eine physikalische Schicht verbunden sind.
1	Physisch	Bit	Senden und Empfangen von Bitströmen über das Medium.

Das OSI-Modell schlüsselt alle Funktionen auf, die notwendig sind, um ein Datenpaket über ein Netzwerk zwischen zwei Hosts zu senden. In den späten 1980er und frühen 1990er Jahren wurde es vom Verteidigungsministerium und allen anderen wichtigen Akteuren im Netzwerkbereich als Standard gegen TCP/IP durchgesetzt. Die Norm , die in ISO 7498 definiert ist, gibt einen kurzen Einblick in die Implementierungsdetails, die damals von den meisten als kompliziert, ineffizient und in gewissem Maße als nicht umsetzbar angesehen wurden. Das OSI-Modell auf hohem Niveau ermöglicht es denjenigen, die sich mit Netzwerken beschäftigen, immer noch, die grundlegenden Konzepte und Herausforderungen von Netzwerken zu verstehen. Außerdem werden diese Begriffe und Funktionen im TCP/IP-Modell, das im nächsten Abschnitt behandelt wird, und schließlich in den Kubernetes-Abstraktionen verwendet. Kubernetes-Dienste unterteilen jede Funktion je nach Schicht, auf der sie arbeitet, z. B. eine IP-Adresse der Schicht 3 oder einen Port der Schicht 4; mehr dazu erfährst du in Kapitel 4. Als Nächstes werden wir die TCP/IP-Suite anhand eines Beispiels genauer unter die Lupe nehmen.

TCP/IP

TCP/IP schafft ein heterogenes Netzwerk mit offenen Protokollen, die unabhängig von Betriebssystemen und Architekturunterschieden sind. Unabhängig davon, ob die Hosts mit Windows, Linux oder einem anderen Betriebssystem arbeiten, können sie über TCP/IP miteinander kommunizieren; TCP/IP ist es egal, ob du Apache oder Nginx als Webserver auf der Anwendungsschicht einsetzt. Die Trennung der Verantwortlichkeiten ähnlich dem OSI-Modell macht das möglich. In Abbildung 1-3 vergleichen wir das OSI-Modell mit TCP/IP.

Hier gehen wir auf die Unterschiede zwischen dem OSI-Modell und TCP/IP ein:

Bewerbung

In TCP/IP umfasst die Anwendungsschicht die Kommunikationsprotokolle, die bei der Prozess-zu-Prozess-Kommunikation in einem IP-Netzwerk verwendet werden. Die Anwendungsschicht standardisiert die Kommunikation und hängt von den zugrunde liegenden Protokollen der Transportschicht ab, um die Datenübertragung von Host zu Host herzustellen. Die untere Transportschicht verwaltet auch den Datenaustausch in der Netzwerkkommunikation. Die Anwendungen auf dieser Schicht werden in RFCs definiert; in diesem Buch werden wir weiterhin HTTP, RFC 7231 als Beispiel für die Anwendungsschicht verwenden.

Transport

TCP und UDP sind die Hauptprotokolle der Transportschicht, die Host-to-Host-Kommunikationsdienste für Anwendungen bereitstellen. Die Transportprotokolle sind für die verbindungsorientierte Kommunikation, die Zuverlässigkeit, die Flusskontrolle und das Multiplexing zuständig. Bei TCP steuert die Fenstergröße die Flusskontrolle, während UDP den Staufluss nicht steuert und als unzuverlässig gilt; mehr dazu erfährst du in "UDP". Jeder Port identifiziert den Hostprozess, der für die Verarbeitung der Informationen aus der Netzwerkkommunikation zuständig ist. HTTP verwendet den bekannten Port 80 für unsichere Kommunikation und 443 für sichere Kommunikation. Jeder Port auf dem Server identifiziert seinen Datenverkehr, und der Absender erzeugt lokal einen zufälligen Port, um sich zu identifizieren. Das Gremium , das die Zuweisung von Portnummern verwaltet, ist die Internet Assigned Number Authority (IANA); es gibt 65.535 Ports.

Internet

Die Internet- oder Netzwerkschicht ist für die Übertragung von Daten zwischen Netzwerken zuständig. Für ein ausgehendes Paket wählt sie den nächsten Host aus und überträgt es an diesen Host, indem sie es an die entsprechende Verbindungsschicht weitergibt. Sobald das Paket am Zielort angekommen ist, leitet die Internetschicht die Nutzlast des Pakets an das entsprechende Protokoll der Transportschicht weiter.

IP ermöglicht die Fragmentierung oder Defragmentierung von Paketen auf der Grundlage der maximalen Übertragungseinheit (MTU); das ist die maximale Größe des IP-Pakets. IP gibt keine Garantie dafür, dass die Pakete auch wirklich ankommen. Da die Zustellung von Paketen in verschiedenen Netzwerken von Natur aus unzuverlässig und fehleranfällig ist, liegt diese Last bei den Endpunkten eines Kommunikationspfads und nicht beim Netzwerk. Die Aufgabe, die Zuverlässigkeit des Dienstes zu gewährleisten, liegt in der Transportschicht. Eine Prüfsumme stellt sicher, dass die Informationen in einem empfangenen Paket korrekt sind, aber diese Schicht prüft nicht die Datenintegrität. Die IP-Adresse identifiziert die Pakete im Netzwerk.

Link

Die Schicht Link im TCP/IP-Modell umfasst Netzwerkprotokolle, die nur in dem lokalen Netzwerk funktionieren, mit dem sich ein Host verbindet. Pakete werden nicht an nicht-lokale Netzwerke weitergeleitet; das ist die Aufgabe der Internetschicht. Ethernet ist das vorherrschende Protokoll auf dieser Schicht, und die Hosts werden über die Link-Layer-Adresse oder üblicherweise über ihre Media Access Control-Adressen auf den Netzwerkkarten identifiziert. Sobald vom Host mithilfe des Address Resolution Protocol 9 (ARP) ermittelt wurde, werden die über das lokale Netzwerk gesendeten Daten von der Internetschicht verarbeitet. Diese Schicht umfasst auch Protokolle für die Übertragung von Paketen zwischen zwei Hosts der Internetschicht.

Physikalische Schicht

Die physikalische Schicht definiert die Komponenten der Hardware, die für das Netzwerk verwendet werden soll. Die physikalische Netzwerkschicht legt zum Beispiel die physikalischen Eigenschaften der Kommunikationsmedien fest. Die physikalische Schicht von TCP/IP beschreibt Hardware-Standards wie IEEE 802.3, die Spezifikation für Ethernet-Netzwerkmedien. Mehrere Interpretationen von RFC 1122 für die physikalische Schicht sind in den anderen Schichten enthalten; wir haben dies der Vollständigkeit halber hinzugefügt.

In diesem Buch werden wir den minimalen Golang-Webserver (auch Go genannt) aus Beispiel 1-1 verwenden, um die verschiedenen Ebenen der Netzwerkkomponenten von tcpdump, einem Linux-Syscall, zu zeigen, wie Kubernetes die Syscalls abstrahiert. In diesem Abschnitt wird gezeigt, was auf der Anwendungs-, Transport-, Netzwerk- und Datenverbindungsebene passiert.

Bewerbung

Wie bereits erwähnt, ist die Anwendung die höchste Schicht im TCP/IP-Stack; hier interagiert der Benutzer mit den Daten, bevor sie über das Netzwerk gesendet werden. In unserem Beispiel werden wir das Hypertext Transfer Protocol (HTTP) und eine einfache HTTP-Transaktion verwenden, um zu zeigen, was auf jeder Schicht des TCP/IP-Stacks passiert.

HTTP

HTTP ist verantwortlich für das Senden und Empfangen von HTML-Dokumenten (Hypertext Markup Language) - du weißt schon, eine Webseite. Ein großer Teil dessen, was wir im Internet sehen und tun, läuft über HTTP: Amazon-Einkäufe, Reddit-Posts und Tweets nutzen alle HTTP. Ein Client stellt eine HTTP-Anfrage an unseren minimalen Golang-Webserver aus Beispiel 1-1 und dieser sendet eine HTTP-Antwort mit dem Text "Hallo". Der Webserver läuft lokal in einer virtuellen Ubuntu-Maschine, um den kompletten TCP/IP-Stack zu testen.

Hinweis

Eine vollständige Anleitung findest du im Beispielcode-Repository.

Beispiel 1-1. Minimaler Webserver in Go

package main

import (
	"fmt"
	"net/http"
)

func hello(w http.ResponseWriter, _ *http.Request) {
	fmt.Fprintf(w, "Hello")
}

func main() {
	http.HandleFunc("/", hello)
	http.ListenAndServe("0.0.0.0:8080", nil)
}

In unserer virtuellen Ubuntu-Maschine müssen wir unseren minimalen Webserver starten. Wenn du Golang lokal installiert hast, kannst du dies auch einfach ausführen:

go run web-server.go

Lass uns die Anfrage für jede Schicht des TPC/IP-Stacks aufschlüsseln.

cURL ist der anfordernde Client für unser HTTP-Anfragebeispiel. Normalerweise wäre der Client für eine Webseite ein Webbrowser, aber wir verwenden cURL, um die Befehlszeile zu vereinfachen und anzuzeigen.

Hinweis

cURL ist für das Hoch- und Herunterladen von Daten gedacht, die mit einer URL angegeben werden. Es ist ein clientseitiges Programm (das c), das Daten von einer URL anfordert und die Antwort zurückgibt.

In Beispiel 1-2 können wir jeden Teil der HTTP-Anfrage, die der cURL-Client stellt, und die Antwort sehen. Schauen wir uns an, was all diese Optionen und Ausgaben sind.

Beispiel 1-2. Kundenanfrage

○ → curl localhost:8080 -vvv 
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8080 
> GET / HTTP/1.1 
> Host: localhost:8080 
> User-Agent: curl/7.64.1 
> Accept: */* 
>
< HTTP/1.1 200 OK 
< Date: Sat, 25 Jul 2020 14:57:46 GMT 
< Content-Length: 5 
< Content-Type: text/plain; charset=utf-8 
<
* Connection #0 to host localhost left intact
Hello* Closing connection 0

: curl localhost:8080 -vvv ist der Befehl curl, der eine Verbindung zum lokal laufenden Webserver localhost am TCP-Port 8080 öffnet. -vvv stellt die Ausführlichkeit der Ausgabe ein, damit wir alles sehen können, was mit der Anfrage passiert. Außerdem weist TCP_NODELAY die TCP-Verbindung an, die Daten ohne Verzögerung zu senden, eine von vielen Optionen, die der Client einstellen kann.
: Connected to localhost (::1) port 8080 Es hat funktioniert! cURL hat sich mit dem Webserver auf localhost und über Port 8080 verbunden.
: Get / HTTP/1.1 HTTP hat mehrere Methoden, um Informationen abzurufen oder zu aktualisieren. In unserer Anfrage führen wir einen HTTP GET aus, um unsere "Hallo"-Antwort abzurufen. Der Schrägstrich ist der nächste Teil, ein Uniform Resource Locator (URL), der angibt, wohin wir die Client-Anfrage an den Server senden. Der letzte Teil dieses Headers ist die Version von HTTP, die der Server verwendet, nämlich 1.1.
: Host: localhost:8080 HTTP hat mehrere Möglichkeiten, Informationen über die Anfrage zu senden. In unserer Anfrage hat der cURL-Prozess den HTTP-Host-Header gesetzt. Der Client und der Server können Informationen mit einer HTTP-Anfrage oder -Antwort übermitteln. Ein HTTP-Header enthält seinen Namen, gefolgt von einem Doppelpunkt (:) und dann seinen Wert.
: User-Agent: cURL/7.64.1: Der User Agent ist eine Zeichenfolge, die das Computerprogramm angibt, das die HTTP-Anfrage im Namen des Endnutzers stellt; in unserem Zusammenhang ist es cURL. Diese Zeichenkette identifiziert oft den Browser, seine Versionsnummer und sein Host-Betriebssystem.
: Accept: */* Header: Dieser Header teilt dem Webserver mit, welche Inhaltstypen der Client versteht. Tabelle 1-3 zeigt Beispiele für gängige Inhaltstypen, die gesendet werden können.
: HTTP/1.1 200 OK Dies ist die Antwort des Servers auf unsere Anfrage. Der Server antwortet mit der HTTP-Version und dem Statuscode der Antwort. Es gibt mehrere mögliche Antworten des Servers. Ein Statuscode von 200 bedeutet, dass die Antwort erfolgreich war. 1XX steht für Informationen, 2XX für erfolgreich, 3XX für Weiterleitungen, 4XX Antworten weisen auf Probleme mit den Anfragen hin und 5XX bezieht sich im Allgemeinen auf Probleme mit dem Server.
: Date: Sat, July 25, 2020, 14:57:46 GMT: Das Date Header-Feld gibt das Datum und die Uhrzeit an, zu der die Nachricht erstellt wurde. Der Absender generiert den Wert als ungefähres Datum und Uhrzeit der Nachrichtenerstellung.
: Content-Length: 5: Der Content-Length Header gibt die Größe des Nachrichtentextes in Bytes an, der an den Empfänger gesendet wird; in unserem Fall ist die Nachricht 5 Bytes groß.
: Content-Type: text/plain; charset=utf-8: Der Content-Type entity header wird verwendet, um den Medientyp der Ressource anzugeben. Unsere Antwort gibt an, dass es sich um eine reine Textdatei handelt, die in UTF-8 kodiert ist.
: Hello* Closing connection 0: Damit wird die Antwort von unserem Webserver ausgedruckt und die HTTP Verbindung geschlossen.

Tabelle 1-3. Gängige Inhaltstypen für HTTP-Daten
Typ	Beschreibung
Bewerbung	Jede Art von Binärdaten, die nicht explizit unter einen der anderen Typen fällt. Gängige Beispiele sind application/json, application/pdf, application/pkcs8 und application/zip.
Audio	Audio- oder Musikdaten. Beispiele sind audio/mpeg und audio/vorbis.
Schriftart	Schriftart/Schriftart-Daten. Gängige Beispiele sind font/woff, font/ttf und font/otf.
Bild	Bild- oder Grafikdaten, die sowohl Bitmap- als auch Vektordaten enthalten, wie z. B. animiertes GIF oder APNG. Gängige Beispiele sind image/jpg, image/png und image/svg+xml.
Modell	Modelldaten für ein 3D-Objekt oder eine Szene. Beispiele sind model/3mf und model/vrml.
Text	Reine Textdaten, die von Menschen lesbare Inhalte, Quellcode oder Textdaten enthalten. Beispiele sind text/plain, text/csv und text/html.
Video	Videodaten oder -dateien, wie z. B. Video/mp4.

Dies ist eine vereinfachte Ansicht, die bei jeder HTTP-Anfrage passiert. Heutzutage stellt eine einzige Webseite eine exorbitante Anzahl von Anfragen, wenn eine Seite geladen wird, und das in nur ein paar Sekunden! Dies ist ein kurzes Beispiel für Cluster-Administratoren, wie HTTP (und damit auch die Anwendungen der anderen sieben Schichten) funktionieren. Wir werden unser Wissen darüber erweitern, wie diese Anfrage auf jeder Schicht des TCP/IP-Stapels abgeschlossen wird und wie Kubernetes dieselben Anfragen abwickelt. All diese Daten werden auf Schicht 7 formatiert und Optionen festgelegt, aber die eigentliche Arbeit wird auf den unteren Schichten des TCP/IP-Stacks erledigt, die wir in den nächsten Abschnitten besprechen werden.

Transport

Die Protokolle der Transport schicht sind für die verbindungsorientierte Kommunikation, die Zuverlässigkeit, die Flusskontrolle und das Multiplexing zuständig; dies trifft vor allem auf TCP zu. Wir werden die Unterschiede in den folgenden Abschnitten beschreiben. Unser Golang-Webserver ist eine Layer-7-Anwendung, die HTTP verwendet; die Transportschicht, auf die sich HTTP stützt, ist TCP.

TCP

Wie bereits erwähnt, ist TCP ein verbindungsorientiertes, zuverlässiges Protokoll, das Flusskontrolle und Multiplexing bietet. TCP gilt als verbindungsorientiert, weil es den Verbindungsstatus während des gesamten Lebenszyklus der Verbindung verwaltet. Bei TCP wird die Flusskontrolle durch die Fenstergröße gesteuert, im Gegensatz zu UDP, das den Stau nicht steuert. Außerdem ist UDP unzuverlässig, und die Daten können außer der Reihe ankommen. Jeder Port identifiziert den Host-Prozess, der für die Verarbeitung der Informationen aus der Netzwerkkommunikation verantwortlich ist. TCP ist bekannt als ein Host-zu-Host-Schichtprotokoll. Um den Prozess auf dem Host, der für die Verbindung verantwortlich ist, zu identifizieren, kennzeichnet TCP die Segmente mit einer 16-Bit-Portnummer. HTTP Server verwenden den bekannten Port 80 für unsichere Kommunikation und 443 für sichere Kommunikation mit Transport Layer Security (TLS). Clients, die eine neue Verbindung anfordern, erstellen einen lokalen Quellport im Bereich von 0-65534.

Um zu verstehen, wie TCP das Multiplexing durchführt, schauen wir uns einen einfachen HTML-Seitenabruf an:

Gib in einem Webbrowser die Adresse einer Webseite ein.
Der Browser öffnet eine Verbindung, um die Seite zu übertragen.
Der Browser öffnet Verbindungen für jedes Bild auf der Seite.
Der Browser öffnet eine weitere Verbindung für das externe CSS.
Jede dieser Verbindungen verwendet einen anderen Satz von virtuellen Ports.
Alle Assets der Seite werden gleichzeitig heruntergeladen.
Der Browser rekonstruiert die Seite.

Schauen wir uns an, wie TCP das Multiplexing mit Hilfe der Informationen in den TCP-Segment-Headern verwaltet:

Source port (16 Bits): Damit wird der sendende Port identifiziert.
Destination port (16 Bits): Dies kennzeichnet den empfangenden Anschluss.
Sequence number (32 Bits): Wenn das SYN-Flag gesetzt ist , ist dies die anfängliche Sequenznummer. Die Sequenznummer des ersten Datenbytes und die bestätigte Nummer in der entsprechenden ACK ist diese Sequenznummer plus 1. Sie wird auch verwendet, um die Daten wieder zusammenzusetzen, wenn sie nicht in der richtigen Reihenfolge ankommen.

Acknowledgment number (32 Bits)

Wenn das ACK Flag gesetzt ist, ist der Wert dieses Feldes die nächste Sequenznummer der ACK, die der Absender erwartet. Damit wird der Empfang aller vorangegangenen Bytes (falls vorhanden) bestätigt. Die erste ACK eines jeden Endes bestätigt die erste Sequenznummer des anderen Endes, aber es wurden noch keine Daten gesendet.

Data offset (4 Bits)

Hier wird die Größe des TCP-Headers in 32-Bit-Wörtern angegeben.

Reserved (3 Bits)

Dies ist für die zukünftige Verwendung von und sollte auf Null gesetzt werden.

Flags (9 Bits)

Es gibt neun 1-Bit-Felder, die für den TCP-Header definiert sind:

NS-ECN-nonce: Tarnkappenschutz.
CWR: Congestion Window Reduced (Überlastungsfenster reduziert); der Absender hat seine Übertragungsrate reduziert.
ECE: ECN Echo; der Absender hat eine frühere Überlastungsmeldung erhalten.
URG: Dringend; das Feld Urgent Pointer ist gültig, wird aber selten verwendet.
ACK: Acknowledgment; das Feld Acknowledgment Number ist gültig und leuchtet immer, nachdem eine Verbindung hergestellt wurde.
PSH: Push; der Empfänger sollte diese Daten so schnell wie möglich an die Anwendung weitergeben.
RST: Zurücksetzen der Verbindung oder Verbindungsabbruch, normalerweise aufgrund eines Fehlers.
SYN: Synchronisiere Sequenznummern, um eine Verbindung zu initiieren.
FIN: Der Absender des Segments hat die Datenübertragung an seine Gegenstelle beendet.

Hinweis

Das NS-Bitfeld wird in RFC 3540, "Robust Explicit Congestion Notification (ECN) Signaling with Nonces" näher erläutert. Diese Spezifikation beschreibt einen optionalen Zusatz zu ECN, der die Robustheit gegen böswilliges oder versehentliches Verstecken von markierten Paketen verbessert.

Window size (16 Bits)

Dies ist die Größe des Empfangsfensters.

Checksum (16 Bits)

Das Feld Prüfsumme wird zur Fehlerprüfung des TCP-Headers verwendet.

Urgent pointer (16 Bits): Dies ist ein Offset von der Sequenznummer, der das letzte dringende Datenbyte angibt.
Options: Variable 0-320 Bits, in Einheiten von 32 Bits.
Padding: Das TCP-Header Padding wird verwendet, um sicherzustellen, dass der TCP-Header an einer 32-Bit-Grenze endet und die Daten beginnen.
Data: Dies ist der Teil der Anwendungsdaten, die in diesem Segment gesendet werden.

In Abbildung 1-4 siehst du alle TCP-Segment-Header, die Metadaten über die TCP-Streams liefern.

Diese Felder helfen dabei, den Datenfluss von zwischen zwei Systemen zu verwalten. Abbildung 1-5 zeigt, wie jeder Schritt des TCP/IP-Stacks Daten von einer Anwendung auf einem Host durch ein Netzwerk sendet, das auf den Schichten 1 und 2 kommuniziert, um die Daten zum Zielhost zu bringen.

Im nächsten Abschnitt werden wir zeigen, wie TCP diese Felder verwendet, um eine Verbindung durch den Drei-Wege-Handshake zu initiieren.

TCP-Handshake

TCP verwendet ein Drei-Wege-Handshake, das in Abbildung 1-6 dargestellt ist, um eine Verbindung herzustellen, indem es unterwegs Informationen mit verschiedenen Optionen und Flags austauscht:

Der anfordernde Knoten sendet eine Verbindungsanfrage über ein SYN-Paket, um die Übertragung zu starten.
Wenn der empfangende Knoten den vom Absender angeforderten Port abhört, antwortet der empfangende Knoten mit einem SYN-ACK, um zu bestätigen, dass er den anfordernden Knoten gehört hat.
Der anfragende Knoten sendet ein ACK-Paket zurück, in dem er Informationen austauscht und mitteilt, dass die Knoten bereit sind, sich gegenseitig Informationen zu senden.

Jetzt ist die Verbindung hergestellt. Die Daten können über das physische Medium übertragen und zwischen den Netzwerken geroutet werden, um ihren Weg zum lokalen Ziel zu finden - aber woher weiß der Endpunkt, wie er die Informationen verarbeiten soll? Auf den lokalen und entfernten Hosts von wird ein Socket erstellt, um diese Verbindung zu verfolgen. Ein Socket ist nur ein logischer Endpunkt für die Kommunikation. InKapitel 2 werden wir besprechen, wie ein Linux-Client und -Server mit Sockets umgehen.

TCP ist ein zustandsbehaftetes Protokoll, das den Zustand der Verbindung während ihres gesamten Lebenszyklus verfolgt. Der Zustand der Verbindung hängt davon ab, dass sowohl der Sender als auch der Empfänger sich darüber einig sind, wo sie sich im Verbindungsfluss befinden. Der Verbindungsstatus gibt Auskunft darüber, wer Daten im TCP-Stream sendet und empfängt. TCP verfügt über einen komplexen Zustandsübergang, der mit Hilfe der 9-Bit-TCP-Flags im TCP-Segmentheader erklärt, wann und wo sich die Verbindung befindet, wie du in Abbildung 1-7 sehen kannst.

Die TCP-Verbindungszustände sind:

LISTEN (Server): Steht für das Warten auf eine Verbindungsanfrage von einem beliebigen entfernten TCP und Port
SYN-SENT (Kunde): Steht für das Warten auf eine passende Verbindungsanfrage nach dem Senden einer Verbindungsanfrage
SYN-RECEIVED (Server): Steht für das Warten auf eine Bestätigung der Verbindungsanforderung, nachdem eine Verbindungsanforderung sowohl empfangen als auch gesendet wurde.
ESTABLISHED (sowohl Server als auch Client): Stellt eine offene Verbindung dar; empfangene Daten können dem Nutzer zugestellt werden - der Zwischenzustand für die Datenübertragungsphase der Verbindung
FIN-WAIT-1 (sowohl Server als auch Client): Steht für das Warten auf eine Verbindungsabbruchanforderung vom entfernten Host
FIN-WAIT-2 (sowohl Server als auch Client): Steht für das Warten auf eine Verbindungsabbruchanforderung vom entfernten TCP
CLOSE-WAIT (sowohl Server als auch Client): Steht für das Warten auf die Verbindungsabbruchanfrage eines lokalen Benutzers
CLOSING (sowohl Server als auch Client): Steht für das Warten auf eine Bestätigung des Verbindungsabbruchs von der entfernten TCP
LAST-ACK (sowohl Server als auch Client): Steht für das Warten auf eine Bestätigung der zuvor an den entfernten Host gesendeten Verbindungsabbruchanfrage
TIME-WAIT (entweder Server oder Client): Stellt dar, dass genügend Zeit verstrichen ist, um sicherzustellen, dass der entfernte Host die Bestätigung seiner Verbindungsabbruchanfrage erhalten hat.
CLOSED (sowohl Server als auch Client): Stellt überhaupt keinen Verbindungsstatus dar

Beispiel 1-3 ist ein Beispiel für die TCP-Verbindungen eines Macs, ihren Status und die Adressen für beide Enden der Verbindung.

Beispiel 1-3. Zustände der TCP-Verbindung

○ → netstat -ap TCP
Active internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp6       0      0  2607:fcc8:a205:c.53606 g2600-1407-2800-.https ESTABLISHED
tcp6       0      0  2607:fcc8:a205:c.53603 g2600-1408-5c00-.https ESTABLISHED
tcp4       0      0  192.168.0.17.53602     ec2-3-22-64-157..https ESTABLISHED
tcp6       0      0  2607:fcc8:a205:c.53600 g2600-1408-5c00-.https ESTABLISHED
tcp4       0      0  192.168.0.17.53598     164.196.102.34.b.https ESTABLISHED
tcp4       0      0  192.168.0.17.53597     server-99-84-217.https ESTABLISHED
tcp4       0      0  192.168.0.17.53596     151.101.194.137.https  ESTABLISHED
tcp4       0      0  192.168.0.17.53587     ec2-52-27-83-248.https ESTABLISHED
tcp6       0      0  2607:fcc8:a205:c.53586 iad23s61-in-x04..https ESTABLISHED
tcp6       0      0  2607:fcc8:a205:c.53542 iad23s61-in-x04..https ESTABLISHED
tcp4       0      0  192.168.0.17.53536     ec2-52-10-162-14.https ESTABLISHED
tcp4       0      0  192.168.0.17.53530     server-99-84-178.https ESTABLISHED
tcp4       0      0  192.168.0.17.53525     ec2-52-70-63-25..https ESTABLISHED
tcp6       0      0  2607:fcc8:a205:c.53480 upload-lb.eqiad..https ESTABLISHED
tcp6       0      0  2607:fcc8:a205:c.53477 text-lb.eqiad.wi.https ESTABLISHED
tcp4       0      0  192.168.0.17.53466     151.101.1.132.https    ESTABLISHED
tcp4       0      0  192.168.0.17.53420     ec2-52-0-84-183..https ESTABLISHED
tcp4       0      0  192.168.0.17.53410     192.168.0.18.8060      CLOSE_WAIT
tcp6       0      0  2607:fcc8:a205:c.53408 2600:1901:1:c36:.https ESTABLISHED
tcp4       0      0  192.168.0.17.53067     ec2-52-40-198-7..https ESTABLISHED
tcp4       0      0  192.168.0.17.53066     ec2-52-40-198-7..https ESTABLISHED
tcp4       0      0  192.168.0.17.53055     ec2-54-186-46-24.https ESTABLISHED
tcp4       0      0  localhost.16587        localhost.53029        ESTABLISHED
tcp4       0      0  localhost.53029        localhost.16587        ESTABLISHED
tcp46      0      0  *.16587                *.*                    LISTEN
tcp6      56      0  2607:fcc8:a205:c.56210 ord38s08-in-x0a..https CLOSE_WAIT
tcp6       0      0  2607:fcc8:a205:c.51699 2606:4700::6810:.https ESTABLISHED
tcp4       0      0  192.168.0.17.64407     do-77.lastpass.c.https ESTABLISHED
tcp4       0      0  192.168.0.17.64396     ec2-54-70-97-159.https ESTABLISHED
tcp4       0      0  192.168.0.17.60612     ac88393aca5853df.https ESTABLISHED
tcp4       0      0  192.168.0.17.58193     47.224.186.35.bc.https ESTABLISHED
tcp4       0      0  localhost.63342        *.*                    LISTEN
tcp4       0      0  localhost.6942         *.*                    LISTEN
tcp4       0      0  192.168.0.17.55273     ec2-50-16-251-20.https ESTABLISHED

Nachdem wir nun wissen, wie TCP Verbindungen aufbaut und verfolgt, wollen wir die HTTP-Anfrage für unseren Webserver auf der Transportschicht mit TCP überprüfen. Dazu verwenden wir ein Kommandozeilen-Tool namens tcpdump.

tcpdump

tcpdump gibt eine Beschreibung des Inhalts von Paketen auf einer Netzwerkschnittstelle aus, die mit dem booleschen Ausdruck übereinstimmt.

tcpdump man page

tcpdump ermöglicht es Administratoren und Benutzern, alle Pakete anzuzeigen, die auf dem System verarbeitet wurden, und sie anhand vieler TCP-Segment-Header-Details herauszufiltern. In der Anfrage filtern wir alle Pakete mit dem Zielport 8080 auf der Netzwerkschnittstelle mit der Bezeichnung lo0; das ist die lokale Loopback-Schnittstelle des Macs. Unser Webserver läuft auf 0.0.0.0:8080. Abbildung 1-8 zeigt , wo tcpdump Daten in Bezug auf den gesamten TCP/IP-Stack sammelt, zwischen dem Treiber der Netzwerkkarte (NIC) und der Schicht 2.

Hinweis

Eine Loopback Schnittstelle ist eine logische, virtuelle Schnittstelle auf einem Gerät. Eine Loopback-Schnittstelle ist keine physische Schnittstelle wie eine Ethernet-Schnittstelle. Loopback-Schnittstellen sind immer in Betrieb und immer verfügbar, auch wenn andere Schnittstellen auf dem Host nicht verfügbar sind.

Das allgemeine Format einer tcpdump Ausgabe enthält die folgenden Felder: tos,TTL, id, offset, flags, proto, length, und options. Schauen wir uns diese an:

tos: Der Typ des Dienstfeldes.
TTL: Die Zeit zu leben; sie wird nicht gemeldet, wenn sie Null ist.
id: Das IP Identifikationsfeld.
offset: Das Fragment Offset-Feld; es wird gedruckt, ob dieses Teil eines fragmentierten Datagramms ist oder nicht.
flags: Das Flag DF, Don't Fragment, das anzeigt, dass das Paket für die Übertragung nicht fragmentiert werden kann. Wenn es nicht gesetzt ist, bedeutet es, dass das Paket fragmentiert werden kann. Das Flag MF, More Fragments, zeigt an, dass es Pakete gibt, die noch weitere Fragmente enthalten, und wenn es nicht gesetzt ist, bedeutet es, dass keine weiteren Fragmente übrig sind.
proto: Das Protokoll ID-Feld.
length: Das Feld für die Gesamtlänge .
options: Die IP Optionen.

Systeme, die Prüfsummen-Offloading unterstützen, und IP-, TCP- und UDP-Prüfsummen werden auf der NIC berechnet, bevor sie über die Leitung übertragen werden. Da wir eine tcpdump Paketerfassung vor der NIC durchführen, erscheinen Fehler wie cksum 0xfe34 (incorrect -> 0xb4c1) in der Ausgabe von Beispiel 1-4.

Um die Ausgabe für Beispiel 1-4 zu erzeugen, öffne ein anderes Terminal und starte einen tcpdump Trace auf dem Loopback nur für TCP und Port 8080; andernfalls wirst du eine Menge anderer Pakete sehen, die für unser Beispiel nicht relevant sind. Du musst mit erweiterten Rechten verwenden, um Pakete zu verfolgen, also in diesem Fall sudo.

Beispiel 1-4. `tcpdump`

○ → sudo tcpdump -i lo0 tcp port 8080 -vvv  

tcpdump: listening on lo0, link-type NULL (BSD loopback),
capture size 262144 bytes  

08:13:55.009899 localhost.50399 > localhost.http-alt: Flags [S],
cksum 0x0034 (incorrect -> 0x1bd9), seq 2784345138,
win 65535, options [mss 16324,nop,wscale 6,nop,nop,TS val 587364215 ecr 0,
sackOK,eol], length 0 

08:13:55.009997 localhost.http-alt > localhost.50399: Flags [S.],
cksum 0x0034 (incorrect -> 0xbe5a), seq 195606347,
ack 2784345139, win 65535, options [mss 16324,nop,wscale 6,nop,nop,
TS val 587364215 ecr 587364215,sackOK,eol], length 0  

08:13:55.010012 localhost.50399 > localhost.http-alt: Flags [.],
cksum 0x0028 (incorrect -> 0x1f58), seq 1, ack 1,
win 6371, options [nop,nop,TS val 587364215 ecr 587364215],
length 0  

v 08:13:55.010021 localhost.http-alt > localhost.50399: Flags [.],
cksum 0x0028 (incorrect -> 0x1f58), seq 1, ack
1, win 6371, options [nop,nop,TS val 587364215 ecr 587364215],
length 0  

08:13:55.010079 localhost.50399 > localhost.http-alt: Flags [P.],
cksum 0x0076 (incorrect -> 0x78b2), seq 1:79,
ack 1, win 6371, options [nop,nop,TS val 587364215 ecr 587364215],
length 78: HTTP, length: 78  
GET / HTTP/1.1
Host: localhost:8080
User-Agent: curl/7.64.1
Accept: */*
08:13:55.010102 localhost.http-alt > localhost.50399: Flags [.],
cksum 0x0028 (incorrect -> 0x1f0b), seq 1,
ack 79, win 6370, options [nop,nop,TS val 587364215 ecr 587364215],
length 0  

08:13:55.010198 localhost.http-alt > localhost.50399: Flags [P.],
cksum 0x00a1 (incorrect -> 0x05d7), seq 1:122,
ack 79, win 6370, options [nop,nop,TS val 587364215 ecr 587364215],
length 121: HTTP, length: 121  
HTTP/1.1 200 OK
Date: Wed, 19 Aug 2020 12:13:55 GMT
Content-Length: 5
Content-Type: text/plain; charset=utf-8
Hello[!http]

08:13:55.010219 localhost.50399 > localhost.http-alt: Flags [.], cksum 0x0028
(incorrect -> 0x1e93), seq 79,
ack 122, win 6369, options [nop,nop,TS val 587364215 ecr 587364215], length 0  

08:13:55.010324 localhost.50399 > localhost.http-alt: Flags [F.],
cksum 0x0028 (incorrect -> 0x1e92), seq 79,
ack 122, win 6369, options [nop,nop,TS val 587364215 ecr 587364215],
length 0  

08:13:55.010343 localhost.http-alt > localhost.50399: Flags [.],
cksum 0x0028 (incorrect -> 0x1e91), seq 122,
\ack 80, win 6370, options [nop,nop,TS val 587364215 ecr 587364215],
length 0  

08:13:55.010379 localhost.http-alt > localhost.50399: Flags [F.],
cksum 0x0028 (incorrect -> 0x1e90), seq 122,
ack 80, win 6370, options [nop,nop,TS val 587364215 ecr 587364215],
length 0  

08:13:55.010403 localhost.50399 > localhost.http-alt: Flags [.],
cksum 0x0028 (incorrect -> 0x1e91), seq 80, ack
123, win 6369, options [nop,nop,TS val 587364215 ecr 587364215],
length 0  

 12 packets captured, 12062 packets received by filter
 0 packets dropped by kernel.

: Dies ist der Anfang der tcpdump Sammlung mit ihrem Befehl und allen Optionen. Das Paket sudo erfasst die erforderlichen erweiterten Rechte. tcpdump ist die Binärdatei tcpdump. -i lo0 ist die Schnittstelle, von der wir Pakete erfassen wollen. dst port 8080 ist der passende Ausdruck, der auf der Manpage besprochen wurde; hier werden alle Pakete erfasst, die für den TCP-Port 8080 bestimmt sind, den Port, an dem der Webservice auf Anfragen lauscht. -v ist die Verbose-Option, mit der wir mehr Details der tcpdump Erfassung sehen können.
: Feedback von tcpdump, das uns über den laufenden tcpdump Filter informiert.
: Dies ist das erste Paket im TCP-Handshake. Wir können erkennen, dass es sich um SYN handelt, weil das Flags-Bit mit [S] gesetzt ist und die Sequenznummer von cURL auf 2784345138 gesetzt wird, wobei die Prozessnummer von localhost 50399 ist.
: Das SYN-ACK-Paket ist dasjenige, das von tcpdump aus dem Prozess localhost.http-alt, dem Webserver von Golang, gefiltert wird. Das Flag ist auf [S.] gesetzt, also ist es ein SYN-ACK. Das Paket sendet 195606347 als nächste Sequenznummer, und ACK 2784345139 wird gesetzt, um das vorherige Paket zu bestätigen.
: Das Bestätigungspaket von cURL wird nun mit gesetztem ACK-Flag [.] an den Server zurückgeschickt, wobei die ACK- und SYN-Nummern auf 1 gesetzt sind, was bedeutet, dass er bereit ist, Daten zu senden.
: Die Bestätigungsnummer wird auf 1 gesetzt, um den Empfang des SYN-Flags des Kunden im Eröffnungsdaten-Push anzuzeigen.
: Die TCP-Verbindung ist aufgebaut; sowohl der Client als auch der Server sind bereit für die Datenübertragung. Die nächsten Pakete sind unsere Datenübertragungen der HTTP-Anfrage mit dem Flag, das auf einen Daten-Push und ACK gesetzt ist, [P.]. Die vorherigen Pakete hatten eine Länge von Null, aber die HTTP-Anfrage ist 78 Byte lang und hat eine Sequenznummer von 1:79.
: Der Server bestätigt den Empfang der Datenübertragung mit dem gesetzten ACK-Flag, [.], indem er die Bestätigungsnummer 79 sendet.
: Dieses Paket ist die Antwort des HTTP-Servers auf die cURL-Anfrage. Das Daten-Push-Flag ist gesetzt, [P.], und es bestätigt das vorherige Paket mit einer ACK-Nummer von 79. Bei der Datenübertragung wird eine neue Sequenznummer gesetzt, 122, und die Datenlänge beträgt 121 Byte.
: Der cURL-Client bestätigt den Empfang des Pakets mit dem gesetzten ACK-Flag, setzt die Bestätigungsnummer auf 122 und die Sequenznummer auf 79.
: Der Beginn des Schließens der TCP-Verbindung, wobei der Client das FIN-ACK-Paket, das [F.], sendet, das den Empfang des vorherigen Pakets, Nummer 122, und eine neue Sequenznummer an 80 bestätigt.
: Der Server erhöht die Bestätigungsnummer auf 80 und setzt das ACK-Flag.
: TCP erfordert, dass sowohl der Sender als auch der Empfänger das FIN-Paket zum Schließen der Verbindung setzen. In diesem Paket werden die Flaggen FIN und ACK gesetzt.
: Dies ist die letzte ACK vom Kunden mit der Bestätigungsnummer 123. Die Verbindung ist jetzt geschlossen.
: tcpdump beim Beenden zeigt uns die Anzahl der Pakete in diesem Capture, die Gesamtzahl der Pakete, die während des tcpdump erfasst wurden, und wie viele Pakete vom Betriebssystem verworfen wurden.

tcpdump ist eine hervorragende Anwendung zur Fehlersuche für Netzwerktechniker und Cluster-Administratoren. Die Fähigkeit, die Konnektivität auf vielen Ebenen des Clusters und des Netzwerks zu überprüfen, ist eine wertvolle Fähigkeit. Du wirst in Kapitel 6 sehen, wie nützlich tcpdump sein kann.

Unser Beispiel war eine einfache HTTP-Anwendung, die TCP verwendet. Alle diese Daten wurden im Klartext über das Netzwerk gesendet. Während es sich bei diesem Beispiel um ein einfaches Hello World handelte, müssen andere Anfragen, wie z. B. die Anmeldung bei unserer Bank, abgesichert werden. Die Transportschicht bietet keinen Schutz für Daten, die über das Netzwerk übertragen werden. TLS fügt zusätzliche Sicherheit zu TCP hinzu. Darauf gehen wir in unserem nächsten Abschnitt ein.

TLS

TLS erweitert TCP um die Verschlüsselung . TLS ist ein Zusatz zur TCP/IP-Suite und wird nicht als Teil der Basisfunktion von TCP betrachtet. HTTP-Transaktionen können ohne TLS durchgeführt werden, sind aber nicht vor Abhörern auf der Leitung sicher. TLS ist eine Kombination von Protokollen, mit denen sichergestellt wird, dass der Datenverkehr zwischen dem Absender und dem vorgesehenen Empfänger sichtbar ist. Ähnlich wie TCP verwendet TLS einen Handshake, um die Verschlüsselungsmöglichkeiten festzustellen und Schlüssel für die Verschlüsselung auszutauschen. Die folgenden Schritte beschreiben den TLS-Handshake zwischen dem Client und dem Server, der auch in Abbildung 1-9 zu sehen ist:

ClientHello: Dies enthält die vom Client unterstützten Cipher Suites und eine Zufallszahl.
ServerHello: Diese Nachricht enthält die unterstützte Chiffre und eine Zufallszahl.
ServerZertifikat: Dies enthält das Zertifikat des Servers und den öffentlichen Schlüssel des Servers.
ServerHelloDone: Dies ist das Ende des ServerHello. Wenn der Client eine Anfrage für sein Zertifikat erhält, sendet er eine ClientCertificate-Nachricht.
ClientKeyExchange: Ausgehend von der Zufallszahl des Servers erzeugt unser Client ein zufälliges Premaster-Geheimnis, verschlüsselt es mit dem öffentlichen Schlüsselzertifikat des Servers und sendet es an den Server.
Schlüsselgenerierung: Der Client und der Server generieren ein Mastergeheimnis aus dem Premastergeheimnis und tauschen Zufallswerte aus.
ChangeCipherSpec: Jetzt tauschen der Client und der Server ihre ChangeCipherSpec aus, um die neuen Schlüssel für die Verschlüsselung zu verwenden.
Beendeter Client: Der Client sendet die Fertigmeldung, um zu bestätigen, dass der Schlüsselaustausch und die Authentifizierung erfolgreich waren.
Beendeter Server: Jetzt sendet der Server die Fertigmeldung an den Client, um den Handshake zu beenden.

Kubernetes-Anwendungen und -Komponenten verwalten TLS für Entwickler, daher ist eine grundlegende Einführung erforderlich; in Kapitel 5 erfährst du mehr über TLS und Kubernetes.

Wie wir mit unserem Webserver cURL und tcpdump gezeigt haben, ist TCP ein zustandsabhängiges und zuverlässiges Protokoll für die Datenübertragung zwischen Hosts. Durch die Verwendung von Flags in Verbindung mit dem Sequenz- und Bestätigungsnummerntanz werden Tausende von Nachrichten über unzuverlässige Netzwerke auf der ganzen Welt übertragen. Diese Zuverlässigkeit hat jedoch ihren Preis. Von den 12 Paketen, die wir eingestellt haben, waren nur zwei echte Datenübertragungen. Für Anwendungen, die keine Zuverlässigkeit benötigen, wie z. B. Sprachübertragungen, bietet der Overhead von UDP eine Alternative. Da wir nun wissen, wie TCP als zuverlässiges verbindungsorientiertes Protokoll funktioniert, wollen wir uns ansehen, wie sich UDP von TCP unterscheidet.

UDP

UDP bietet eine Alternative für Anwendungen, die nicht die Zuverlässigkeit von TCP benötigen. UDP ist eine ausgezeichnete Wahl für Anwendungen, die Paketverluste verkraften können, wie z. B. Sprach- und DNS-Anwendungen. Im Gegensatz zu seinem ausführlichen Bruder TCP bietet UDP aus der Netzwerkperspektive nur wenig Overhead, da es nur vier Felder und keine Datenbestätigung enthält.

Es ist transaktionsorientiert und eignet sich für einfache Anfrage- und Antwortprotokolle wie das Domain Name System (DNS) und das Simple Network Management Protocol (SNMP). UDP unterteilt eine Anfrage in Datagramme und kann daher mit anderen Protokollen für das Tunneln wie ein virtuelles privates Netzwerk (VPN) verwendet werden. Es ist leichtgewichtig und einfach, was es im Falle von DHCP ideal für das Bootstrapping von Anwendungsdaten macht. Die zustandslose Art der Datenübertragung macht UDP perfekt für Anwendungen wie z. B. Sprachübertragungen, die Paketverluste verkraften können - hast du das gehört? Da UDP keine erneute Übertragung vorsieht, eignet es sich auch hervorragend für das Streaming von Videos.

Schauen wir uns unter die wenigen Header an, die in einem UDP-Datagramm benötigt werden (siehe Abbildung 1-10):

Source port number (2 Bytes): Identifiziert den Port des Absenders. Der Quellhost ist der Client; die Portnummer ist flüchtig. UDP-Ports haben bekannte Nummern wie DNS auf 53 oder DHCP 67/68.
Destination port number (2 Bytes): Kennzeichnet den Anschluss des Empfängers und ist erforderlich.
Length (2 Bytes): Legt die Länge in Bytes des UDP-Headers und der UDP-Daten fest. Die Mindestlänge ist 8 Byte, die Länge des Headers.
Checksum (2 Bytes): Wird für die Fehlerprüfung des Headers und der Daten verwendet. Sie ist in IPv4 optional, in IPv6 jedoch obligatorisch und besteht aus Nullen, wenn sie nicht verwendet wird.

UDP und TCP sind allgemeine Transportprotokolle, die den Versand und Empfang von Daten zwischen Hosts ermöglichen. Kubernetes unterstützt beide Protokolle im Netzwerk, und Dienste ermöglichen es den Nutzern, die Last vieler Pods über Dienste auszugleichen. Wichtig ist auch, dass die Entwickler in jedem Dienst das Transportprotokoll definieren müssen. Wenn sie dies nicht tun, wird standardmäßig TCP verwendet .

Die nächste Schicht im TCP/IP-Stack ist die Internetworking-Schicht - das sind die Pakete, die in den riesigen Netzwerken, aus denen das Internet besteht, über den Globus geschickt werden können. Schauen wir uns an, wie das funktioniert.

Netzwerk

Alle TCP- und UDP-Daten werden als IP-Pakete in TCP/IP auf der Netzwerkschicht übertragen. Die Internet- oder Netzwerkschicht ist für die Übertragung von Daten zwischen Netzwerken zuständig. Ausgehende Pakete wählen den Next-Hop-Host aus und senden die Daten an diesen Host, indem sie ihm die entsprechenden Details der Verbindungsschicht übergeben; die Pakete werden von einem Host empfangen, entkapselt und an das richtige Protokoll der Transportschicht weitergeleitet. In IPv4 bietet IP sowohl beim Senden als auch beim Empfangen eine Fragmentierung oder Defragmentierung der Pakete basierend auf der MTU; dies ist die maximale Größe des IP-Pakets.

IP garantiert nicht, dass Pakete ordnungsgemäß ankommen. Da die Zustellung von Paketen über verschiedene Netzwerke von Natur aus unzuverlässig und fehleranfällig ist, liegt diese Last bei den Endpunkten eines Kommunikationspfads und nicht beim Netzwerk. Wie im vorherigen Abschnitt beschrieben, ist die Transportschicht für die Zuverlässigkeit der Dienste zuständig. Jedes Paket ist mit einer Prüfsumme versehen, um sicherzustellen, dass die Informationen des empfangenen Pakets korrekt sind, aber diese Schicht prüft nicht die Integrität der Daten. Quell- und Ziel-IP-Adressen identifizieren die Pakete im Netzwerk, was wir als Nächstes behandeln werden.

Internetprotokoll

Dieses allmächtige Paket ist in RFC 791 definiert und wird zum Senden von Daten über Netzwerke verwendet. Abbildung 1-11 zeigt das IPv4-Header-Format.

Schauen wir uns die Kopffelder genauer an:

Version

Das erste Header-Feld im IP-Paket ist das Vier-Bit-Versionsfeld. Bei IPv4 ist es immer gleich vier.

Internet Header Length (IHL)

Der IPv4 Header hat eine variable Größe aufgrund der optionalen 14.

Type of Service

Ursprünglich als Type of Service (ToS) definiert, jetzt Differentiated Services Code Point (DSCP), gibt dieses Feld differenzierte Dienste an. DSCP ermöglicht es Routern und Netzwerken, in Zeiten der Überlastung Entscheidungen über die Priorität von Paketen zu treffen. Technologien wie Voice over IP nutzen DSCP, um sicherzustellen, dass Anrufe Vorrang vor anderem Verkehr haben.

Total Length

Dies ist die gesamte Paketgröße in Bytes.

Identification

Dies ist das Identifikationsfeld und wird zur eindeutigen Identifizierung der Gruppe von Fragmenten eines einzelnen IP-Datagramms verwendet.

Flags

Dies ist , das zur Kontrolle oder Identifizierung von Fragmenten verwendet wird. In der Reihenfolge vom höchsten zum niedrigsten Wert:

Bit 0: Reserviert, auf Null gesetzt
Bit 1: Nicht fragmentieren
bit 2: Weitere Fragmente

Fragment Offset

Dies gibt den Offset eines bestimmten Fragments relativ zum ersten unfragmentierten IP-Paket an. Das erste Fragment hat immer einen Versatz von Null.

Time To Live (TTL)

Ein 8-Bit-Feld time to live verhindert, dass sich Datagramme im Netzwerk im Kreis drehen.

Protocol

Diese wird im Datenteil des IP-Pakets verwendet. Die IANA hat eine Liste von IP-Protokollnummern in RFC 790; einige bekannte Protokolle sind auch in Tabelle 1-4 aufgeführt.

Tabelle 1-4. IP-Protokollnummern
Protokollnummer	Name des Protokolls	Abkürzung
1	Internet Control Message Protocol	ICMP
2	Internet Group Management Protocol	IGMP
6	Übertragungssteuerungsprotokoll	TCP
17	Benutzer-Datagramm-Protokoll	UDP
41	IPv6-Kapselung	ENCAP
89	Kürzester Weg zuerst öffnen	OSPF
132	Stream Control Transmission Protocol	SCTP

Header Checksum (16-bit)

Das Prüfsummenfeld des IPv4-Headers wird zur Fehlerprüfung verwendet. Wenn ein Paket ankommt, berechnet ein Router die Prüfsumme des Headers; wenn die beiden Werte nicht übereinstimmen, verwirft der Router das Paket. Das eingekapselte Protokoll muss Fehler im Datenfeld behandeln. Sowohl UDP als auch TCP haben Prüfsummenfelder.

Hinweis

Wenn der Router ein Paket empfängt, setzt er das TTL-Feld um eins herab. Infolgedessen muss der Router eine neuePrüfsumme berechnen.

Source address

Dies ist die IPv4-Adresse des Absenders des Pakets.

Hinweis

Die Quelladresse kann während der Übertragung durch ein Netzwerkadressübersetzungsgerät geändert werden; NAT wird später in diesem Kapitel und ausführlich in Kapitel 3 behandelt.

Destination address

Dies ist die IPv4-Adresse des Empfängers des Pakets. Wie die Quelladresse kann ein NAT-Gerät auch die IP-Adresse des Empfängers ändern.

Options

Die möglichen Optionen in der Kopfzeile sind Kopiert, Optionsklasse, Optionsnummer, Optionslänge und Optionsdaten.

Die entscheidende Komponente ist hier die Adresse, mit der Netzwerke identifiziert werden. Sie identifizieren gleichzeitig den Host im Netzwerk und das gesamte Netzwerk (mehr dazu in "Das Netzwerk kennenlernen"). Das Wissen, wie man eine IP-Adresse identifiziert, ist für einen Ingenieur entscheidend. Zuerst werden wir uns IPv4 ansehen und dann die drastischen Änderungen in IPv6 verstehen.

IPv4-Adressen werden für uns Menschen in der Punkt-Dezimal-Schreibweise angegeben; Computer lesen sie als binäre Zeichenfolgen aus. Abbildung 1-12zeigt die punktierte Dezimalschreibweise und die Binärschreibweise im Detail. Jeder Abschnitt ist 8 Bits lang, mit vier Abschnitten, so dass die Gesamtlänge 32 Bits beträgt. IPv4-Adressen bestehen aus zwei Teilen: Der erste Teil ist das Netzwerk und der zweite Teil ist die eindeutige Kennung des Hosts im Netzwerk.

In Beispiel 1-5 wird die IP-Adresse eines Computers für seine Netzwerkkarte ausgegeben und wir sehen, dass die IPv4-Adresse 192.168.1.2 lautet. Der IP-Adresse ist auch eine Subnetzmaske oder Netzmaske zugeordnet, um zu erkennen, welches Netzwerk ihr zugewiesen ist. Das Subnetz des Beispiels ist netmask 0xffffff00 in punktierter Dezimalzahl, also 255.255.255.0.

Beispiel 1-5. IP-Adresse

○ → ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=400<CHANNEL_IO>
	ether 38:f9:d3:bc:8a:51
	inet6 fe80::8f4:bb53:e500:9557%en0 prefixlen 64 secured scopeid 0x6
	inet 192.168.1.2 netmask 0xffffff00 broadcast 192.168.1.255
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: active

Das Subnetz bringt die Idee der klassenweisen Adressierung auf den Punkt. Ursprünglich wurde bei der Zuweisung eines IP-Adressbereichs davon ausgegangen, dass ein Bereich eine Kombination aus einem 8-, 16- oder 24-Bit-Netzwerkpräfix und einer 24-, 16- oder 8-Bit-Hostkennung ist. Klasse A hatte 8 Bits für den Host, Klasse B 16 und Klasse C 24. Danach hatte Klasse A 2 hoch 16 Hosts zur Verfügung, also 16.777.216; Klasse B hatte 65.536 und Klasse C hatte 256. Jede Klasse hatte eine Host-Adresse, die erste in ihrer Begrenzung, und die letzte wurde als Broadcast-Adresse bezeichnet. Abbildung 1-13 veranschaulicht dies für uns.

Hinweis

Es gibt noch zwei weitere Klassen, die aber in der Regel nicht für IP-Adressen verwendet werden. Adressen der Klasse D werden für IP-Multicasting verwendet, und Adressen der Klasse E sind für experimentelle Zwecke reserviert.

Die Klassenadressierung war im Internet nicht skalierbar ( ). Um das Problem der Skalierbarkeit zu lösen, begannen wir , die Klassengrenzen mit Hilfe von CIDR-Bereichen (Classless Inter-Domain Routing) aufzulösen. Anstatt die gesamten über 16 Millionen Adressen in einem Klassenadressbereich zu haben, gibt ein Internetunternehmen nur einen Teil dieses Bereichs an. Dadurch können Netzwerktechniker/innen die Subnetzgrenze an eine beliebige Stelle innerhalb des Klassenbereichs verschieben, was ihnen mehr Flexibilität mit CIDR-Bereichen gibt und die Skalierung von IP-Adressbereichen erleichtert.

In Abbildung 1-14 sehen wir die Aufteilung der 208.130.29.33 IPv4-Adresse und die dadurch entstehende Hierarchie. Der 208.128.0.0/11 CIDR-Bereich wird ARIN von der IANA zugewiesen. ARIN unterteilt das Subnetz für seine Zwecke weiter in immer kleinere Subnetze, bis hin zum einzelnen Host im Netzwerk 208.130.29.33/32.

Hinweis

Die globale Koordination der DNS-Root, der IP-Adressen und anderer Internetprotokoll-Ressourcen wird von der IANA durchgeführt.

Letztendlich führte jedoch auch diese Praxis, den Bereich einer IPv4-Adresse mit CIDR zu erweitern, dazu, dass die zu verteilenden Adressräume erschöpft waren, was Netzwerkingenieure und die IETF dazu veranlasste, den IPv6-Standard zu entwickeln.

In Abbildung 1-15 ist zu sehen, dass IPv6 im Gegensatz zu IPv4 hexadezimale Werte verwendet, um die Adressen zu verkürzen. Es hat ähnliche Eigenschaften wie IPv4, da es ein Host- und ein Netzwerkpräfix hat.

Der wichtigste Unterschied zwischen IPv4 und IPv6 ist die Größe des Adressraums. IPv4 hat 32 Bits, während IPv6 128 Bits hat, um seine Adressen zu erzeugen. Um diesen Größenunterschied zu verdeutlichen, sind hier die Zahlen:

IPv4 hat 4.294.967.296.

IPv6 has 340,282,366,920,938,463,463,374,607,431,768,211,456.

Da wir nun wissen, wie ein einzelner Host im Netzwerk identifiziert wird und zu welchem Netzwerk er gehört, werden wir untersuchen, wie diese Netzwerke mithilfe von Routing-Protokollen Informationen untereinander austauschen.

Das Netzwerk erkunden

Die Pakete sind adressiert und die Daten können gesendet werden, aber wie kommen die Pakete von unserem Host in unserem Netzwerk zu dem Ziel in einem anderen Netzwerk am anderen Ende der Welt? Das ist die Aufgabe des Routings. Es gibt verschiedene Routing-Protokolle, aber das Internet setzt auf das Border Gateway Protocol (BGP), ein dynamisches Routing-Protokoll, das dafür sorgt, dass die Pakete zwischen den Kanten-Routern im Internet weitergeleitet werden. Es ist für uns relevant, weil einige Kubernetes-Netzwerkimplementierungen BGP nutzen, um den Cluster-Netzwerkverkehr zwischen den Knoten zu routen. Zwischen den einzelnen Knoten in den einzelnen Netzwerken gibt es eine Reihe von Routern.

Wenn wir uns die Karte des Internets in Abbildung 1-1 ansehen, wird jedem Netzwerk im Internet eine autonome BGP-Systemnummer (ASN) zugewiesen, um eine einzelne administrative Einheit oder Gesellschaft zu bezeichnen, die eine gemeinsame und klar definierte Routing-Politik im Internet vertritt. BGP und ASNs ermöglichen es Netzwerkadministratoren, die Kontrolle über das Routing ihres internen Netzwerks zu behalten und gleichzeitig ihre Routen im Internet anzukündigen und zusammenzufassen. In Tabelle 1-5 sind die verfügbaren ASNs aufgeführt, die von IANA und anderen regionalen Stellen verwaltet werden.¹

Tabelle 1-5. Verfügbare ASNs
Nummer	Bits	Beschreibung	Referenz
0	16	Reserviert	RFC 1930, RFC 7607
1-23455	16	Öffentliche ASNs
23456	16	Reserviert für AS-Pool-Übergang	RFC 6793
23457-64495	16	Öffentliche ASNs
64496-64511	16	Reserviert für die Verwendung in der Dokumentation/im Beispielcode	RFC 5398
64512-65534	16	Für den privaten Gebrauch reserviert	RFC 1930, RFC 6996
65535	16	Reserviert	RFC 7300
65536-65551	32	Reserviert für die Verwendung in der Dokumentation und im Beispielcode	RFC 4893, RFC 5398
65552-131071	32	Reserviert
131072-4199999999	32	Öffentliche 32-Bit-ASNs
4200000000–4294967294	32	Für den privaten Gebrauch reserviert	RFC 6996
4294967295	32	Reserviert	RFC 7300

In Abbildung 1-16 haben wir fünf ASNs, 100-500. Ein Host auf 130.10.1.200 möchte einen Host erreichen, der auf 150.10.2.300 liegt. Sobald der lokale Router oder das Standardgateway für den Host 130.10.1.200 das Paket erhält, sucht er nach der Schnittstelle und dem Pfad für 150.10.2.300, die BGP für diese Route ermittelt hat.

Anhand der Routing-Tabelle in Abbildung 1-17 hat der Router für AS 100 festgestellt, dass das Paket zu AS 300 gehört und der bevorzugte Weg über die Schnittstelle 140.10.1.1 führt. Dies wird auf AS 200 so lange wiederholt, bis der lokale Router für 150.10.2.300 auf AS 300 das Paket empfängt. Der Ablauf wird in Abbildung 1-6 beschrieben, die den TCP/IP-Datenfluss zwischen Netzwerken zeigt. Grundlegende Kenntnisse über BGP sind erforderlich, da einige Container-Netzwerkprojekte wie Calico BGP für das Routing zwischen den Knotenpunkten nutzen; mehr dazu erfährst du in Kapitel 3.

Abbildung 1-17 zeigt eine lokale Routentabelle. In der Routentabelle ist zu erkennen, dass die Schnittstelle, über die ein Paket gesendet wird, auf der IP-Adresse des Ziels basiert. Zum Beispiel wird ein Paket, das für 192.168.1.153 bestimmt ist, über das Gateway link#11 gesendet, das lokal im Netzwerk liegt und kein Routing benötigt. 192.168.1.254 ist der Router in dem Netzwerk, das mit unserer Internetverbindung verbunden ist. Wenn das Zielnetzwerk unbekannt ist, wird es über die Standardroute gesendet.

Hinweis

Wie bei allen Linux- und BSD-Betriebssystemen findest du weitere Informationen zu auf der Manpage von netstat(man netstat). Apples netstat ist von der BSD-Version abgeleitet. Weitere Informationen findest du im FreeBSD-Handbuch.

Router kommunizieren ständig über das Internet, tauschen Routeninformationen aus und informieren sich gegenseitig über Änderungen in ihren jeweiligen Netzwerken. BGP kümmert sich um einen Großteil dieses Datenaustauschs, aber Netzwerkingenieure und Systemadministratoren können das ICMP-Protokoll und die ping Befehlszeilentools verwenden, um die Konnektivität zwischen Hosts und Routern zu testen.

ICMP

ping ist ein Netzwerk Dienstprogramm, das ICMP verwendet, um die Konnektivität zwischen Hosts im Netzwerk zu testen. In Beispiel 1-6 sehen wir einen erfolgreichen ping Test an 192.168.1.2, bei dem fünf Pakete alle eine ICMP Echo-Antwort zurückgeben.

Beispiel 1-6. ICMP-Echo-Anfrage

○ → ping 192.168.1.2 -c 5
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.052 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.089 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.142 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.050 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.050 ms
--- 192.168.1.2 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.050/0.077/0.142/0.036 ms

Beispiel 1-7 zeigt einen fehlgeschlagenen Ping-Versuch, der beim Versuch, den Host 1.2.3.4 zu erreichen, eine Zeitüberschreitung verursacht. Router und Administratoren nutzen ping, um Verbindungen zu testen, und es ist auch nützlich, um die Konnektivität von Containern zu testen. Mehr dazu erfährst du in den Kapiteln 2 und 3, wenn wir unseren minimalen Golang-Webserver in einem Container und einem Pod einrichten.

Beispiel 1-7. ICMP-Echoanforderung fehlgeschlagen

○ → ping 1.2.3.4 -c 4
PING 1.2.3.4 (1.2.3.4): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
--- 1.2.3.4 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss

Wie bei TCP und UDP gibt es Header, Daten und Optionen in ICMP-Paketen; sie werden hier besprochen und inAbbildung 1-18 dargestellt:

Type: ICMP-Typ.
Code: ICMP-Subtyp.
Checksum: Internet Prüfsumme zur Fehlerprüfung, die aus dem ICMP-Header und den Daten mit dem Wert 0 berechnet wird, ersetzt dieses Feld.
Rest of Header (4-Byte-Feld): Der Inhalt hängt vom ICMP-Typ und -Code ab.
Data: ICMP-Fehlermeldungen enthalten einen Datenteil, der eine Kopie des gesamten IPv4-Headers enthält.

Hinweis

Manche betrachten ICMP als ein Transportschichtprotokoll, da es weder TCP noch UDP verwendet. In RFC 792 wird ICMP definiert, das Routing-, Diagnose- und Fehlerfunktionen für IP bereitstellt. Obwohl ICMP-Meldungen in IP-Datagrammen gekapselt sind, wird die ICMP-Verarbeitung als Teil der IP-Schicht betrachtet und in der Regel auch so implementiert. ICMP ist das IP-Protokoll 1, während TCP das Protokoll 6 und UDP das Protokoll 17 ist.

Der Wert kennzeichnet Kontrollmeldungen im Feld Type. Das Feld code enthält zusätzliche Kontextinformationen für die Nachricht. Einige Standard-ICMP-Typnummern findest du in Tabelle 1-6.

Tabelle 1-6. Übliche ICMP-Typnummern
Nummer	Name	Referenz
0	Echo Antwort	RFC 792
3	Ziel unerreichbar	RFC 792
5	umleiten	RFC 792
8	Echo	RFC 792

Jetzt, da unsere Pakete wissen, in welche Netzwerke sie gesendet werden, ist es an der Zeit, diese Datenanforderung physisch über das Netzwerk zu senden; dafür ist die Verbindungsschicht zuständig.

Verbindungsschicht

Die HTTP-Anfrage wurde in Segmente aufgeteilt, für die Weiterleitung über das Internet adressiert und nun müssen die Daten nur noch über die Leitung gesendet werden. Die Verbindungsschicht des TCP/IP-Stapels besteht aus zwei Teilschichten: der Media Access Control (MAC) Teilschicht und der Logical Link Control (LLC) Teilschicht. Zusammen bilden sie die OSI-Schichten 1 und 2, Data Link und Physical. Die Verbindungsschicht ist für die Verbindung zum lokalen Netzwerk zuständig. Die erste Unterschicht, MAC, ist für den Zugriff auf das physikalische Medium zuständig. Die LLC-Schicht hat das Privileg, die Flusskontrolle und Multiplexing-Protokolle über die MAC-Schicht zu verwalten, um zu senden und zu demultiplexen, wenn sie empfangen werden, wie in Abbildung 1-19 dargestellt. Der IEEE-Standard 802.3, Ethernet, definiert die Protokolle für das Senden und Empfangen von Rahmen, um IP-Pakete zu kapseln. IEEE 802 ist der übergreifende Standard für LLC (802.2), Wireless (802.11) und Ethernet/MAC (802.3).

Wie die anderen PDUs hat auch Ethernet einen Kopf- und einen Fußteil, wie in Abbildung 1-20 dargestellt.

Schauen wir uns diese im Detail an:

Preamble (8 Bytes): Eine abwechselnde Folge von Einsen und Nullen zeigt dem empfangenden Host an, dass ein Frame eingeht.
Destination MAC Address (6 Bytes): MAC-Zieladresse; der Empfänger des Ethernet-Rahmens.
Source MAC Address (6 Bytes): MAC-Quelladresse; die Quelle des Ethernet-Frames.
VLAN tag (4 Bytes): Optionales 802.1Q-Tag zur Unterscheidung des Datenverkehrs in den Netzwerksegmenten.
Ether-type (2 Bytes): Gibt an, welches Protokoll in der Nutzlast des Rahmens eingekapselt ist.
Payload (variable Länge): Das eingekapselte IP-Paket.
Frame Check Sequence (FCS) oder Cycle Redundancy Check (CRC) (4 Bytes): Die Frame Check Sequence (FCS) ist eine vier Oktette umfassende zyklische Redundanzprüfung (CRC), die es ermöglicht, beschädigte Daten innerhalb des gesamten Frames zu erkennen, wie sie auf der Empfängerseite empfangen werden. Die CRC ist Teil der Fußzeile des Ethernet-Rahmens.

Abbildung 1-21 zeigt, dass MAC-Adressen der Netzwerkschnittstellen-Hardware zum Zeitpunkt der Herstellung zugewiesen werden. MAC-Adressen bestehen aus zwei Teilen: dem Organization Unit Identifier (OUI) und den NIC-spezifischen Teilen.

Der Rahmen zeigt dem Empfänger der Netzwerkschicht Pakettyp an. In Tabelle 1-7 sind die gängigen Protokolle aufgeführt. In Kubernetes sind wir hauptsächlich an IPv4- und ARP-Paketen interessiert. IPv6 wurde erst kürzlich mit der Version 1.19 in Kubernetes eingeführt.

Tabelle 1-7. Übliche EtherType-Protokolle
EtherType	Protokoll
0x0800	Internetprotokoll Version 4 (IPv4)
0x0806	Adressauflösungsprotokoll (ARP)
0x8035	Reverse Address Resolution Protocol (RARP)
0x86DD	Internetprotokoll Version 6 (IPv6)
0x88E5	MAC-Sicherheit (IEEE 802.1AE)
0x9100	VLAN-getaggter (IEEE 802.1Q) Frame mit doppeltem Tagging

Wenn ein IP-Paket sein Zielnetzwerk erreicht, wird die IP-Adresse des Ziels mit dem Address Resolution Protocol für IPv4 (Neighbor Discovery Protocol bei IPv6) in die MAC-Adresse des Zielhosts aufgelöst. Das Address Resolution Protocol muss die Adressübersetzung von Internetadressen in Adressen der Verbindungsschicht in Ethernet-Netzwerken verwalten. Die ARP-Tabelle dient der schnellen Suche nach den bekannten Hosts, damit nicht für jeden Frame, den der Host aussenden will, eine ARP-Anfrage gesendet werden muss. Beispiel 1-8 zeigt die Ausgabe einer lokalen ARP-Tabelle. Alle Geräte im Netzwerk führen zu diesem Zweck einen Cache mit ARP-Adressen.

Beispiel 1-8. ARP-Tabelle

○ → arp -a
? (192.168.0.1) at bc:a5:11:f1:5d:be on en0 ifscope [ethernet]
? (192.168.0.17) at 38:f9:d3:bc:8a:51 on en0 ifscope permanent [ethernet]
? (192.168.0.255) at ff:ff:ff:ff:ff:ff on en0 ifscope [ethernet]
? (224.0.0.251) at 1:0:5e:0:0:fb on en0 ifscope permanent [ethernet]
? (239.255.255.250) at 1:0:5e:7f:ff:fa on en0 ifscope permanent [ethernet]

Abbildung 1-22 zeigt den Austausch zwischen den Hosts im lokalen Netzwerk. Der Browser stellt eine HTTP-Anfrage für eine Website, die auf dem Zielserver gehostet wird. Über DNS stellt er fest, dass der Server die IP-Adresse 10.0.0.1 hat. Um die HTTP-Anfrage weiter zu senden, benötigt er auch die MAC-Adresse des Servers. Zuerst konsultiert der anfragende Computer eine zwischengespeicherte ARP-Tabelle, um auf 10.0.0.1 nach vorhandenen Einträgen der MAC-Adresse des Servers zu suchen. Wird die MAC-Adresse gefunden, sendet er einen Ethernet-Frame mit der Zieladresse der MAC-Adresse des Servers und dem IP-Paket, das an 10.0.0.1 gerichtet ist, auf die Verbindung. Wenn der Cache keinen Treffer für 10.0.0.2 ergeben hat, muss der anfragende Computer eine Broadcast-ARP-Anfrage mit der Ziel-MAC-Adresse FF:FF:FF:FF:FF:FF senden, die von allen Hosts im lokalen Netzwerk akzeptiert wird und eine Antwort für 10.0.0.1 anfordert. Der Server antwortet mit einer ARP-Antwortnachricht, die seine MAC- und IP-Adresse enthält. Bei der Beantwortung der Anfrage fügt der Server möglicherweise einen Eintrag für die MAC-Adresse des anfragenden Computers in seine ARP-Tabelle ein, um sie später zu verwenden. Der anfragende Computer empfängt und speichert die Antwortinformationen in seiner ARP-Tabelle und kann nun die HTTP-Pakete senden.

Dies bringt auch ein entscheidendes Konzept in den lokalen Netzwerken zur Sprache, die Broadcast-Domänen. Alle Pakete in der Broadcast-Domäne empfangen alle ARP-Nachrichten von Hosts. Außerdem werden alle Rahmen an alle Knoten in der Broadcast-Domäne gesendet, und der Host vergleicht die Ziel-MAC-Adresse mit seiner eigenen. Frames, die nicht für ihn bestimmt sind, verwirft er. Wenn die Hosts im Netzwerk wachsen, nimmt auch der Broadcast-Verkehr zu.

Wir können tcpdump verwenden, um alle ARP-Anfragen im lokalen Netzwerk zu sehen, wie inBeispiel 1-9. Das Paket-Capture zeigt die ARP-Pakete, den verwendeten Ethernet-Typ, Ethernet (len 6), und das übergeordnete Protokoll, IPv4. Außerdem wird angegeben, wer die MAC-Adresse der IP-Adresse Request who-has 192.168.0.1 tell 192.168.0.12 anfordert.

Beispiel 1-9. ARP `tcpdump`

○ → sudo tcpdump -i en0 arp -vvv
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 262144 bytes
17:26:25.906401 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:27.954867 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:29.797714 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:31.845838 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:33.897299 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:35.942221 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:37.785585 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:39.628958 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.13, length 28
17:26:39.833697 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:41.881322 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:43.929320 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:45.977691 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
17:26:47.820597 ARP, Ethernet (len 6), IPv4 (len 4),
Request who-has 192.168.0.1 tell 192.168.0.12, length 46
^C
13 packets captured
233 packets received by filter
0 packets dropped by kernel

Um das Layer-2-Netzwerk weiter zu segmentieren ( ), können Netzwerktechniker/innen Virtual Local Area Network (VLAN)-Tagging verwenden. Im Header des Ethernet-Rahmens befindet sich ein optionales VLAN-Tag, das den Verkehr im LAN unterscheidet. Es ist sinnvoll, VLANs zu verwenden, um LANs aufzuteilen und Netzwerke auf demselben Switch oder auf verschiedenen Switches auf dem Netzwerkcampus zu verwalten. Router zwischen VLANs filtern den Broadcast-Verkehr, sorgen für Netzwerksicherheit und lindern Netzwerküberlastungen. Für diese Zwecke sind sie für den Netzwerkadministrator nützlich , aber Kubernetes-Netzwerkadministratoren können die erweiterte Version der VLAN-Technologie nutzen, die als virtuelles erweiterbares LAN (VXLAN) bekannt ist.

Abbildung 1-23 zeigt, wie ein VXLAN eine Erweiterung eines VLANs ist, die es Netzwerktechnikern ermöglicht, Layer-2-Frames in Layer-4-UDP-Pakete zu kapseln. Ein VXLAN erhöht die Skalierbarkeit von auf bis zu 16 Millionen logische Netzwerke und ermöglicht eine Layer-2-Adjazenz über IP-Netzwerke hinweg. Diese Technologie wird in Kubernetes-Netzwerken verwendet, um Overlay-Netzwerke zu erstellen, über die du in späteren Kapiteln mehr erfahren wirst.

Ethernet legt auch die Spezifikationen für das Medium fest, über das die Frames übertragen werden, z. B. Twisted Pair, Koaxialkabel, Glasfaser, drahtlos oder andere Übertragungsmedien, die erst noch erfunden werden müssen, wie z. B. das Gammastrahlennetzwerk, das den Philotic Parallax Instantaneous Communicator betreibt.² Ethernet definiert sogar die Kodierungs- und Signalisierungsprotokolle, die auf der Leitung verwendet werden; dies ist jedoch nicht Gegenstand unserer Vorschläge.

An der Verbindungsschicht sind aus Sicht des Netzwerks mehrere andere Protokolle beteiligt. Wie bei den zuvor besprochenen Schichten haben wir auch bei der Link-Schicht nur die Oberfläche berührt. Wir haben uns in diesem Buch auf die Details beschränkt, die für ein grundlegendes Verständnis des Link-Layers für das Netzwerkmodell von Kubernetes notwendig sind.

Unser Webserver auf dem Prüfstand

Unsere Reise durch alle Schichten von TCP/IP ist abgeschlossen. Abbildung 1-24 zeigt alle Kopf- und Fußzeilen, die jede Schicht des TCP/IP-Modells erzeugt, um Daten über das Internet zu senden.

Schauen wir uns die Reise noch einmal an und erinnern uns daran, was vor sich geht, nachdem wir nun jede Schicht im Detail verstanden haben.Beispiel 1-10 zeigt noch einmal unseren Webserver und Beispiel 1-11 zeigt die cURL-Anfrage für ihn von weiter oben im Kapitel.

Beispiel 1-10. Minimaler Webserver in Go

package main

import (
	"fmt"
	"net/http"
)

func hello(w http.ResponseWriter, _ *http.Request) {
	fmt.Fprintf(w, "Hello")
}

func main() {
	http.HandleFunc("/", hello)
	http.ListenAndServe("0.0.0.0:8080", nil)
}

Beispiel 1-11. Kundenanfrage

○ → curl localhost:8080 -vvv
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8080
> GET / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Date: Sat, 25 Jul 2020 14:57:46 GMT
< Content-Length: 5
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host localhost left intact
Hello* Closing connection 0

Wir beginnen mit dem Webserver , der in Beispiel 1-10 auf eine Verbindung wartet. cURL fordert den HTTP-Server unter 0.0.0.0 auf Port 8080 an. cURL ermittelt die IP-Adresse und Portnummer aus der URL und baut eine TCP-Verbindung zum Server auf. Sobald die Verbindung über einen TCP-Handshake hergestellt ist, sendet cURL die HTTP-Anfrage. Wenn der Webserver startet, wird auf dem HTTP-Server ein -Socket mit der Nummer 8080 erstellt, die dem TCP-Port 8080 entspricht; dasselbe geschieht auf der cURL-Client-Seite mit einer zufälligen Portnummer. Anschließend werden diese Informationen an die Netzwerkschicht gesendet, wo die IP-Adressen von Quelle und Ziel an den IP-Header des Pakets angehängt werden. Auf der Datenverbindungsschicht des Clients wird die MAC-Quelladresse der Netzwerkkarte dem Ethernet-Rahmen hinzugefügt. Wenn die Ziel-MAC-Adresse unbekannt ist, wird eine ARP-Anfrage gestellt, um sie zu finden. Anschließend wird die Netzwerkkarte verwendet, um die Ethernet-Frames an den Webserver zu übertragen.

Wenn der Webserver die Anfrage erhält, erstellt er Datenpakete, die die HTTP-Antwort enthalten. Die Pakete werden an den cURL-Prozess zurückgeschickt, indem sie über die IP-Adresse des Anforderungspakets durch das Internet geleitet werden. Sobald das Paket vom cURL-Prozess empfangen wurde, wird es vom Gerät an die Treiber gesendet. Auf der Datenverbindungsschicht wird die MAC-Adresse entfernt. Auf der Netzwerkprotokollschicht wird die IP-Adresse überprüft und dann aus dem Paket entfernt. Wenn eine Anwendung Zugriff auf die Client-IP benötigt, muss sie deshalb auf der Anwendungsschicht gespeichert werden; das beste Beispiel hierfür sind HTTP-Anfragen und der X-Forwarded-For-Header. Nun wird der Socket aus den TCP-Daten ermittelt und entfernt. Das Paket wird dann an die Client-Anwendung weitergeleitet, die diesen Socket erstellt. Der Client liest es und verarbeitet die Antwortdaten. In diesem Fall war die Socket-ID zufällig und entspricht dem cURL-Prozess. Alle Pakete werden an cURL gesendet und zu einer HTTP-Antwort zusammengesetzt. Hätten wir die Ausgabeoption -Overwendet, wäre sie in einer Datei gespeichert worden; andernfalls gibt cURL die Antwort über den Standardausgang des Terminals aus.

Puh, das ist ein ganz schöner Brocken: 50 Seiten und 50 Jahre Netzwerkwissen, zusammengefasst in zwei Absätzen! Die Grundlagen des Netzwerks, die wir besprochen haben sind nur der Anfang, aber sie sind notwendig, wenn du Kubernetes-Cluster und Netzwerke in großem Maßstab betreiben willst.

Fazit

Die HTTP-Transaktionen, die in diesem Kapitel beschrieben werden, finden jede Millisekunde statt, weltweit, den ganzen Tag über das Internet und das Netzwerk des Rechenzentrums. Die APIs der Kubernetes-Netzwerke helfen Entwicklern, diese Größenordnung in einfaches YAML zu abstrahieren. Das Verständnis der Größenordnung des Problems ist der erste Schritt, um die Verwaltung eines Kubernetes-Netzwerks zu meistern. Wenn du unser einfaches Beispiel des Golang-Webservers nimmst und die ersten Prinzipien des Netzwerks lernst, kannst du damit beginnen, die Pakete, die in und aus deinen Clustern fließen, zu verwalten.

Bis jetzt haben wir folgende Themen behandelt:

Geschichte der Vernetzung
OSI-Modell
TCP/IP

In diesem Kapitel haben wir viele Dinge im Zusammenhang mit Netzwerken besprochen, aber nur die, die für die Nutzung der Kubernetes-Abstraktionen notwendig sind. Es gibt mehrere O'Reilly-Bücher über TCP/IP; TCP/IP Network Administration von Craig Hunt (O'Reilly) ist eine hervorragende Lektüre zu allen Aspekten von TCP.

Wir haben besprochen, wie sich Netzwerke entwickelt haben, sind das OSI-Modell durchgegangen, haben es auf den TCP/IP-Stack übertragen und mit diesem Stack eine beispielhafte HTTP-Anfrage ausgeführt. Im nächsten Kapitel werden wir uns ansehen, wie dies für den Client und den Server mit Linux-Netzwerken umgesetzt wird.

¹ "Autonome System (AS)-Nummern". IANA.org. 2018-12-07. Abgerufen am 2018-12-31.

² Im Film Ender's Game benutzen sie das Ansible-Netzwerk, um sofort in der ganzen Galaxie zu kommunizieren. Philotic Parallax Instantaneous Communicator ist der offizielle Name des Ansible-Netzwerks.

Get Vernetzung und Kubernetes now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Kapitel 1. Einführung in die Vernetzung

Geschichte der Vernetzung

Abbildung 1-1. Barrett Lyon, "Mapping the Internet", 2003

Hinweis

OSI-Modell

Abbildung 1-2. OSI-Modell-Schichten

Hinweis

TCP/IP

Abbildung 1-3. OSI-Modell im Vergleich zu TCP/IP

Bewerbung

HTTP

Hinweis

Beispiel 1-1. Minimaler Webserver in Go

Hinweis

Beispiel 1-2. Kundenanfrage

Transport

TCP

Hinweis

Abbildung 1-4. TCP-Segmentkopf

Abbildung 1-5. tcp/ip-Datenfluss

TCP-Handshake

Abbildung 1-6. TCP Drei-Wege-Handshake

Abbildung 1-7. TCP-Zustandsübergangsdiagramm

Beispiel 1-3. Zustände der TCP-Verbindung

tcpdump

Abbildung 1-8. tcpdump packet capture

Hinweis

Beispiel 1-4. tcpdump

TLS

Abbildung 1-9. TLS-Handshake

UDP

Abbildung 1-10. UDP-Kopfzeile

Netzwerk

Internetprotokoll

Abbildung 1-11. IPv4-Header-Format

Hinweis

Hinweis

Abbildung 1-12. IPv4-Adresse

Beispiel 1-5. IP-Adresse

Hinweis

Abbildung 1-13. IP-Klasse

Abbildung 1-14. CIDR-Beispiel

Hinweis

Abbildung 1-15. IPv6-Adresse

Das Netzwerk erkunden

Abbildung 1-16. BGP-Routing-Beispiel

Abbildung 1-17. Lokale Routing-Tabelle

Hinweis

ICMP

Beispiel 1-6. ICMP-Echo-Anfrage

Beispiel 1-7. ICMP-Echoanforderung fehlgeschlagen

Abbildung 1-18. ICMP-Header

Hinweis

Verbindungsschicht

Abbildung 1-19. Beispiel für das Demultiplexen von Ethernet

Abbildung 1-20. Ethernet Kopf- und Fußzeile

Abbildung 1-21. MAC-Adresse

Beispiel 1-8. ARP-Tabelle

Abbildung 1-22. ARP-Anfrage

Beispiel 1-9. ARP tcpdump

Abbildung 1-23. VXLAN-Paket

Unser Webserver auf dem Prüfstand

Abbildung 1-24. TCP/IP PDU Vollansicht

Beispiel 1-10. Minimaler Webserver in Go

Beispiel 1-11. Kundenanfrage

Fazit

Don’t leave empty-handed

It’s yours, free.

Check it out now on O’Reilly

Abbildung 1-8. `tcpdump` packet capture

Beispiel 1-4. `tcpdump`

Beispiel 1-9. ARP `tcpdump`