По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
При изучении принципов написания программного кода вы, вероятно, встречались с термином AJAX и задавались вопросом, что же он значит. Что это – язык программирования, платформа или приложение? На самом деле ничего из перечисленного, но к концу прочтения этой статьи вы будете знать, что же такое AJAX (Asynchronous Javascript and XML - асинхронные сценарии JavaScript и XML).
История AJAX
До конца 1990-х годов большинство веб-сайтов могли выдавать в качестве результата только полные веб-страницы при посещении страницы на сайте. Иначе говоря, для того, чтобы перезагрузить какие-либо отдельные данные, вам необходимо было перезагрузить всю страницу.
Это был не самый эффективный способ предоставления информации пользователям, и, соответственно, не очень хорошо сказывалось на впечатлениях пользователей от взаимодействия с сайтом. Также это увеличивало нагрузку на серверы и пропускную способность, необходимую для обслуживания данных.
В 1996 году Microsoft представила тег iframe для Internet Explorer, который позволял браузеру асинхронно извлекать данные в фоновом режиме. Это был шаг в верном направлении на пути к современным веб-приложения.
В 2004 году Google добавила в Gmail функцию, позволяющую получать данные в фоновом режиме, а в 2005 году они сделали то же самое и для Google Maps.
Технологии Google и Microsoft позволяли разработчикам получать данные с веб-сервера с помощью JavaScript без необходимости перезагружать страницу. В 2005 году Джесси Джеймсон Гарретт в своей статье (о том, как Google добились такого результата) назвал эту технологию AJAX. Эта технология быстро стала одним из самых популярных способов создания веб-приложений.
А теперь, когда вы узнали немного из истории AJAX, давайте посмотрим, как это работает.
Как работает AJAX?
Что делает работу AJAX возможной, так это встроенный в веб-браузер объект XMLHttpRequests (XHR). Этот объект поддерживают все современные браузеры, включая:
Chrome
Firefox
IE7+
Safari
Opera
Большинство библиотек JavaScript, которые используют AJAX, помещают этот объект в пользовательский код для того, чтобы упростить его использование разработчиками, но мы рассмотрим, как AJAX работает в обычном JavaScript.
Первый шаг – создать переменную, которая будет создавать для вас экземпляр объекта XMLHttpReaquests в JavaScript. Ниже приведен пример:
const request = new XMLHttpRequest();
Поскольку мы хотим использовать эти данные в дальнейшем, например, хотим распечатать их на веб-странице, то мы добавим к этому запросу получатель запроса, который сообщит нам, когда наш запрос закончит обрабатываться и получит нужные данные.
Как можно понять из самого термина, запросы AJAX выполняются асинхронно. Это значит, что код JavaScript продолжает работать после отправки запроса и не ждет ответа. Прикрепив получатель запросов, мы можем перехватить ответ, когда он будет готов. Сделаем мы это вот так:
function requestListener() {
console.log(this.responseText);
}
request.addEventListener("load", requestListener);
Выше у нас есть функция, которая выводит ответ на консоль JavaScript, которую мы можем получить из атрибута responseText объекта XMLHttpRequests. Затем мы присоединяем эту функцию к событию load нашего запроса.
Следующий шаг – используем этот объект для отправки запроса к серверу с помощью метода open объекта XMLHttpRequests. Метод open принимает два параметра. Первый параметр – это используемый метод запроса. Ниже приведены несколько наиболее распространенных методов:
GET: этот метод используется для извлечения данных и является наиболее распространенным.
POST: этот метод отправляет данные запрошенному ресурсу и чаще всего используется для создания новых записей или для входа в систему.
PUT: этот метод заменяет текущие представления данных измененными, которые были отправлены в запросе.
PATCH: этот метод обычно используется для обновления части данных в запрошенном ресурсе.
DELETE: этот метод используется для удаления определенного ресурса.
Второй параметр, который передается методу open, - это запрашиваемый ресурс. Мы будем использовать страницу с веб-сайта example.org и использовать запрос GET для простого получения данных. Вот так это будет выглядеть:
request.open("GET", "http://www.example.org/example.txt");
Последний шаг – фактическая отправка запроса на удаленный ресурс с помощью метода send объекта XMLHttpRequests. Ниже приведен пример:
request.send();
Если мы используем метод POST, PUT или какой-либо другой метод, который обновляет ресурс, то этот метод мы вызываем с параметром, содержащем данные, которые мы отправляем:
request.send(OUR_DATA_VARIABLE)
В нашем случае мы только извлекаем данные, поэтому, как только мы выполним этот код, на консоли нашего веб-браузера выведется содержимое http://example.org/example.txt.
Данный пример помогает объяснить то, как работает AJAX, но на самом деле технология AJAX имеет куда более продвинутые функциональные возможности.
Для чего нужен AJAX?
Что вы должны были вынести из приведенного выше примера, так это то, что все функции кода загружаются на одной странице. Действительно, сначала загрузится веб-страница с нашим кодом JavaScript, затем он выполнится, и после он распечатает результаты запроса.
С таким же успехом можно было прикрепить приведенный выше код к функции, которая выполняется при нажатии кнопки. Это бы означало, что каждый раз при нажатии кнопки, будет выполняться код, отправляться запрос, и результаты будут выводиться на консоль без загрузки новой страницы.
И эта магическая технология изменила подход к веб-разработке. С появлением AJAX большая часть веб-разработки переместилась на внешний интерфейс приложения – часть, которая работает в браузере. Вы наблюдаете то, как работает AJAX ежедневно и даже не подозреваете об этом.
Когда вы заходите на современный веб-сайт, перед вами появляется форма. Вы вводите свои учетные данные и нажимаете кнопку «Войти». Индикатор загрузки может вращаться в течение нескольких минут, но если вы обратите внимание, то заметите, что страница на самом деле никогда не перезагружается. Все, что вы сделали, это просто отправили свое имя пользователя и пароль на сервер с помощью AJAX.
Индикатор загрузки нужен только для отвода глаз, пока запрос выполняется, независимо от того, ввели ли вы верные учетные данные или нет. Если ваши учетные данные верны, то ваша домашняя страница загружается, скорее всего, из другого запроса AJAX.
Большинство запросов AJAX в JavaScript не загружают целые веб-страницы, как в нашем примере. Данные отправляются и извлекаются в формате JSON, для представления данных используется текстовый формат, а для форматирования этих данных в формате HTML и их печати на странице используется дополнительный код JavaScript. Например, данные, которые отправляются для входа на веб-сайт, в формате JSON будут выглядеть так:
{ username: "MyUserName", password: "MyPassword" }
Как только учетные данные будут проверены, файл JSON, содержащий минимальный объем данных для отображения панели инструментов, будет отправлен обратно в браузер. AJAX в сочетании с JSON не только наделяет современные веб-страницы способностью быстро реагировать на действия пользователей, но и экономит пропускную способность, отправляя только необходимые данные для создания веб-страницы.
Мы продолжаем знакомить вас с одной из самых распространенных IP-АТС – 3CX Phone System и в сегодняшней статье более детально рассмотрим ее особенности и возможности.
По сути 3СХ Phone System – это программное обеспечение, готовый дистрибутив, который остается только установить на сервер и он станет полноценной IP-АТС, поддерживающей все сервисы VoIP. VoIP-система построенная на основе 3CX обычно включает в себя сервер, один или несколько терминалов, работающих по протоколу SIP, шлюз VoIP/PSTN или сервис VoIP провайдера. 3CX сервер выполняет те же функции, что и Proxy-сервер: SIP терминалы, будь то телефонные аппараты или софтфоны, регистрируются на сервере и когда они хотят инициировать вызов, то обращаются к серверу с запросом об установлении соединения. Proxy-сервер содержит базу данных всех телефонов/пользователей, которые прошли регистрацию, а также соответствующие SIP-адреса, по которым устанавливается внутренний вызов или же маршрутизируется внешний от VoIP/PSTN шлюза или провайдера VoIP.
3CX это Windows ориентированная система, то есть дистрибутив сервера может быть установлен только на рабочие станции с операционной системой Microsoft Windows, клиентом же может быть устройство с любой ОС (iOS, Android, Mac, Windows, Linux).
Ниже приведены поддерживаемые версии для 3CX Phone System:
- Windows 7 Professional (x86 & x64)
- Windows 7 Ultimate (x86 & x64)
- Windows 7 Enterprise (x86 & x64)
- Windows 8 Pro (x86 & x64)
- Windows 8 Enterprise (x86 & x64)
- Windows 8.1 Pro (x86 & x64)
- Windows 8.1 Enterprise (x86 & x64)
- Windows 2008 Web Server (x64 only)
- Windows 2008 (& R2) Foundation (x64 only)
- Windows 2008 (& R2) Standard (x64 only)
- Windows 2008 (& R2) Enterprise (x64 only)
- Windows 2008 (& R2) Datacenter (x64 only)
- Windows 2012 Foundation (max. 15 presence connections on IIS installations)
- Windows 2012 Essentials (max. 25 presence connections on IIS installations)
- Windows 2012 Standard
- Windows 2012 Datacenter
- Windows 2012 R2 Essentials (max. 25 presence connections on IIS installations)
- Windows 2012 R2 Standard
Кроме того 3CX Phone System можно устанавливать на виртуальную машину, что сокращает расходы на содержание аппаратной части. Ниже приведены поддерживаемые версии гипервизоров:
- VMware ESX 5.X и выше
- Microsoft HyperV 2008 R2 и выше
Как в аппаратной так и в виртуальной реализации, производительность системы будет зависеть от следующих факторов:
Как много одновременных вызовов будет проводиться? (Это также является основным критерием при выборе лицензии)
Как много пользователей будет одновременно подключаться к серверу?
Будет ли использоваться запись телефонных разговоров?
Будут ли использоваться услуги VoIP провайдера?
Осуществляется ли маршрутизация вызовов главным образом по очередям и IVR?
3CX Phone System имеет надежную утилиту, позволяющую сделать полнейший бэкап системы, включая ее конфигурацию и другие важные данные – Backup and Restore. Это необходимо главным образом при обновлении системы или же переносе сервисов на другой сервер или виртуальную машину. Имеется также возможность настройки бэкапирования 3CX по графику. То есть, в определенным момент времени, система будет делать полный бэкап текущего состояния и в случае нештатных ситуаций, запланированного обновления или переноса, можно будет заново развернуть все сервисы системы.
3CX Phone System поддерживает большое количество телефонных аппаратов и может автоматически определить, когда он подключается к серверу. Это существенно сокращает время настройки и введения в эксплуатацию нового оборудования. Список поддерживаемых устройств приведен ниже:
Рекомендованные:
Fanvil F52/F52P, C58/C58P, C62/C62P
Fanvil X3/X3P, X5/X5G
Htek UC802, UC803, UC804, UC806, UC840, UC842, UC860, UC862
snom 3 Series - 300, 320, 360, 370
snom 7 Series - 710, 715/D715, 720/D725, 760/D765
snom M300, M700 Dect (M300 Base, M700 Base)
Yealink T19P/E2, T20P, T21P/E2, T22P, T26P, T28P
Yealink T23P/G, T32G, T38G, T41P, T42G, T46G, T48G
Yealink VP530 Руководство по настройке, Yealink DECT W52P
Поддерживаемые:
- Cisco 7940/ 7941/ 7960 /7961 Руководство по настройке
- Cisco SPA 302, 303, 501G, 502G, 504G, 508G, 509G, 525G/G2
- Gigaset N510 IP PRO Руководство по настройке
- Panasonic KX-TGP500B01 (DECT)
- Polycom SoundPoint 320, 330 Polycom SoundPoint 321, 331, 335, 450, 550, 560, 650, 670
- Polycom SoundStation 5000, 6000, 7000
- snom MeetingPoint, snom PA1 – Public Announcement System, snom 8 Series - 820, 821, 870
Каждый SIP-терминал имеет инструкцию по настройке через веб-интерфейс, или же, может быть автоматически настроенным с помощью удаленного интерфейса 3CX Phone System с помощью функции Provisioning.
За каждым SIP-терминалом (пользователем) закрепляется свой добавочный номер (Extension), по которому он будет доступен для звонка во внутренней сети или же из внешней с введением общего номера.
Управление Extension’ами осуществляет Администратор системы. Администратор может редактировать правила для каждого Пользователя, разрешать или запрещать пользоваться некоторыми функциями системы, запускать сбор статистической информации с каждого Extension’а и другие:
- Записывать все разговоры на данном Extension
- Отправлять автоматическое письмо о пропущенном звонке
- Скрыть Extension в адресной книге
- Отключить Extension
- Разрешить/запретить проводить внешние/внутренние вызовы
- Разрешить проведение вызовов только после ввода PIN
- Запретить регистрацию Extension вне сети
И многое другое.
Перед начало убедитесь, что ознакомились с материалом про построение деревьев в сетях.
Правило кратчайшего пути, является скорее отрицательным, чем положительным экспериментом; его всегда можно использовать для поиска пути без петель среди набора доступных путей, но не для определения того, какие другие пути в наборе также могут оказаться свободными от петель. Рисунок 4 показывает это.
На рисунке 4 легко заметить, что кратчайший путь от A до пункта назначения проходит по пути [A, B, F]. Также легко заметить, что пути [A, C, F] и [A, D, E, F] являются альтернативными путями к одному и тому же месту назначения. Но свободны ли эти пути от петель? Ответ зависит от значения слова "без петель": обычно путь без петель - это такой путь, при котором трафик не будет проходить через какой-либо узел (не будет посещать какой-либо узел в топологии более одного раза). Хотя это определение в целом хорошее, его можно сузить в случае одного узла с несколькими следующими переходами, через которые он может отправлять трафик в достижимый пункт назначения. В частности, определение можно сузить до:
Путь является свободным от петель, если устройство следующего прыжка не пересылает трафик к определенному месту назначения обратно ко мне (отправляющему узлу).
В этом случае путь через C, с точки зрения A, можно назвать свободным от петель, если C не пересылает трафик к месту назначения через A. Другими словами, если A передает пакет C для пункта назначения, C не будет пересылать пакет обратно к A, а скорее пересылает пакет ближе к пункту назначения. Это определение несколько упрощает задачу поиска альтернативных путей без петель. Вместо того, чтобы рассматривать весь путь к месту назначения, A нужно только учитывать, будет ли какой-либо конкретный сосед пересылать трафик обратно самому A при пересылке трафика к месту назначения.
Рассмотрим, например, путь [A, C, F]. Если A отправляет пакет C для пункта назначения за пределами F, переправит ли C этот пакет обратно в A? Доступные пути для C:
[C, A, B, F], общей стоимостью 5
[C, A, D, E], общей стоимостью 6
[C, F], общей стоимостью 2
Учитывая, что C собирается выбрать кратчайший путь к месту назначения, он выберет [C, F] и, следовательно, не будет пересылать трафик обратно в A. Превращая это в вопрос: почему C не будет перенаправлять трафик обратно в A? Потому что у него есть путь, стоимость которого ниже, чем у любого пути через A до места назначения. Это можно обобщить и назвать downstream neighbor:
Любой сосед с путем, который короче локального пути к месту назначения, не будет возвращать трафик обратно ко мне (отправляющему узлу).
Или, скорее, учитывая, что локальная стоимость представлена как LC, а стоимость соседа представлена как NC, тогда:
Если NC LC, то тогда neighbor is downstream.
Теперь рассмотрим второй альтернативный путь, показанный на рисунке 4: [A, D, E, F]. Еще раз, если A отправляет трафик к пункту назначения к D, будет ли D зацикливать трафик обратно к A?
Имеющиеся у D пути:
[D, A, C, F], общей стоимостью 5
[D, A, B, F], общей стоимостью 4
[D, E, F], общей стоимостью 3
Предполагая, что D будет использовать кратчайший доступный путь, D будет пересылать любой такой трафик через E, а не обратно через A. Это можно обобщить и назвать альтернативой без петель (Loop-Free Alternate -LFA):
Любой сосед, у которого путь короче, чем локальный путь к месту назначения, плюс стоимость доступа соседа ко мне (локальный узел), не будет возвращать трафик обратно ко мне (локальному узлу).
Или, скорее, учитывая, что локальная стоимость обозначена как LC, стоимость соседа обозначена как NC, а стоимость обратно для локального узла (с точки зрения соседа) - BC:
Если NC + BC LC, то сосед - это LFA.
Есть две другие модели, которые часто используются для объяснения Loop-Free Alternate: модель водопада и пространство P/Q. Полезно посмотреть на эти модели чуть подробнее.
Модель водопада (Waterfall (or Continental Divide) Model).
Один из способов предотвратить образование петель в маршрутах, рассчитываемых плоскостью управления, - просто не объявлять маршруты соседям, которые пересылали бы трафик обратно мне (отправляющему узлу). Это называется разделенным горизонтом (split horizon). Это приводит к концепции трафика, проходящего через сеть, действующую как вода водопада или вдоль русла ручья, выбирая путь наименьшего сопротивления к месту назначения, как показано на рисунке 5.
На рисунке 5, если трафик входит в сеть в точке C (в источнике 2) и направляется за пределы E, он будет течь по правой стороне кольца. Однако, если трафик входит в сеть в точке A и предназначен для выхода за пределы E, он будет проходить по левой стороне кольца. Чтобы предотвратить зацикливание трафика, выходящего за пределы E, в этом кольце, одна простая вещь, которую может сделать плоскость управления, - это либо не позволить A объявлять пункт назначения в C, либо не позволить C объявлять пункт назначения в A. Предотвращение одного из этих двух маршрутизаторов от объявления к другому называется разделенным горизонтом (split horizon), потому что это останавливает маршрут от распространения через горизонт, или, скорее, за пределами точки, где любое конкретное устройство знает, что трафик, передаваемый по определенному каналу, будет зациклен.
Split horizon реализуется только за счет того, что устройству разрешается объявлять о доступности через интерфейсы, которые оно не использует для достижения указанного пункта назначения. В этом случае:
D использует E для достижения пункта назначения, поэтому он не будет объявлять о доступности в направлении E
C использует D для достижения пункта назначения, поэтому он не будет объявлять о доступности D
B использует E для достижения пункта назначения, поэтому он не будет объявлять о доступности в направлении E
A использует B для достижения пункта назначения, поэтому он не будет объявлять о доступности B
Следовательно, A блокирует B от знания альтернативного пути, который он имеет к месту назначения через C, а C блокирует D от знания об альтернативном пути, который он имеет к месту назначения через A. Альтернативный путь без петель пересекает этот разделенный горизонт. точка в сети. На рис. 12-5 A может вычислить, что стоимость пути C меньше стоимости пути A, поэтому любой трафик A, направляемый в C к месту назначения, будет перенаправлен по какому-то другому пути, чем тот, о котором знает A. C, в терминах LFA, является нижестоящим соседом A.
Следовательно, A блокирует B от знания об альтернативном пути, который он имеет к месту назначения через C, и C блокирует D от знания об альтернативном пути, который он имеет к месту назначения через A. Альтернативный путь без петли будет пересекать эту точку split horizon в сети. На рисунке 5 A может вычислить, что стоимость пути C меньше стоимости пути A, поэтому любой трафик A, направленный в C к месту назначения, будет перенаправлен по какому-то другому пути, чем тот, о котором знает A. В терминах LFA, С является нижестоящим соседом (downstream neighbor) A.
P/Q пространство
Еще одна модель, описывающая, как работают LFA, - это пространство P / Q.
Рисунок 6 иллюстрирует эту модель.
Проще всего начать с определения двух пространств.
Предполагая, что линия связи [E, D] должна быть защищена от сбоя:
Рассчитайте Shortest Path Tree из E (E использует стоимость путей к себе, а не стоимость от себя, при вычислении этого дерева, потому что трафик течет к D по этому пути).
Удалите линию связи [E,D] вместе с любыми узлами, доступными только при прохождении через эту линию.
Остальные узлы, которых может достичь E, - это пространство Q.
Рассчитайте Shortest Path Tree из D.
Удалите канал [E, D] вместе со всеми узлами, доступными только при прохождении по линии.
Остальные узлы, которых может достичь D, находятся в пространстве P.
Если D может найти маршрутизатор в пространстве Q, на который будет перенаправляться трафик в случае отказа канала [E, D]- это LFA.
Удаленные (remote) Loop-Free Alternates
Что делать, если нет LFA? Иногда можно найти удаленную альтернативу без петель (remote Loop-Free Alternate - rLFA), которая также может передавать трафик к месту назначения. RLFA не подключен напрямую к вычисляющему маршрутизатору, а скорее находится на расстоянии одного или нескольких переходов. Это означает, что трафик должен передаваться через маршрутизаторы между вычисляющим маршрутизатором и remote next hop. Обычно это достигается путем туннелирования трафика.
Эти модели могут объяснить rLFA, не обращая внимания на математику, необходимую для их расчета. Понимание того, где кольцо "разделится" на P и Q, или на две половины, разделенные split horizon, поможет вам быстро понять, где rLFA можно использовать для обхода сбоя, даже если LFA отсутствует. Возвращаясь к рисунку 6, например, если канал [E, D] выходит из строя, D должен просто ждать, пока сеть сойдется, чтобы начать пересылку трафика к месту назначения. Лучший путь от E был удален из дерева D из-за сбоя, и E не имеет LFA, на который он мог бы пересылать трафик.
Вернитесь к определению loop-free path, с которого начался этот раздел-это любой сосед, к которому устройство может перенаправлять трафик без возврата трафика. Нет никакой особой причины, по которой сосед, которому устройство отправляет пакеты в случае сбоя локальной линии связи, должен быть локально подключен. В разделе "виртуализация сети" описывается возможность создания туннеля или топологии наложения, которая может передавать трафик между любыми двумя узлами сети.
Учитывая возможность туннелирования трафика через C, поэтому C пересылает трафик не на основе фактического пункта назначения, а на основе заголовка туннеля, D может пересылать трафик непосредственно на A, минуя петлю. Когда канал [E, D] не работает, D может сделать следующее:
Вычислите ближайшую точку в сети, где трафик может быть туннелирован и не вернется к самому C.
Сформируйте туннель к этому маршрутизатору.
Инкапсулируйте трафик в заголовок туннеля.
Перенаправьте трафик.
Примечание. В реальных реализациях туннель rLFA будет рассчитываться заранее, а не рассчитываться во время сбоя. Эти туннели rLFA не обязательно должны быть видимы для обычного процесса пересылки. Эта информация предоставлена для ясности того, как работает этот процесс, а не сосредоточен на том, как он обычно осуществляется.
D будет перенаправлять трафик в пункт назначения туннеля, а не в исходный пункт назначения - это обходит запись локальной таблицы переадресации C для исходного пункта назначения, что возвращает трафик обратно в C. Расчет таких точек пересечения будет обсуждаться в чуть позже в статьях, посвященных первому алгоритму кратчайшего пути Дейкстры.