Протокол UDP. Принцип работы

User Datagram Protocol (UDP) (протокол пользовательских дейтаграмм) - является протоколом стандарта TCP/IP , определенный в стандарте RFC 768, "User Datagram Protocol (UDP)". UDP используется вместо TCP для быстрой и ненадежной транспортировки данных между TCP/IP хостами.

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

Чувствительные ко времени приложения часто используют UDP (видеоданные), так как предпочтительнее сбросить пакеты, чем ждать задержавшиеся пакеты, что может оказаться невозможным в системах реального времени. Также потеря одного или нескольких кадров, при передаче видеоданных по UDP, не так критична, в отличии от передачи бинарных файлов, где потеря одно пакета может привести к искажению всего файла. Еще одним преимуществом протокола UDP является то, что длина заголовка UDP составляет 4 байта, а у TCP протокола - 20 байт.

UDP сообщения инкапсулируются и передаются в IP дейтаграммы.

UDP заголовок

На рисунке показаны поля, присутствующие в UDP заголовке.

• Порт отправителя - в этом поле указывается номер порта отправителя. Предполагается, что это значение задает порт, на который при необходимости будет посылаться ответ. В противном же случае, значение должно быть равным 0. Если хостом-источником является клиент, то номер порта будет, скорее всего, эфемерным. Если источником является сервер, то его порт будет одним из "хорошо известных".
• Порт получателя - это поле обязательно и содержит порт получателя. Аналогично порту отправителя, если клиент - хост-получатель, то номер порта эфемерный, иначе (сервер - получатель) это "хорошо известный порт".
• Длина дейтаграммы - поле, задающее длину всей дейтаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка - 8 байт. Теоретически, максимальный размер поля - 65535 байт для UDP-дейтаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 - 65507 (помимо 8 байт на UDP-заголовок требуется еще 20 на IP-заголовок).
• Контрольная сумма - поле контрольной суммы используется для проверки заголовка и данных на ошибки. Если сумма не сгенерирована передатчиком, то поле заполняется нулями.

Рассмотрим структуру заголовка UDP с помощью сетевого анализатора Wireshark:

UDP порты

Так как на одном и том же компьютере могут быть запущены несколько программ, то для доставки UDP-пакета конкретной программе, используется уникальный идентификатор каждой программы или номер порта.

Номер порта - это условное 16-битное число от 1 до 65535, указывающее, какой программе предназначается пакет.

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

Все номера портов UDP, которые меньше чем 1024 - зарезервированы и зарегистрированы в Internet Assigned Numbers Authority (IANA).
Номера портов UDP и TCP не пересекаются.

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

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

Привет, меня зовут Гленн Фидлер и я приветствую вас в первой статье из моей онлайн-книги “Сетевое программирование для разрабочиков игр”.

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

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

Выбор типа сокетов полностью зависит от жанра игры, которую разрабатываете. В данном цикле статей я буду считать, что вы пишете игру в стиле action - наподобие Halo, Battlefield 1942, Quake, Unreal, CounterStrike, Team Fortress и т.п.

Теперь мы более подробно рассмотрим свойства каждого типа сокетов (учитывая тот факт, что мы разрабатыватаем игру в стиле action), и немного углубимся в детали работы сети интернет. После подробного обзора правильный вариант станет очевиден!

TCP расшифровывается как “transmission control protocol” (протокол контроля передачи), а IP - как “internet protocol”. Вместе они лежат в основе практически всего, что вы делаете в сети, начиная от просмотра веб-страниц и кончая общением в IRC и электронной почтой - все это работает на основе TCP/IP.

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

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

Еще разок - все просто, как обычная запись или чтение из файла. Элементарно, Ватсон!

Но такая простота в обращении совершенно отличается от того, что на самом деле происходит «под капотом», на более низком уровне - уровне протокола IP.

На этом уровне нет понятия соединения - вместо этого отдельные пакеты передаются от одного компьютера к другому. Можно представить этот процесс как передачу записки от одного человека к другому в комнате, полной народу: в конце концов записка попадает к кому надо, но при этом пройдя через множество рук.

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

