TCP-поток против UDP-сообщения

TCP ориентирован на поток, поскольку данные передаются как продолжающийся поток байтов. Но меня смущает то, что TCP создает сегменты и передает это значение IP. IP создает пакеты, инкапсулирует сегменты и передает их. Итак, где именно сплошной поток здесь?

UDP, с другой стороны, ориентирован на сообщения. Он получает сообщения с прикладного уровня, создает датаграммы и переносит их на IP. Пока это то же самое, что и TCP, вместо этого дейтаграмма создана и нажата. Что делает этот протокол ориентированным на сообщения?

Ответ 1

Интерфейс/API, представленный вам пользователем (программистом) этих протоколов:

UDP

На основе сообщений, у вас есть API (send/recv и т.д.), которые предоставляют вам возможность отправлять одну дейтаграмму и получить одну дейтаграмму. 1 отправить() результаты вызова в 1 датаграмме отправлено, а 1 вызов recv() получит ровно 1 датаграмму.

TCP

С потоком, у вас есть API (send/recv и т.д.), который дает вам возможность отправлять или получать поток байтов. Существует не сохранение границ сообщений, TCP может объединить данные из многих вызовов send() в один сегмент или может разбивать данные из одного вызова send() на многие сегменты, но это прозрачно для приложений, сидящих поверх TCP, и recv() просто возвращает вам данные без какого-либо отношения к тому, сколько вызовов send() выдает данные, которые вы возвращаете.

Ответ 2

TCP ориентирован на поток, поскольку он способен собирать данные в смежном формате. Например. у вас были данные от 1 до 4000 байт. Теперь он будет разделен на сегменты tcp, где каждый сегмент будет иметь порядковый номер, скажем, сначала 1-1200 байт, второй - 1201 - 2400 и т.д.

Он может быть доставлен не в порядке при отправке через ip-дейтаграммы, но собирается в смежные данные, находящиеся там, появляясь в виде потока. Номер последовательности помогает переупорядочить пакеты.

Немного более глубокое объяснение:

Байт-поток состоит из одного большого фрагмента данных без сегментов или другие нарушения. С помощью дейтаграмм (меньше) отправляются данные и получил сразу в целом. На практике это означает, что с датаграммы каждый вызов отправки/записи отправляет один пакет, а каждый read/recv вызов получает один пакет, тогда как с протоколом потока данные могут быть отправлять и получать в любом случае. Например. Отправитель может вызвать send() десять раз, в то время как приемник получает все эти данные с одним вызовом recv. С datagrams десять отправленных вызовов означает десять пакетов и десять вызовов приема

Дейтаграммы и потоки

Байт-потоки

Ответ 3

TCP - это протокол, ориентированный на соединение, означающий, что он сначала устанавливает соединение с получателем, а затем отправляет данные в сегменты (PDU для транспортного уровня), которые переносятся IP-пакетами. Таким образом, он называется потоком, потому что он сохраняет поток данных между концами во время переноса.

UDP - это транспортный протокол без подключения (как IP) с модулем данных, называемым дейтаграммой. Таким образом, в отличие от tcp, UDP передает данные, не настраивая соединение, просто отправляя сообщения дейтаграмм на IP-уровень для передачи.

Ответ 4

Особенность TCP заключается в том, что это поведение является прозрачным для пользователя, соответственно. приложение.

Единственное, что нужно сделать, это вызвать send() и recv() для отправки и получения данных.

Нижеследующие уровни гарантируют, что данные будут получены точно в том порядке, в котором они были отправлены, и что отсутствующие данные повторно передаются, если он "остается отсутствующим".

UDP, OTOH, хранит данные одного вызова send() вместе, даже если он разделен на несколько IP-пакетов. Таким образом, эти данные можно рассматривать как одну дейтаграмму.

Ответ 5

Здесь много путаницы. Позвольте мне уточнить.

TCP/IP - это протокол, ориентированный на поток, пакет и соединение. UDP - это просто пакетно-ориентированный протокол. Сначала не устанавливается соединение.

