heim - Einrichten des Routers
Mit welchem ​​Protokoll funktioniert udp? Wie unterscheidet sich TCP vereinfacht von UDP?

Eine Reihe von Netzwerkprotokollen für das Internet. Mit UDP können Computeranwendungen Nachrichten (in diesem Fall Datagramme genannt) über ein IP-Netzwerk an andere Hosts senden, ohne dass eine vorherige Kommunikation zum Aufbau spezieller Übertragungskanäle oder Datenpfade erforderlich ist. Das Protokoll wurde 1980 von David P. Reed entwickelt und in RFC 768 offiziell definiert.

UDP verwendet ein einfaches Übertragungsmodell ohne implizite Handshakes, um die Zuverlässigkeit, Reihenfolge oder Integrität der Daten sicherzustellen. Daher stellt UDP einen unzuverlässigen Dienst dar und Datagramme können in der falschen Reihenfolge ankommen, dupliziert werden oder spurlos verschwinden. UDP impliziert, dass eine Fehlerprüfung und -korrektur entweder nicht erforderlich ist oder von der Anwendung durchgeführt werden muss. Zeitkritische Anwendungen verwenden häufig UDP, da es besser ist, Pakete zu verwerfen, als auf verzögerte Pakete zu warten, was auf Echtzeitsystemen möglicherweise nicht möglich ist. Wenn es notwendig ist, Fehler auf der Netzwerkschnittstellenebene zu korrigieren, kann die Anwendung das für diesen Zweck konzipierte TCP oder SCTP verwenden.

Die Natur von UDP als zustandsloses Protokoll ist auch für Server nützlich, die auf kleine Anfragen einer großen Anzahl von Clients reagieren, z. B. DNS- und Streaming-Media-Anwendungen wie IPTV, Voice over IP, IP-Tunnelprotokolle und viele Online-Spiele.

Enzyklopädisches YouTube

    1 / 5

    ✪ Ports und Umleitung\Öffnung von Ports. Anweisungen und Erklärungen immer zur Hand!

  • Untertitel

Service-Ports

UDP bietet keine Garantien für die Nachrichtenübermittlung an das höhere Protokoll und speichert nicht den Status gesendeter Nachrichten. Aus diesem Grund wird UDP manchmal als Unreliable Datagram Protocol bezeichnet.

Prüfsumme

Das Prüfsummenfeld wird verwendet, um den Header und die Daten auf Fehler zu überprüfen. Wird der Betrag nicht vom Sender generiert, wird das Feld mit Nullen gefüllt. Das Feld ist für IPv4 optional.

Prüfsummenberechnung

Die Methode zur Berechnung der Prüfsumme ist in RFC 1071 definiert.

Wenn vor der Berechnung der Prüfsumme die Länge der UDP-Nachricht in Bytes ungerade ist, wird die UDP-Nachricht am Ende mit einem Nullbyte aufgefüllt (der Pseudo-Header und das Auffüll-Nullbyte werden nicht mit der Nachricht gesendet, sondern nur verwendet). bei der Berechnung der Prüfsumme). Bei der Prüfsummenberechnung wird davon ausgegangen, dass das Prüfsummenfeld im UDP-Header Null ist.

Zur Berechnung der Prüfsumme werden Pseudo-Header und UDP-Nachricht in Doppelbyte-Wörter aufgeteilt. Dann wird die Summe aller Wörter in der Arithmetik des umgekehrten Codes berechnet (d. h. ein Code, bei dem aus einer positiven Zahl eine negative Zahl durch Invertieren aller Ziffern der Zahl erhalten wird und es zwei Nullen gibt: 0x0000 (bezeichnet mit +). 0) und 0xffff (bezeichnet mit −0)). Das Ergebnis wird in das entsprechende Feld im UDP-Header geschrieben.

Der Prüfsummenwert gleich 0x0000 (+0 im umgekehrten Code) ist reserviert und bedeutet, dass die Prüfsumme für die Nachricht nicht berechnet wurde. Wenn die Prüfsumme berechnet wurde und sich als gleich 0x0000 herausstellte, wird der Wert 0xffff (-0 im umgekehrten Code) in das Prüfsummenfeld eingetragen.

Wenn eine Nachricht empfangen wird, berechnet der Empfänger die Prüfsumme erneut (unter Berücksichtigung des Prüfsummenfelds). Wenn das Ergebnis −0 (d. h. 0xffff) ist, gilt die Prüfsumme als konvergiert. Konvergiert die Summe nicht (die Daten wurden bei der Übertragung beschädigt oder die Prüfsumme wurde auf der sendenden Seite falsch berechnet), liegt die Entscheidung über das weitere Vorgehen bei der empfangenden Seite. In der Regel verfügen die meisten modernen Geräte, die mit UDP/IP-Paketen arbeiten, über Einstellungen, die es ihnen ermöglichen, solche Pakete unabhängig von der Unrichtigkeit der Prüfsumme entweder zu ignorieren oder zur weiteren Verarbeitung zu überspringen.

Beispiel für die Berechnung der Prüfsumme

Berechnen wir zum Beispiel die Prüfsumme mehrerer 16-Bit-Wörter: 0x398a, 0xf802, 0x14b2, 0xc281.

Dazu können Sie Zahlen zunächst paarweise addieren und sie als vorzeichenlose 16-Bit-Zahlen behandeln und anschließend durch Addition von Eins zum Ergebnis auf den Zweierkomplementcode reduzieren, wenn bei der Addition eine Übertragung auf die höchste (17.) Ziffer erfolgte (Das heißt, de facto konvertieren wir mit dieser Operation eine negative Zahl von ihrem Komplement in ihren Kehrwert). Oder, was äquivalent ist, wir können davon ausgehen, dass der Übertrag zur niederwertigen Ziffer der Zahl hinzugefügt wird.

0x398a + 0xf802 = 0x1318c → 0x318d (Übertragung nach hoher Ordnung) 0x318d + 0x14b2 = 0x0463f → 0x463f (positive Zahl) 0x463f + 0xc281 = 0x108c0 → 0x08c1

Am Ende werden alle Bits der resultierenden Zahl invertiert

0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73e oder, andernfalls - 0xffff − 0x08c1 = 0xf73e . Dies ist die gewünschte Prüfsumme.

Bei der Berechnung der Prüfsumme wird wiederum ein Pseudo-Header verwendet, der einen echten IPv6-Header simuliert:

UDP ist ein einfaches Protokoll und hat einen bestimmten Umfang. Dies sind in erster Linie Client-Server-Interaktionen und Multimedia. Die meisten Internetanwendungen erfordern jedoch eine zuverlässige und konsistente Übertragung. UDP erfüllt diese Anforderungen nicht, daher ist ein anderes Protokoll erforderlich. Dieses Protokoll heißt TCP und ist das Arbeitspferd des Internets.

TCP-Grundlagen

Das Transmission Control Protocol (TCP) wurde speziell entwickelt, um einen zuverlässigen End-to-End-Byte-Stream über ein unzuverlässiges Internet-Netzwerk bereitzustellen. Ein verbundenes Netzwerk unterscheidet sich von einem eigenständigen Netzwerk dadurch, dass seine verschiedenen Abschnitte sehr unterschiedliche Topologien, Bandbreiten, Latenzwerte, Paketgrößen und andere Parameter aufweisen können. Bei der Entwicklung von TCP lag der Schwerpunkt auf der Fähigkeit des Protokolls, sich an die Eigenschaften des Internetnetzwerks anzupassen und gegenüber verschiedenen Problemen widerstandsfähig zu sein.

Das TCP-Protokoll ist in RFC 793 beschrieben. Im Laufe der Zeit wurden verschiedene Fehler und Ungenauigkeiten entdeckt und in einigen Punkten wurden die Anforderungen geändert. Eine detaillierte Beschreibung dieser Klarstellungen und Korrekturen finden Sie in RFC 1122. Protokollerweiterungen finden Sie in RFC 1323.

Jede Maschine, die das TCP-Protokoll unterstützt, verfügt über eine TCP-Transporteinheit, bei der es sich entweder um eine Bibliotheksprozedur, einen Benutzerprozess oder einen Teil des Systemkernels handelt. In beiden Fällen verwaltet die Transporteinheit die TCP-Flüsse und die Schnittstelle zur IP-Schicht. Die TCP-Entität empfängt Benutzerdatenströme von lokalen Prozessen und zerlegt sie in Teile, die nicht größer als 64 KB sind (in der Praxis beträgt diese Zahl normalerweise 460 Datenbytes, sodass sie in einem Ethernet-Frame mit IP- und TCP-Headern platziert werden können). und sendet sie als separate IP-Datagramme an. Wenn IP-Datagramme mit TCP-Daten am Computer ankommen, werden sie an die TCP-Entität weitergeleitet, die den ursprünglichen Bytestrom rekonstruiert. Der Einfachheit halber verwenden wir manchmal „TCP“, um auf die TCP-Transporteinheit (eine Software) oder das TCP-Protokoll (ein Regelwerk) zu verweisen. Aus dem Kontext wird deutlich, was gemeint ist. Beispielsweise ist im Ausdruck „Der Benutzer überträgt TCP-Daten“ natürlich die Transportentität TCP impliziert.

Die IP-Schicht garantiert nicht die korrekte Zustellung von Datagrammen, daher muss TCP abgelaufene Zeitüberschreitungen überwachen und Pakete bei Bedarf erneut übertragen. Manchmal kommen Datagramme in der falschen Reihenfolge an. TCP ist auch für die Wiederherstellung von Nachrichten aus solchen Datagrammen verantwortlich. Daher ist TCP so konzipiert, dass es die Zuverlässigkeit bietet, die viele Benutzer wünschen, die IP jedoch nicht bietet.

TCP-Dienstmodell