А что, если мы захотим пересылать информацию между компьютерами не в стиле чтения/записи в файл, а непосредственно отправляя и получая отдельные пакеты?

Что ж, мы можем сделать это, используя UDP. UDP расшифровывается как “user datagram protocol” (протокол пользовательских датаграмм), и он работает поверх IP (как и TCP), но вместо добавления кучи функциональности он представляет собой лишь небольшую надстройку над IP.

Используя UDP, мы можем отослать пакет по определенному IP адресу (к примеру, 112.140.20.10) и порту (к примеру, 52423), и он будет передаваться от компьютера к компьютеру, пока не достигнет цели (или не потеряется по пути).

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

Протокол UDP не гарантирует доставку данных. На практике большинство пакетов, конечно, доходят, но всегда имеются потери около 1-5%, а иногда бывают периоды времени, в которые пакеты вообще не доходят (помните, что между отправителем и получателем могут находиться тысячи компьютеров, на любом из которых что-то может отказать или сломаться).

Также UDP не гарантирует порядок доставки пакетов. Вы можете отправить пять пакетов по порядку - 1, 2, 3, 4, 5 - а прийти они могут совершенно в другом порядке - к примеру, 3, 1, 2, 5, 4. Опять же, на практике, они скорее всего придут в правильном порядке в большинстве случаев, но полагаться на это нельзя!

Наконец, хоть UDP и ничего особо не добавляет к IP, одну вещь он все-таки гарантирует. Если вы пересылаете пакет, то он либо дойдет полностью, либо не дойдет вообще. Так, если вы пересылаете пакет в 256 байт другому компьютеру, то он не может получить только первые 100 байт от пакета - он обязательно должен получить все 256 байт. Это реально единственная вещь, которую гарантирует протокол UDP - все остальное ложится на ваши плечи.

Итак, нам нужно решить - использовать TCP или UDP сокеты? Давайте взглянем на их свойства:

• Использует принцип соединений
• Гарантирует доставку и очередность
• Автоматически разбивает информацию на пакеты
• Следит за тем, чтобы не пересылать данные слишком интенсивно (контроль потока данных)
• Легко использовать - как запись/чтение из файла

UDP:

• Не использует принцип соединений - придется реализовывать это вручную
• Не гарантирует доставку и порядок доставки пакетов - они могут дойти в неправильном порядке, с дубликатами, или вообще не дойти!
• Нужно вручную разбивать данные на пакеты и отправлять их
• Нужно следить за тем, чтобы не пересылать данные слишком интенсивно
• Если пакет потеряется, то нужно как-то это отследить, и в случае необходимости переслать его заново

С таким списком решение кажется очевидным - TCP реализует всю необходимую нам функциональность и его проще использовать, тогда как использование UDP обещает геморрой с написанием всего на свете вручную, с нуля. Значит, используем TCP, да?

А вот и нет.

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

Как работает TCP

TCP и UDP оба работают поверх IP, но по факту они совершенно разные. UDP ведет себя очень похоже на IP, в то время как TCP абстрагирует пользователя от всех проблем с пакетами, делая взаимодействие с ним похожим на чтение/запись в файл.

Итак, как же он это делает?

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

Такое поведение может стать проблемой для нашей многопользовательской игры, если нужно передавать очень маленькие пакеты. Может случиться так, что TCP решит не передавать наши данные, пока их не накопится достаточно, чтобы сформировать пакет определенного размера (скажем, больше ста байт). И это - большая проблема, потому что необходимо передавать данные с клиента (нажатия клавиш игрока) на сервер как можно быстрее, и если при этом будут возникать задержки из-за буферизации данных протоколом, то для игрока на клиентской стороне игра будет происходить далеко не самым приятным образом. При этом обновление объектов игры будет происходить с задержкой и редко - тогда как нам нужно делать обновление объектов вовремя и часто.

В TCP есть опция, призванная исправить это - “TCP_NODELAY”. Она говорит протоколу, чтобы он не ждал накопления данных в очереди на отправку, а отсылал их сразу.

К сожалению, даже с установленной данной опцией, у TCP наблюдается множество проблем при использовании его в сетевых играх.

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

Как TCP обеспечивает надежность соединения

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

Но что будет, если один из пакетов не дойдет? Или если пакеты придут не по порядку, или с дубликатами?

Если особо не углубляться в детали работы TCP (а это реально очень сложная тема - можете почитать в TCP/IP Illustrated), процесс выглядит так: TCP отправляет пакет, определяет, что пакет не дошел, и заново отправляет тот же пакет адресату. Дублирующиеся пакеты отсеиваются на стороне адресата, а пакеты, пришедшие не по порядку - переупорядочиваются, чтобы все было как надо - надежно и по порядку.

Проблема заключается в том, что когда TCP таким образом “синхронизирует” поток данных, в случае потери пакета передача останавливается до тех пор, пока потерянный пакет не будет отправлен заново (и получен адресатом). Если во время ожидания придут новые данные, они будут поставлены в очередь, и вы не сможете прочитать их, пока не дойдет тот самый потерянный пакет. Сколько времени занимает посылка пакета заново? Она занимает как минимум время, равное времени прохождения пакета туда и обратно (когда TCP определяет, какой пакет надо отправить заново), плюс время на повторную доставку потерянного пакета. Так что, если пинг между компьютерами составляет 125 мс, повторная передача пакета займет примерно одну пятую секунды, а в худшем случае - до полсекунды (представьте, если вдруг заново отправленный пакет тоже потеряется). Веселуха!

Почему никогда не стоит использовать TCP для многопользовательских игр

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

Рассмотрим простой пример многопользовательской игры, например, 3d-шутер. Сетевая часть в игре построена очень просто: каждую итерацию цикла игры клиент посылает на сервер описание всех действий игрока (нажатые клавиши, положение мыши и т.п.), и каждую итерацию сервер обрабатывает эти данные, обновляет модель игрового мира и посылает обратно клиенту текущие позиции объектов мира, чтобы тот отрисовал игроку новый кадр.

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

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

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

Но подождите! Почему я не могу использовать и UDP, и TCP вместе?

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

Конечно, велико искушение использовать UDP для передачи данных пользовательского ввода и состояния мира, а TCP - для тех данных, которые должны быть гарантированно доставлены. Возможно, вы даже думаете, что можно сделать несколько “потоков” команд - например, один для загрузки уровней, другой - для команд AI. Вы думаете: “Мне не нужно, чтобы команды AI ждали в очереди, если потеряется пакет с данными для загрузки уровня, ведь они же совершенно не связаны!”. В данном случае вы правы, и вы можете решить создать по TCP сокету на каждый поток команд.

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

На канальном и сетевом уровне протоколов TCP / IP пакета , которые касаются основного механизма передачи блоков данных между странами и между сетями, являются основами TCP / IP . Они используют стек протоколов, но они не используются непосредственно в приложениях, которые работают по протоколу TCP / IP . В этой статье мы рассмотрим два протокола, которые используются приложениями: User Datagram Protocol (UDP) и Transmission Control Protocol (TCP).

Протокол дейтаграммы пользователя
User Datagram Protocol очень простой протокол. Как и IP , это надежный протокол без соединений. Вам не нужно устанавливать соединение с хостом для обмена данными с ним, используя UDP , и не существует механизма для обеспечения передаваемых данных.
Блок данных, передаваемых с помощью UDP называется датаграммой. UDP добавляет четыре 16-битных поля заголовка (8 байт) к передаваемым данным. Эти поля: длина поля, поле контрольной суммы, а также источник и номер порта назначения. «Порт», в этом контексте, представляет собой программное обеспечение порта, а не аппаратный порт.
Концепция номера порта является общей для обоих UDP и TCP . Номера портов определяют, какой модуль протокола направляет (или получает) данные. Большинство протоколов имеют стандартные порты, которые обычно используются для этого. Например, протокол Telnet обычно использует порт 23. Simple Mail Transfer Protocol (SMTP), использует порт 25. Использование стандартных номеров портов позволяет клиентам взаимодействовать с сервером без предварительной установки, какой порт использовать.
Номер порта и протокола в поле в заголовка IP дублируют друг друга в какой-то степени, хотя поля протокола не доступны для протоколов более высокого уровня. IP использует поле протокола, чтобы определить, куда должны быть переданы данные на UDP или TCP модули. UDP или TCP используют номер порта, чтобы определить, какой протокол прикладного уровня, должен получать данные.
Несмотря на то, UDP не является надежным, он все еще подходящий выбор для многих приложений. Он используется приложениями в реальном времени, такими как потоковое аудио и видео, где, если данные будут потеряны, то лучше обойтись без него, чем отправить его снова по порядку. Он также используется протоколами, такими как Simple Network Management Protocol (SNMP).
Трансляция
UDP подходит для информационного вещания, поскольку он не требует подключения к открытой связи.Цели широковещательного сообщения определяются отправителем, на указанный в IP-адрес назначения. UDP датаграммы с адресом назначения IP все бинарные 255.255.255.255) и будет получен каждый хост в локальной сети. Обратите внимание на слово местные: дейтаграммы с таким адресом не будут приняты маршрутизатором к Интернету.
Передачи могут быть направлены на конкретные сети. UDP датаграммы с хоста и подсети части IP-адреса, установленные как бинарные транслируются на все узлы на всех подсетях сети, которая соответствует чистой части IP-адреса. Если только принимающая сторона (другими словами, все биты, которые равны нулю в маске подсети) устанавливается в бинарные, то вещание ограничено для всех хостов в подсети, который соответствует остальной части адреса.
Многоадресная рассылка используются для передачи данных в группе хостов, которые выразили желание их получать. Многоадресная UDP датаграмма имеет адрес назначения, в котором первые четыре бита 1110, предоставлены адреса в диапазоне 224.xxx в 239.xxx Остальные биты адреса используются для обозначения группы многоадресной рассылки. Это, скорее, как радио-или телеканал. Так, например, 224.0.1.1 используется для протокола NTP. Если TCP / IP приложения хотят получить многоадресное сообщение, они должны присоединиться к соответствующей группе многоадресной рассылки, что он и делает, передавая адрес группы в стек протоколов.
Широкое вещание, по сути, фильтруют передачу. Multicaster не рассматривает индивидуальные сообщения для каждого хоста, который присоединяется к группе. Вместо этого, сообщения в эфир, и драйвера на каждом хосте решают, следует ли игнорировать их или передать содержимое стеку протоколов.
Это означает, что многоадресные сообщения должны транслироваться по всему Интернету, так как multicaster не знает, какие хосты хотят получать сообщения. К счастью, это не является необходимым. IP использует протокол под названием Internet Group Management Protocol (IGMP), чтобы сообщить маршрутизаторам, какие хосты хотят получать сообщения многоадресной группы, так что сообщения отправляются только туда, где они необходимы.
Протокол управления передачей
Transmission Control Protocol является протоколом транспортного уровня и используется большинством интернет-приложений, такими как Telnet, FTP и HTTP. Это протокол с установлением соединения. Это означает, что два компьютера - один клиент, другой сервер и между ними необходимо установить соединение до того, как данные могут передаваться между ними.
TCP обеспечивает надежность. Приложение, которое использует TCP знает, что он отправляет данные полученные на другом конце, и что он получил их правильно. TCP использует контрольные суммы, как на заголовках,так и на данных. При получении данных, TCP посылает подтверждение обратно к отправителю. Если отправитель не получает подтверждения в течение определенного периода времени, данные отправляются повторно.
TCP включает в себя механизмы обеспечения данных, которые поступают в обратной последовательности, в порядке как они были отправлены. Он также реализует управление потоком, так что отправитель не может подавить приемник данных.
TCP передает данные, используя IP, в блоках, которые называются сегментами. Длина отрезка определяется протоколом. В дополнение к IP-заголовку, каждый сегмент состоит из 20 байт заголовка. Заголовок TCP начинается с 16-битного источника и поля назначения номера порта. Как и UDP , эти поля определяют уровень приложения, которые направлены и на получение данных. IP-адрес и номер порта, вместе взятые однозначно идентифицируют службы, работающие на хозяина, и пары известной как гнездо.
Далее в заголовке идет 32-битный порядковый номер. Это число определяет позицию в потоке данных, что должен занимать первый байт данных в сегменте. Порядковый номер TCP позволяет поддерживать поток данных в правильном порядке, хотя сегменты могут быть получены из последовательности.
Следующее поле представляет собой 32-битное поле, которое используется для передачи обратно отправителю, что данные были получены правильно. Если ACK флаг, которым он обычно и бывает, то это поле содержит положение следующего байта данных, что отправитель сегмента ожидает получить.
В TCP нет необходимости для каждого сегмента данных, которые будут признаны. Значение в поле подтверждения интерпретируется как «все данные до сих пор получены ОК». Это экономит полосу пропускания, когда все данные направляются в одну сторону, уменьшая потребность в признании сегментов. Если данные одновременно отправляються в обоих направлениях, как в полной дуплексной связи, то марки не связаны с расходами,так как сегмент передачи данных в одну сторону может содержать подтверждение для данных, передаваемых по-другому.
Далее в заголовке представляется 16-битное поле, содержащее длину заголовка и флаги. TCP заголовки могут содержать дополнительные поля, так что длина может варьироваться от 20 до 60 байт. Флаги: URG, ACK (который мы уже упоминали), PSH, RST, SYN и FIN. Позже,мы рассмотрим некоторые другие флаги.
Заголовок содержит поле, называемое размером окна, что дает количество байт, которые приемник может принять. Также существует 16-битная контрольная сумма, охватывающая как заголовок,так и данные. Наконец (до дополнительных данных) есть поле называемое «указатель срочности». Когда флаг URG установлен, это значение интерпретируется как смещение порядкового номера. Он определяет начало данных в потоке, которые должны быть обработаны в срочном порядке. Эти данные часто называют данными «вне группы». Пример её использования, когда пользователь нажимает клавишу перерыв, чтобы прервать выход из программы во время Telnet сессии.

Говоря о безопасности информации, мы имеем в виду конфиденциальность, целостность и доступность информации в каждый момент времени. И если с конфиденциальностью и доступностью все понятно, то как обеспечить целостность информации при ее передаче по сети? Для решения этой задачи нам пригодится знание сетевых протоколов. В данной статье мы рассмотрим протоколы TCP и UDP. Они входят в стек протоколов TCP/IP, относятся к транспортному уровню модели OSI и используются для передачи информации от узла к узлу.

Что из себя представляет каждый из этих протоколов, в чем их отличие и когда целесообразнее использовать UDP подключение, а когда TCP.

UDP

UDP protocol – протокол, обеспечивающий передачу данных (датаграмм) без предварительного создания соединения между хостами. При отправке датаграмм нет уверенности в существовании получателя и его готовности к обмену. Сетевой протокол UDP не обеспечивает также упорядочивание датаграмм при получении. Он используется приложениями для которых существенное значение имеет время доставки, когда нет возможности ждать задержавшиеся или запрашивать потерянные пакеты, например, в системах реального времени. Датаграммы могут доставляться не в заданном порядке, дублироваться или вовсе не доставляться. Поэтому протокол UDP называют «ненадёжным протоколом датаграмм».

Приложения, использующие протокол UDP не чувствительны к потерям данных, нарушению порядка получения датаграмм и дублированию. При этом они могут использовать механизмы обеспечения надёжности на прикладном уровне.

TCP

Протокол передачи данных TCP – протокол обеспечивающий надежную доставку пакетов данных, он обеспечивает установку соединения между двумя хостами методом «рукопожатия», после которого может осуществляться обмен данными.

