По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Когда мы, разговаривая по IP телефону, слышим голос собеседника в трубке, или, используя систему видеоконференцсвязи, общаемся со своими коллегами и родственниками, то обмениваемся непрерывным потоком данных. При передаче потоковых данных, таких как голос и видео через пакетную сеть, очень важно использовать такие механизмы, которые решали бы следующие задачи:
Устранение эффекта потери пакетов
Восстановление порядка и контроль поступления пакетов
Сглаживание эффекта задержки (джиттера)
Именно для этих целей был разработан RTP (Real-time Transport Protocol) - протокол передачи в реальном времени, о котором пойдет речь в сегодняшней статье. Протокол разрабатывался в IETF группой Audio-Video Transport Working Group и описывается в рекомендации RFC 3550.
Как правило, RTP работает поверх протокола UDP (User Datagram Protocol), так как при передаче мультимедийных данных очень важно обеспечить их своевременную доставку.
RTP включает возможность определения типа полезной нагрузки и назначения последовательного номера пакета в потоке, а также применение временных меток.
На передающей стороне каждый пакет помечается временной меткой, принимающая сторона получает ее и определяет суммарную задержку, после чего вычисляется разница в суммарных задержках и определяется джиттер. Таким образом, появляется возможность установить постоянную задержку выдачи пакетов и тем самым снизить влияние джиттера.
Ещё одна функция RTP связана с возможными потерями пакетов при прохождении по IP сети, что выражается в появлении кратковременных пауз в разговоре. Внезапная тишина в телефонной трубке, как правило, очень негативно действует на слушателя, поэтому возможностями протокола RTP такие периоды тишины заполняются, так называемым,“комфортным шумом”
RTP работает в связке с еще одним протоколом IETF, а именно RTCP (Real - time Transport Control Protocol), который описывается в RFC 3550. RTCP предназначен для сбора статистической информации, определения качества обслуживания QoS (Quality of Service), а также для синхронизации между медиа потоками RTP-сессии.
Основная функция RTCP – установление обратной связи с приложением для отчета о качестве получаемой информации. Участники RTCP сессии обмениваются сведениями о числе полученных и утраченных пакетов, значении джиттера, задержке и т.д. На основе анализа этой информации принимается решение об изменении параметров передачи, например, для уменьшения коэффициента сжатия информации с целью улучшения качества ее передачи.
Для выполнения этих функций RTCP передает специальные сообщения определенных типов:
SR - Sender Report - отчёт источника со статистической информацией о RTP сессии
RR - Receiver Report - отчёт получателя со статистической информацией о RTP сессии
SDES - содержит описание параметров источника, включая cname (имя пользователя)
BYE – Инициирует завершение участия в группе
APP - Описание функций приложения
RTP является протоколом однонаправленного действия, поэтому для организации двусторонней связи необходимо две RTP сессии, по одной с каждой стороны.
RTP-сессия определяется IP адресами участников, а также парой незарезервированных UDP портов из диапазона 16384 - 32767. Кроме того, для организации обратной связи с приложением необходимо также установить двустороннюю RTCP сессию. Для RTCP сессии занимаются порты с номером на единицу большим чем RTP. Так например, если для RTP выбран 19554 порт, то RTCP сессия займет 19555 порт. Наглядно формирование RTP/RTCP сессии представлено на рисунке ниже.
Стоит также отметить, что сам протокол RTP не имеет механизмов для самостоятельного установления сессии, эта задачу выполняют протоколы сигнализации, такие как SIP,H.323,SCCP , которые мы подробно рассматривали в предыдущих статьях.
Почитать лекцию №15 про управление потоком пакетов в сетях можно тут.
Совокупность проблем и решений, рассмотренных в предыдущих лекциях, дает некоторое представление о сложности сетевых транспортных систем. Как системные администраторы могут взаимодействовать с очевидной сложностью таких систем?
Первый способ - рассмотреть основные проблемы, которые решают транспортные системы, и понять спектр решений, доступных для каждой из этих проблем. Второй - создание моделей, которые помогут понять транспортные протоколы с помощью:
Помощь администраторам сетей в классификации транспортных протоколов по их назначению, информации, содержащейся в каждом протоколе, и интерфейсам между протоколами;
Помочь администраторам сетей узнать, какие вопросы задавать, чтобы понять конкретный протокол или понять, как конкретный протокол взаимодействует с сетью, в которой он работает, и приложениями, для которых он несет информацию;
Помощь администраторам сетей в понимании того, как отдельные протоколы сочетаются друг с другом для создания транспортной системы.
Далее будет рассмотрен способ, с помощью которого администраторы могут более полно понимать протоколы: модели. Модели по сути являются абстрактными представлениями проблем и решений. Они обеспечивают более наглядное и ориентированное на модули представление, показывающее, как вещи сочетаются друг с другом. В этой лекции мы рассмотрим этот вопрос:
Как можно смоделировать транспортные системы таким образом, чтобы администраторы могли быстро и полностью понять проблемы, которые эти системы должны решать, а также то, как можно объединить несколько протоколов для их решения?
В этой серии лекции будут рассмотрены три конкретные модели:
Модель Министерства обороны США (United States Department of Defense - DoD)
Модель взаимодействия открытых систем (Open Systems Interconnect - OSI)
Модель рекурсивной интернет-архитектуры (Recursive Internet Architecture - RINA)
Модель Министерства обороны США (DoD)
В 1960-х годах Агентство перспективных исследовательских проектов Министерства обороны США (DARPA) спонсировало разработку сети с коммутацией пакетов для замены телефонной сети в качестве основного средства компьютерной связи. Вопреки мифу, первоначальная идея состояла не в том, чтобы пережить ядерный взрыв, а скорее в том, чтобы создать способ для различных компьютеров, используемых в то время в нескольких университетах, исследовательских институтах и правительственных учреждениях, чтобы общаться друг с другом. В то время каждая компьютерная система использовала свою собственную физическую проводку, протоколы и другие системы; не было никакого способа соединить эти устройства, чтобы даже передавать файлы данных, не говоря уже о создании чего-то вроде "Всемирной паутины" или кросс-исполняемого программного обеспечения. Эти оригинальные модели часто разрабатывались для обеспечения связи между терминалами и хостами, поэтому вы могли установить удаленный терминал в офис или общественное место, которое затем можно было использовать для доступа к общим ресурсам системы или хоста. Большая часть оригинальных текстов, написанных вокруг этих моделей, отражает эту реальность.
Одной из первых разработок в этой области была модель DoD, показанная на рисунке 1.
DoD разделяла работу по передаче информации по сети на четыре отдельные функции, каждая из которых могла выполняться одним из многих протоколов. Идея наличия нескольких протоколов на каждом уровне считалась несколько спорной до конца 1980-х и даже в начале 1990-х гг. На самом деле одним из ключевых различий между DoD и первоначальным воплощением модели OSI является концепция наличия нескольких протоколов на каждом уровне.
В модели DoD:
Физический уровень отвечает за получение "0" и "1" модулированных или сериализованных на физическом канале. Каждый тип связи имеет свой формат для передачи сигналов 0 или 1; физический уровень отвечает за преобразование 0 и 1 в физические сигналы.
Интернет-уровень отвечает за передачу данных между системами, которые не связаны между собой ни одной физической связью. Таким образом, уровень интернета предоставляет сетевые адреса, а не локальные адреса каналов, а также предоставляет некоторые средства для обнаружения набора устройств и каналов, которые должны быть пересечены, чтобы достичь этих пунктов назначения.
Транспортный уровень отвечает за построение и поддержание сеансов между коммутирующими устройствами и обеспечивает общий прозрачный механизм передачи данных для потоков или блоков данных. Управление потоком и надежная транспортировка также могут быть реализованы на этом уровне, как и в случае с TCP.
Прикладной уровень - это интерфейс между Пользователем и сетевыми ресурсами или конкретными приложениями, которые используют и предоставляют данные другим устройствам, подключенным к сети.
В частности, прикладной уровень кажется неуместным в модели сетевого транспорта. Почему приложение, использующее данные, должно считаться частью транспортной системы? Потому что ранние системы считали пользователя-человека конечным пользователем данных, а приложение - главным образом способом изменить данные, которые будут представлены фактическому пользователю. Большая часть обработки от машины к машине, тяжелая обработка данных перед их представлением пользователю и простое хранение информации в цифровом формате даже не рассматривались как жизнеспособные варианты использования. Поскольку информация передавалась от одного человека другому, приложение считалось частью транспортной системы.
Два других момента могли бы помочь включению прикладного уровня сделать его более осмысленным. Во-первых, в конструкции этих оригинальных систем было два компонента: терминал и хост. Терминал тогда был дисплейным устройством, приложение располагалось на хосте. Во-вторых, сетевое программное обеспечение не рассматривалось как отдельная "вещь" в системе, маршрутизаторы еще не были изобретены, как и любое другое отдельное устройство для обработки и пересылки пакетов. Скорее, хост был просто подключен к терминалу или другому хосту; сетевое программное обеспечение было просто еще одним приложением, запущенным на этих устройствах.
Со временем, когда модель OSI стала чаше использоваться, модель DoD была изменена, чтобы включить больше уровней. Например, на рисунке 2, на диаграмме, взятой из статьи 1983 года о модели DoD ("Cerf and Cain, "The DoD Internet Architecture Model"), есть семь слоев (семь почему-то являются магическим числом).
Были добавлены три слоя:
Уровень утилит - это набор протоколов, "живущих" между более общим транспортным уровнем и приложениями. В частности, простой протокол передачи почты (SMTP), протокол передачи файлов (FTP) и другие протоколы рассматривались как часть этого уровня.
Сетевой уровень из четырехслойной версии был разделен на сетевой уровень и уровень интернета. Сетевой уровень представляет различные форматы пакетов, используемые на каждом типе канала, такие как радиосети и Ethernet (все еще очень Новые в начале 1980-х годов). Уровень межсетевого взаимодействия объединяет представление приложений и протоколов утилит, работающих в сети, в единую службу интернет-дейтаграмм.
Канальный уровень был вставлен для того, чтобы различать кодирование информации на различные типы каналов и подключение устройства к физическому каналу связи. Не все аппаратные интерфейсы обеспечивали уровень связи.
Со временем эти расширенные модели DoD потеряли популярность; модель с четырьмя слоями является той, на которую чаще всего ссылаются сегодня. На это есть несколько причин:
Уровни утилит и приложений в большинстве случаев дублируют друг друга. Например, FTP мультиплексирует контент поверх протокола управления передачей (TCP), а не как отдельный протокол или слой в стеке. TCP и протокол пользовательских дейтаграмм (UDP) со временем превратились в два протокола на транспортном уровне, а все остальное (как правило) работает поверх одного из этих двух протоколов.
С изобретением устройств, предназначенных в первую очередь для пересылки пакетов (маршрутизаторы и коммутаторы), разделение между сетевым и межсетевым уровнями было преодолено определенными событиями. Первоначальная дифференциация проводилась в основном между низкоскоростными дальнемагистральными (широкозонными) и короткозонными локальными сетями; маршрутизаторы обычно брали на себя бремя установки каналов в широкополосные сети вне хоста, поэтому дифференциация стала менее важной.
Некоторые типы интерфейсов просто не имеют возможности отделить кодирование сигнала от интерфейса хоста, как было предусмотрено в разделении между канальным и физическим уровнями. Следовательно, эти два уровня обычно объединены в одну "вещь" в модели DoD.
Модель DoD исторически важна, потому что
Это одна из первых попыток систематизировать функциональность сети в модели.
Это модель, на которой был разработан набор протоколов TCP / IP (на котором работает глобальный Интернет); Артефакты этой модели важны для понимания многих аспектов проектирования протокола TCP / IP.
В нее была встроена концепция множественных протоколов на любом конкретном уровне модели. Это подготовило почву для общей концепции сужения фокуса любого конкретного протокола, позволяя одновременно работать многим различным протоколам в одной и той же сети.
ИТ-среда является основой для функционирования многих предприятий. Постоянное управление позволяет быстро обнаруживать и исправлять любые ошибки и обеспечивать безопасность определенной области.
ИТ-мониторинг - что это значит?
Мониторинг ИТ-инфраструктуры - это набор действий, которые позволяют наблюдать за ИТ-средой, осуществляемой с целью получения информации о функционировании инфраструктуры, систем и приложений. Это решение для любой компании, у которой есть хотя бы один компьютер. Более того, этот метод защиты ИТ-систем должен заинтересовать даже небольшое предприятие, которое заботится о безопасности собранных данных, цифровых документов и корпоративной информации.
Мониторинг ИТ-инфраструктуры можно разделить на:
Реактивный мониторинг - решения, благодаря которым можно быстро обнаруживать сбои с одновременным указанием источника проблемы и возможностью информирования о ней конкретных людей или систем.
Проактивный мониторинг - основан на анализе собранных данных и прогнозировании поведения выбранных компонентов на их основе, что позволяет исключить нежелательные события в будущем.
7 преимуществ использования IT-мониторинга
1. Непрерывный мониторинг ИТ-систем
Преимущество использования защиты и контроля ИТ-инфраструктуры на предприятии позволяет точно контролировать отдельные процессы в режиме реального времени. Услуга может включать мониторинг приложений, сетевых служб (например, POP3 или HTTP), использование системных ресурсов (системные журналы, процессоры) или управление событиями и тенденциями.
2. Быстрая информация об угрозе
В зависимости от выбранной опции системы уведомлений отдельные программы могут уведомлять администратора о возникающей угрозе, например, по электронной почте, SMS или другими сообщениями. Благодаря контролю в режиме реального времени можно быстро получать информацию и так же быстро реагировать на любые проблемы.
3. Мониторинг пользователей
Система ИT-мониторинга позволяет контролировать деятельность сотрудников на оборудовании компании. Это не только повышает безопасность, но иногда и эффективность сотрудников. Некоторые системы также позволяют отслеживать действия удаленных работников.
4. Комфорт работы
Помимо контроля со стороны работодателя, сотрудники, работающие на оборудовании компании, могут чувствовать себя более комфортно на работе благодаря различным функциональным возможностям и гарантиям безопасности конкретной системы или устройства. Более того, благодаря профессиональному ИТ-сервису риск простоев и потерь бизнеса сводится к минимуму.
5. Безопасность данных
Процесс мониторинга ИТ-инфраструктуры также защищает от утечки или потери важных данных с компьютеров и серверов компании. Это защита от ошибок пользователя и попытки кражи корпоративных данных.
6. Система отчетности
Профессиональный мониторинг ИТ-инфраструктуры позволяет формировать отчеты о частоте отказов отдельных областей ИТ-инфраструктуры и на их основе создавать процедуры обслуживания и устранять возможные ошибки.
7. Оптимизация затрат
Благодаря профессиональному мониторингу ИТ можно эффективно оптимизировать расходы на предприятии. Предотвращение поломок на работе исключит возможные простои в работе предприятия. Это также означает снижение затрат на возможный ремонт или дополнительные ИТ-операции.
Мониторинг системного журнала
Контроль ИТ-инфраструктуры позволит обнаруживать возможные угрозы и предотвращать их. Важность управления журналами для безопасности данной организации чрезвычайно высока. Особенностью всех ИТ-систем является то, что они сохраняют логи. Без них часто было бы невозможно контролировать ИТ-инфраструктуру, а также находить причины сбоев и решать конкретные проблемы. Системные журналы могут быть собраны и проанализированы, что часто позволяет обнаружить потенциальную опасность или реальную угрозу для компании.
Мониторинг сетевых устройств
Он заключается в управлении сетевым трафиком, то есть чтении количества переданных битов на данном порту. Статусы портов и нагрузка на устройство также важны для ИТ-администратора.
Мониторинг сервера
Проверка включает проверку загрузки ресурса: процессоров, оперативной памяти или жесткого диска.
Мониторинг приложений
Деятельность направлена на лучшую оптимизацию работы данного устройства. Мониторинг касается доступности самого приложения с различными протоколами или портами и времени отклика отдельных функциональных возможностей приложения. Контролируется вся инфраструктура, от устройств до уровня приложений. Это комплексное решение, которое выбирают все больше и больше компаний.
Управление ИТ-ресурсами
Измерение, получение информации, анализ и выводы на этой основе являются рядом факторов, которые составляют профессиональный мониторинг ИТ. Нужны опытные специалисты и проверенные инструменты мониторинга, которые позволяют вам управлять производительностью и событиями в рамках определенных ресурсов. Поэтому такие процессы являются неотъемлемыми элементами ИТ-инфраструктуры.
Преимущества мониторинга ИТ-инфраструктуры включают в себя:
Эффективное предотвращение неправильного использования ресурсов;
Защита активов компании - как от людей, которые имеют к ним доступ, так и от атак в киберпространстве;
минимизация риска;
Быстрая возможность выявления ошибок в определенных областях ИТ-инфраструктуры и их эффективное устранение.
Правильный выбор решений, их правильная реализация и конфигурация позволяют быстрее находить возможные проблемы и удалять их источники. Надежная ИТ-инфраструктура должна быть основой любого предприятия - как маленького, так и крупного.