Der TCP-Dienst basiert auf sogenannten Sockets (Sockets oder Endpunkten), die sowohl vom Sender als auch vom Empfänger erstellt werden. Sie wurden im Abschnitt Berkeley Sockets besprochen. Jeder Socket verfügt über eine Nummer (Adresse), die aus der IP-Adresse des Hosts und einer lokalen 16-Bit-Nummer des Hosts besteht, die als Port bezeichnet wird. Ein Port wird in TCP als TSAP-Adresse bezeichnet. Um auf den TCP-Dienst zuzugreifen, muss explizit eine Verbindung zwischen einem Socket auf dem sendenden Computer und einem Socket auf dem Empfängercomputer hergestellt werden.

Eine Buchse kann für mehrere Verbindungen gleichzeitig verwendet werden. Mit anderen Worten: Zwei oder mehr Verbindungen können am selben Socket enden. Verbindungen werden durch die Socket-IDs an beiden Enden unterschieden – (Socket1, Socket2). Virtuelle Kanalnummern oder andere Kennungen werden nicht verwendet.

Portnummern unter 1024, sogenannte beliebte Ports, werden von Standarddiensten reserviert. Beispielsweise kann jeder Prozess, der eine Verbindung zu einem Host herstellen möchte, um eine Datei per FTP zu übertragen, Port 21 des Zielhosts und damit dessen FTP-Daemon kontaktieren. Eine Liste beliebter Häfen finden Sie auf der Website www.iana.org.

Wir könnten natürlich den FTP-Daemon beim Booten an Port 21 binden, dann den Telnet-Daemon an Port 23 usw. binden. Wenn wir das täten, würden wir jedoch nur Speicher mit Informationen über die Daemons verschwenden, die tatsächlich funktionieren Sie sind die meiste Zeit untätig. Stattdessen ist es üblich, einen einzelnen Daemon namens inetd unter UNIX zu verwenden, der mit mehreren Ports kommuniziert und auf die erste eingehende Verbindung wartet. In diesem Fall erstellt inetd einen neuen Prozess und ruft den entsprechenden Daemon auf, um die Anfrage zu bearbeiten. Somit ist nur inetd ständig aktiv, die anderen werden nur dann aufgerufen, wenn Arbeit für sie vorhanden ist. Inetd verfügt über eine spezielle Konfigurationsdatei, aus der es Portzuweisungen erfahren kann. Dies bedeutet, dass der Systemadministrator das System so konfigurieren kann, dass persistente Daemons den am stärksten ausgelasteten Ports (z. B. 80) und inetd den übrigen Ports zugeordnet werden.

Einige reservierte Ports

Protokoll

Verwendung

21

FTP

Dateien übertragen

23

Telnet

Fernanmeldung

25

SMTP

E-Mail

69

TFTP

Das einfachste Dateiübertragungsprotokoll

79

Finger

Suche nach Benutzerinformationen

80

HTTP

Weltweites Netz

110

POP-3

Remote-E-Mail-Zugriff

119

NNTP

Newsgroups

Alle TCP-Verbindungen sind Vollduplex und Punkt-zu-Punkt. Vollduplex bedeutet, dass der Datenverkehr gleichzeitig in entgegengesetzte Richtungen fließen kann. Eine Punkt-zu-Punkt-Verbindung bedeutet, dass sie zwei Endpunkte hat. Broadcasting und Multicasting werden von TCP nicht unterstützt.

Eine TCP-Verbindung ist ein Bytestrom, kein Nachrichtenstrom. Grenzen zwischen Nachrichten bleiben nicht erhalten. Wenn ein sendender Prozess beispielsweise vier 512-Byte-Datenblöcke in einen TCP-Stream schreibt, könnten diese Daten als vier 512-Byte-Blöcke, zwei 1024-Byte-Blöcke, ein 2048-Byte-Blöcke oder so an den empfangenden Prozess übermittelt werden anders. Für den Empfänger besteht keine Möglichkeit festzustellen, wie die Daten geschrieben wurden.

Auch Dateien auf einem UNIX-System verfügen über diese Eigenschaft. Das Programm, das die Schiene liest, kann nicht feststellen, wie diese Datei geschrieben wurde: Block für Block, Byte für Byte oder vollständig auf einmal. Wie bei UNIX-Systemdateien haben TCP-Programme keine Ahnung von der Bedeutung von Bytes und kümmern sich auch nicht darum. Für sie ist ein Byte nur ein Byte.

Sobald TCP Daten von einer Anwendung empfängt, kann es diese ganz nach Wunsch auf einmal senden oder zwischenspeichern, um einen größeren Datenblock auf einmal zu senden. Manchmal benötigt eine Anwendung jedoch eine sofortige Übermittlung der Daten. Nehmen wir zum Beispiel an, dass sich ein Benutzer bei einem Remote-Computer anmeldet. Nachdem er einen Befehl eingegeben und die Eingabetaste gedrückt hat, ist es wichtig, dass die von ihm eingegebene Zeile sofort an den Remote-Rechner übermittelt wird und nicht zwischengespeichert wird, bis die nächste Zeile eingegeben wird. Um eine verzögerungsfreie Datenübertragung zu erzwingen, kann eine Anwendung das PUSH-Flag setzen.

Einige ältere Anwendungen verwendeten das PUSH-Flag als Nachrichtentrennzeichen. Obwohl dieser Trick manchmal funktioniert, übergeben nicht alle TCP-Implementierungen das PUSH-Flag an die empfangende Anwendung. Wenn die TCP-Entität außerdem mehrere weitere solcher Pakete empfängt, bevor das erste PUSH-Paket auf der Leitung gesendet wird (d. h. die Ausgangsleitung ist belegt), hat die TCP-Entität das Recht, alle diese Daten als ein einziges Datagramm zu senden. Teilen Sie sie nicht in separate Portionen auf.

Die letzte erwähnenswerte Funktion des TCP-Dienstes sind dringende Daten. Wenn ein Benutzer, der interaktiv mit einem Programm interagiert, Entf oder Strg-C drückt, um einen laufenden Remote-Prozess abzubrechen, fügt die sendende Anwendung Steuerinformationen in den Ausgabedatenstrom ein und übergibt sie zusammen mit dem DRINGEND-Flag an den TCP-Dienst. Dieses Flag bewirkt, dass die TCP-Entität das Sammeln von Daten stoppt und alle vorhandenen Daten sofort für die Verbindung zum Netzwerk freigibt.

Wenn dringende Daten am Ziel ankommen, wird die empfangende Anwendung unterbrochen (das heißt, in der UNIX-Terminologie „signalisiert“), woraufhin sie die Daten aus dem Eingabestream lesen und unter ihnen nach dringenden Daten suchen kann. Das Ende dringender Daten wird markiert, damit die Anwendung erkennen kann, wo sie enden. Der Beginn dringender Daten ist nicht markiert. Die Anwendung sollte es selbst herausfinden. Diese Schaltung stellt einen groben Signalmechanismus bereit und überlässt alles andere der Anwendung.

TCP-Protokoll

In diesem Abschnitt wird das TCP-Protokoll allgemein erläutert. Im nächsten Abschnitt besprechen wir den Protokoll-Header Feld für Feld.

Eine Schlüsseleigenschaft von TCP, die die gesamte Protokollstruktur definiert, besteht darin, dass in einer TCP-Verbindung jedes Byte eine eigene 32-Bit-Sequenznummer hat. In den Anfangsjahren des Internets betrug die grundlegende Datenübertragungsgeschwindigkeit zwischen Routern über Mietleitungen 56 Kbit/s. Bei einem Host, der ständig Daten mit Höchstgeschwindigkeit ausgibt, würde es mehr als eine Woche dauern, bis sich der Kreis der Sequenznummern schließt. Bei den aktuellen Geschwindigkeiten können die Sequenznummern sehr schnell ausgehen, mehr dazu später. Für Bestätigungen und für den Sliding-Window-Mechanismus, der ebenfalls später erläutert wird, werden separate 32-Bit-Sequenznummern verwendet.

Die sendenden und empfangenden TCP-Entitäten tauschen Daten in Form von Segmenten aus. Ein Segment besteht aus einem festen 20-Byte-Header (plus einem optionalen Teil), dem Datenbytes folgen können. Die Größe der Segmente wird von der TCP-Software bestimmt. Es kann Daten, die als Ergebnis mehrerer Schreibvorgänge erhalten wurden, in einem Segment zusammenfassen oder umgekehrt das Ergebnis eines Schreibvorgangs auf mehrere Segmente verteilen. Die Größe der Segmente ist durch zwei Grenzen begrenzt. Zunächst muss jedes Segment, einschließlich des TCP-Headers, in das 65.515 Byte große Nutzlastfeld des IP-Pakets passen. Zweitens verfügt jedes Netzwerk über eine Maximum Transfer Unit (MTU) und jedes Segment muss in die MTU passen. In der Praxis beträgt die Größe der maximalen Übertragungseinheit typischerweise 1500 Byte (was der Größe des Ethernet-Nutzdatenfelds entspricht) und definiert somit die Obergrenze der Segmentgröße.

Das von TCP-Entitäten verwendete Hauptprotokoll ist das Sliding-Window-Protokoll. Beim Senden eines Segments startet der Sender einen Timer. Wenn das Segment am Ziel ankommt, sendet die empfangende TCP-Entität ein Segment (mit Daten, falls etwas zu senden ist, oder ohne Daten) mit Nummer zurück

Bestätigung gleich der Sequenznummer des nächsten erwarteten Segments. Wenn das Bestätigungs-Timeout abläuft, sendet der Absender das Segment erneut.

Obwohl dieses Protokoll einfach erscheint, gibt es einige Details, die genauer untersucht werden müssen. Segmente kommen möglicherweise in der falschen Reihenfolge an. So ist es beispielsweise möglich, dass die Bytes 3072 bis 4095 bereits eingetroffen sind, für sie jedoch keine Bestätigung gesendet werden kann, da die Bytes 2048 bis 3071 noch nicht empfangen wurden. Darüber hinaus können Segmente so lange im Netzwerk verbleiben, dass der Absender eine Zeitüberschreitung erleidet und sie erneut überträgt. Das erneut übertragene Segment kann unterschiedliche Fragmentbereiche umfassen. Daher ist eine sehr sorgfältige Verwaltung erforderlich, um die bereits empfangenen Bytenummern korrekt zu ermitteln. Da jedoch jedes Byte im Stream durch seinen Offset eindeutig identifiziert wird, ist diese Aufgabe machbar.

TCP muss in der Lage sein, mit diesen Problemen umzugehen und sie effizient zu lösen. Es wurde viel Aufwand in die Optimierung der Leistung von TCP-Streams gesteckt. Im nächsten Abschnitt werden wir mehrere Algorithmen besprechen, die in verschiedenen Implementierungen des TCP-Protokolls verwendet werden.

TCP-Segmentheader

Jedes Segment beginnt mit einem 20-Byte-Header mit festem Format. Es können weitere Felder folgen. Nach den zusätzlichen Feldern können bis zu 65.535 – 20 – 20 = 65.495 Bytes an Daten vorhanden sein, wobei die ersten 20 Bytes der IP-Header und die zweiten der TCP-Header sind. Segmente dürfen keine Daten enthalten. Solche Segmente werden häufig zur Übertragung von Bestätigungen und Steuernachrichten verwendet.

Schauen wir uns den TCP-Header Feld für Feld an. Die Felder Receiver Port und Source Port sind Kennungen der lokalen Verbindungsendpunkte. Die Portnummer bildet zusammen mit der Host-IP-Adresse eine eindeutige 48-Bit-Endpunktkennung. Ein Paar solcher Kennungen, bezogen auf Quelle und Ziel, identifiziert die Verbindung eindeutig.

Die Felder „Sequenznummer“ und „Bestätigungsnummer“ erfüllen ihre üblichen Funktionen. Beachten Sie, dass sich das Feld „Bestätigungsnummer“ auf das nächste erwartete Byte bezieht, nicht auf das letzte empfangene Byte. Beide sind 32-Bit, da jedes Datenbyte in einem TCP-Stream nummeriert ist.

Das Feld „TCP-Header-Länge“ enthält die Größe des TCP-Headers, ausgedrückt in 32-Bit-Wörtern. Diese Informationen sind erforderlich, da das Feld „Optionale Felder“ und damit der gesamte Header eine variable Länge haben kann. Im Wesentlichen gibt dieses Feld den Offset vom Anfang des Segments zum Datenfeld an, gemessen in 32-Bit-Wörtern. Dies entspricht der Titellänge.

Als nächstes kommt ein unbenutztes 6-Bit-Feld. Die Tatsache, dass dieses Gebiet ein Vierteljahrhundert überlebt hat, ist ein Beweis dafür, wie durchdacht das Design von TCP ist.

Darauf folgen sechs 1-Bit-Flags. Das URG-Bit wird auf 1 gesetzt, wenn das Feld „Urgent Data Pointer“ verwendet wird, das den Byte-Offset von der aktuellen Byte-Sequenznummer zum Speicherort der dringenden Daten enthält. Auf diese Weise implementiert TCP Interrupt-Nachrichten. Wie bereits erwähnt, stellt das TCP-Protokoll nur die Zustellung des Nutzsignals an den Empfänger sicher, ohne sich für die Ursache der Unterbrechung zu interessieren.

Wenn das ACK-Bit auf 1 gesetzt ist, enthält das Feld „Bestätigungsnummer“ aussagekräftige Daten. Andernfalls enthält dieses Segment keine Bestätigung und das Feld „Bestätigungsnummer“ wird einfach ignoriert.

Das PSH-Bit ist im Wesentlichen ein PUSH-Flag, das den Absender anweist, die Daten an die Anwendung zu senden, sobald diese das Paket empfängt, anstatt sie in einem Puffer zu speichern, bis er voll ist. (Der Empfänger kann für eine höhere Effizienz puffern.)

Das RST-Bit wird verwendet, um den Status einer Verbindung zurückzusetzen, die aufgrund eines Hostfehlers oder aus anderen Gründen blockiert ist. Es wird auch verwendet, um ein ungültiges Segment oder den Versuch, eine Verbindung herzustellen, abzulehnen. Wenn Sie ein Segment mit gesetztem RST-Bit empfangen, liegt ein Problem vor.

Das SYN-Bit wird zum Aufbau einer Verbindung verwendet. Eine Verbindungsanforderung hat das SYN-Bit = 1 und das ACK-Bit = 0, was bedeutet, dass das Bestätigungsfeld nicht verwendet wird. Die Antwort auf diese Anfrage enthält eine Bestätigung, daher sind die Werte dieser Bits: SYN= 1, ACK-1. Somit wird das SYN-Bit verwendet, um die Segmente CONNECTION REQUEST und CONNECTION ACCEPTED anzuzeigen, und das ACK-Bit wird verwendet um sie voneinander zu unterscheiden.

Das FIN-Bit wird zum Beenden der Verbindung verwendet. Es zeigt an, dass der Absender keine Daten mehr zu übertragen hat. Allerdings kann der Prozess auch nach dem Schließen der Verbindung weiterhin Daten empfangen. Segmente mit den FIN- und SYN-Bits haben Sequenznummern, um sicherzustellen, dass sie in der richtigen Reihenfolge ausgeführt werden.

Die Flusskontrolle im TCP-Protokoll erfolgt über ein Schiebefenster variabler Größe. Das Feld „Fenstergröße“ gibt an, wie viele Bytes nach dem Bestätigungsbyte gesendet werden können. Der Wert des Felds „Fenstergröße“ kann Null sein, was bedeutet, dass alle Bytes bis zur Bestätigungsnummer 1 empfangen wurden, der Empfänger jedoch derzeit Probleme hat und die restlichen Bytes noch nicht empfangen kann. Die Erlaubnis zur weiteren Übertragung kann erhalten werden, indem ein Segment mit demselben Feldwert für die Bestätigungsnummer und einem Feldwert für die Fenstergröße ungleich Null gesendet wird.

In einigen Protokollen sind Frame-Bestätigungen mit der Erlaubnis zur Fortsetzung der Übertragung verbunden. Diese Beziehung ist eine Folge der starr festgelegten Schiebefenstergröße in diesen Protokollen. In TCP sind Bestätigungen von Berechtigungen zur Datenübertragung getrennt. Im Wesentlichen könnte der Empfänger sagen: „Ich habe Bytes bis zu k-ro empfangen, möchte aber im Moment keine weiteren Daten empfangen.“ Diese Aufteilung (ausgedrückt als Schiebefenster variabler Größe) verleiht dem Protokoll zusätzliche Flexibilität. Auf diesen Aspekt gehen wir im Folgenden näher ein.

Das Prüfsummenfeld wird zur Erhöhung der Zuverlässigkeit verwendet. Es enthält eine Prüfsumme aus Header, Daten und Pseudo-Header. Bei der Durchführung von Berechnungen wird das Prüfsummenfeld auf Null gesetzt und das Datenfeld wird mit einem Nullbyte aufgefüllt, wenn seine Länge eine ungerade Zahl ist. Der Prüfsummenalgorithmus addiert einfach alle 16-Bit-Wörter im Zweierkomplement und berechnet dann das gesamte Summenkomplement. Wenn der Empfänger daher das gesamte Segment einschließlich des Prüfsummenfelds überprüft, muss das Ergebnis 0 sein.

Der Pseudo-Header enthält die 32-Bit-Quell- und Ziel-IP-Adressen, die Protokollnummer für TCP (6) und die Byteanzahl für das TCP-Segment (einschließlich Header). Das Einfügen eines Pseudo-Headers in die TCP-Prüfsumme hilft dabei, falsch zugestellte Pakete zu erkennen, obwohl dadurch die Protokollhierarchie durchbrochen wird, da die darin enthaltenen IP-Adressen zur IP-Schicht und nicht zur TCP-Schicht gehören. UDP verwendet denselben Pseudo-Header für die Prüfsumme.

Das Feld „Optionale Felder“ bietet zusätzliche Funktionen, die nicht durch den Standardheader abgedeckt werden. Mithilfe eines dieser Felder kann jeder Host die maximale Nutzlastfeldgröße angeben, die er akzeptieren kann. Je größer die verwendeten Segmente sind, desto höher ist die Effizienz, da dadurch der Overhead von 20-Byte-Headern reduziert wird. Allerdings können nicht alle Hosts sehr große Segmente akzeptieren. Hosts können sich beim Verbindungsaufbau gegenseitig die maximale Nutzlastfeldgröße mitteilen. Standardmäßig beträgt diese Größe 536 Byte. Alle Hosts müssen TCP-Segmente mit einer Größe von 536 + 20 = 556 Byte akzeptieren. Jede Richtung kann ihre eigene maximale Nutzlastfeldgröße haben.

Für Leitungen mit hohen Übertragungsraten und/oder hoher Latenz ist ein 64-KB-Fenster zu klein. Somit kann für eine TZ-Leitung (44,736 Mbit/s) ein vollständiges Fenster in nur 12 ms auf die Leitung übertragen werden. Wenn die Umlaufzeit 50 ms beträgt (typisch für transkontinentale optische Kabel), verbringt der Absender drei Viertel der Zeit damit, auf eine Bestätigung zu warten. Bei der Kommunikation über Satellit wird die Situation noch schlimmer. Eine größere Fenstergröße würde die Effizienz verbessern, das 16-Bit-Feld „Fenstergröße“ lässt dies jedoch nicht zu. RFC 1323 schlug einen neuen Parameter „Window Scale“ vor, auf dessen Wert sich zwei Hosts beim Verbindungsaufbau einigen konnten. Mit dieser Zahl kann das Feld „Fenstergröße“ um bis zu 14 Bit nach links verschoben werden, sodass die Fenstergröße auf 230 Byte (1 GB) erweitert werden kann. Derzeit unterstützen die meisten TCP-Protokollimplementierungen diese Funktion.

Eine weitere Option, die in RFC 1106 vorgeschlagen wird und mittlerweile weit verbreitet ist, ist die Verwendung des selektiven Wiederholungsprotokolls anstelle von Backtracking. Wenn das Ziel ein schlechtes Segment gefolgt von einer großen Anzahl guter Segmente empfängt, kommt es bei einem normalen TCP-Protokoll irgendwann zu einer Zeitüberschreitung, und das wird auch der Fall sein Alle unbestätigten Segmente erneut übertragen, einschließlich derjenigen, die korrekt empfangen wurden. RFC 1106 schlug die Verwendung negativer Bestätigungen (NAKs) vor, um dem Empfänger die Anforderung eines einzelnen Segments oder mehrerer Segmente zu ermöglichen. Nach dem Empfang kann die empfangende Partei alle im Puffer gespeicherten Daten bestätigen und so die Menge der erneut übertragenen Daten reduzieren.

Bits 0 - 7 8 - 15 16 - 23 24 - 31
0 Quelladresse
32
64
96
128 Adresse des Empfängers
160
192
224
256 UDP-Länge
288 Nullen Nächster Titel
320 Quellport Zielhafen
352 Länge Prüfsumme
384+
Daten

Die Quelladresse ist dieselbe wie im IPv6-Header. Empfängeradresse – Endempfänger; Wenn das IPv6-Paket keinen Routing-Header enthält, ist dies die Zieladresse aus dem IPv6-Header. Andernfalls ist es auf dem Startknoten die Adresse des letzten Elements des Routing-Headers und auf dem empfangenden Knoten. die Zieladresse aus dem IPv6-Header. Der Next-Header-Wert entspricht dem Protokollwert – 17 für UDP. UDP-Länge – die Länge des UDP-Headers und der Daten.

Zuverlässigkeit und Lösungen für Überlastungsprobleme

Aufgrund der mangelnden Zuverlässigkeit müssen UDP-Anwendungen auf Verluste, Fehler und Duplikate vorbereitet sein. Einige von ihnen (z. B. TFTP) können optional elementare Zuverlässigkeitsmechanismen auf Anwendungsebene hinzufügen.

Doch in den meisten Fällen werden solche Mechanismen von UDP-Anwendungen nicht genutzt und beeinträchtigen diese sogar. Streaming-Medien, Echtzeit-Multiplayer-Spiele und VoIP sind Beispiele für Anwendungen, die häufig das UDP-Protokoll verwenden. Bei diesen speziellen Anwendungen stellt der Paketverlust normalerweise kein großes Problem dar. Wenn die Anwendung ein hohes Maß an Zuverlässigkeit erfordert, können Sie ein anderes Protokoll (TCP) verwenden oder fehlerresistente Codierungsmethoden (Erasure-Code) verwenden. ru en).

Ein schwerwiegenderes potenzielles Problem besteht darin, dass UDP-basierte Anwendungen im Gegensatz zu TCP nicht unbedingt über gute Mechanismen zur Überlastungskontrolle und -vermeidung verfügen. Überlastungsempfindliche UDP-Anwendungen, die einen erheblichen Teil der verfügbaren Bandbreite verbrauchen, können die Internetstabilität gefährden.

Netzwerkmechanismen wurden entwickelt, um die potenziellen Auswirkungen einer Überlastung bei unkontrollierten Hochgeschwindigkeitslasten zu minimieren. Netzwerkelemente wie Router, die Paketwarteschlangen und Drop-Techniken verwenden, sind oft die einzigen verfügbaren Tools, um übermäßigen UDP-Verkehr zu verlangsamen. DCCP (Datagram Congestion Control Protocol) ist als Teillösung für dieses potenzielle Problem konzipiert, indem dem Endhost Mechanismen hinzugefügt werden, um die Überlastung für Hochgeschwindigkeits-UDP-Streams wie Streaming-Medien zu überwachen.

Anwendungen

Zahlreiche wichtige Internetanwendungen nutzen UDP, darunter DNS (wobei Anfragen schnell sein müssen und nur aus einer Anfrage gefolgt von einem einzigen Antwortpaket bestehen müssen), Simple Network Management Protocol (SNMP), Routing Information Protocol (RIP) und Dynamic Host Configuration (DHCP). .

Sprach- und Videoverkehr wird normalerweise über UDP übertragen. Live-Video- und Audio-Streaming-Protokolle sind darauf ausgelegt, zufällige Paketverluste zu verarbeiten, sodass die Qualität nur geringfügig beeinträchtigt wird, anstatt dass es zu großen Verzögerungen kommt, wenn die verlorenen Pakete erneut übertragen werden. Da sowohl TCP als auch UDP im selben Netzwerk laufen, haben viele Unternehmen festgestellt, dass der jüngste Anstieg des UDP-Verkehrs von diesen Echtzeitanwendungen die Leistung von TCP-Anwendungen wie Datenbank- oder Buchhaltungssystemen beeinträchtigt. Da für Unternehmen sowohl Geschäfts- als auch Echtzeitanwendungen wichtig sind, wird die Entwicklung hochwertiger Problemlösungen für einige als oberste Priorität angesehen.

Vergleich von UDP und TCP

TCP ist ein verbindungsorientiertes Protokoll, was bedeutet, dass ein „Handshake“ erforderlich ist, um eine Verbindung zwischen zwei Hosts herzustellen. Sobald die Verbindung hergestellt ist, können Benutzer Daten in beide Richtungen senden.

  • Zuverlässigkeit- TCP verwaltet Nachrichtenbestätigung, erneute Übertragung und Zeitüberschreitung. Es werden zahlreiche Versuche unternommen, die Botschaft zu überbringen. Geht es unterwegs verloren, fordert der Server den verlorenen Teil erneut an. Bei TCP gibt es keine fehlenden Daten oder (bei mehreren Timeouts) unterbrochene Verbindungen.
  • Ordentlichkeit- Wenn zwei Nachrichten nacheinander gesendet werden, erreicht die erste Nachricht zuerst die Empfängeranwendung. Wenn Datenblöcke in der falschen Reihenfolge eintreffen, sendet TCP die Daten in der falschen Reihenfolge an einen Puffer, bis alle Daten geordnet und an die Anwendung gesendet werden können.
  • Schwere- TCP benötigt drei Pakete, um vor dem Senden von Daten eine Socket-Verbindung herzustellen. TCP überwacht Zuverlässigkeit und Überlastung.
  • Einfädeln- Die Daten werden als Bytestrom gelesen, es werden keine besonderen Bezeichnungen für Nachrichtengrenzen oder -segmente übertragen.

UDP ist ein einfacheres, nachrichtenbasiertes, verbindungsloses Protokoll. Diese Art von Protokollen stellt keine dedizierte Verbindung zwischen zwei Hosts her. Kommunikation wird dadurch erreicht, dass Informationen in eine Richtung von einer Quelle zu einem Empfänger übertragen werden, ohne die Bereitschaft oder den Zustand des Empfängers zu prüfen. Bei Voice-over-IP-Anwendungen (TCP/IP) hat UDP einen Vorteil gegenüber TCP, wo jeder Handshake eine gute Sprachkommunikation verhindern würde. Bei VoIP wird von Endbenutzern erwartet, dass sie den Nachrichtenempfang in Echtzeit bestätigen.

  • Unzuverlässig- Wenn eine Nachricht gesendet wird, ist nicht bekannt, ob sie ihr Ziel erreicht – sie kann unterwegs verloren gehen. Es gibt keine Konzepte wie Bestätigung, erneute Übertragung oder Zeitüberschreitung.
  • Störung- Wenn zwei Nachrichten an denselben Empfänger gesendet werden, kann die Reihenfolge, in der sie das Ziel erreichen, nicht vorhergesagt werden.
  • Leichtigkeit- Keine Nachrichtenreihenfolge, keine Verbindungsverfolgung usw. Es handelt sich um eine kleine Transportschicht, die in IP entwickelt wurde.
  • Datagramme- Pakete werden einzeln versendet und erst beim Eintreffen auf Integrität überprüft. Pakete haben bestimmte Grenzen, die nach dem Empfang eingehalten werden, was bedeutet, dass ein Lesevorgang am empfangenden Socket die Nachricht so erzeugt, wie sie ursprünglich gesendet wurde.
  • Keine Überlastkontrolle- UDP selbst vermeidet keine Überlastung. Es ist möglich, dass Anwendungen mit hoher Bandbreite zu einem Zusammenbruch der Überlastung führen, sofern sie keine Kontrollen auf Anwendungsebene implementieren.

UDP (User Datagram Protocol) ist ein Transportprotokoll zur verbindungslosen Datenübertragung über IP-Netzwerke. Es ist eines der einfachsten Transportschichtprotokolle des OSI-Modells. Seine IP-ID ist 0x11.

UDP wird typischerweise in Anwendungen wie Video-Streaming und Computerspielen verwendet, bei denen Paketverlust akzeptabel ist und ein erneuter Versuch schwierig oder ungerechtfertigt ist, oder in Challenge-Response-Anwendungen (wie DNS-Abfragen), bei denen das Herstellen einer Verbindung mehr Ressourcen beansprucht als das erneute Senden. Tatsächlich laufen UDP-Funktionen auf Multiplex- und Demultiplex-Vorgänge sowie auf einfache Fehlerprüfungen in Daten hinaus. Somit kommuniziert die Anwendung bei Verwendung von U DP nahezu direkt mit dem IP-Netzwerkschichtprotokoll.

UDP empfängt Nachrichten von der Anwendungsschicht, fügt Quell- und Zielportfelder zum Demultiplexen durch den Empfänger sowie zwei weitere Spezialfelder hinzu und übergibt das resultierende Segment an die Netzwerkschicht. Die Netzwerkschicht verpackt das Segment in ein Datagramm und leitet es „wenn möglich“ an den Zielhost weiter. Wenn dieser das Segment erfolgreich empfängt, leitet UDP die Segmentdaten über das Zielportnummernfeld an den gewünschten Prozess weiter. Daher soll UDP eine verbindungslose Datenübertragung ermöglichen.

Ein Beispiel für ein Protokoll der Anwendungsschicht, das UDP-Protokolldienste verwendet, ist DNS. Wenn eine DNS-Anwendung eine Abfrage generiert, erstellt sie eine DNS-Nachricht und leitet sie an das UDP-Protokoll weiter.


Vergleich der UDP- und TCP-Protokolle.

Wenn eine Anwendung eine Bestätigung der Nachrichtenübermittlung erfordert, verwendet sie das Protokoll TCP. TCP zerlegt die Nachricht in kleinere Teile, sogenannte Segmente. Diese Segmente werden fortlaufend nummeriert und an das IP-Protokoll übergeben, das dann die Pakete zusammenstellt. TCP verfolgt die Anzahl der Segmente, die von einer bestimmten Anwendung an einen bestimmten Host gesendet werden. Wenn der Absender innerhalb eines bestimmten Zeitraums keine Bestätigung erhält, behandelt TCP diese Segmente als verwaist und sendet sie erneut. Es wird nur der verlorene Teil der Nachricht erneut gesendet, nicht die gesamte Nachricht.

Das TCP-Protokoll am empfangenden Knoten ist dafür verantwortlich, die Nachrichtensegmente wieder zusammenzusetzen und an die entsprechende Anwendung zu übertragen.

FTP und HTTP sind Beispiele für Anwendungen, die TCP zur Übermittlung von Daten verwenden.

Protokoll UDP führt eine nicht garantierte Datenlieferung durch und fordert keine Bestätigung vom Empfänger. UDP ist das bevorzugte Protokoll zum Streamen von Audio, Video und Sprache über das Internet Protocol (VoIP). Durch die Bestätigung der Übermittlung wird der Datenübertragungsprozess nur verlangsamt und eine erneute Übermittlung ist nicht ratsam. Ein Beispiel für die Verwendung des UDP-Protokolls ist Internetradio.


ARP-Protokoll. Anwendung.

ARP(Englisch) Adressauflösungsprotokoll- Adressbestimmungsprotokoll) ist ein Low-Level-Protokoll, das in Computernetzwerken verwendet wird und dazu dient, die Link-Layer-Adresse aus einer bekannten Netzwerk-Layer-Adresse zu ermitteln. Dieses Protokoll hat aufgrund der Allgegenwart von IP-Netzwerken, die auf Ethernet aufbauen, die weiteste Verbreitung gefunden, da in fast 100 % der Fälle ARP in dieser Kombination verwendet wird. Die Protokollbeschreibung wurde im November 1982 in RFC 826 veröffentlicht. ARP wurde für den Fall der Übertragung von IP-Paketen über ein Ethernet-Segment konzipiert. Gleichzeitig wurde das für ARP vorgeschlagene allgemeine Prinzip möglicherweise auch für andere Netzwerktypen verwendet.

Es gibt die folgenden Arten von ARP-Nachrichten: ARP-Anfrage und ARP-Antwort. Das sendende System verwendet eine ARP-Anfrage, um die physische Adresse des empfangenden Systems anzufordern. Die Antwort (die physische Adresse des Zielhosts) erfolgt in Form einer ARP-Antwort.

Bevor ein Netzwerkschichtpaket über ein Ethernet-Segment gesendet wird, überprüft der Netzwerkstapel den ARP-Cache, um festzustellen, ob die erforderlichen Informationen über den Zielhost bereits darin registriert sind. Wenn im ARP-Cache kein solcher Eintrag vorhanden ist, wird eine ARP-Broadcast-Anfrage gestellt. Diese Abfrage nach Geräten im Netzwerk hat folgende Bedeutung: „Kennt jemand die physikalische Adresse des Geräts, das die folgende IP-Adresse hat?“ Wenn der Empfänger mit dieser IP-Adresse dieses Paket erhält, muss er antworten: „Ja, das ist meine IP-Adresse.“ Meine physische Adresse lautet: …“ Der Absender aktualisiert dann seinen ARP-Cache und kann die Informationen an den Empfänger übermitteln.

ARP-Cache-Einträge können statisch oder dynamisch sein. Das oben angegebene Beispiel beschreibt einen dynamischen Cache-Eintrag. Sie können auch statische Einträge in der ARP-Tabelle erstellen.

ARP wurde ursprünglich nicht nur für das IP-Protokoll entwickelt, sondern wird heute vor allem zur Abbildung von IP- und MAC-Adressen verwendet.

Arbeitsprinzip

Ein Knoten, der eine IP-Adresse einer lokalen Adresse zuordnen muss, generiert eine ARP-Anfrage, fügt sie in einen Link-Layer-Protokollrahmen ein, gibt darin eine bekannte IP-Adresse an und sendet die Anfrage.

Alle Hosts im lokalen Netzwerk erhalten eine ARP-Anfrage und vergleichen die dort angegebene IP-Adresse mit ihrer eigenen.

Bei Übereinstimmung generiert der Knoten eine ARP-Antwort, in der er seine IP-Adresse und seine lokale Adresse angibt und sendet diese bereits gerichtet, da der Absender in der ARP-Anfrage seine lokale Adresse angibt.

Die ganze Artikelreihe gefällt mir sehr gut, außerdem wollte ich mich schon immer mal als Übersetzer versuchen. Vielleicht erscheint der Artikel erfahrenen Entwicklern zu offensichtlich, aber ich denke, dass er auf jeden Fall nützlich sein wird.

Hallo, mein Name ist Glenn Fiedler und ich begrüße Sie zum ersten Artikel in meinem Online-Buch „Network Programming for Game Developers“.

In diesem Artikel beginnen wir mit den grundlegendsten Aspekten der Netzwerkprogrammierung – dem Empfangen und Senden von Daten über das Netzwerk. Das Empfangen und Senden von Daten ist der grundlegendste und einfachste Teil des gesamten Aufgabenspektrums von Netzwerkprogrammierern, aber es ist oft schwierig zu bestimmen, wie man am besten vorgeht. Schenken Sie diesem Teil genügend Aufmerksamkeit – wenn Sie ein Missverständnis haben, kann das später schlimme Folgen für Ihr Multiplayer-Spiel haben!

Sie haben wahrscheinlich schon etwas über Sockets gehört und wissen vielleicht, dass es zwei Haupttypen von ihnen gibt: TCP und UDP. Das erste, was Sie bei der Entwicklung eines Multiplayer-Spiels entscheiden müssen, ist, welche Art von Sockets Sie verwenden möchten – TCP, UDP oder beides?

Die Wahl des Sockeltyps hängt ganz vom Genre des Spiels ab, das Sie entwickeln. In dieser Artikelserie gehe ich davon aus, dass Sie ein Actionspiel schreiben – wie Halo, Battlefield 1942, Quake, Unreal, CounterStrike, Team Fortress usw.

Nun werfen wir einen genaueren Blick auf die Eigenschaften jedes Socket-Typs (unter Berücksichtigung der Tatsache, dass wir ein Action-Spiel entwickeln) und gehen etwas tiefer auf die Details der Funktionsweise des Internets ein. Nach einer ausführlichen Prüfung wird die richtige Option klar sein!

TCP steht für „Transmission Control Protocol“ und IP für „Internet Protocol“. Zusammen unterstützen sie fast alles, was Sie online tun, vom Surfen im Internet bis hin zur IRC- und E-Mail-Kommunikation – alles läuft über TCP/IP.

Wenn Sie jemals TCP-Sockets verwendet haben, sollten Sie wissen, dass TCP ein Protokoll ist, das das Prinzip einer zuverlässigen Verbindung nutzt. Das bedeutet, dass Sie eine Verbindung zwischen zwei Computern herstellen und dann Daten zwischen ihnen senden, so als würden Sie Informationen in eine Datei auf einem Computer schreiben und sie auf einem anderen aus derselben Datei lesen.

In diesem Fall gilt die Verbindung als zuverlässig und konsistent – ​​das heißt, alle von Ihnen gesendeten Informationen erreichen den Empfänger garantiert in der gleichen Reihenfolge, in der sie gesendet wurden. Außerdem kann eine TCP-Verbindung als kontinuierlicher Datenstrom betrachtet werden – das Protokoll selbst sorgt dafür, dass die Daten in Pakete aufgeteilt und über das Netzwerk gesendet werden.

Noch einmal: Alles ist so einfach wie normales Schreiben oder Lesen aus einer Datei. Elementarer Watson!

Diese Benutzerfreundlichkeit unterscheidet sich jedoch völlig von dem, was tatsächlich „unter der Haube“ auf einer niedrigeren Ebene geschieht – der IP-Protokollebene.

Auf dieser Ebene gibt es kein Verbindungskonzept, sondern es werden einzelne Pakete von einem Computer zum anderen übertragen. Sie können sich diesen Vorgang so vorstellen, als würden Sie in einem Raum voller Menschen einen Zettel von einer Person an eine andere weitergeben: Am Ende gelangt der Zettel bei der richtigen Person an, geht aber gleichzeitig durch viele Hände.

Es gibt jedoch keine Garantie dafür, dass die Notiz den Adressaten erreicht. Der Absender sendet einfach eine Nachricht in der Hoffnung, dass diese ankommt, weiß aber nicht einmal, ob die Nachricht angekommen ist oder nicht – bis der Empfänger sich dazu entschließt, zurückzuschreiben.
In der Realität ist natürlich alles etwas komplizierter, da der sendende Computer nicht die genaue Reihenfolge der Computer im Netzwerk kennt, über die das Paket übertragen werden muss, damit es so schnell wie möglich ankommt. Manchmal überträgt IP mehrere Kopien desselben Pakets, die möglicherweise unterschiedliche Wege nehmen, um das Ziel zu erreichen – und wahrscheinlich zu unterschiedlichen Zeiten ankommen.

Was wäre, wenn wir Informationen zwischen Computern nicht im Datei-Lese-/Schreibstil, sondern durch direktes Senden und Empfangen einzelner Pakete übertragen möchten?

Nun, wir können dies mit UDP tun. UDP steht für „User Datagram Protocol“ und läuft auf IP (wie TCP), aber anstatt eine Menge Funktionalität hinzuzufügen, ist es nur eine kleine Ergänzung zu IP.

Mit UDP können wir ein Paket an eine bestimmte IP-Adresse (z. B. 112.140.20.10) und einen Port (z. B. 52423) senden und es wird von Computer zu Computer übertragen, bis es sein Ziel erreicht (oder unterwegs verloren geht). Weg).

Gleichzeitig sitzen wir auf der Empfängerseite einfach da und warten, hören auf einen bestimmten Port (in unserem Fall 52423) und wenn ein Paket von jemandem ankommt (denken Sie daran, dass keine Verbindungen verwendet werden), erhalten wir eine Benachrichtigung darüber mit die Adresse und den Port des sendenden Computers, die Paketgröße, und danach können wir die Daten aus diesem Paket lesen.

Das UDP-Protokoll garantiert keine Datenlieferung. In der Praxis kommen natürlich die meisten Pakete an, aber es gibt immer einen Verlust von etwa 1-5 %, und manchmal gibt es Zeiträume, in denen Pakete überhaupt nicht ankommen (denken Sie daran, dass es zwischen dem Absender und dem Empfänger sein kann). Es kann sich um Tausende von Computern handeln, auf denen es zu Ausfällen oder Ausfällen kommen kann.

Außerdem garantiert UDP nicht die Reihenfolge, in der Pakete zugestellt werden. Sie können fünf Pakete in der Reihenfolge senden – 1, 2, 3, 4, 5 –, aber sie können in einer völlig anderen Reihenfolge ankommen – zum Beispiel 3, 1, 2, 5, 4. Auch in der Praxis wird dies höchstwahrscheinlich der Fall sein Meistens kommen sie in der richtigen Reihenfolge an, aber darauf kann man sich nicht verlassen!

Obwohl UDP nicht viel zu IP beiträgt, garantiert es doch eines. Wenn Sie ein Paket weiterleiten, kommt es entweder vollständig oder gar nicht an. Wenn Sie also ein 256-Byte-Paket an einen anderen Computer senden, kann dieser nicht nur die ersten 100 Bytes des Pakets empfangen – er muss alle 256 Bytes empfangen. Das ist wirklich das Einzige, was das UDP-Protokoll garantiert – alles andere liegt auf Ihren Schultern.

Wir müssen uns also entscheiden: Sollen wir TCP- oder UDP-Sockets verwenden? Werfen wir einen Blick auf ihre Eigenschaften:

  • Verwendet das Verbindungsprinzip
  • Garantiert Lieferung und Bearbeitungszeit
  • Teilt Informationen automatisch in Pakete auf
  • Sorgt dafür, dass Daten nicht zu intensiv gesendet werden (Datenflusskontrolle)
  • Einfach zu bedienen – wie das Schreiben/Lesen aus einer Datei
UDP:
  • Das Verbindungsprinzip wird nicht verwendet – Sie müssen es manuell implementieren
  • Gewährleistet nicht die Zustellung und Reihenfolge der Zustellung von Paketen – sie können in der falschen Reihenfolge, mit Duplikaten oder überhaupt nicht ankommen!
  • Sie müssen die Daten manuell in Pakete aufteilen und versenden
  • Sie müssen darauf achten, die Daten nicht zu intensiv zu versenden
  • Wenn ein Paket verloren geht, müssen Sie es irgendwie verfolgen und gegebenenfalls erneut senden
Mit einer solchen Liste scheint die Lösung offensichtlich: TCP implementiert alle von uns benötigten Funktionen und ist einfacher zu verwenden, während die Verwendung von UDP Hämorrhoiden verspricht, da alles manuell und von Grund auf neu geschrieben werden muss. Wir verwenden also TCP, oder?

Aber nein.

Die Verwendung von TCP ist wahrscheinlich der schlimmste Fehler, den Sie bei der Entwicklung eines Multiplayer-Spiels machen können. Um zu verstehen, warum, schauen wir uns an, was die Verwendung von TCP so einfach macht!

So funktioniert TCP
TCP und UDP funktionieren beide auf IP, sind aber in Wirklichkeit völlig unterschiedlich. UDP verhält sich sehr ähnlich wie IP, während TCP den Benutzer von allen Paketproblemen abstrahiert und die Interaktion dem Lesen/Schreiben in eine Datei ähnelt.

Wie macht er das?

Erstens verwendet TCP eine Datenstromabstraktion – Sie können einfach Datenbytes in diesen Strom schreiben und TCP stellt sicher, dass er sein Ziel erreicht. Da IP Daten in Paketen überträgt und TCP auf IP läuft, muss TCP den Eingabestrom des Benutzers in einzelne Pakete aufteilen. Innerhalb von TCP sammelt also eine Logik Daten in einer Warteschlange, und wenn genug davon vorhanden sind, bildet sie ein Paket und sendet es an das Ziel.

Dieses Verhalten könnte für unser Multiplayer-Spiel ein Problem darstellen, wenn wir sehr kleine Pakete übertragen müssen. Es kann vorkommen, dass TCP beschließt, unsere Daten erst zu übertragen, wenn sie genug angesammelt haben, um ein Paket einer bestimmten Größe (z. B. mehr als hundert Bytes) zu bilden. Und das ist ein großes Problem, denn es ist notwendig, die Daten vom Client (Tastenanschläge des Players) so schnell wie möglich zum Server zu übertragen, und wenn es durch die Datenpufferung durch das Protokoll zu Verzögerungen kommt, dann für den Player auf der Clientseite Das Spiel wird nicht das angenehmste sein. In diesem Fall erfolgt die Aktualisierung von Spielobjekten mit Verzögerung und selten – wohingegen wir Objekte rechtzeitig und häufig aktualisieren müssen.

TCP verfügt über eine Option zur Behebung dieses Problems: „TCP_NODELAY“. Es weist das Protokoll an, nicht darauf zu warten, bis sich die Daten in der Sendewarteschlange ansammeln, sondern sie sofort zu senden.

Leider gibt es trotz dieser Option bei der Verwendung von TCP in Online-Spielen viele Probleme.

Die Wurzel aller Probleme liegt in der Art und Weise, wie TCP verlorene oder nicht in der richtigen Reihenfolge befindliche Pakete verarbeitet, wodurch die Illusion einer zuverlässigen und konsistenten Verbindung entsteht.

Wie TCP die Verbindungszuverlässigkeit gewährleistet
Bei der Übertragung zerlegt TCP den Datenstrom in einzelne Pakete, leitet sie mithilfe des unzuverlässigen IP-Protokolls über das Netzwerk weiter und rekonstruiert dann aus den empfangenen Paketen auf dem empfangenden Computer den ursprünglichen Strom.

Doch was passiert, wenn eines der Pakete nicht ankommt? Oder wenn die Pakete nicht in der richtigen Reihenfolge oder mit Duplikaten ankommen?

Ohne zu tief in die Details der Funktionsweise von TCP einzutauchen (und das ist wirklich ein sehr komplexes Thema – Sie können es in TCP/IP Illustrated nachlesen), sieht der Prozess wie folgt aus: TCP sendet ein Paket und stellt fest, dass das Paket nicht angekommen ist und sendet dasselbe Paket erneut an den Empfänger. Doppelte Pakete werden auf Empfängerseite eliminiert und Pakete, die in der falschen Reihenfolge ankommen, werden neu geordnet, sodass alles so ist, wie es sein soll – zuverlässig und in Ordnung.

Das Problem besteht darin, dass, wenn TCP den Datenstrom auf diese Weise „synchronisiert“ und ein Paket verloren geht, die Übertragung angehalten wird, bis das verlorene Paket erneut gesendet (und vom Ziel empfangen) wird. Wenn während des Wartens neue Daten eintreffen, werden diese in die Warteschlange gestellt und Sie können sie erst dann lesen, wenn das verlorene Paket eintrifft. Wie lange dauert es, ein Paket erneut zu versenden? Es dauert mindestens die Umlaufzeit des Pakets (wenn TCP bestimmt, welches Paket erneut gesendet werden soll) plus die Zeit für die erneute Zustellung des verlorenen Pakets. Wenn also der Ping zwischen Computern 125 ms beträgt, dauert die erneute Übertragung des Pakets etwa eine Fünftelsekunde und im schlimmsten Fall bis zu einer halben Sekunde (stellen Sie sich vor, dass auch das erneut gesendete Paket plötzlich verloren geht). Veselukha!

Warum Sie TCP niemals für Multiplayer-Spiele verwenden sollten
Das Problem bei der Verwendung von TCP in Online-Spielen besteht darin, dass Spiele im Gegensatz zu Browsern, E-Mail und anderen Anwendungen auf Echtzeitinteraktion angewiesen sind. Für viele Aspekte des Spiels, etwa die Tastenanschläge des Benutzers und die Position der Spieler im Spiel, kommt es nicht darauf an, was vor einer Sekunde passiert ist, sondern nur auf den aktuellsten Stand der Spielwelt.

Schauen wir uns ein einfaches Beispiel eines Multiplayer-Spiels an, beispielsweise einen 3D-Shooter. Der Netzwerkteil des Spiels ist sehr einfach aufgebaut: Bei jeder Iteration des Spielzyklus sendet der Client eine Beschreibung aller Aktionen des Spielers (gedrückte Tasten, Mausposition usw.) an den Server, und bei jeder Iteration verarbeitet der Server diese Daten , aktualisiert das Modell der Spielwelt und sendet die aktuellen Positionen von Weltobjekten an den Client zurück, sodass ein neuer Rahmen für den Spieler gezeichnet wird.

Wenn also in unserem Spiel ein Paket während der Übertragung über das Netzwerk verloren geht, stoppt das Spiel und wartet, bis das Paket erneut zugestellt wird. Auf der Client-Seite frieren Spielobjekte ein und auf dem Server können sich Spieler auch nicht bewegen oder schießen, da der Server keine neuen Pakete annehmen kann. Wenn das verlorene Paket schließlich eintrifft, enthält es veraltete Informationen, die nicht mehr relevant sind. Darüber hinaus treffen danach auch alle Pakete ein, die sich während der Wartezeit in der Warteschlange angesammelt haben, und müssen alle in einer Iteration der Schleife verarbeitet werden. Völlige Verwirrung!

Leider gibt es keine Möglichkeit und auch keine Notwendigkeit, dieses Verhalten von TCP zu ändern, da dies die Bedeutung von TCP ist. Dies ist eine Notwendigkeit, um die Datenübertragung über das Internet zu einem zuverlässigen und konsistenten Datenfluss zu machen.
Aber wir brauchen keinen zuverlässigen und konsistenten Datenstrom.

Wir benötigen, dass die Daten so schnell wie möglich vom Client zum Server gelangen, und wir möchten nicht darauf warten, dass die Daten erneut gesendet werden.
Aus diesem Grund sollten Sie TCP niemals für Multiplayer-Spiele verwenden.

Aber warte! Warum kann ich UDP und TCP nicht zusammen verwenden?

Für Echtzeit-Spieldaten wie Benutzerklicks und den Status der Spielwelt sind nur die aktuellsten Daten wichtig, für andere Datentypen wie Befehlssätze, die von einem Computer an einen anderen gesendet werden, jedoch die Zuverlässigkeit und Konsistenz des Kanals kann sehr wichtig sein.

Natürlich ist es verlockend, UDP für Benutzereingaben und Weltzustandsdaten und TCP für Daten zu verwenden, deren Zustellung garantiert sein muss. Möglicherweise denken Sie sogar darüber nach, dass Sie mehrere „Threads“ mit Befehlen erstellen könnten – zum Beispiel einen für Ladestufen und einen anderen für KI-Befehle. Sie denken: „Ich brauche keine KI-Teams, die in der Schlange stehen, wenn das Datenpaket zum Laden eines Levels verloren geht, weil sie überhaupt nichts miteinander zu tun haben!“ In diesem Fall haben Sie Recht und können sich dafür entscheiden, für jeden Befehlsstream einen TCP-Socket zu erstellen.

Auf den ersten Blick ist das eine tolle Idee. Das Problem besteht jedoch darin, dass sich die Pakete beider Protokolle gegenseitig beeinflussen, da sowohl TCP als auch UDP auf IP laufen – bereits auf IP-Ebene. Wie sich dieser Effekt genau manifestiert, ist eine sehr komplexe Frage und hängt mit den Zuverlässigkeitsmechanismen in TCP zusammen. Beachten Sie jedoch auf jeden Fall, dass die Verwendung von TCP normalerweise zu einem erhöhten Verlust von UDP-Paketen führt. Wenn Sie mehr darüber erfahren möchten, können Sie diesen Artikel lesen.

Abschluss
Ich empfehle, nicht nur UDP zu verwenden, sondern nur UDP und nichts anderes. Verwenden Sie TCP und UDP nicht zusammen, sondern lernen Sie, wie Sie die benötigten TCP-Funktionen auf Basis von UDP selbst implementieren.

In den folgenden Artikeln verrate ich Ihnen, wie das geht – von der Implementierung Ihres eigenen Protokolls über UDP-basierte Verbindungen bis hin zur Implementierung von Übertragungssicherheit und Datenflusskontrolle.

Guten Tag, liebe Leser.
Auf vielfachen Wunsch veröffentliche ich heute für Sie einen Artikel, der Sie in die Grundlagen der Computernetzwerkbegriffe einführt, nämlich:

  • Netzwerkprotokolle – was sind diese gruseligen Namen und wofür werden sie verwendet?
  • UDP, TCP, ICMP – was, warum und was ist der Unterschied
  • Jeder hat eine IP-Adresse, aber nicht jeder weiß, warum das so ist :-)
  • Adressmaske (Subnetz)
  • Tor
  • Ein paar Worte zu Routing-Tabellen
  • Häfen – was sind sie eigentlich?
  • MAC-Adresse

Ungefähr so.

Ich denke, der Artikel wird für alle, ob jung oder alt, nützlich sein, da er nicht so sehr eine Reihe seltsamer, unverständlicher Handlungen oder Wörter enthält, sondern einen Informationsblock in einer zugänglichen Sprache, der zumindest etwas gibt Sie verstehen, wie das Ganze im Allgemeinen funktioniert und warum es notwendig ist. Gehen.

Netzwerkprotokolle TCP/IP, NWLink IPX/SPX, NetBEUI

Beginnen wir damit, was ein Netzwerkprotokoll ist und wofür es verwendet wird.
Netzwerkprotokoll ist eine Reihe softwareimplementierter Regeln für die Kommunikation zwischen Computern. Eine Art Sprache, in der Computer miteinander kommunizieren und Informationen übermitteln. Früher waren Computer sozusagen mehrsprachig und ältere Windows-Versionen nutzten eine ganze Reihe von Protokollen – TCP/IP, NWLink IPX/SPX, NetBEUI. Jetzt sind wir zu einer allgemeinen Einigung gekommen und der Standard ist die ausschließliche Verwendung des TCP/IP-Protokolls geworden, weshalb wir weiter darauf eingehen werden.

Wenn sie über TCP/IP sprechen, meinen sie mit diesem Namen normalerweise viele verschiedene ... Regeln oder, sagen wir, Standards, die für die Verwendung (oder Verwendung) dieses Protokolls vorgeschrieben sind. So gibt es beispielsweise Regeln, nach denen Nachrichten zwischen Mailservern ausgetauscht werden, und es gibt Regeln, nach denen der Endbenutzer Briefe in seinem Postfach erhält. Es gibt Regeln für die Durchführung von Videokonferenzen und Regeln für die Organisation von „Telefongesprächen“ über das Internet. Tatsächlich handelt es sich dabei nicht einmal um wirkliche Regeln ... Eher um eine Art Grammatik oder so etwas. Nun, wissen Sie, im Englischen gibt es eine Struktur zum Aufbau von Dialogen, im Französischen gibt es eine andere ... Also in TCP/IP etwas Ähnliches, d. h. Eine bestimmte Reihe unterschiedlicher grammatikalischer Regeln ist genau das integrale TCP/IP-Protokoll oder, genauer gesagt, TCP/IP-Protokollstapel.

Netzwerkprotokolle UDP, TCP, ICMP

Innerhalb des TCP/IP-Protokolls werden für die Datenübertragung die Protokolle TCP und UDP verwendet. Viele Leute haben wahrscheinlich gehört, dass es sowohl TCP- als auch UDP-Ports gibt, aber nicht jeder weiß, was der Unterschied ist und worum es geht. Also..

Die Datenübertragung über das TCP-Protokoll (Transmission Control Protocol) erfordert eine Bestätigung des Informationsempfangs. „Nun, sagen sie, hast du es verstanden? – Verstanden!“ Sollte die übermittelnde Partei die erforderliche Bestätigung nicht innerhalb der gesetzten Frist erhalten, werden die Daten erneut übermittelt. Daher gilt TCP als verbindungsbasiertes Protokoll, UDP (User Datagram Protocol) hingegen nicht. UDP wird in Fällen verwendet, in denen keine Empfangsbestätigung erforderlich ist (z. B. DNS-Anfragen oder IP-Telefonie (wobei Skype ein prominenter Vertreter ist)). Das heißt, der Unterschied liegt im Vorliegen einer Empfangsbestätigung. Es scheint „Das ist alles!“, aber in der Praxis spielt es eine wichtige Rolle.

Darüber hinaus gibt es das ICMP-Protokoll (Internet Control Message Protocol), mit dem Daten über Netzwerkparameter übertragen werden. Es umfasst Dienstprogrammpakettypen wie Ping, Entfernung nicht erreichbar, TTL usw.

Was ist eine IP-Adresse?

Jeder hat eine, aber nicht jeder hat eine Vorstellung davon, was das für eine Adresse ist und warum es unmöglich ist, ohne sie zu leben. Ich sage dir.

Die IP-Adresse ist eine 32-Bit-Nummer, die zur Identifizierung eines Computers in einem Netzwerk verwendet wird. Es ist üblich, die Adresse in Dezimalwerten jedes Oktetts dieser Zahl zu schreiben und die resultierenden Werte durch Punkte zu trennen. Beispiel: 192.168.101.36

IP-Adressen sind eindeutig, was bedeutet, dass jeder Computer seine eigene Zahlenkombination hat und es nicht zwei Computer im Netzwerk mit derselben Adresse geben kann. IP-Adressen werden zentral verteilt, Internetprovider stellen je nach Bedarf Anträge bei nationalen Zentren. Die von den Providern empfangenen Adressbereiche werden weiter auf die Clients verteilt. Clients wiederum können selbst als Provider fungieren und empfangene IP-Adressen zwischen Subclients usw. verteilen. Bei dieser Methode zur Verteilung von IP-Adressen kennt das Computersystem genau den „Standort“ eines Computers, der über eine eindeutige IP-Adresse verfügt; - Es reicht aus, dass sie die Daten an das Netzwerk des „Eigentümers“ sendet, und der Anbieter wiederum analysiert das Ziel und sendet die Informationen, da er weiß, an wen dieser Teil der Adressen weitergegeben wird, an den nächsten Eigentümer von den IP-Adressteilbereich, bis die Daten am Zielcomputer ankommen.

Für den Aufbau lokaler Netzwerke werden spezielle Adressbereiche vergeben. Dies sind die Adressen 10.x.x.x, 192.168.x.x, 10.x.x.x, von 172.16.x.x bis 172.31.x.x, 169.254.x.x, wobei x eine beliebige Zahl von 0 bis 254 bedeutet. Von den angegebenen Adressen gesendete Pakete werden nicht weitergeleitet, das heißt, sie werden einfach nicht über das Internet gesendet. Daher können Computer in verschiedenen lokalen Netzwerken übereinstimmende Adressen aus den angegebenen Bereichen haben. Das heißt, die Firmen LLC „Horns and Hooves“ und LLC „Vasya and Company“ können zwei Computer mit den Adressen 192.168.0.244 haben, aber nicht beispielsweise mit den Adressen 85.144.213.122, die sie vom Internetprovider erhalten haben, weil . Im Internet kann es keine zwei identischen IP-Adressen geben. Um Informationen von solchen Computern ins Internet und zurück zu senden, werden spezielle Programme und Geräte verwendet, die bei der Arbeit mit dem Internet lokale Adressen durch echte ersetzen. Mit anderen Worten: Daten werden von einer echten IP-Adresse an das Netzwerk gesendet und nicht von einer lokalen. Dieser Vorgang erfolgt für den Benutzer unbemerkt und wird als Adressübersetzung bezeichnet. Ich möchte auch erwähnen, dass es innerhalb desselben Netzwerks, beispielsweise einer Firma, Horns and Hooves LLC, nicht zwei Computer mit einer lokalen IP-Adresse geben kann, d. h. im obigen Beispiel war damit ein Computer mit der Adresse 192.168.0.244 gemeint in einem Unternehmen, das zweite mit der gleichen Adresse in einem anderen. Im selben Unternehmen vertragen sich zwei Computer mit der Adresse 192.168.0.244 einfach nicht.

