По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Мир VoIP (Voice over IP) многогранен. На рынке существует целое множество решений для построения корпоративных систем связи – IP – АТС. Нас интересуют программные «open source» решения, поэтому, сегодня мы сравним две популярные телефонные платформы и ответим на вопрос: что круче, FreeSWITCH или Asterisk? :)
Про Asterisk
Давайте немного теории: Asterisk - программная автоматическая телефонная станция (АТС) на базе протокола IP, которая способна предложить богатый, с точки зрения телефонии, инструментарий для офиса. Asterisk, будучи одной из первых программных IP-АТС был создан в 1999 году как решение с открытым кодом (open source). При поддержке компании Digium в 2005 году IP – АТС увидела свет и была выпущена в «продакшн». Реализация происходит под двумя лицензиями: GNU GPL (General Public License) и патентная лицензия для разработки собственных решений на базе Asterisk, рассчитанных на дальнейшую продажу. Более миллиона пользователь радуются IP – АТС Asterisk каждый день по всему миру :)
Но не все так гладко (удар молнии за окном). Исторически, Asterisk имеет ряд проблем, связанных с масштабируемостью, нестабильностью работы при повышении нагрузки. С учетом особенностей лицензирования, многие пользователи (в том числе компании - разработчики) искали новый продукт.
Про FreeSWITCH
В 2006 году группа бывших разработчиков Asterisk приняли решение разработать альтернативное решение – на свет появился FreeSWITCH. Вдохновленные модульной структурой веб – сервера Apache, команда разработчиков преследовала цель улучшить параметры масштабируемости и стабильности работы на разных платформах.
FreeSWITCH создан по модели состояний, вследствие чего, каждый вызов(канал) работает по отдельному потоку данных. Для построения структуры, использовались компоненты open – source решений, такие как, например, Sofia SIP – SIP UA с открытым исходным кодом, созданный компанией Nokia.
Что под капотом?
Asterisk – модульная структура. Во время работы, Asterisk использует общие ресурсы, включая программные потоки – это главная проблема при большой интенсивности вызовов.
Несмотря на сложность и многогранность программного кода, на котором написан Asterisk, он находит огромное множество применений в сети. С другой стороны, FreeSWITCH написан на C, структура которого более понятна и прозрачна. Потоки процессов выполняются последовательно и отдельно для каждого канала, что безусловно отличает Фрисвитч от Asterisk. При этом, как правило, по этой причине FreeSWITCH требует больший объем оперативной памяти (RAM)
Отметим, что FreeSWITCH имеет хорошо документированный API (Application Programming Interface), сегментированный по ролям. Такая структура обеспечивает безопасное подключение к API в отличие от Asterisk, где более открытая конструкция API допускает вероятность внесения багов и ошибок.
Asterisk базируется на текстовых конфигурационных файлах, в то время как FreeSWITCH использует файлы формата .xml. Безусловно, с точки зрения работы с конфигами для админа, файлы текстового формата проще редактировать, однако, плюсы формата .xml всплывают на этапе автоматизации различных процессов.
Требования к железу
Оценить общие требования к IP – АТС достаточно сложно, так как в каждой инсталляции используется разный набор фичей и целей эксплуатации. Однако, в таблице ниже сконцентрированы минимальные требования к серверу, на котором будет развернут Asterisk и FreeSWITCH для работы 15 телефонными аппаратами и 5 одновременными вызовами. Сравните их:
Параметр
FreeSWITCH
Asterisk
CPU
Одно ядро, частота процессор 1 гГц
Одно ядро, частота процессор 700 мГц
RAM
1 ГБ
512 МБ
HDD
10 ГБ
10 ГБ
OS
Linux, 32/64 бит
Linux, 64 бит
Как видно, FreeSWITCH потребляет больше RAM. О причине этого мы писали ранее – это связано с архитектурой.
Функционал
С точки зрения базового набора функций, АТС идентичны. Голосовая почты, IVR, маршрутизация, intercom и другие опции доступны для обоих лагерей пользователей.
Рассмотрим преимущества, которые интересны для профессионального и более глубокого использования платформ. Начнем, пожалуй, с возможности FreeSWITCH создавать мульти – площадки. Фрисвич нативно (из коробки) умеет сегментировать площадки пользователей, разные домены и суб – домены. Это означает, что пользователи одной площадки не смогут дозвониться до пользователей другой по внутренним номерам. Другими словами, обеспечивается полнофункциональная сегрегация пользователей.
Так же, безусловным преимуществом FreeSWITCH стоит отметить возможность кластеризации (объединения нескольких серверов), где каждый хост в кластере будет выполнять свою определенную роль.
Итог
Подведем итоги. Мы составили таблицу с результатами, чтобы вам было проще ориентироваться:
Функция
FreeSWITCH
Asterisk
Малое потребление ресурсов сервера, включая ресурсы процессора и оперативной памяти
✕
✓
Документация и поддержка: решение проблем, форму, гайды, сильное комьюнити проекта
✕
✓
Богатый базовый функционал: конференции, видеозвонки, IVR, голосовая почта и так далее
✓
✓
Возможность реализации функций мульти - площадок (поддержка отдельных телефонных доменов с полной сегрегацией пользователей)
✓
✕
Внутренние механизмы устойчивости к повышению нагрузки, связанной с повышением количества одновременных вызовов
✓
✕
Объединение серверов в кластер, с последующим разделением ролей
✓
✕
Sup! Сейчас я объясню тебе, что такое фаэрволл, он же брандмауэр и межсетевой экран. Давай сразу учиться говорить правильно!
Поэтому запомни - не брандмаузер, не браузер, не фаерболл и поверь мне - никто в профессиональной среде не говорит "огненная стена" или "стена огня". Гуд, мы стали чуточку грамотнее.
Видео: Что такое Firewall? | Простыми словами за 5 минут
Почему он так странно называется?
Всё дело в том, что это название пришло в мир сетевых технологий откуда бы вы, думали? Из пожарной безопасности, где фаэрволлом называется стена здания, из негорючих материалов, предназначенная для препятствования распространению огня на соседние части здания или другие строения. Фаэрволл, наряду с коммутаторами и роутерами является активным сетевым устройством и обеспечивает безопасность инфраструктуры.
Он работает на 3 уровне модели OSI и защищает локальную сеть от неавторизованного доступа из внешних недоверенных сетей, таких как например этот ваш Интернет.
В Интернете полно ужасов, там много хакеров, вредоносных файлов и ресурсов, там постоянно кто-то кого-то пытается взломать и происходят всякие кибератаки. Мы же не хотим, чтобы всё это беспрепятственно проникало в нашу сеть? В то же время, мы хотим, чтобы нормальный трафик мог свободно как входить в нашу сеть, так и покидать её.
Тут нам и помогает Firewall. Он блокирует нежелательный трафик (как на вход, так и на выход) и пропускает разрешенный трафик.
Делает он это с помощью специальных правил, которые называются списками контроля доступа или ACL.
В этих правилах определяется какой трафик может входить в сеть и покидать её, а какой - нет. Ну, ОК, а кто определяет, что можно, а что нельзя? Сетевой администратор.
Он настраивает списки контроля доступа для обеспечения прохождения нужного трафика и блокировки нежелательного. Так что, если ты не можешь смотреть ютубчик и сидеть в одноклассниках с рабочего компа - это сисадмин постарался!
Самое простое, что может сделать сисадмин чтобы запретить доступ к ресурсу - это настроить ACL на блокировку IP адреса этого ресурса.А что если у ресурса много IP адресов и они постоянно меняются?
Не беда - фаэрволл может решать что делать с трафиком не только на основе IP, но ещё портов, доменных имён, протоколов, и даже приложений[2].
Рассмотрим простенький пример
Допустим сисадмин не нашёл ответа на свой вопрос в нашей базе знаний wiki.merionet.ru и решил заблочить её на фаэрволле для всего IT отдела, который живет в подсети 10.15.15.0/24.
Для этого он создал примерно такой ACL:
Action = DENY Source IP = 10.15.15.0/24 Destination =wiki.merionet.ru Destination Port = ANY
Теперь инженер Фёдор с адресом 10.15.15.5 не может прочитать как настроить BGP на нашем ресурсе. В тоже время для отдела разработки, живущего в подсети 10.15.20.0/24 таких запретов нет, поэтому разработчик Илья спокойно может читать наши статьи дальше.
Ну или такой пример - сисадмин Василий узнал, что бухгалтер Ирина использует приложение TikTok и снимает видео в рабочее время, загружая свои танцы под Cardi B через офисную вай-фай сеть. Вернувшись на рабочее место, Василий настроил блокировку приложения TikTok для всех Wi-Fi сетей в офисе и получил премию.
Нужно сказать, что такое возможно только если фаэрволл Васи поддерживает определение приложений в трафике. Обычно такие фичи есть только у крутых Stateful фаэрволлов следующего поколения - NGFW (Next Generation Firewall)
Воу, воу - что за Stateful?
Есть два типа фаэрволов - Stateful и Stateless.
Stateful фаэрволлы более крутые. Они понимают весь контекст траффика и следят за состоянием соединения.
Если Stateful фаэрволл получает пакет, он также проверяет метаданные этого пакета, такие как порты и IP-адреса, принадлежащие источнику и получателю, длину пакета, информацию уровня 3, флаги и многое другое. Таким образом, Stateful фаэрволл анализирует пакет в потоке и может принимать решения основываясь на множестве параметров.
Stateless фаэрволлы более простые, они исследуют каждый пришедший пакет изолированно и принимают решение на основании того, что сказано ACL. А на содержимое пакета и что было до него им пофиг.
Кстати, мы немного слукавили, когда сказали, что фаэрволл - это устройство. На самом деле, они бывают разными. Это может быть:
крутая железяка, которая стоит как машина,
простенький девайс, у которого есть функции фаэрволла, как например - домашний роутер,
программное обеспечение, которое устанавливается на компьюстер,
виртуальная машина
или вообще - облачное приложение.
Программное обеспечение с функциями фаэрволла для компа называется Host-Based firewall. Его задача - защита одного хоста, на которое оно установлено. Например, почти все антивирусы имеют функции хостовых фаэрволлов.
Почти во всех остальных случаях фаэрволл защищает всю сеть. Таким образом, обеспечивается двойной уровень защиты, на уровне сети и на уровне хоста.
Фаэрволл - это важнейший элемент любой сети, к его настройке следует относиться предельно внимательно, в противном случае можно поставить под угрозу безопасность всей инфраструктуры.
Кстати, если ты хочешь реально хочешь научиться общаться с сетевыми железками, освоить настройку сетевых протоколов и построить свою собственную сеть, то не пропусти наш большой курс по сетевым технологиям:
Учиться!
Кстати, еще, по промокоду PRIVET_YA_PODSYADU ты получишь скидку 10% на весь ассортимент нашего магазина shop.merionet.ru!
А теперь вопрос - чтобы заблокировать facebook.com достаточно ли будет stateless firewall или необходим stateful и почему? Ответ пиши в комент.
Если вас удивляет то, каким образом веб-приложения могут взаимодействовать друг с другом и передавать информацию для оптимизации операций, то вам следует познакомиться с
Webhook
, веб-перехватчиком.
Webhook (он же веб-перехватчик) – это больше, чем просто средство информационного взаимодействия для онлайн-сервисов. Webhook – это достаточно любопытная технология, используемая для запуска приложений. Эта статья позволит получить четкое понимание того, что же такое Webhook и какие методы его работы существуют.
Видео: что такое Webhook и чем отличается от API?
Что такое Webhook: быстрый экскурс
Webhook – это автоматически сгенерированный HTTP-запрос, созданный на основе каких-то данных. Он запускается предопределенным событием или действием в исходной системе и передается системе, с которой исходная система пытается установить связь.
Webhook работает быстрее, чем опрос или API. Вместе с этим для разработчиков он является менее трудоемким с точки зрения работы. Применительно к приложениям, Webhook – это не что иное, как SMS-уведомления, которые мы получаем во время использования приложения. Например, при покупке некого товара в Интернете продавец присылает вам уведомление по SMS.
Аналогично, каждый раз, когда в исходной системе происходит некоторое событие/действие, система принимающей стороны уведомляется через Webhook.
Для чего нужен Webhook?
Webhook используется для связи приложений и быстрого обмена данными между системой-источником и системой-получателем. Это приводит к двусторонней связи между двумя различными сетевыми системами.
Ниже приведен список нескольких сценариев, при который Webhook справится лучше, чем любое другое средство связи приложений:
Использование Webhook для передачи информации о событиях в различные базы данных.
Требуется мгновенный ответ приложения при выполнении определенного действия.
Использование Webhook для беспрепятственной синхронизации данных клиентов в приложении.
Необходимость иметь модель push-уведомлений для получения своевременных обновлений.
Связь должна быть взаимно-однозначной.
Webhook может помочь установить соединение между средством массовой email-рассылки/управления проводимыми акциями и платежными системами.
Разработчики требуют приравнять 2 системы к временной системе связи.
Принимая во внимание все эти утилиты, Webhook можно назвать ключевым инструментом для разработки SaaS-приложений. Одним из реально существующих примеров использования Webhook является
Shopify
, который использует веб-перехватчик, например, для операций автоматического обновления корзины или объявления о продаже.
Еще одной известной платформой является
Stripe
. Она использует Webhook для передачи сведений, связанных с обновлениями учетных записей, уведомлений об оплате и др.
Webhook vs API
Человеку, не являющемуся специалистом в данной области, может показаться, что Webhook и
API
это одно и то же, поскольку они оба используются для установки связи между приложениями. Ситуация усугубляется, когда некоторые разработчики называют Webhook
обратным API
. В данном случае только опытный разработчик сможет понять разницу между этими двумя технологиями и использовать их. Мы подготовили краткий обзор основных различий между Webhook и API.
Обе эти технологии, как принято считать, используются приложениями для передачи информации другому приложению. В общих чертах они работают одинаково. Ключевое различие заключается в процессе получения данных.
API использует процесс «опроса» для получения необходимых данных. Опрос (
polling
) – это выполнение запросов на сервер с целью проверки появления новых данных.
Webhook работает по принципу «принудительной отправки данных», то есть как только происходит инициирующее событие, из источника отправляются необходимые данные.
API ожидает появления новых данных и требует периодической активности, в то время как Webhook активируется автоматически при возникновении события.
Если говорить об их практической реализации, то они принципиально разные. Например, API связывается с продавцом, чтобы удостовериться, что нужный вам товар есть в наличии, а Webhook попросит продавца самому связаться с вами, как только нужный товар будет доступен. При таком подходе обе стороны экономят время и усилия.
Безопасность Web API – сложная задача, поскольку запросы выполняются снова и снова, и каждый раз необходимо внедрять методы обеспечения безопасности API. Обеспечить безопасность Webhook относительно просто, поскольку запросы производятся не так часто.
Webhook лучше использовать, когда требуются обновления приложения в режиме реального времени, а API – когда часто обновляется серверное приложение.
Webhook – это простейшая модель API. API – это полноценный язык приложений, способный выполнять добавление, удаление и извлечение данных. Webhook работает автоматически, в то время как API требует некоторых усилий разработчика.
Webhook не является широко поддерживаемым, в то время как большинство сторонних интеграций принимают API.
Как работает Webhook?
На первый взгляд все кажется похожим, но Webhook включает в себя определённый сложный процесс. Вот как это работает:
Шаг 1: Генерация запроса
Для использования Webhook система должна быть достаточно оборудована для поддержки всего процесса. Можно разработать дружественную к Webhook систему, осуществляя несколько HTTP-запросов для различных событий. Основанный на этом принципе Webhook имеет хорошую совместимость с платформой SaaS, поскольку присутствует поддержка нескольких событий. Также с Webhook совместимы такие платформы, как GitHub, Shopify, Twilio, Stripe и Slack.
Для начала нужно зарегистрироваться, чтобы принять Webhook'и. Регистрация должна быть проведена для более чем одного события. После регистрации на целевой URL будет автоматически сгенерирован запрос Webhook. Этот запрос обработается автоматически, когда произойдет определенное событие.
Шаг 2: Применение Webhook
Когда процесс подготовки завершен, можно использовать Webhook'и. Процесс можно упростить, если вы создадите свои Webhook и протестируете их на пригодность. Если вам покажется это слишком тяжелым, то вы можете просто добавить нужный URL-адрес веб-перехватчика в приложение и начать делиться данными.
Для использования Webhook вы можете использовать средства, указанные ниже:
1. RequestBin и Postman для тестирования Webhook
Как уже отмечалось, тестирование Webhook – это наиболее эффективный способ понять его метод работы.
RequestBin
и
Postman
– два самых популярный инструмента для тестирования.
Используя RequestBin, разработчики могут создавать нужные URL-адреса веб-перехватчиков и обмениваться данными, чтобы проверить, как он их идентифицирует. Postman аналогично может обрабатывать процесс отправки запроса для терминала и выделенный код приложения. Разработчик может свободно работать с кодировкой JSON и XML.
2. Общение приложений
Тестирование Webhook было исчерпывающим. И теперь можно приступить к делу и позволить приложениям общаться между собой. Для начала разработчикам необходимо активировать Webhook триггерных приложений.
Как правило, каждое приложение имеет большое количество настроек веб-перехватчиков. Чтобы получить данные из используемого триггерного приложения, необходимо открыть настройку Webhook в заданной форме. Будет сгенерировано поле URL и варианты для спецификации HTTP-запроса веб-перехватчика.
На следующем шаге уже необходимо использовать URL-адреса приложения, получающего данные. В этом приложении каждый документ имеет свой конкретный URL-адрес слияния. Скопируйте URL-адрес слияния или любой другой предполагаемый URL-адрес приложения. Затем снова перейдите в приложение-триггер и вставьте скопированный URL-адрес веб-перехватчика из приложения, получающего данные, в поле URL-адреса приложения-триггера. Сохраните изменения. Теперь приложение готово к работе.
Вы можете использовать любой из вышеупомянутых средств включения Webhook. Чтобы концепция работы была более понятна, ниже мы привели пример работы Webhook Shopify:
Пример Webhook
Давайте продолжим приведенный выше пример Shopify. Предположим, что новый пользователь только что разместил 2 заказа в интернет-магазине после подтверждения адреса электронной почты. Получение информации с помощью события
customer/update
будет выглядеть примерно так:
HTTP/1.1 200 OK
{
"webhook": {
"id": 744408886555322224,
"email": "ss@testmail.com",
"accepts_marketing": false,
"created_at": null,
"updated_at": null,
"first_name": "Jane",
"last_name": "Doe",
"orders_count": 2,
"state": "disabled",
"total_spent": "0.00",
"last_order_id": 54254, 54258
"note": "The user registered from India and uses store for sending gifts",
"verified_email": true,
"multipass_identifier": null,
"tax_exempt": false,
"phone": 8585858585,
"tags": "retailer",
"last_order_name": null,
"currency": "INR",
"addresses": [
],
"accepts_marketing_updated_at": null,
"marketing_opt_in_level": null,
"admin_graphql_api_id": "gid://shopify/Customer/744408886555322224" }
}
Заключение
Процесс передачи данных является ключевым во взаимодействии человека и веб-приложений. Webhook делает взаимодействие между приложениями быстрым, беспрепятственным и не таким сложным. Webhook является альтернативой API и автоматизирует коммуникационное соединение.