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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

Потоковое гнездо:

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

Гнездо датаграммы:

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