Допустим, вы используете Java-программу для подключения к сети в своем приложении, вызывая класс java.net.Socket на стороне клиента и java.net.ServerSocket на стороне сервера. Как только соединение установлено, начинается передача данных. Возникает вопрос, данные отправляются в потоке (Codata или бесконечный поток) или пакет, если я выбрал TCP? Ответ - данные, полученные методом TCP, являются потоком, но TCP преобразует поток в пакет перед отправкой стека нижнего уровня. По существу, вышеприведенный прикладной уровень отправляет данные в потоке на уровень TCP, а TCP разбивает их на пакеты для сетевого уровня и выполняет потоковую передачу пакетов при приеме со стороны сервера (получателя), поскольку Java вашего приложения может понимать только Ручей. Передача файлов предпочтительнее по TCP, а не по UDP, потому что вы не можете позволить себе потерять пакеты.

UDP, с другой стороны, является пакетно-ориентированным протоколом, где приложение, такое как класс Java, java.net.DatagramPacket; java.net.DatagramPacket; import java.net.DatagramsSocket сначала создает пакет, прежде чем разговаривать с UDP, и пакет отправляется с дополнительной информацией по протоколам UDP/IP на сторону сервера. Обратите внимание, что некоторые приложения могут представлять данные в виде потока, если основным протоколом является UDP. Однако это уровень дополнительного протокола поверх UDP, и он не является чем-то присущим самому протоколу UDP. Прямая трансляция телевидения обычно осуществляется по протоколу UDP, поскольку вы не беспокоитесь о потере пакетов.

Ответ 6

TCP и UDP оба являются протоколами транспортного уровня, оба обеспечивают процесс для обработки доставки (клиент-сервер), но они сильно отличаются друг от друга тем, как они предоставляют свои услуги. основное различие между UDP и TCP заключается в; UDP предоставляет сервис без установления соединения, тогда как TCP предоставляет сервисы, ориентированные на соединение.

вот почему TCP надежен, а теперь почему мы назвали TCP потоковым протоколом?

Как мы все знаем, протокол TCP отслеживает передаваемые или принимаемые сегменты, поэтому он надежен, но все же, если вы видите заголовок сегмента TCP, в заголовке сегмента нет поля для значения номера сегмента. Вместо этого есть два поля, которые называются порядковым номером и номером подтверждения. Эти два поля относятся к номеру байта, а не к номеру сегмента.

Номер байта: TCP нумерует все байты данных (октеты), которые передаются в соединении. Нумерация независимы в каждом направлении. Когда TCP получает байты данных от процесса, TCP сохраняет их в буфере отправки и нумерует их. Нумерация не обязательно начать с 0. Вместо этого TCP выбирает произвольное число от 0 до ((2) ** 32) - 1 для номер первого байта. Например, если число оказывается 1,057 и общее количество отправляемых данных составляет 6000 байтов, байты пронумерованы от 1 057 до 7 056.

Порядковый номер: После того, как байты были пронумерованы, TCP назначает порядковый номер каждому сегменту это отправляется. Порядковый номер для каждого сегмента является номером первого байта данных, переносимых в этом сегменте.

Предположим, TCP-соединение передает файл размером 5000 байт. Первый байт пронумерован 10,001. Каковы порядковые номера для каждого сегмента, если данные отправляются в пяти сегментах, каждый из которых содержит 1000 байтов?

TCP_segments

Сегмент 1 → Порядковый номер: 10 001 Диапазон: от 10 001 до 11 000 Сегмент 2 → Порядковый номер: 11 001 Диапазон: от 11 001 до 12 000 Сегмент 3 → Порядковый номер: 12 001 Диапазон: от 12 001 до 13 000 Сегмент 4 → Порядковый номер: 13 001 Диапазон: от 13 001 до 14 000 Сегмент 5 → Порядковый номер: 14 001 Диапазон: от 14 001 до 15 000

По этой причине мы назвали TCP протоколом, управляемым потоком, потому что он отслеживает все отправленные или полученные байты и подтверждает все сегменты.

тогда как почему мы назвали UDP протоколом, ориентированным на сообщения?

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

более подробно читайте главу 14 и № 15 набора протоколов TCP/IP от Бехруза А. Форузана

Надеюсь это поможет!