Jaka jest różnica między strumieniami i datagramami w programowaniu sieciowym?

Question

Jaka jest różnica między gniazdami (strumieniem) a gniazdami (datagramami)? Dlaczego warto korzystać z jednego na drugim?

Answer 1

Dawno temu czytałem świetną analogię do wyjaśnienia różnicy między tymi dwoma. Nie pamiętam, gdzie to czytałem, więc niestety nie mogę przyznać autorowi pomysłu, ale i tak dodałem do mojej rdzennej analogii sporo mojej wiedzy. Więc tutaj:

Gniazdo strumieniowe jest jak połączenie telefoniczne - jedna strona nawiązuje połączenie, inne odpowiedzi, przywitasz się ze sobą (SYN/ACK w TCP), a następnie wymieniasz informacje. Gdy skończysz, pożegnasz się (FIN/ACK w TCP). Jeśli jedna ze stron nie usłyszy pożegnania, zwykle wywoła drugą, ponieważ jest to nieoczekiwane zdarzenie; zazwyczaj klient ponownie łączy się z serwerem. Istnieje gwarancja, że ​​dane nie dotrą w innej kolejności niż wysłana, i istnieje uzasadniona gwarancja, że ​​dane nie zostaną uszkodzone.

Gniazdo datagramowe przypomina przekazywanie notatki w klasie. Rozważ przypadek, w którym nie jesteś bezpośrednio obok osoby, do której przekazujesz notatkę; notatka będzie podróżować od osoby do osoby. Może nie dotrzeć do miejsca docelowego i może zostać zmodyfikowany do czasu, kiedy się tam dostanie. Jeśli przekażesz dwie notatki tej samej osobie, mogą pojawić się w zamówieniu, którego nie zamierzałeś, ponieważ trasa, którą przechodzą notatki w klasie, może nie być taka sama, jedna osoba może nie przesłać notatki tak szybko, jak inna, itd.

Używasz więc gniazda strumieniowego, gdy ważne są informacje w porządku i nienaruszone. Protokoły przesyłania plików są tutaj dobrym przykładem. Nie chcesz pobrać jakiegoś pliku z jego zawartością losowo przetasowaną i uszkodzoną!

Używałbyś gniazda datagramowego, gdy zamówienie jest mniej ważne niż dostarczanie w odpowiednim czasie (pomyśl o protokołach VoIP lub protokołach gier), gdy nie chcesz wyższego narzutów strumienia (dlatego DNS jest przede wszystkim protokołem datagramowym, aby serwery mogły szybko odpowiadać na wiele, wiele próśb) lub gdy nie obchodzi ich zbyt wiele, jeśli dane kiedykolwiek dotrą do miejsca przeznaczenia.

Aby rozwinąć w przypadku VoIP/gier, takie protokoły zawierają własny mechanizm zamawiania danych. Ale jeśli jeden pakiet jest uszkodzony lub zagubiony, nie chcesz czekać na protokół strumienia (zwykle TCP), aby wysłać żądanie ponownego wysłania - musisz szybko odzyskać. Aby odzyskać protokół TCP, może minąć kilka minut, a dla protokołów czasu rzeczywistego, takich jak gry lub VoIP, nawet trzy sekundy mogą być niedopuszczalne! Korzystanie z protokołu datagramowego, takiego jak UDP, pozwala oprogramowaniu bardzo szybko odzyskać dane z takiego zdarzenia, po prostu ignorując utracone dane lub ponownie żądając go wcześniej niż TCP.

VoIP jest dobrym kandydatem do po prostu ignorowania utraconych danych - jedna strona usłyszałaby tylko krótką przerwę, podobną do tego, co dzieje się podczas rozmowy z kimś na telefonie komórkowym, gdy ma słaby odbiór. Protokoły gier są często nieco bardziej skomplikowane, ale najczęściej podejmowane działania polegają albo na zignorowaniu brakujących danych (jeśli później odebrane dane zastępują dane, które zostały utracone), ponownym zażądaniu brakujących danych, albo zażądaniu pełnej aktualizacji stanu do upewnij się, że stan klienta jest zsynchronizowany z serwerem.

Answer 2

Stream Gniazdo:

• Dedykowane & punkt-punkt kanał między serwerem a klientem.
• Użyj protokołu TCP do transmisji danych.
• Niezawodny i bezstratny.
• Dane wysyłane/odbierane w podobnej kolejności.
• Dawno do odzyskiwania utraconych/dane błędne

Datagram socket:

• Nie dedykowany & punkt-punkt kanał między serwerem a klientem.
• Użyj UDP do transmisji danych.
• Nie jest w 100% niezawodny i może utracić dane.
• danych wysłanych/odebranych zamówienie nie może być taka sama
• Nie obchodzi mnie czy szybkiego odzyskiwania utraconych/dane błędne