По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Когда мы, разговаривая по 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 , которые мы подробно рассматривали в предыдущих статьях.
Где и зачем?
На сегодняшний день логирование информации в процессе разработки имеет огромное значение. Сохранение информации в лог-файлы это первоочередная задача для выявления неполадок и слабых мест в работе приложения. Однако, если приложение работает на основе многих сложных процессов здесь не обойтись без эффективного инструмента навигации и анализа по логам. В одной из предыдущих статей мы разбирали такое решение, как ELK Elasticsearch, Logstash, Kibana. В таком сочетании эти программы способны оперативно решать задачи по сбору, хранению, выборке и анализу информации даже в крупных проектах. Это и является их основным назначением. Однако, эти программы также можно использовать по отдельности, поскольку они являются самостоятельными программными продуктами. Как же можно использовать эти приложения в разных сочетаниях, и для чего это нужно? Приступим к разбору.
Самым востребованным инструментом из этой тройки является Elasticsearch. Оно и понятно поисковая система, действующая на основе горизонтального масштабирования (то есть, с возможностью искать данные по запросу пользователя параллельно на множестве серверов) стала очень популярным решением для осуществления поиска не только в логах, но и во множестве данных. При этом данные не обязательно могут быть структурированы, и пользователь с высокой вероятностью получит четкие результаты по запрашиваемому фрагменту текста. При этом широкую популярность данному приложению обеспечивают также широкие возможности по интегрированию с другими программами, множество вариантов конфигурирования, а также подключаемые плагины, работа над которыми ведется как специалистами компании Elastic, так и "народными умельцами"
Альтернативным вариантом использования Elasticsearch является вариант с созданием на основе этого приложения централизованных хранилищ данных, содержащих логи использования с разных устройств. Конечно, в этом случае потребуется визуализация, поэтому наилучшее взаимодействие с Elasticsearch обеспечивает Kibana. Данная связка является наиболее популярной и эффективной, поскольку обе программы разрабатывались специально с прицелом на взаимодействие.
Несомненным плюсом ELK является модульная архитектура. Комбинируя различные модули, можно сконфигурировать систему для выполнения разнородных задач. Так, например, модуль Metricbeat, включенный в систему позволяет оптимально сконфигурировать систему для мониторинга инфраструктуры,решение Heartbeat позволяет осуществлять uptime-мониторинг. Направления Elastic SIEM и Elastic API также существенно расширяют функциональность ELK
Помимо непосредственно разработчиков, комплекс ELK Stack также могут использовать и тестировщики. Конечно, если приложение занимает небольшой объем, то установка ELK вряд ли будет рациональным решением, но, если это будет серьезная объемная программа, тогда тестер сможет быстро выявить проблему и не тратить время разработчика на поиск и анализ. Такая схема работы достаточно популярна и эффективна в некоторых компаниях, разрабатывающих программное обеспечение.
Также доступ к логам программы могут затребовать управленцы - менеджер, курирующий проект, или же представители заказчика. В данном случае анализ логов позволяет выявить, эффективно ли ведется работа над исправлением выявленных ранее неисправностей, и не появилось ли новых багов в процессе исправления старых.
В последнее время развивается использование комплекса ELK в бизнес-процессах для обеспечения эффективного сбора информации, оперативного анализа и принятия решений. Как пример, можно привести огромный супермаркет со множеством касс. Как правило, для наличного расчета на начало рабочего дня в кассе должна быть определенная сумма наличных для выдачи сдачи. Так вот, комплекс ELK применяется для сбора данных о проведенных по кассе операциях, выборки из собранных данных информации об остатках наличных в разных кассах, и анализа информации, после которого специалист, работающий с программой, может принять решение, какая сумма наличных нужна для обеспечения нужд кассиров по выдаче сдачи.
Непрерывный сбор и анализ информации позволяет оценить пики и спады, сравнить информацию с аналогичными показателями за вчерашний день, прошедшие неделю или месяц. По этой причине решение ELK приобретает все большую популярность как инструмент биржевой аналитики. Хотя на текущий момент есть инструменты и получше, однако динамика развития данного решения позволяет думать, что оно вряд ли перестанет быть актуальным и для подобных задач.
Третья часть тут
Поскольку трафик в реальном времени начал передаваться по сетям с коммутацией пакетов, QoS стал серьезной проблемой. Передача голоса и видео полагается на то, что сеть способна быстро переносить трафик между хостами (с низкой задержкой) и с небольшими колебаниями межпакетного разнесения (jitter). Дискуссии вокруг QoS фактически начались в первые дни сети с коммутацией пакетов, но достигли высшей точки примерно в то время, когда рассматривался ATM. На самом деле, одним из главных преимуществ ATM была возможность тщательно контролировать способ, которым обрабатывались пакеты, когда они передавались по сети с коммутацией пакетов.
С провалом ATM на рынке, появились два направления идей о приложениях, которые требуют сильного контроля над jitter и delay:
Эти приложения никогда не будут работать в сетях с коммутацией пакетов. Такого рода приложения всегда должны запускаться в отдельной сети.
Это просто поиск правильного набора элементов управления QoS, чтобы позволить таким приложениям работать в сетях с коммутацией пакетов.
Основное, что больше всего волновало большинство провайдеров и инженеров, была голосовая связь, и основной вопрос сводился к следующему: можно ли обеспечить приличную голосовую связь по сети, также передающей большие файлы и другой "nonreal - time" трафик? Были изобретены сложные схемы, позволяющие классифицировать и маркировать пакеты (называемые QoS-маркировкой), чтобы сетевые устройства знали, как правильно их обрабатывать. Картографические системы были разработаны для переноса этих маркировок QoS из одного типа сети в другой, и много времени и усилий было вложено в исследование механизмов массового обслуживания-порядка, в котором пакеты отправляются по интерфейсу. На рис. 1 показана примерная диаграмма одной системы QoS, и сопоставления между приложениями и маркировками QoS будет достаточно, чтобы проиллюстрировать сложность этих систем.
Увеличение скорости связи оказывают двойной эффект на обсуждение QoS:
Более быстрые каналы связи будут (это очевидно) нести больше данных. Поскольку любой отдельный голосовой и видеопоток становится сокращающейся частью общего использования полосы пропускания, необходимость строго сбалансировать использование полосы пропускания между различными приложениями стала менее важной.
Время, необходимое для перемещения пакета из памяти в провод через микросхему, уменьшается с каждым увеличением пропускной способности.
По мере того, как доступная пропускная способность увеличивалась, потребность в сложных стратегиях массового обслуживания для противодействия jitter становилась все менее значимой. Это увеличение скорости было дополнено новыми системами массового обслуживания, которые гораздо эффективнее управляют различными видами трафика, уменьшая необходимость маркировки и обработки трафика детализированным способом.
Такое увеличение пропускной способности часто обеспечивалось переходом от медного волокна к стекловолокну. Оптоволокно не только обеспечивает большую полосу пропускания, но и более надежную передачу данных. Способ построения физических связей также эволюционировал, делая их более устойчивыми к поломкам и другим материальным проблемам. Вторым фактором, увеличивающим доступность полосы пропускания, стал рост Интернета. По мере того, как сети становились все более распространенными и более связанными, отказ одного канала оказывал меньшее влияние на объем доступной полосы пропускания и на потоки трафика по сети.
Поскольку процессоры стали быстрее, появилась возможность разрабатывать системы, в которых отброшенные и задержанные пакеты будут иметь меньшее влияние на качество потока в реальном времени. Увеличение скорости процессора также позволило использовать очень эффективные алгоритмы сжатия, уменьшая размер каждого потока. На стороне сети более быстрые процессоры означали, что control plane могла быстрее вычислять набор loop-free путей через сеть, уменьшая как прямые, так и косвенные последствия сбоев связи и устройств.
В конечном счете, хотя QoS все еще важен, его можно значительно упростить. Четырех-шести очередей часто бывает достаточно для поддержки даже самых сложных приложений. Если требуется больше, некоторые системы теперь могут либо проектировать потоки трафика через сеть, либо активно управлять очередями, чтобы сбалансировать сложность управления очередями и поддержки приложений.
Централизованный Control Plane - есть ли смысл?
В 1990-х годах, чтобы решить многие из предполагаемых проблем с сетями с коммутацией пакетов, таких как сложные плоскости управления и управление QoS, исследователи начали работать над концепцией, называемой активной сетью. Общая идея состояла в том, что плоскость управления для сети с коммутацией пакетов может и должна быть отделена от устройств пересылки, чтобы позволить сети взаимодействовать с приложениями, запущенными поверх нее.
Базовая концепция более четкого разделения плоскостей управления и данных в сетях с коммутацией пакетов была вновь рассмотрена при формировании рабочей группы по переадресации и разделению элементов управления (ForCES) в IETF. Эта рабочая группа в основном занималась созданием интерфейса, который приложения могли бы использовать для установки пересылки информации на сетевые устройства. Рабочая группа была в конечном итоге закрыта в 2015 году, и ее стандарты никогда не применялись широко.
В 2006 году исследователи начали эксперимент с плоскостями управления в сетях с коммутацией пакетов без необходимости кодирования модификаций на самих устройствах- особая проблема, поскольку большинство этих устройств продавались поставщиками как неизменяемые устройства (или black boxes). Конечным результатом стал OpenFlow, стандартный интерфейс, который позволяет приложениям устанавливать записи непосредственно в таблицу пересылки (а не в таблицу маршрутизации). Исследовательский проект был выбран в качестве основной функции несколькими поставщиками, и широкий спектр контроллеров был создан поставщиками и проектами с открытым исходным кодом. Многие инженеры считали, что технология OpenFlow позволила бы реконструировать инженерные сети за счет централизации управления.
В реальности, все будет по-иному-то, что, скорее всего, произойдет в мире сетей передачи данных: лучшие части централизованной control plane будут поглощены существующими системами, а полностью централизованная модель будет выброшена на обочину, оставив на своем пути измененные представления о том, как control plane взаимодействует с приложениями и сетью в целом.