В чем разница между сокетами (потоком) и сокетами (дейтаграммами)? Зачем использовать одно вместо другого?
131
В чем разница между сокетами (потоком) и сокетами (дейтаграммами)? Зачем использовать одно вместо другого?
Давным-давно я прочитал отличную аналогию, объясняющую разницу между ними. Я не помню, где я это читал, поэтому, к сожалению, я не могу поверить в идею автора, но я все равно добавил много своих собственных знаний к основной аналогии. Итак, здесь идет:
Потоковый сокет похож на телефонный звонок - одна сторона выполняет звонок, другая отвечает, вы здороваетесь друг с другом (SYN / ACK в TCP), а затем вы обмениваетесь информацией. Как только вы закончите, вы прощаетесь (FIN / ACK в TCP). Если одна сторона не слышит прощания, она обычно перезвонит другой, поскольку это неожиданное событие; обычно клиент повторно подключается к серверу. Есть гарантия, что данные не будут доставлены в порядке, отличном от того, в каком вы их отправили, и есть разумная гарантия, что данные не будут повреждены.
Сокет датаграммы похож на передачу заметки в классе. Рассмотрим случай, когда вы не находитесь непосредственно рядом с человеком, которому передаете записку; записка будет передаваться от человека к человеку. Он может не добраться до места назначения и может быть изменен к тому времени, когда он туда попадет. Если вы передадите две записки одному и тому же человеку, они могут прийти в порядке, в котором вы не планировали, поскольку маршрут, по которому заметки проходят через класс, может быть другим, один человек может передать записку не так быстро, как другой, и т. Д. ,
Таким образом, вы используете сокет потока, когда важна упорядоченность и целостность информации. Протоколы передачи файлов являются здесь хорошим примером. Вы же не хотите скачивать какой-то файл, содержимое которого случайно перемешано и повреждено!
Вы бы использовали сокет датаграммы, когда порядок менее важен, чем своевременная доставка (например, VoIP или игровые протоколы), когда вам не нужны более высокие накладные расходы потока (вот почему DNS в первую очередь является протоколом датаграмм, так что серверы могут отвечать на множество запросов одновременно, очень быстро), или когда вас не слишком заботит, дойдут ли данные до места назначения.
Чтобы расширить возможности VoIP / игр, такие протоколы включают собственный механизм упорядочивания данных. Но если один пакет поврежден или утерян, вы не хотите ждать, пока протокол потока (обычно TCP) выдаст запрос на повторную отправку - вам нужно быстро восстановить. Восстановление TCP может занять некоторое количество минут, а для протоколов реального времени, таких как игры или VoIP, даже три секунды могут быть неприемлемыми! Использование протокола дейтаграмм, такого как UDP, позволяет программному обеспечению очень быстро восстанавливаться после такого события, просто игнорируя потерянные данные или повторно запрашивая их раньше, чем это сделает TCP.
VoIP - хороший кандидат для того, чтобы просто игнорировать потерянные данные - одна сторона просто услышит короткий промежуток времени, аналогично тому, что происходит при разговоре с кем-то по мобильному телефону при плохом приеме. Игровые протоколы часто немного сложнее, но обычно предпринимаемые действия заключаются в игнорировании отсутствующих данных (если полученные впоследствии данные заменяют данные, которые были потеряны), повторный запрос недостающих данных или запрос полного обновления состояния для убедитесь, что состояние клиента синхронизировано с состоянием сервера.
Потоковое гнездо:
Разъем датаграммы:
источник
Если это сетевое программирование, я думаю, что начать с сокетов было бы неплохо.
socket = ip + port
существует три типа
потока сокетов (TCP, порядок и доставка гарантированы, без дублирования, без ограничений длины или символов для данных, ориентированный на соединение, надежный, параллелизм)
дейтаграмма (UDP, на основе пакетов, без установления соединения, дейтаграмма ограничение размера, данные могут быть потеряны или дублированы, порядок не гарантирован, ненадежен)
необработанный (прямой доступ к протоколам нижнего уровня IP, ICMP)
Я не вижу строгих правил для типа транспортного протокола относительно того, какой сокет должен использовать какой транспортный протокол и надежность не должна быть ошибочной, потому что UDP действителен, если оба конца активны.
Надежность больше похожа на надежность доставки, так как существуют проверки порядковых номеров с использованием TCP в качестве транспортного протокола, которых нет в UDP. Лучше использовать анализатор сетевых протоколов, такой как wirehark tcpdump и т. Д., Чтобы увидеть, что именно делает ваше программное обеспечение; своего рода проверка или объединение теории на бумаге с вашей работой в действии.
источник