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


131

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

Ответы:


304

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

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

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

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

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

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

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


3
Просто превосходно для детализации SYNACK.
LazerSharks

2
Этот или очень похожий пример взят из интерфейса программирования Linux. Издание 2010 года содержит эти примеры на страницах 1155 и 1159.
Джош

30

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

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

Разъем датаграммы:

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

Разве данные не отправляются в одном и том же порядке (а не просто в «похожем»)? то есть. было бы бессмысленно встраивать механизм упорядочивания пакетов в потоковый сокет
Мэтью Д. Шолфилд

Пакеты в потоковой передаче отправляются и принимаются в «похожем» порядке в том смысле, что сами пакеты НЕ гарантированно будут доставлены принимающему хосту по порядку, но TCP обнаруживает несоответствия, переупорядочивая пакеты по мере их поступления и запрашивая что-либо который, кажется, заблудился по пути.
Алехандро Бласко

В этом есть смысл. Может быть, просто удалите это как разницу и поместите ниже (поскольку, если я правильно это понимаю, когда речь идет только о порядке, в котором отправляются пакеты, в обоих случаях порядок отправки / получения данных может не быть тот же самый).
Мэтью Д. Сколфилд

@Rick Точнее, сокеты известны как сквозные точки, потому что транспортные протоколы отвечают за доставку сообщений к одной или нескольким конечным точкам сети.
Алехандро Бласко

0

Если это сетевое программирование, я думаю, что начать с сокетов было бы неплохо.
socket = ip + port
существует три типа
потока сокетов (TCP, порядок и доставка гарантированы, без дублирования, без ограничений длины или символов для данных, ориентированный на соединение, надежный, параллелизм)
дейтаграмма (UDP, на основе пакетов, без установления соединения, дейтаграмма ограничение размера, данные могут быть потеряны или дублированы, порядок не гарантирован, ненадежен)
необработанный (прямой доступ к протоколам нижнего уровня IP, ICMP)
Я не вижу строгих правил для типа транспортного протокола относительно того, какой сокет должен использовать какой транспортный протокол и надежность не должна быть ошибочной, потому что UDP действителен, если оба конца активны.
Надежность больше похожа на надежность доставки, так как существуют проверки порядковых номеров с использованием TCP в качестве транспортного протокола, которых нет в UDP. Лучше использовать анализатор сетевых протоколов, такой как wirehark tcpdump и т. Д., Чтобы увидеть, что именно делает ваше программное обеспечение; своего рода проверка или объединение теории на бумаге с вашей работой в действии.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.