Давным-давно я прочитал замечательную аналогию для объяснения различий между ними. Я не помню, где я его читал, поэтому, к сожалению, я не могу отдать должное автору за идею, но я все равно добавил много своих собственных знаний в основную аналогию. Итак, вот так:
Потоковая розетка похожа на телефонный звонок - одна сторона отвечает на вызов, другая отвечает, вы здороваетесь друг с другом (SYN / ACK в TCP), а затем вы обмениваетесь информацией. Когда вы закончите, вы попрощаетесь (FIN / ACK в TCP). Если одна сторона не слышит прощания, она обычно перезванивает другой, так как это неожиданное событие; обычно клиент переподключается к серверу. Существует гарантия того, что данные не будут доставлены в другом порядке, чем вы их отправили, и есть разумная гарантия того, что данные не будут повреждены.
Сокет датаграммы похож на передачу заметки в классе. Рассмотрим случай, когда вы не находитесь непосредственно рядом с человеком, которому вы передаете записку; заметка будет путешествовать от человека к человеку. Возможно, он не достигнет своего пункта назначения и может быть изменен к тому времени, когда он туда доберется. Если вы передадите две заметки одному и тому же человеку, они могут поступить в том порядке, который вы не намеревались, поскольку маршрут, по которому проходят заметки через классную комнату, может не совпадать, один человек может пропустить заметку не так быстро, как другой, и т. Д. .
Таким образом, вы используете потоковый сокет, когда важно иметь информацию в порядке и нетронутой. Протоколы передачи файлов являются хорошим примером здесь. Вы не хотите загружать какой-либо файл с его содержимым, случайно перемешанным и поврежденным!
Вы бы использовали сокет дейтаграммы, когда порядок менее важен, чем своевременная доставка (например, протоколы VoIP или игровые протоколы), когда вы не хотите более высоких издержек потока (именно поэтому DNS является в первую очередь протоколом дейтаграмм, поэтому эти серверы могут отвечать на множество запросов одновременно очень быстро) или когда вас не слишком волнует, когда данные когда-либо достигнут пункта назначения.
Для расширения возможностей VoIP / игр такие протоколы включают в себя собственный механизм упорядочения данных. Но если один пакет поврежден или потерян, вам не нужно ждать, пока потоковый протокол (обычно TCP) выдаст запрос на повторную отправку - вам нужно быстро восстановиться. Для восстановления TCP может потребоваться некоторое количество минут, а для протоколов реального времени, таких как игры или VoIP, даже три секунды могут оказаться неприемлемыми! Использование протокола дейтаграмм, такого как UDP, позволяет программному обеспечению очень быстро восстанавливаться после такого события, просто игнорируя потерянные данные или повторно запрашивая их раньше, чем TCP.
VoIP является хорошим кандидатом для простого игнорирования потерянных данных - одна сторона просто услышит короткий разрыв, аналогичный тому, что происходит при разговоре с кем-то по мобильному телефону, когда у них плохой прием. Игровые протоколы часто немного сложнее, но обычно предпринимаются следующие действия: либо игнорировать отсутствующие данные (если полученные впоследствии данные заменяют потерянные), либо повторно запрашивать отсутствующие данные или запрашивать полное обновление состояния для убедитесь, что состояние клиента синхронизировано с состоянием сервера.