Длина полезной нагрузки udp и передача пакетов

Структура пакета

UDP не предоставляет никаких гарантий доставки сообщения для вышестоящего протокола и не сохраняет состояния отправленных сообщений. По этой причине UDP иногда называют Unreliable Datagram Protocol (англ. — Ненадёжный протокол датаграмм).

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

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

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

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

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

Это поле обязательно и содержит порт получателя. Аналогично порту отправителя, если хостом-получателем является клиент, то номер порта динамический, если получатель — сервер, то это будет «хорошо известный» порт.

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

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

На практике также следует учитывать, что если длина IPv4 пакета с UDP будет превышать MTU (для Ethernet по умолчанию 1500 байт), то отправка такого пакета может вызвать его фрагментацию, что может привести к тому, что он вообще не сможет быть доставлен, если промежуточные маршрутизаторы или конечный хост не будут поддерживать фрагментированные IP пакеты. Также в RFC791 указывается минимальная длина IP пакета 576 байт, которую должны поддерживать все участники, и рекомендуется отправлять 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 байт.

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

Следует заметить, что большинство современных сетевых устройств отправляют и принимают пакеты IPv4 длиной до 10000 байт без их разделения на отдельные пакеты. Неофициально такие пакеты называют «Jumbo-пакетами», хотя понятие Jumbo официально относится к IPv6. Тем не менее, «Jumbo-пакеты» поддерживают не все устройства и перед организацией связи с помощью UDP/IP IPv4 посылок с длиной превышающей 1500 байт нужно проверять возможность такой связи опытным путём на конкретном оборудовании.

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

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

Linux System потери пакета

Существует много причин для потери пакета Linux System, общие: пакеты UDP, брандмауэр, размер буфера UDP, системные нагрузки высоки, и эти причины потери пакета анализируются.

Ошибка пакета UDP

Если пакет UDP модифицирован во время передачи, ошибка контрольной суммы или ошибка длины, Linux проверяет это, когда сообщение UDP получено, и сообщение будет отброшено после того, как изобретение будет отказаться от сообщения.

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

Брандмауэр

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

Если вы столкнулись с множеством соотношения убытков пакетов, сначала проверьте правила брандмауэра и убедитесь, что брандмауэр не активно падает пакеты UDP.

Размер буфера UDP

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

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

• / proc / sys / net / core / rmem_max: разрешено принять максимум буфера

• / proc / sys / net / core / rmem_default: Получить значение буфера, используемое по умолчанию

• / proc / sys / net / core / wmem_max: максимальное значение разрешено быть установленным

• / proc / sys / net / core / wmem_dafault: максимальное значение, используемое по умолчанию

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

Также может быть измененоСоответствующие параметры позволяют параметрам вступать в силу на следующем запуске.

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

Другой параметр, который можно настроить, этоОн указывает на то, что ядро ​​Linux читает номер пакета после прочтения сообщения от драйвера сети, по умолчанию составляет 1000, что может быть защищено, например, установлено на 2000:

Системная нагрузка слишком высока

System CPU, память, нагрузка на io наполнено, чтобы вызвать потеря сетевой пакеты, такой как CPU, если нагрузка слишком высока, система не успевает сделать сообщение, копировать память и т. Д. Потеря пакета; Память нагрузка слишком высока, приложение слишком медленно, и сообщение не может быть обрабатывается во времени; если нагрузка на io слишком высока, процессор используется для ответа на IO ждать, нет времени для обработки UDP пакеты в кеше.

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

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

Метод, используемый для вычисления контрольной суммы, определен в RFC  , а эффективное вычисление обсуждается в RFC  :

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

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

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

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

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

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

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

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

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

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

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

Порты

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

Управление по присвоению номеров в Интернете (IANA) разделило номера портов на три диапазона. Номера портов от 0 до 1023 используются для общих, хорошо известных служб. В Unix- подобных операционных системах для использования одного из этих портов требуется разрешение суперпользователя . Номера портов с 1024 по 49151 — это зарегистрированные порты, используемые для служб, зарегистрированных IANA. Порты с 49152 по 65535 являются динамическими портами, которые официально не предназначены для какой-либо конкретной службы и могут использоваться для любых целей. Они также могут использоваться как временные порты , которые программное обеспечение, работающее на хосте, может использовать для динамического создания конечных точек связи по мере необходимости.

Эффекты

Как уникальный протокол, протокол User Datagram Protocol имеет свои плюсы и минусы. Некоторые из наиболее распространенных, с которыми вы столкнетесь, объясняются ниже.

Преимущества

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

Недостатки

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

Функциональность

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

Видео в прямом эфире

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

Онлайн игры

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

В онлайн-играх важно то, что происходит в режиме реального времени

Ник или привод потеря пакета

Я сказал раньше, еслиПосерединеТогда это, вероятно, проблема с сетевой картой, вызывая терять пакет, вам необходимо связаться с сервером или поставщиком сетевого карта для обработки.

Он также доступен для приемных пакетов каждого NIC и корпус потери пакетов, а ошибка или падение должны быть 0 на выходе.

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

Вы можете просматривать кольцевой буфер сетевой карты, такой как пример ниже.

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

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

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