Перед началом передачи пакетов через TCP соединение устанавливается сессия с получателем, в рамках которой затем производится передача данных. Это позволяет убедиться в том, что получатель существует и готов принимать данные. После завершения передачи сессия закрывается, получатель извещается о том, что данных больше не будет, а отправитель извещается о том, что получатель извещён.

Каждый пакет при обмене имеет свой порядковый номер. TCP автоматически упорядочивает пакеты, используя порядковый номер, и передает после склейки на уровень приложений. После отправки нескольких пакетов, ожидается подтверждение и порядковый номер следующего пакета. Если подтверждение не получено, отправка повторяется, если попытки не увенчались успехом, сессия разрывается. Количество пакетов данных, на которые будет запрашиваться подтверждение, зависит от надежности сети. Если данные теряются, то подтверждение автоматически запрашивается чаще. Это называется механизмом скользящего окна (sliding window), благодаря которому TCP может работать с сетями, независимо от уровня их надежности.

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

TCP и UDP отличия

Означает ли это, что протокол UDP не стоит использовать? Вовсе нет. За счет отсутствия «гарантии доставки» протокол UDP обеспечивает более высокую скорость передачи данных, чем TCP. По этой причине UDP оптимален для сетевых и онлайн игр, просмотра потокового видео, организации видео-связи и IP телефонии.

Делитесь полезной информацией с близкими.

Все обмены сетевыми процессами, происходящие на компьютерах, описывает общепринятая система OSI. Модель OSI включает в себя семь уровней взаимодействия процессов:

1. Физический. Среда распространения сигнала (кабель или радиосигналы);
2. Канальный. Указывает на формат данных, где информация преобразуется в кадры и регулируется распространенным протоколом Ethernet;
3. Сетевой. Определяет способы маршрутизации;
4. Транспортный. Осуществляет передачу данных посредством протоколов TCP, UDP и т.д.;
5. Сеансовый. Обеспечивает поддержку во время сеанса связи;
6. Представительский. Осуществляет подготовку данных для последующей передачи по сети (конверсия, распаковка, дешифровка);
7. Прикладной. Контролирует взаимодействие различных пользовательских приложений с сетевыми службами.

Для передачи данных между двумя устройствами в различных сетях Интернета используется комплект протоколов TCP/IP. Транспортировку данных в стеке TCP/IP могут осуществлять различные протоколы, в том числе TCP и UDP.

Характеристика TCP

Протокол TCP представляет собой поток информации в виде виртуального канала между узлами с обязательным заранее установленным соединением. Используется для надежной передачи больших объемов информации между сетевыми устройствами.

Для обеспечения надежного соединения в TCP предусмотрена трехэтапная процедура начала сеанса связи. При этом у сервера и клиента запрашивается значение порта и значение ISN. В пакете TCP обязательно присутствует контрольная сумма, которая определяет правильность передачи информации.

Характеристика UDP

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

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

Принципиальные отличия TCP и UDP

Функции	UDP	TCP
Процедура установки соединения	Не требуется	Обязательная трехэтапная процедура начала сеанса связи
Гарантированный обмен трафиком	Пакеты могут теряться	Подтверждение и повторная передача исключают потерю данных
Сохранение порядка доставки сообщений	Неупорядоченные датаграммы	Строгая очередность пересылаемых пакетов
Контроль и управление потоком	Не контролируется передача пакетов данных	Контролирует и управляет потоком данных
Уведомляет о перегрузках	Не защищен от перегрузок	Уведомляет о перегрузках
Сохраняет границы передаваемых сообщений	Всегда сохраняет границы пересылаемых датаграмм	Не сохраняет границы пересылаемых сообщений, но гарантирует их целостность
Сегментация и сборка информационных пакетов	Нет	Поддерживается
Взаимодействия с полуоткрытыми соединениями	Повторная синхронизация не происходит	Соединение осуществляется посредством повторной синхронизации
Проверка достижимости	Нет	Да