Протоколы прикладного уровня.

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

Протокол сетевого времени
Время сервисной сети является одним из простейших интернет-приложений. Оно говорит вам время, как 32-битное значение, давая количество секунд, прошедших с полуночи 1 января 2012 года. Время сервера использует известный номер порта 37. Когда ваше время клиента открывает UDP 37 порт  на сервере, сервер отвечает, посылая четыре байта информации о времени.
Для такой простой операции UDP вполне достаточно, хотя, как это чаще случается много серверов времени также делают поддержку соединения по протоколу TCP. TCP построен надежнее ,но приносит мало пользы в этом приложении, потому что к тому времени, когда протокол решает, что сообщения могут быть потеряны и вновь отправляет, информация в нём будет устаревшей. UDP является наиболее подходящим протоколом для приложений реального времени, как и другие подобные игровые аудио, видео и сети.
Простой сетевой протокол управления
Немного более сложное UDP приложение Simple Network Management Protocol (SNMP). Он позволяет приложениям сделать сбор информации о том, какие различные элементы сети выполняются, и контролирует сеть с помощью команд, посылаемых на него, а не на физическую конфигурацию оборудования.
В SNMP существуют две различные компоненты, SNMP менеджер и SNMP агент. Менеджер может общаться со многими агентами. Как правило, SNMP менеджер приложение, работающее на консоли сетевого администратора, а агенты будут работать на рабочих станциях пользователей, в концентраторах, маршрутизаторах и других частях  сетевого оборудования. Все коммуникации проходят между менеджером и агентом. Агенты не общаются друг с другом. Связь может быть редкой и единичной  и количество информации, которой обмениваются мало. Обычно команды, исходящие от менеджера будут генерировать только один ответ.
SNMP использует UDP. Это позволяет избежать накладных расходов того, чтобы поддерживать связь между SNMP-менеджером и каждым агентом. Поскольку протокол состоит в основном из запроса данных и ответа, содержащий запрашиваемые данные, отсутствие UDP по надежности не является проблемой. Надежность легко реализуется в рамках SNMP менеджера при повторной отправке запроса, если ответ не получен в течение определенного периода.
Основная функция SNMP — позволить менеджеру получить информацию из таблицы обслуживаемой агентами. В таблицах известны информационная база управления (MIB). MIB делится на группы, каждая из которых содержит информацию о различных аспектах сети. Примеры информации, которая может содержать MIB включают имя, тип и скорость сетевого интерфейса, физическое расположение компонентов и контактное лицо, и статистические данные, такие как количество отправленных пакетов и номер.
Идентификаторы объектов
Данные решаются с помощью идентификаторов объекта. Они написаны в виде последовательности чисел, разделенных точками . Каждый номер записан слева направо и представляет собой узел в виде древовидной структуры, с соответствующей информацией сгруппированной на одной ветви дерева. Есть стандартизированный идентификатор объекта для часто используемых элементов информации, а также раздел для конкретного поставщика информации. Назначение объекта идентификаторов управляется через Интернет Assigned Numbers Authority (IANA).
Большинство SNMP сообщения имеют фиксированный формат. В типичной сделке, SNMP менеджер отправит UDP датаграммы на 161 порт  на том же хосте SNMP агента. Датаграмма имеет поля для типа сообщения (в этом случае получает сообщение-запрос), идентификатор транзакции (который будет отображаться в ответе так, что в менеджере может совпасть запросы с полученными данными), а также список объектов имеющих ID значение. В get-сообщении с запросом указваеться идентификатор объекта запрашиваемой информации,значение поля пустое.
Агент будет отвечать на дейтаграммы, в которых поле типа сообщения получают ответы. Поле статуса ошибки будет указывать,  был выполнен запрос, или есть ошибки, такие как запрос на несуществующий объект ID.Тот же список объектов ID  значений, как и в get-запросе, сообщение будет возвращено, но с заполненным значением поля. Есть пять типов сообщений в SNMP версии 1. Кроме get-запроса и получение ответа, есть набор запросов  используемый SNMP менеджером для инициализации значения, и получение следующего запроса. Последнее похоже на перечисление каталога шаблонов спецификации файла, в который он возвращает список всех доступных кодов объектов в той или иной группе.
Пятый тип сообщения, ловушки, используется SNMP агентом, чтобы сигнализировать события SNMP менеджера. Эти сообщения посылаются на UDP  162 порт. Trap сообщения имеют самостоятельный формат. Они включает в себя тип поля ловушки, которая указывает на тип события и сигнализирует: к примеру, агент инициализирует себя, или отключенное устройство. Не существует конкретного производителя типа ловушку, которая позволяет поставщикам определить ловушки для проведения мероприятий по их собственному выбору.