• Надежный — TCP управляет подтверждением сообщений, повторной передачей и тайм-аутом. Сделано несколько попыток доставить сообщение. Если данные будут потеряны по пути, данные будут отправлены повторно. В TCP либо отсутствуют недостающие данные, либо, в случае нескольких тайм-аутов, соединение разрывается.
• Упорядоченный — если по соединению последовательно отправляются два сообщения, первое сообщение сначала достигнет принимающего приложения. Когда сегменты данных прибывают в неправильном порядке, TCP буферизует неупорядоченные данные до тех пор, пока все данные не будут должным образом переупорядочены и доставлены в приложение.
• Heavyweight — TCP требует трех пакетов для установки сокетного соединения, прежде чем какие-либо пользовательские данные могут быть отправлены. TCP обеспечивает надежность и контроль перегрузки .
• Потоковая передача — данные читаются как поток байтов , отличительные признаки не передаются на границы сигнального сообщения (сегмента).

Протокол дейтаграмм пользователя — это более простой протокол без установления соединения на основе сообщений . Протоколы без установления соединения не устанавливают выделенное сквозное соединение. Связь достигается путем передачи информации в одном направлении от источника к месту назначения без проверки готовности или состояния получателя.

• Ненадежный — при отправке сообщения UDP нельзя узнать, достигнет ли оно места назначения; он мог потеряться по пути. Нет концепции подтверждения, повторной передачи или тайм-аута.
• Не упорядочено — если два сообщения отправлены одному и тому же получателю, порядок их доставки не может быть гарантирован.
• Легковесный — сообщения не упорядочиваются, не отслеживаются соединения и т. Д. Это очень простой транспортный уровень, разработанный поверх IP.
• Датаграммы — пакеты отправляются индивидуально и проверяются на целостность по прибытии. Пакеты имеют определенные границы, которые соблюдаются при получении; операция чтения в сокете-получателе даст все сообщение в том виде, в котором оно было изначально отправлено.
• Нет контроля перегрузки — UDP сам по себе не избегает перегрузки. Меры по контролю за перегрузкой должны быть реализованы на уровне приложений или в сети.
• Широковещательная рассылка — протокол UDP не требует установления соединения — отправленные пакеты могут быть адресованы для приема всеми устройствами в подсети.
• Многоадресная рассылка — поддерживается режим многоадресной рассылки, при котором один пакет дейтаграммы может автоматически маршрутизироваться без дублирования группе подписчиков.

Стандарты

• RFC  — протокол дейтаграмм пользователя
• RFC  — Спецификация Интернет-протокола версии 6 (IPv6)
• RFC  — Джумбограммы IPv6
• RFC  — База управляющей информации для UDP
• RFC  — Рекомендации по использованию UDP

Протоколы и порты

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

Система доменных имен (DNS RFC 1034-1035: порт 53)

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

Протокол динамической конфигурации хоста (DHCP RFC 2131: порт 67/68)

Этот протокол в основном используется в сетях, не использующих статические назначения IP-адресов. Сервер может быть настроен либо инженером, либо администратором, у которого есть доступный для назначения пул адресов.
Клиент может включить устройство и запросить IP-адрес с локального DHCP-сервера, когда есть доступный адрес, он будет назначен устройству. Однако это не является постоянным назначением и истекает через определенный промежуток времени. Срок действия договора аренды истекает, если не подается запрос на продление, и он будет возвращен в пул для передачи другим устройствам.

Тривиальный протокол передачи файлов (TFP RFC 1350: порт 69)

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

Простой протокол сетевого управления (SNMP RFC 1901-1908, 3411-3418: порт 161-/162)

Этот протокол используется для управления сетью. Возможность мониторинга, настройки и управления сетевыми устройствами — это некоторые из возможностей SNMP. Ловушки также настраиваются таким образом, чтобы уведомлять о необходимости принятия конкретных мер и осуществлять дальнейший поиск источника события.

Протокол сетевого времени (NTP RFC 5905: порт 123)

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

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

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

Использование PortQry в интерактивном режиме

При устранении неполадок с подключением между компьютерами может потребоваться ввести множество повторяющихся команд. Такие действия можно сделать проще с помощью PortQry в интерактивном режиме.

Интерактивный режим похож на интерактивные функции в службе DNS Nslookup или в утилите Nblookup WINS.

Чтобы запустить PortQry в интерактивном режиме, используйте параметр. Например, выполните следующую команду:

Выход этой команды напоминает следующий отрывок:

Команды интерактивного режима

В интерактивном режиме можно использовать следующие команды:

Ярлыки запроса интерактивного режима

Вы можете использовать следующие ярлыки вместе с командой для запуска общих запросов без настройки параметров порта и протокола. Используйте следующий синтаксис:

Примечание

В этой команде представлен один из ярлыков <shortcut> из следующей таблицы. Если упустить ярлык, команда запросит TCP-порт 80.

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

Параметры интерактивного режима

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

Примечание

В этой команде представлено имя параметра, заданной, и <option> <value> представляет новое значение параметра.

Предположим, необходимо запросить компьютер с IP-адресом 10.0.1.10. В командной подсказке интерактивного режима введите . Эта команда производит вывод, который похож на следующий отрывок:

Чтобы отправить запрос DNS, введите команду интерактивного режима. Эта команда производит вывод, который похож на следующий отрывок: