Вопрос 4 какой из протоколов используется для пересылки отдельных датаграмм

Обновлено: 19.05.2024

· Сетевой уровень является самым низким уровнем модели TCP / IP.

· Сетевой уровень - это комбинация физического уровня и уровня канала передачи данных, определенных в эталонной модели OSI.

· Он определяет, как данные должны передаваться физически через сеть.

· Этот уровень в основном отвечает за передачу данных между двумя устройствами в одной сети.

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

· Протоколы, используемые этим уровнем: Ethernet, Token Ring, FDDI, X.25, Frame Relay.

Интернет-слой

Интернет-уровень - это второй уровень модели TCP / IP.

Уровень Интернета также известен как сетевой уровень.

Основная ответственность интернет-уровня - отправлять пакеты из любой сети, и они прибывают в пункт назначения независимо от маршрута, который они выбирают.

Ниже приведены протоколы, используемые на этом уровне:

Протокол IP : протокол IP используется на этом уровне, и он является наиболее важной частью всего пакета TCP / IP.

Ниже приведены обязанности этого протокола:

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

2) Связь между хостами: определяет путь, по которому должны передаваться данные.

3) Инкапсуляция и форматирование данных.

5) Маршрутизация: когда IP-дейтаграмма отправляется по одной и той же локальной сети, такой как LAN, MAN, WAN, это называется прямой доставкой. Когда источник и пункт назначения находятся в удаленной сети, IP-дейтаграмма отправляется косвенно. Это может быть достигнуто путем маршрутизации дейтаграммы IP через различные устройства, такие как маршрутизаторы.

Протокол ARP

· ARP означает Протокол разрешения адресов.

· ARP - это протокол сетевого уровня, который используется для поиска физического адреса по IP-адресу.

Два термина в основном связаны с протоколом ARP:

· Запрос ARP: когда отправитель хочет узнать физический адрес устройства, он передает запрос ARP в сеть.

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

Протокол ICMP

ICMP расшифровывается как Internet Control Message Protocol.

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

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

Протокол ICMP в основном использует два термина:

· Тест ICMP: Тест ICMP используется для проверки доступности пункта назначения или нет.

· ICMP Reply: ICMP Reply используется для проверки, отвечает ли целевое устройство или нет.

Основная обязанность протокола ICMP - сообщать о проблемах, а не исправлять их. Ответственность за исправление лежит на отправителе.

Транспортный уровень

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

На транспортном уровне используются два протокола: протокол дейтаграмм пользователя и протокол управления передачей.

Протокол пользовательских дейтаграмм (UDP)

Это обеспечивает обслуживание без установления соединения и сквозную доставку передачи.

Это ненадежный протокол, поскольку он обнаруживает ошибки, но не указывает на ошибку.

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

· Общая длина: определяет общее количество байтов пользовательской дейтаграммы в байтах.

· Контрольная сумма: контрольная сумма - это 16-битное поле, используемое для обнаружения ошибок.

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

Протокол управления передачей (TCP)

· Предоставляет приложениям полный сервис транспортного уровня.

· Создает виртуальный канал между отправителем и получателем и активен на время передачи.

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

На принимающей стороне TCP собирает все сегменты и упорядочивает их на основе порядковых номеров.

Уровень приложений

Прикладной уровень является самым верхним уровнем в модели TCP / IP.

Он отвечает за обработку протоколов высокого уровня.

Этот уровень позволяет пользователю взаимодействовать с приложением.

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

Ниже приведены основные протоколы, используемые на уровне приложений:

2) SNMP: SNMP означает простой протокол управления сетью. Это платформа, используемая для управления устройствами в Интернете с помощью набора протоколов TCP / IP.

3) SMTP: SMTP означает простой протокол пересылки почты. Протокол TCP / IP, поддерживающий электронную почту, называется протоколом простой передачи почты. Этот протокол используется для отправки данных на другой адрес электронной почты.

4) DNS: DNS обозначает систему доменных имен. IP-адрес используется для уникальной идентификации подключения хоста к Интернету. Но люди предпочитают использовать имена вместо адресов. Поэтому система, которая сопоставляет имя с адресом, называется Системой доменных имен.

5) Телнет: это сокращение от терминальной сети. Он устанавливает соединение между локальным компьютером и удаленным компьютером таким образом, чтобы локальный терминал представлял собой терминал в удаленной системе.

6) FTP: FTP означает протокол передачи файлов. FTP - это стандартный интернет-протокол, используемый для передачи файлов с одного компьютера на другой.

Кратко

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

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

Как понять

Протоколы транспортного уровня используются для передачи данных по сети. Данные передаются в виде пакетов установленного размера. Протокол TCP (Transmission Control Protocol) формирует поток передачи данных, предварительно установив соединение. Если часть данных потеряно, то протокол автоматически повторно запрашивает утерянные данные и передаёт их от отправителя к получателю. TCP также устраняет дубликаты и информирует отправителя о результате передачи. Протокол UDP (User Datagram Protocol) не предоставляет таких гарантий, не требует установления соединения — просто пересылает пакеты с данными на адрес сетевого узла. Рассмотрим оба протокола с точки зрения взаимодействия клиента (сетевого узла, на котором работает браузер) и сервера.

Протокол TCP

Любое TCP-соединение начинается с установления соединения. Этот процесс называется рукопожатием (handshake). Перед тем как соединение между клиентом и сервером будет установлено, они должны согласовать стартовую последовательность чисел, с которой начинается передача данных. Последовательность чисел уникальна для каждого соединения. В TCP рукопожатие проходит в три этапа:

Отправитель генерирует случайное число x и передаёт его получателю в пакете SYN (от Sequence number). В этом же пакете могут указываться какие-то специальные флаги для настройки соединения.
Получатель прибавляет к числу x единицу и генерирует своё число y. После этого получатель посылает отправителю числа x + 1 и y в пакете SYN ACK (от Acknowledgment Number).
Завершающим этапом является передача пакета ACK отправителем с числами x + 1 и y + 1.

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

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

Если возникла необходимость использования TCP Fast Open, необходимо настроить, что именно нужно отправлять. Это может быть критический CSS или JavaScript, а может быть и часть страницы. Браузеры на движке Chromium давно уже использует технологию Critical Rendering Path, с помощью которой браузер начинает рисовать страницу до того момента, когда получит весь HTML, CSS и JavaScript. Сейчас эту технологию поддерживает Internet Explorer, Firefox и Safari. Можно использовать Critical Rendering Path для более быстрой отрисовки страницы для пользователей этих браузеров, а это — подавляющее число пользователей.

TCP Fast Open поддерживается на уровне операционной системы (Chrome OS, Android, Linux с ядром v.4.1+, FreeBSD v.10.3+, iOS v.9+, macOS v10.11+, Windows v.10+) или браузера (Google Chrome и другие на основе Chromium, Firefox v.58+) на клиенте и на уровне операционной системы на сервере. В среднем загрузку сайта можно ускорить на 10-15%.

Протокол UDP

Центральным понятием протокола UDP является датаграмма (datagram). Это блок данных, который передаётся от отправителя к получателю без предварительной процедуры установления соединения и создания канала связи. Датаграмма — это пакет, в заголовках которого отсутствует информация:

Подтверждающая факт доставки пакета получателю.
Определяющая место пакета в изначальной последовательности данных.
О наличии соединения между отправителем и получателем.
О загруженности канала передачи данных.

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

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

Кажется, что в некоторых приложениях это хороший способ оптимизации трафика, но есть и проблемы при передачи датаграмм. Проблему нехватки IP-адресов решают путём отделения внутренних сетей от публичных IP-адресов сети интернет с помощью Network address translation (NAT). NAT — это специальный протокол, который при переходе из одной сети к другой подменяет сетевой адрес, сохраняя данные. Решение одной проблемы порождает другие, в частности, проблемы с передачей UDP трафика.

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

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

Решение указанных проблем заключается в применении вспомогательных протоколов Session Traversal Utilities for NAT (STUN) и Traversal Using Relays around NAT (TURN). STUN запоминает публичный (уникальный в сети интернет) сетевой адрес последнего узла, который стоит перед получателем. Это позволяет избежать проблем потери пакетов и переадресации их на получателя с тем же адресом. TURN позволяет установить соединение между двумя узлами NAT через промежуточный сервер. Это закрепляет путь прохождения пакетов, и они не теряются.

Сравнение TCP и UDP

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

Надёжность передачи данных.
Упорядоченность данных.
Громоздкость процедуры пересылки данных.
Организация пересылки в виде потока.
Контроль перегрузок канала передачи данных.

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

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

UDP подходит для целей, в которых проверка и исправление ошибок либо не нужны, либо выполняются в приложении; UDP позволяет избежать накладных расходов на такую обработку в стек протоколов. Чувствительные ко времени приложения часто используют UDP, потому что отбрасывание пакетов предпочтительнее, чем ожидание пакетов, задержанных из-за ретрансляция, что не может быть вариантом в система реального времени. [1]

Содержание

Атрибуты

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

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

Порты

Структура дейтаграммы UDP

Дейтаграмма UDP состоит из дейтаграммы заголовок и данные раздел. Заголовок дейтаграммы UDP состоит из 4 полей, каждое из которых имеет размер 2 байта (16 бит). [1] Раздел данных следует за заголовком и представляет собой данные полезной нагрузки, переносимые для приложения.

