FreePBX пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅ
Слишком длинный поисковый запрос.
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Управление кэш-памятью определяет поведение кэширования для веб-сайта, давая браузерам понять, как часто следует обновлять локально хранящиеся ресурсы.
Что такое cache-control?
Cache-control – это HTTP-заголовок, который определяет поведение браузера при кэшировании. Проще говоря, когда кто-то посещает веб-сайт, то его браузер сохраняет определенные ресурсы, такие как изображения и данные веб-сайта, в хранилище, которое называется кэш. Когда пользователь вновь посещает этот веб-сайт, то cache-control диктует правила, которые определяют, будут ли эти ресурсы загружены из локального кэша данного пользователя, или браузер должен отправить запрос на сервер для получения новых ресурсов. Для более глубокого понимания, что такое cache-control необходимо базовое понимание того, что такое кэширование в браузере и что такое HTTP-заголовки.
Что такое кэширование в браузере?
Как уже было описано выше, кэширование в браузере – это когда веб-браузер сохраняет ресурсы веб-сайта, чтобы не запрашивать их вновь с сервера. Например, фоновое изображение веб-сайта может быть сохранено локально в кэше, чтобы при повторном посещении пользователем данного веб-сайта изображение загружалось из локальных файлов пользователя, и тем самым страница загружалась бы быстрее.
Браузеры хранят эти ресурсы в течение определенного периода времени, известного как время жизни информации (TTL - Time To Live). Если пользователь запросит кэшированный ресурс после истечения TTL, то браузеру придется снова обратиться к серверу, чтобы загрузить новую копию ресурса. Как браузеры и веб-серверы узнают TTL для каждого ресурса? Вот здесь в игру вступают HTTP-заголовки.
Что такое HTTP-заголовки?
Протокол передачи гипертекста (HTTP - Hypertext Transfer Protocol) представляет собой синтаксис для обмена данными во Всемирной паутине, и этот обмен данными состоит из запросов от клиентов к серверам и ответов от серверов к клиентам. Каждый из HTTP-запросов и ответов содержит ряд пар «ключ-значение», которые называют заголовками.
Заголовки содержат большое количество важной информации о каждом сообщении. Например, заголовок запроса обычно содержит:
Информацию о том, какой ресурс запрашивается
Информацию о том, какой браузер использует клиент
Информацию о том, какие форматы данных примет клиент
Заголовки ответов обычно содержат информацию о:
Успешности выполнения запроса
Языке и формате любых ресурсов в теле ответа
Заголовок cache-control может использоваться как в HTTP-запросах, так и в HTTP-ответах.
Что находится внутри заголовка cache-control?
Заголовки состоят из пар «ключ-значение», разделенных двоеточием. Для cache-control «ключ», или часть слева от двоеточия, - это всегда «cache-control». «Значение» - это то, что находится справа от двоеточия. Значений для cache-control может быть несколько, или оно может быть одно. Если их несколько, то они разделяются запятыми.
Эти значения называются директивами, и они определяют, кто может кэшировать ресурс, а также как долго эти ресурсы могут быть кэшированными, прежде чем их необходимо будет обновить. Давайте рассмотрим несколько наиболее распространенных директив cache-control:
cache-control: private
Ответ с директивой private может быть кэширован только клиентом, но никак не посредником, таким как CDN или прокси-сервером. Часто сюда относятся ресурсы, которые содержат личные данные, например, веб-сайт, отображающий личную информацию пользователя.
cache-control: public
Здесь наоборот, директива public говорит о том, что ресурс может хранится в любом кэше.
cache-control: no-store
Ответ с директивой no-store нельзя кэшировать нигде и никогда. Это означает, что при каждом запросе пользователем этих данных, требуется отправить запрос на исходный сервер для их получения. Эта директива, как правило, используется для ресурсов, содержащих конфиденциальные данные, например, информацию о банковском счете.
cache-control: no-cache
Эта директива означает, что кэшированные версии запрошенного ресурса нельзя использовать без предварительной проверки наличия обновленной версии. Обычно это делается с помощью ETag.
ETag – это еще один HTTP-заголовок, который содержит маркер, уникальный для версии ресурса на момент его запроса. Этот маркер меняется на исходном сервере при каждом обновлении ресурса.
Когда пользователь возвращается на страницу с ресурсом под директивой no-cache, клиенту всегда придется подключаться к исходному серверу и сравнивать ETag на кэшированном ресурсе с ETag на сервере. Если они совпадают, то кэшированный ресурс предоставляется пользователю. В противном случае, это означает, что ресурс был обновлен, и клиенту необходимо загрузить обновленную версию, чтобы иметь возможность предоставить его пользователю. Этот процесс гарантирует, что пользователь всегда будет получать самую последнюю версию ресурса без ненужных постоянных загрузок.
cache-control: max-age
Эта директива определяет время жизни информации, или, иными словами, сколько секунд ресурс может находиться в кэше после его загрузки. Например, если max-age установлен на 1800, то это значит, что в течение 1800 секунд (30 минут) после того, как ресурс был впервые запрошен с сервера, пользователю будет предоставляться кэшированная версия этого ресурса при последующих запросах. Если пользователь запросит этот ресурс снова по истечении этих 30 минут, то клиенту необходимо будет запросить новую копию с исходного сервера.
Директива s-maxage предназначена специально для общих кэшей, таких как CDN. Она определяет, как долго эти общие кэши могут продолжать обслуживать ресурс из кэша. Эта директива отменяет действие директивы max-age для некоторых клиентов.
Почему cache-control так важен?
Кэширование в браузере – это отличный способ сохранить ресурсы и, тем самым, улучшить процесс взаимодействия с пользователем в Интернете, но без cache-control этот процесс не был бы столь надежным. Все ресурсы на всех сайтах будут использовать одни и те же правила кэширования, а это значит, что конфиденциальная информация будет кэшироваться также, как и общедоступная информация, а ресурсы, которые часто обновляются, будут кэшироваться на то же время, что и ресурсы, которые редко обновляются.
Cache-control добавляет гибкости, которая делает кэширование в браузере действительно полезным, позволяя разработчикам определять, как будет кэшироваться каждый ресурс. Этот заголовок также позволяет разработчикам устанавливать определенные правила для посредников, что является причиной, по которой сайты, которые используют CDN, как правило, работают лучше, чем сайты, которые этого не делают.
В сегодняшней статье рассмотрим модуль, который стал доступен во FreePBX только с версии 13 и который позволяет создать первичную низкоуровневую защиту нашей IP-АТС - Firewall. Нужно отметить, что попытки создать нечто подобное на ранних версиях FreePBX всё-таки были, но все они не увенчались успехом и заставляли пользователей так или иначе идти на компромиссы для сохранения доступности функционала IP-АТС. Модуль Firewall был разработан с глубоким пониманием существующих проблем и его основной целью является защита “средней”, или другими словами, типовой инсталляции при обязательном сохранении VoIP сервисов.
/p>
Данный модуль отслеживает и блокирует атаки, пропуская при этом разрешенный трафик, а также непрерывно контролирует конфигурацию системы, автоматически открывая и закрывая порты для необходимых транков.
Настройка модуля Firewall
Перейдём к настройке. Для того, чтобы попасть в модуль, нужно перейти по следующему пути: Connectivity -> Firewall, откроется следующее окно:
Чтобы включить модуль, нажмите кнопку Enable Firewall. Обратите внимание, после включения модуля никакие правила ещё не задействованы, их нужно настроить.
Первое о чём сообщает модуль, это то, что IP-адрес, под которым мы зашли на IP-АТС не является членом “зоны доверия” (Trusted Zone) и предлагает добавить его для исключения возможных блокировок:
Для наибольшего понимания, давайте разберёмся с понятием зоны (Zone), которым оперирует модуль Firewall.
Все сетевые соединения, поступающие на VoIP-сервер считаются частью зоны. Каждый сетевой интерфейс и данные, поступающие на него принадлежат к определенной зоне. Стандартные зоны делятся на следующие:
Reject - Все соединения, относящиеся к данной зоне, запрещены. Обратите внимание, что эта зона по-прежнему принимает RTP трафик, но никакие другие порты по умолчанию не прослушиваются. Трафик данной зоны может быть обработан с помощью Responsive Firewall, о котором будет сказано далее.
External - Позволяет только https соединения для доступа к интерфейсу управления и UCP порту, если они определены. Трафик данной зоны может также быть обработан с помощью Responsive Firewall
Other - Используется на доверенных внешних сетях, или других хорошо известных сетях. По умолчанию, позволяет получить доступ к UCP, а также обеспечивает нефильтрованный SIP и IAX.
Internal - Используется на внутренних локальных сетях, по умолчанию позволяет получить доступ ко всем сервисам IP-АТС.
Trusted - Все сетевые соединения данной зоны разрешены. Пропускается весь трафик от доверенной зоны. Именно сюда нам предложат добавить наш IP-адрес при первом включении модуля.
Итак, чтобы добавить наш IP-адрес в список доверенных, нужно нажать You can add the host automatically here.
Мы попадём во вкладку Preconfigured. Предлагается два варианта, это добавление адреса хоста и добавление подсети Add Host и Add Network соответственно:
Проверить, что адрес (или сеть) добавлены в список доверенных можно во вкладке Zones в разделе Networks.
В модуле Firewall есть также дополнительный элемент, который отслеживает сигнализационные запросы определённых сервисов и блокирует возможные атаки - Responsive Firewall. Такими запросами могут быть запросы протоколов сигнализации SIP или IAX, например, запросы авторизации или вызова. Когда Responsive включен, то любой сигнализационный пакет исходящий от хоста проходит через Firewall, если после некоторого количества таких пакетов, хост отправлявший их не прошёл успешную регистрацию, то весь трафик от этого хоста сбрасывается на короткий промежуток времени (60 сек). Если после данной блокировки хост продолжает слать пакеты с запросом регистрации и безуспешно пытается зарегистрироваться, то блокируется уже его IP-адрес на 24 часа. Кроме того, если на сервере настроен fail2ban, то система ещё и письмо отправит о данном событии.
Чтобы включить данный функционал, на вкладке Responsive нужно нажать на кнопку Enable:
Далее необходимо указать, для каких протоколов должен работать данный функционал:
Известные IP-адреса или даже целые подсети, которые проявляли подозрительную активность и которые не должны иметь доступа к IP-АТС можно заблокировать во вкладке Zones -> Blacklists.
И последний по счёту, но не по значимости, функционал модуля Firewall, о котором хотелось бы рассказать - Safe Mode. Данный функционал позволяет получить доступ к IP-АТС если случайно была применена неправильная конфигурация, которая привела к потере доступа, а доступа к консоли у вас нет.
При включении модуля Firewall, Safe Mode уже доступен, но чтобы его активировать, необходимо дважды перезапустить систему. Сначала необходимо выполнить перезапуск один раз, дождаться, пока сервер полностью загрузится, а затем произвести вторую перезагрузку. После чего, система отложит загрузку правил Firewall’а, а вы сможете спокойно убрать ту конфигурацию, из-за которой потеряли доступ.
О том, что система находится в Safe Mode, будет говорить огромное уведомление в самом верху страницы, которое исчезнет через пять минут, тогда же запустятся правила Firewall.
API расшифровывается как Application Programming Interface (программный интерфейс приложения). Что же это такое?
По сути, это описание способов взаимодействия между программами, как они могут общаться и передавать данные друг другу.
Рассмотрим пример из жизни:
Приходя в ресторан вы взаимодействуйте с официантом - можете попросить меню, сделать заказ, попросить принести счет. Официант является интерфейсом вашего взаимодействия с рестораном - вам не нужно знать о том как готовится еда, ингредиенты, как рассчитывать чек, все это сделает ресторан, и отдаст вам результаты при помощи официанта, который в этом примере представляет собой API ресторана. От вас скрываются сложные детали и просто происходит общение между двумя системами - клиентом и рестораном.
Вернемся к компьютерам. Предположим, что у нашей платформы доступного айти образования Merion Academy есть интерфейс работы с клиентами - тот самый API, в котором есть определенные функции, куда можно отправить какой - то запрос, и получить ответ. Представим, что у нашего API есть функция вернуть список курсов по Linux, на которые сейчас действует скидка 50% - в такой случае браузер должен сделать запрос к нашему API на получение такого списка курсов, а ответ получить эти данные и отрисовать на странице.
Важно учесть, что API интерфейсы не всемогущи - вы получите только те функции, которые заложил разработчик. Например, если помимо курсов по Linux со скидкой 50% вы захотите еще получить прогноз погоды в селе “Добрые Пчёлы” - то сорри, наш API пока так не умеет. Для добавления каждой такой новой функции программист должен разработать ее.
API состоит из двух частей: это сам интерфейс взаимодействия, скажем так некий мост, портал, окно, а вторая часть - это его описание, которое отвечает на вопрос “а как этой штукой то пользоваться?”
Взаимодействие может быть не только между клиентом и сервером, как в примере с нашей ИТ платформой, но и между серверами. Представьте: решили вы полететь в солнечный Дубай, купили билетик на сайте, а он вам еще и погоду показывает. Как же так! Неужели у компании по продаже билетов еще и метеорологические датчики по всему миру стоят, которые сообщают о погоде? Конечно нет - сайт с билетами взаимодействует с каким - то сервисом погоды по API, который как раз занимается погодными данными. А сайт с билетиками еще и скорее всего платит за каждый запрос небольшую денюжку.
Кстати, API может быть не только у веб - сервисов, где общение происходит по протоколу HTTP. API есть и у операционных систем, для взаимодействия с самой операционкой и железом. Например, если вы создаете свой аналог инстаграма, то для работы с камерой на устройстве вам нужно взаимодействовать с API системы, которая уже знает как работать с камерой, а не придумывать что-то самому с нуля, да еще и для миллиона разных устройств.
API действительно делает жизнь разработчика удобнее, а чтобы работа с API не превратилась в бардак, оно стандартизировано. Самый популярный, это конечно же REST API, но перед тем как перейти к нему, скажем пару слов про SOAP (Service Object Access Protocol), который появился несколько раньше и описывал правила синтаксиса для сообщений запросов и ответов, отправляемых веб-приложениями. Подробнее про SOAP - тут.
Ну и все, кто поддерживал SOAP должны были обмениваться XML-сообщениями между системами через HTTP или SMTP. XML (Extensible Markup Language), он же расширяемый язык разметки - это формат для хранения и передачи данных, в котором данные размещены в тегах, что делает их легко читаемыми как для компьютера, так и для человека.
Развиваясь, люди перешли на REST, который в отличии от SOAP не является протоколом, а является архитектурным стилем. В SOAP приходилось писать в разы больше кода и заворачивать каждое сообщение в XML.
REST же делает данные доступными в качестве ресурсов, которые представлены уникальным URL-адресом, и можно запросить этот ресурс, указав его URL-адрес. Например чтобы посмотреть свои подписки на ютубе нужно выполнить запрос на вот такой адрес https://www.youtube.com/feed/subscriptions.
Веб-API, соответствующие стандартам подхода REST, называются RESTful API. Они используют различные HTTP-запросы для работы с ресурсами, такие как GET - запрос, который используется для получения информации или POST, который в свою очередь нужен для отправки данных.
RESTful системы поддерживают обмен сообщениями в различных форматах, таких как самый обычный текст, HTML формат, YAML, XML и JSON, в то время как SOAP разрешает только XML, как мы и сказали ранее. Самый популярный это конечно JavaScript Object Notation, он же JSON - простой и универсальный формат, который содержит в себе набор пар ключ:значение.
Также хотим сказать про штуку, которая называется gRPC (Remote Procedure Calls) которая в основном используется для связи между разными сервисами и работает очень быстро благодаря тому что тут используется протокол HTTP/2 который работает гораздо быстрее засчет всяких новинок вроде сжатия хедеров, а вместо JSON или XML используется формат Protocol Buffers (protobuf), который работает быстрее и потребляет меньше ресурсов при работе с ним. Работает все это настолько быстро, что можно делать вызов к функции на другом сервере с такой же скоростью, как если бы она находилась на нашем. Подробнее про gRPC и Protobuf - тут
Ну и не можем не сказать про модный GraphQL - это язык запросов для API который позволяет указывать точные данные, которые ему нужны, и упрощает получение и склейку данных из нескольких источников, поэтому разработчик может использовать один вызов API для запроса всех необходимых ему данных.