В чем разница между потоками и дейтаграммами в сетевом программировании?

Question

В чем разница между сокетами (потоком) и сокетами (дейтаграммы)? Зачем использовать один над другим?

Answer 1

Давным-давно я прочел отличную аналогию для объяснения разницы между ними. Я не помню, где я его читал, поэтому, к сожалению, я не могу отдать должное автору за эту идею, но я также добавил много своих собственных знаний в основную аналогию. Итак, здесь идет:

Сокет потока похож на телефонный звонок - одна сторона помещает вызов, другая отвечает, вы говорите привет друг другу (SYN/ACK в TCP), а затем вы обмениваетесь информацией. Как только вы закончите, вы попрощались (FIN/ACK в TCP). Если одна сторона не слышит прощание, они обычно называют другую, так как это неожиданное событие; обычно клиент будет подключаться к серверу. Существует гарантия того, что данные не поступят в другом порядке, чем вы его отправили, и есть разумная гарантия того, что данные не будут повреждены.

Сокет datagram как передача заметки в классе. Рассмотрите случай, когда вы не находитесь непосредственно рядом с человеком, которому вы передаете примечание; записка будет перемещаться от человека к человеку. Он может не дойти до места назначения, и к моменту его поступления он может быть изменен. Если вы передадите две заметки одному и тому же лицу, они могут прийти в том порядке, который вы не намеревались, поскольку маршрут, который ноты проходят через класс, может быть не таким, один человек может не передавать заметку так же быстро, как другой, и т. Д. .

Таким образом, вы используете сокет потока, когда информация имеет порядок и неповрежденность. Хорошим примером здесь являются протоколы передачи файлов. Вы не хотите загружать некоторый файл с его содержимым, случайным образом перетасованным и поврежденным!

Вы должны использовать сокет datagram, если заказ менее важен, чем своевременная доставка (подумайте о VoIP или игровых протоколах), когда вам не нужны более высокие накладные расходы потока (именно поэтому DNS является главным образом протоколом дейтаграммы, так что серверы могут реагировать на многие, многие запросы сразу очень быстро) или когда вам неинтересно, если данные когда-либо добираются до места назначения.

Чтобы расширить сферу действия VoIP/игры, такие протоколы включают в себя собственный механизм упорядочения данных. Но если один пакет поврежден или потерян, вы не хотите ждать по протоколу потока (обычно TCP) для выдачи запроса на повторную отправку - вам нужно быстро восстановить. Для восстановления TCP может потребоваться некоторое количество минут, а для протоколов реального времени, таких как игры или VoIP, даже три секунды, может быть неприемлемым! Использование протокола датаграмм, такого как UDP, позволяет программному обеспечению быстро восстанавливаться с такого события, просто игнорируя потерянные данные или повторно запрашивая его раньше, чем TCP.

VoIP является хорошим кандидатом для простого игнорирования утраченных данных - одна сторона просто услышала бы короткий пробел, подобный тому, что происходит при разговоре с кем-то на сотовом телефоне, когда у них плохой прием. Игровые протоколы часто немного сложнее, но предпринимаемые действия обычно состоят в том, чтобы либо игнорировать отсутствующие данные (если впоследствии полученные данные перечеркнули потерянные данные), повторно запросить отсутствующие данные или запросить полное обновление состояния убедитесь, что состояние клиента синхронизировано с сервером.

Answer 2

поток Цоколь:

• Выделенный & точка-точка канала между сервером и клиентом.
• Используйте протокол TCP для передачи данных.
• Надежный и без потерь.
• Данные, отправленные/полученные в аналогичном порядке.
• Долгое время для восстановления потерянных/ошибочных данных

Datagram Разъем:

• Нет выделенного канала & точка-точка между сервером и клиентом.
• Используйте UDP для передачи данных.
• Не на 100% надежно и может потерять данные.
• данных переданных/принятых порядок не может быть такой же
• Не заботьтесь или быстрого восстановления утерянных/ошибочные данные