Использование контрольная сумма и исходный порт поля являются необязательными в IPv4 (розовый фон в таблице). В IPv6 только исходный порт поле не является обязательным.

Расчет контрольной суммы

Метод, используемый для вычисления контрольной суммы, определен в 768:

Контрольная сумма - 16-битная дополнение суммы дополнений до единицы псевдозаголовка информации из заголовка IP, заголовка UDP и данных, дополненных нулевыми октетами в конце (при необходимости), чтобы сделать их кратными двум октетам. [7]

Другими словами, все 16-битные слова суммируются с использованием дополнительной арифметики. Сложите 16-битные значения. При каждом добавлении, если производится перенос (17-й бит), поверните этот 17-й бит переноса и добавьте его к младшему значащему биту промежуточной суммы. [8] Наконец, сумма затем дополняется, чтобы получить значение поля контрольной суммы UDP.

Если результат вычисления контрольной суммы дает нулевое значение (все 16 битов 0), оно должно быть отправлено как дополнение до единицы (все единицы), поскольку контрольная сумма с нулевым значением указывает, что контрольная сумма не была вычислена. [7] В этом случае никакой специальной обработки на приемнике не требуется, потому что все нули и все единицы равны нулю в арифметике дополнения до единицы.

Разница между IPv4 и IPv6 находится в псевдозаголовке, используемом для вычисления контрольной суммы, и контрольная сумма не является необязательной в IPv6. [9]

Псевдо-заголовок IPv4

Адреса источника и назначения указаны в заголовке IPv4. Протокол такой же, как и для UDP (см. Список номеров IP-протокола): 17 (0x11). Поле длины UDP - это длина заголовка и данных UDP. Поле data обозначает переданные данные.

Вычисление контрольной суммы UDP не является обязательным для IPv4. Если контрольная сумма не используется, ей следует установить нулевое значение.

Псевдо-заголовок IPv6

Когда UDP работает через IPv6, контрольная сумма является обязательной. Метод, используемый для его вычисления, изменен, как описано в 2460:

При вычислении контрольной суммы снова используется псевдозаголовок, который имитирует настоящий заголовок IPv6:

Исходный адрес - это адрес в заголовке IPv6. Адрес назначения - это конечный пункт назначения; если пакет IPv6 не содержит заголовка маршрутизации, это будет адрес назначения в заголовке IPv6; в противном случае на исходном узле это будет адрес в последнем элементе заголовка маршрутизации, а на принимающем узле это будет адрес назначения в заголовке IPv6. Значение поля Next Header - это значение протокола для UDP: 17. Поле длины UDP - это длина заголовка и данных UDP.

Решения по обеспечению надежности и контроля перегрузок

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

Приложения

Многие ключевые интернет-приложения используют UDP, в том числе: система доменных имен (DNS), где запросы должны быть быстрыми и состоять только из одного запроса, за которым следует один пакет ответа, Простой протокол управления сетью (SNMP), Протокол маршрутной информации (РВАТЬ) [1] и Протокол динамического конфигурирования сервера (DHCP).

Голосовой и видеотрафик обычно передается с использованием UDP. Видео в реальном времени и протоколы потокового аудио предназначены для обработки случайных потерянных пакетов, поэтому происходит только небольшое ухудшение качества, а не большие задержки, если потерянные пакеты были повторно переданы. Поскольку и TCP, и UDP работают в одной и той же сети, многие компании обнаруживают, что недавнее увеличение трафика UDP от этих приложений реального времени снижает производительность приложений, использующих TCP, таких как торговая точка, бухгалтерский учет, и база данных системы. Когда TCP обнаруживает потерю пакета, он ограничивает использование скорости передачи данных. Поскольку для бизнеса важны как приложения реального времени, так и бизнес-приложения, разработка качество обслуживания некоторые считают решающим. [11]

Немного VPN такие системы как OpenVPN может использовать UDP и выполнять проверку ошибок на уровне приложения при реализации надежных соединений.

Сравнение UDP и TCP

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

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

IANA разбила номера портов на три группы.

UDP обеспечивает многоканальную передачу (с помощью номеров портов) и проверку целостности заголовка и существенных данных (с помощью контрольных сумм). Надёжная передача в случае необходимости должна реализовываться пользовательским приложением.

Заголовок UDP состоит из четырёх полей, каждое по 2 байта (16 бит). Два из них необязательны к использованию в IPv4 (розовые ячейки в таблице), в то время как в IPv6 необязателен только порт отправителя.

Порт отправителя

Порт получателя

Длина датаграммы

