wake-up-neo.com

Was ist der Unterschied zwischen Streams und Datagrammen bei der Netzwerkprogrammierung?

Was ist der Unterschied zwischen Sockets (Stream) und Sockets (Datagrammen)? Warum übereinander verwenden?

122
RoR

Vor langer Zeit habe ich eine großartige Analogie gelesen, um den Unterschied zwischen den beiden zu erklären. Ich erinnere mich nicht, wo ich es gelesen habe, so dass ich den Autor für die Idee leider nicht würdigen kann, aber ich habe der Kernanalogie trotzdem eine Menge meines eigenen Wissens hinzugefügt. Also los geht's:

Ein Stream-Socket ist wie ein Telefonanruf - eine Seite tätigt den Anruf, die andere antwortet, Sie begrüßen sich gegenseitig (SYN/ACK in TCP) und tauschen dann Informationen aus. Sobald Sie fertig sind, verabschieden Sie sich (FIN/ACK in TCP). Wenn eine Seite keinen Abschied hört, ruft sie normalerweise die andere zurück, da dies ein unerwartetes Ereignis ist. In der Regel stellt der Client die Verbindung zum Server wieder her. Es gibt eine Garantie dafür, dass die Daten nicht in einer anderen Reihenfolge als der von Ihnen gesendeten eingehen, und es gibt eine angemessene Garantie dafür, dass die Daten nicht beschädigt werden.

Ein Datagramm-Socket ist wie das Übergeben einer Notiz im Unterricht. Stellen Sie sich den Fall vor, dass Sie sich nicht direkt neben der Person befinden, an die Sie die Notiz weiterleiten. Die Notiz wird von Person zu Person weitergeleitet. Es kann sein, dass es sein Ziel nicht erreicht, und es kann geändert werden, bis es dort ankommt. Wenn Sie zwei Notizen an dieselbe Person weitergeben, treffen diese möglicherweise in einer Reihenfolge ein, die Sie nicht beabsichtigt haben, da der Weg, den die Notizen durch den Unterricht nehmen, möglicherweise nicht derselbe ist und eine Person eine Notiz möglicherweise nicht so schnell weitergibt wie eine andere usw .

Sie verwenden also einen Stream-Socket, wenn Informationen in Ordnung und intakt sind. Dateiübertragungsprotokolle sind hier ein gutes Beispiel. Sie möchten keine Datei herunterladen, deren Inhalt nach dem Zufallsprinzip verschoben und beschädigt wurde!

Sie würden einen Datagramm-Socket verwenden, wenn die Reihenfolge weniger wichtig ist als die rechtzeitige Bereitstellung (z. B. VoIP- oder Spielprotokolle), wenn Sie keinen höheren Overhead eines Streams möchten (aus diesem Grund ist DNS in erster Linie ein Datagramm-Protokoll, sodass Server dies können) sehr schnell auf viele, viele Anfragen gleichzeitig antworten) oder wenn Sie sich nicht allzu sehr darum kümmern, ob die Daten jemals ihr Ziel erreichen.

Um den VoIP-/Spielekoffer zu erweitern, enthalten solche Protokolle einen eigenen Datenbestellungsmechanismus. Wenn jedoch ein Paket beschädigt ist oder verloren geht, möchten Sie nicht auf das Stream-Protokoll (normalerweise TCP) warten, um eine erneute Sendeanforderung auszustellen - Sie müssen sich schnell erholen. TCP kann einige Minuten in Anspruch nehmen, und für Echtzeitprotokolle wie Gaming oder VoIP können sogar drei Sekunden inakzeptabel sein! Die Verwendung eines Datagrammprotokolls wie UDP ermöglicht es der Software, von einem solchen Protokoll wiederherzustellen Ereignis extrem schnell, indem Sie einfach die verlorenen Daten ignorieren oder erneut anfordern, bevor TCP würde.

VoIP ist ein guter Kandidat, um die verlorenen Daten einfach zu ignorieren - ein Teilnehmer hört nur eine kurze Lücke, ähnlich wie wenn er mit jemandem auf einem Handy spricht, der einen schlechten Empfang hat. Spielprotokolle sind oft etwas komplexer, aber die ergriffenen Maßnahmen bestehen normalerweise darin, entweder die fehlenden Daten zu ignorieren (wenn später empfangene Daten die Daten ersetzen, die verloren gegangen sind), die fehlenden Daten erneut anzufordern oder eine vollständige Statusaktualisierung anzufordern Stellen Sie sicher, dass der Status des Clients mit dem des Servers synchronisiert ist.

288
cdhowie

Stream Socket:

  • Dedizierter und durchgehender Kanal zwischen Server und Client.
  • Verwenden Sie TCP Protokoll zur Datenübertragung.
  • Zuverlässig und verlustfrei.
  • Daten gesendet/empfangen in der gleichen Reihenfolge.
  • Lange Zeit für die Wiederherstellung verlorener/fehlerhafter Daten

Datagramm-Sockel:

  • Kein dedizierter und durchgehender Kanal zwischen Server und Client.
  • Verwenden Sie UDP für die Datenübertragung.
  • Nicht 100% zuverlässig und kann Daten verlieren.
  • Die gesendeten/empfangenen Daten stimmen möglicherweise nicht überein.
  • Es ist egal, oder schnell, verlorene/fehlerhafte Daten wiederherzustellen.
26

Wenn es die Netzwerkprogrammierung ist, denke ich, wäre es ein guter Anfang, von Sockets aus zu starten.
Socket = IP + Port
Es gibt drei Arten von Steckdosen
Stream (TCP, Bestellung und Lieferung garantiert, keine Vervielfältigung, keine Länge oder Zeichengrenzen für Daten, verbindungsorientiert, zuverlässig, Parallelität)
Datagramm (UDP, paketbasiert, verbindungslos, Datagrammgrößenbeschränkung, Daten können verloren gehen oder dupliziert werden, Reihenfolge nicht garantiert, nicht zuverlässig)
raw (direkter Zugriff auf IP- und ICMP-Protokolle der unteren Ebene)
Ich sehe keine strikte Regel für den Transportprotokolltyp, welcher Socket welches Transportprotokoll verwenden muss, und die Zuverlässigkeit sollte nicht verwechselt werden, da UDP realisierbar ist, wenn beide Enden aktiv sind.
Zuverlässigkeit bezieht sich eher auf die Zuverlässigkeit der Zustellung, da Sequenznummern mit TCP als Transportprotokoll geprüft werden, die in UDP nicht vorhanden sind. Es ist besser, einen Netzwerkprotokollanalysator wie wireshark zu verwenden tcpdump etc, um zu sehen, was Ihre Software genau macht: Art der Überprüfung oder Zusammenführung der Theorie auf dem Papier mit Ihrer Arbeit in Aktion.

0
hakkican