Sie haben wahrscheinlich Begriffe wie externe IP und interne IP, permanente (statische IP) und variable (dynamische) IP gehört. Kurz und knapp über sie:

  • Die externe IP ist genau die gleiche IP, die Ihnen Ihr Provider gibt, d. h. Ihre eindeutige Adresse im Internet lautet beispielsweise 85.144.24.122
  • interne IP ist lokale IP, d.h. Ihre IP im lokalen Netzwerk lautet beispielsweise 192.168.1.3
  • Eine statische IP ist eine IP, die sich nicht bei jeder Verbindung ändert, d. h. dir fest und für immer zugewiesen
  • Dynamische IP ist eine schwebende IP-Adresse, die sich bei jeder Verbindung ändert

Der Typ Ihrer IP (statisch oder dynamisch) hängt von den Einstellungen Ihres Providers ab.

Was ist eine Adressmaske (Subnetz)?

Das Konzept eines Subnetzes wurde eingeführt, um die Auswahl eines Teils der IP-Adressen einer Organisation, eines Teils einer anderen usw. zu ermöglichen. Ein Subnetz ist ein Bereich von IP-Adressen, die als zum selben lokalen Netzwerk gehörend betrachtet werden. Bei der Arbeit in einem lokalen Netzwerk werden Informationen direkt an den Empfänger gesendet. Sind die Daten für Computer mit einer IP-Adresse bestimmt, die nicht zum lokalen Netzwerk gehört, werden auf sie spezielle Regeln angewendet, um die Route für die Weiterleitung von einem Netzwerk in ein anderes zu berechnen.

Eine Maske ist ein Parameter, der der Software mitteilt, wie viele Computer in einer bestimmten Gruppe (Subnetz) enthalten sind. Die Adressmaske hat den gleichen Aufbau wie die IP-Adresse selbst: Sie besteht aus vier Zahlengruppen, die jeweils im Bereich von 0 bis 255 liegen können. In diesem Fall gilt: Je niedriger der Maskenwert, desto mehr Computer sind mit diesem Subnetz verbunden. Für kleine Unternehmensnetzwerke lautet die Maske normalerweise 255.255.255.x (z. B. 255.255.255.224). Zusammen mit der IP-Adresse wird dem Computer auch die Netzwerkmaske zugewiesen. So kann beispielsweise das Netzwerk 192.168.0.0 mit einer Maske von 255.255.255.0 Computer mit Adressen von 192.168.0.1 bis 192.168.254 enthalten. 192.168.0.0 mit einer Maske von 255.255.255.128 erlaubt Adressen von 192.168.0.1 bis 192. 168,0 .127 . Ich denke, die Bedeutung ist klar. Zur Speicherung von IP-Adressen werden von Anbietern in der Regel Netzwerke mit möglichst geringer Rechneranzahl genutzt. Beispielsweise kann einem Client eine Adresse mit der Maske 255.255.255.252 zugewiesen werden. Dieses Subnetz enthält nur zwei Computer.

Nachdem der Computer eine IP-Adresse erhalten hat und den Wert der Subnetzmaske kennt, kann das Programm mit der Arbeit in diesem lokalen Subnetz beginnen. Um jedoch Informationen mit anderen Computern im globalen Netzwerk auszutauschen, müssen Sie die Regeln kennen, wohin Informationen für das externe Netzwerk gesendet werden sollen. Zu diesem Zweck wird ein Merkmal wie die Gateway-Adresse verwendet.

Was ist ein Gateway?

Ein Gateway ist ein Gerät (Computer oder Router), das Informationen zwischen verschiedenen IP-Subnetzen weiterleitet. Wenn das Programm (anhand von IP und Maske) feststellt, dass die Zieladresse nicht Teil des lokalen Subnetzes ist, sendet es diese Daten an das Gerät, das als Gateway fungiert. Geben Sie in den Protokolleinstellungen die IP-Adresse eines solchen Geräts an.

Um nur im lokalen Netzwerk zu arbeiten, darf das Gateway nicht angegeben werden.

Für einzelne Benutzer, die eine Verbindung zum Internet herstellen, oder für kleine Unternehmen mit einem einzigen Verbindungskanal, sollte das System nur eine Gateway-Adresse haben – dies ist die Adresse des Geräts, das über eine Internetverbindung verfügt. Wenn es mehrere Routen gibt, gibt es mehrere Gateways. In diesem Fall wird eine Routing-Tabelle verwendet, um den Datenpfad zu bestimmen.

Was sind Routing-Tabellen?

Und so erreichten wir sie problemlos. Und so... Was sind das für Tische?

Eine Organisation oder ein Benutzer kann über mehrere Verbindungspunkte zum Internet verfügen (z. B. Backup-Kanäle für den Fall, dass beim ersten Anbieter etwas schief geht, das Internet aber dennoch dringend benötigt wird) oder in seiner Struktur mehrere IP-Netzwerke enthalten. Damit das System in diesem Fall weiß, auf welche Weise (über welches Gateway) diese oder jene Informationen gesendet werden sollen, werden Routing-Tabellen verwendet. Die Routing-Tabellen für jedes Gateway geben an, für welche Internet-Subnetze Informationen über sie übertragen werden sollen. In diesem Fall können Sie für mehrere Gateways die gleichen Reichweiten festlegen, jedoch mit unterschiedlichen Kosten für die Datenübertragung: Informationen werden beispielsweise über den Kanal mit den niedrigsten Kosten gesendet, und wenn dieser aus dem einen oder anderen Grund ausfällt, über den nächsten Verfügbare meisten werden automatisch günstige Verbindung verwendet.

Was sind Netzwerkports?

Bei der Datenübertragung enthält das Informationspaket neben den IP-Adressen von Sender und Empfänger auch Portnummern. Beispiel: 192.168.1.1:80, – in diesem Fall ist 80 die Portnummer. Ein Port ist eine Nummer, die beim Empfangen und Senden von Daten verwendet wird, um den Prozess (das Programm) zu identifizieren, der die Daten verarbeiten soll. Wenn das Paket also an Port 80 gesendet wird, bedeutet dies, dass die Informationen für den HTTP-Server bestimmt sind.

Portnummern von 1 bis 1023 sind bestimmten Programmen (den sogenannten Well-Known-Ports) zugeordnet. Ports mit den Nummern 1024 -65 535 können in proprietären Programmen verwendet werden. In diesem Fall müssen mögliche Konflikte von den Programmen selbst gelöst werden, indem sie einen freien Port wählen. Mit anderen Worten, die Ports werden dynamisch verteilt: Es ist möglich, dass das Programm beim nächsten Start einen anderen Portwert wählt, es sei denn, Sie stellen den Port natürlich manuell über die Einstellungen ein.

Was ist eine MAC-Adresse?

Tatsache ist, dass im Netzwerk gesendete Pakete nicht über deren Namen oder IP-Adressen an Computer adressiert werden. Das Paket ist für ein Gerät mit einer bestimmten Adresse bestimmt, die MAC-Adresse genannt wird.

Eine MAC-Adresse ist eine eindeutige Adresse eines Netzwerkgeräts, die ihm vom Gerätehersteller zugewiesen wird, d. h. Dabei handelt es sich um eine Art gestempelte Nummer Ihrer Netzwerkkarte. Die erste Hälfte der MAC-Adresse ist die Herstellerkennung, die zweite die eindeutige Nummer dieses Geräts.

In der Regel wird eine MAC-Adresse zur Identifikation z. B. bei einem Provider benötigt (sofern der Provider statt Login-Passwort eine MAC-Adressbindung nutzt) oder bei der Einrichtung eines Routers.

Hier werden alle Netzwerkeinstellungen angezeigt

Ich hätte fast vergessen, ein paar Worte darüber zu sagen, wo man das alles suchen und ändern kann.



 


Lesen:



Öffnen Sie das linke Menü Cayo Coco

Öffnen Sie das linke Menü Cayo Coco

Cayo Coco Island ist eine Ferieninsel in Zentralkuba. Lage der Insel Cayo Coco Island liegt direkt gegenüber dem Canal Viejo in...

Warum brauchen wir Funkkommunikation und Radiosender?

Warum brauchen wir Funkkommunikation und Radiosender?

Manche Menschen träumen von einem neuen iPhone, andere von einem Auto und wieder andere von einem Teilesatz und einem neuen Lautsprecher für ihr Radio. Es gab eine Zeit vor nicht allzu langer Zeit, da...

Kendall- und Spearman-Rangkorrelationskoeffizienten Beispiel für einen Kendall-Rangkorrelationskoeffizienten

Kendall- und Spearman-Rangkorrelationskoeffizienten Beispiel für einen Kendall-Rangkorrelationskoeffizienten

Präsentation und Vorbearbeitung von Gutachten. In der Praxis kommen mehrere Arten von Gutachten zum Einsatz: - qualitativ (oft-selten,...)

Programmierfunktionen

Programmierfunktionen

Zweck der Arbeit: 1) die Regeln zur Beschreibung von Funktionen studieren; 2) Kenntnisse im Umgang mit Funktionen beim Schreiben von Programmen in C++ erwerben. Theoretisch...

Feed-Bild RSS