Поле, задающее длину всей датаграммы (заголовка и данных) в байтах. Минимальная длина равна длине заголовка — 8 байт. Теоретически, максимальный размер поля — 65535 байт для UDP-датаграммы (8 байт на заголовок и 65527 на данные). Фактический предел для длины данных при использовании IPv4 — 65507 (помимо 8 байт на UDP-заголовок требуется ещё 20 на IP-заголовок).

На практике также следует учитывать, что если длина IPv4 пакета с UDP будет превышать MTU (для Ethernet по умолчанию 1500 байт), то отправка такого пакета может вызвать его фрагментацию, что может привести к тому, что он вообще не сможет быть доставлен, если промежуточные маршрутизаторы или конечный хост не будут поддерживать фрагментированные IP пакеты. Также в RFC 791 указывается минимальная длина IP пакета 576 байт, которую должны поддерживать все участники IPv4, и рекомендуется отправлять IP пакеты большего размера только в том случае если вы уверены, что принимающая сторона может принять пакеты такого размера. Следовательно, чтобы избежать фрагментации UDP пакетов (и возможной их потери), размер данных в UDP не должен превышать: MTU — (Max IP Header Size) — (UDP Header Size) = 1500 — 60 — 8 = 1432 байт. Для того чтобы быть уверенным, что пакет будет принят любым хостом, размер данных в UDP не должен превышать: (минимальная длина IP пакета) — (Max IP Header Size) — (UDP Header Size) = 576 — 60 — 8 = 508 байт [2] .

В Jumbogram’мах IPv6 пакеты UDP могут иметь больший размер. Максимальное значение составляет 4 294 967 295 байт (2 32 — 1), из которых 8 байт соответствуют заголовку, а остальные 4 294 967 287 байт — данным.

Контрольная сумма

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

Метод для вычисления контрольной суммы определён в RFC 1071 [4] .

Значение контрольной суммы, равное 0х0000 (+0 в обратном е), зарезервировано и означает, что для посылки контрольная сумма не вычислялась. В случае, если контрольная сумма вычислялась и получилась равной 0х0000, то в поле контрольной суммы заносят значение 0xffff (-0 в обратном е).

Пример расчёта контрольной суммы

Для примера рассчитаем контрольную сумму нескольких 16-битных слов: 0x398a, 0xf802, 0x14b2, 0xc281 .

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

В конце выполняется инверсия всех битов получившегося числа

0x08c1 = 0000 1000 1100 0001 → 1111 0111 0011 1110 = 0xf73e или, иначе — 0xffff − 0x08c1 = 0xf73e . Это и есть искомая контрольная сумма.

В документе RFC 1071 [4] приведены и другие способы расчёта контрольной суммы, в частности, с использованием 32х-разрядной арифметики.

Псевдозаголовок для IPv4

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

Вычисление контрольной суммы для IPv4 необязательно, если она не используется, то значение равно 0.

Псевдозаголовок для IPv6

При работе UDP над IPv6 контрольная сумма обязательна. Метод для её вычисления был опубликован в RFC 2460:

При вычислении контрольной суммы опять используется псевдозаголовок, имитирующий реальный IPv6-заголовок:

Из-за недостатка надёжности приложения UDP должны быть готовы к некоторым потерям, ошибкам и дублированиям. Некоторые из них (например, TFTP) могут при необходимости добавить элементарные механизмы обеспечения надёжности на прикладном уровне.

Но чаще такие механизмы не используются UDP-приложениями и даже мешают им. Потоковые медиа, многопользовательские игры в реальном времени и VoIP — примеры приложений, часто использующих протокол UDP. В этих конкретных приложениях потеря пакетов обычно не является большой проблемой. Если приложению необходим высокий уровень надёжности, то можно использовать другой протокол (TCP) или воспользоваться методами помехоустойчивого ирования ( Erasure code ru _en ).

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

Сетевые механизмы были предназначены для того, чтобы свести к минимуму возможные эффекты от перегрузок при неконтролируемых, высокоскоростных нагрузках. Такие сетевые элементы, как маршрутизаторы, использующие пакетные очереди и техники сброса, часто являются единственным доступным инструментом для замедления избыточного UDP-трафика. DCCP (англ. Datagram Congestion Control Protocol — протокол контроля за перегрузками датаграмм) разработан как частичное решение этой потенциальной проблемы с помощью добавления конечному хосту механизмов для отслеживания перегрузок для высокоскоростных UDP-потоков вроде потоковых медиа.

Многочисленные ключевые Интернет-приложения используют UDP, в их числе — DNS (где запросы должны быть быстрыми и состоять только из одного запроса, за которым следует один пакет ответа), Простой Протокол Управления Сетями (SNMP), Протокол Маршрутной Информации (RIP), Протокол Динамической Конфигурации Узла (DHCP).

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

Читайте также: