URL-фильтрация — Service Gateway Engine
URL-фильтрация — Service Gateway Engine — RDPEcoFilterВысокопроизводительная URL-фильтрация (URL filtering) запрещенных сайтов по реестрам Роскомнадзора (РКН), Минюста, а также нежелательных сайтов по реестру ЦАИР (www.cair.ru) и пользовательским спискам.
Документация EcoFilter
- Техническая спецификация: URL-фильтрация ( 688,4 КБ )
- Руководство по установке и конфигурированию ( 3,0 МБ )
- Свидетельство о гос.
регистрации программы для ЭВМ
(
333,7 КБ ) - Сертификат соответствия в области связи ( 475,9 КБ )
- Сертификат соответствия EAC (Таможенный союз) ( 1,1 МБ )
регистрации программы для ЭВМ
(
333,7 КБ )Таблицу можно прокручивать по горизонтали
| 1010 / 2010 / 2020 | 2040 | 4080 | 4120 / 4160 | 5200 | |
|---|---|---|---|---|---|
| Платформа | |||||
| Производительность* | 6 / 12 до 24 Гбит/с | 34 Гбит/с | 60 Гбит/с | 120 / 160 Гбит/с | 200 Гбит/с |
| Форм-фактор | 1 U | 1 U | 1 U | 1 U | 1 U |
Новых подключений в сек. | 2,3 млн | 2,3 млн | 2,5 млн | 5 млн | 5 млн |
| Одновременных сессий | 32 млн | 32 млн | 40 млн | 150 млн | 150 млн |
| Сетевые интерфейсы | |||||
| — 1 GE Copper | 6 | 6 | 0 | 0 | |
| — 10 GE Fiber (SFP+) | 2 | 4 | 8 | 12 / 16 | 0 |
| — 100 GE Fiber (QSFP28) | 0 | 0 | 0 | 0 | 2 |
| Интерфейс логирования | 1 x 10/100/1000BaseT | 1 x 10/100/1000BaseT | 1 x 10/100/1000BaseT | 1 x 10/100/1000BaseT | 1 x 10/100/1000BaseT |
| Интерфейс управления | 1 x 10/100/1000BaseT | 1 x 10/100/1000BaseT | 1 x 10/100/1000BaseT | 1 x 10/100/1000BaseT | 1 x 10/100/1000BaseT |
| Консольный порт | RJ45 (RS232C) | RJ45 (RS232C) | RJ45 (RS232C) | RJ45 (RS232C) | |
| Система хранения данных | CF Industrial SLC | CF Industrial SLC | CF Industrial SLC | CF Industrial SLC | CF Industrial SLC |
| Потребление (рабочее / максимальное) | 140 / 170 Вт | 140 / 170 Вт | 250 / 285 Вт | 340 / 400 Вт | 400 Вт |
| Блок питания | Dual 200W RPS 100-240 VAC (-36-72 DC) | Dual 200W RPS 100-240 VAC (-36-72 DC) | Dual 500W RPS 100-240 VAC (-40-72 DC) | Dual 500W RPS 100-240 VAC (-40-72 DC) | Dual 500W RPS 100-240 VAC (-40-72 DC) |
| Охлаждение | Standard Fans | Standard Fans | Hot Swap Smart Fans | Hot Swap Smart Fans | Hot Swap Smart Fans |
| Размеры (Ш х Д х В) | 430 x 400 x 44 мм | 430 x 400 x 44 мм | 440 x 576 x 44 мм | 440 x 576 x 44 мм | 440 x 576 x 44 мм |
* Пакетная производительность достаточна для работы «на скорости проводов» при среднем размере пакетов 480 байт. | |||||
Бесплатное тестирование и настройка оборудования
Подайте заявку и мы бесплатно предоставим свое оборудование для тестирования в вашей сети.
Подать заявку
Советы по REST API
Будь то RESTful или нет (в соответствии с шестью ограничениями, описанными ранее), вот несколько рекомендованных REST концепций, которые помогут построить более хорошие и удобные сервисы:
Используйте HTTP-глаголы, чтобы ваши запросы имели понятное значение
Пользователи API должны иметь возможность отправлять команды GET, POST, PUT и DELETE, что значительно повышает ясность того, что делает запрос.
Как правило, четыре основных HTTP-глагола используются следующим образом:
- GET
- Прочитать конкретный ресурс (по идентификатору) или набор ресурсов
- PUT
- Обновить конкретный ресурс (по идентификатору) или набор ресурсов. Также может использоваться для создания определенного ресурса, если идентификатор ресурса известен заранее
- DELETE
- Удалить конкретный ресурс по идентификатору
- POST
- Создать новый ресурс. Также универсальное действие для операций, которые не вписываются в другие категории
Также универсальное действие для операций, которые не вписываются в другие категорииПримечание
GET-запросы не должны изменять данные базовых ресурсов. При этом может выполняться отслеживание, приводящее к обновлению данных, но данные ресурса, идентифицированного данным URI, не должны изменяться.
Давайте ресурсам продуманные имена
Создание хорошего API — это на 80% искусство и на 20% наука. Создание иерархии осмысленных URL-адресов относится к искусству. Рациональное наименование ресурсов (названия которых представляют собой просто URL-пути, такие как /customers/12345/orders) улучшает понимание того, что делает данный запрос.
Подходящие названия ресурсов предоставляют контекст для запроса и делают API сервиса более понятным. Ресурсы должны просматриваться иерархически по их именам. Пользователям должна предлагаться удобная, легко понимаемая иерархия ресурсов для использования в их приложениях.
Вот несколько простых правил для дизайна URL-пути (имени ресурса):
Используйте идентификаторы в URL-адресах, а не в строке запроса.
Хорошо: /users/12345
Плохо: /api?type=user&id=23
URL-адреса иерархичны, пользуйтесь этим для задания структуры ресурсов
Дизайн сервиса должен быть ориентирован на ваших клиентов, а не на ваши данные
Имена ресурсов должны быть существительными. Избегайте глаголов в именах ресурсов, это позволит сделать их яснее. Используйте методы HTTP, чтобы указать, какое действие выполняет запрос
Используйте множественное число в соответствующих сегментах URL-адресов, чтобы обеспечить согласованность URI вашего API во всех HTTP-методах, применяя метафору коллекции
Хорошо: /customers/33245/orders/8769/lineitems/1
Плохо: /customer/33245/order/8769/lineitem/1
Избегайте использования наборов слов в URL-адресах (например, customer_list в качестве ресурса).
Используйте множественное число для названий коллекцийХорошо: /customers
Плохо: /customer_list
Используйте строчные буквы в URL, разделяя слова подчеркиванием («_») или дефисом («-«). Некоторые серверы игнорируют регистр, поэтому лучше четко придерживаться нижнего регистра
Старайтесь, чтобы URL-адреса были как можно короче и содержали как можно меньше сегментов
Используйте множественное число для названий коллекцийИспользуйте коды HTTP-ответов для указания статуса
Коды ответа являются частью спецификации HTTP. Для описания самых распространенных ситуаций существует большой набор HTTP-ответов.
Поскольку наши RESTful сервисы следуют спецификации HTTP, наши веб-API должны возвращать коды состояний HTTP. Например, когда ресурс успешно создан с помощью запроса POST, API должен вернуть код состояния HTTP 201. Полный список возможных кодов состояния HTTP c подробным описанием доступен здесь.
Top 10 кодов состояния HTTP-ответа:
- 200 ОК
- Код, указывающий на успешное выполнение запроса и чаще всего встречающийся на практике
- 201 CREATED
- Ресурс успешно создан (через POST или PUT). Установите заголовок Location со ссылкой на вновь созданный ресурс (при POST). Тело ответа может быть как пустым, так и содержать что-то
- 204 NO CONTENT
- Запрос выполнен успешно, но в теле ответа нет данных. Часто используется для операций DELETE и PUT
- 400 BAD REQUEST
- Общая ошибка, когда при выполнении запроса возникает недопустимое состояние. Примеры — ошибки проверки домена, отсутствующие данные и т.д.
- 401 UNAUTHORIZED
- Код ошибки для отсутствующего или недопустимого токена аутентификации
- 403 FORBIDDEN
- Код ошибки, когда пользователь не авторизован для выполнения операции или ресурс недоступен по какой-либо причине (например, ограничения по времени и т. п.)
- 404 NOT FOUND
- Этот код используется, когда запрошенный ресурс не найден. Ресурс не существует, либо была ошибка 401 или 403, которую по соображениям безопасности сервис хочет скрыть
- 405 METHOD NOT ALLOWED
- Используется для указания на то, что запрошенный URL-адрес существует, но используемый HTTP-метод неприменим. Например, POST /users/12345, где API не поддерживает создание ресурсов таким образом (с предоставленным идентификатором). При возврате ошибки 405 должен быть установлен HTTP-заголовок Allow, указывающий на поддерживаемые методы HTTP. В примере выше заголовок выглядел бы как «Allow: GET, PUT, DELETE»
- 409 CONFLICT
- Этот код ошибки отправляется всякий раз, когда выполнение запроса может привести к конфликту ресурсов. Примеры таких ситуаций — двойные записи, например, попытка создать двух клиентов с одинаковой информацией; удаление корневых объектов, когда не поддерживается каскадное удаление
- 500 INTERNAL SERVER ERROR
- Никогда не отправляйте этот код вручную. Это общая ошибка, когда на стороне сервера выбрасывается какое-то исключение. Этот код должен использоваться только для ошибок, которые пользователь не может устранить со своей стороны
п.)
Это общая ошибка, когда на стороне сервера выбрасывается какое-то исключение. Этот код должен использоваться только для ошибок, которые пользователь не может устранить со своей стороныXML и JSON
Если вы не работаете в строго стандартизированной и регулируемой отрасли, лучше поддерживать JSON. Но если вас ничто не сковывает, позвольте пользователям выбирать в каком формате получать данные — JSON или XML. У пользователей должна быть возможность переключаться между ними с помощью HTTP-заголовка Accept или просто изменив расширение с .xml на .json.
Имейте в виду, что как только мы начинаем говорить о поддержке XML, мы начинаем говорить о валидации, пространствах имен и т.д. Если этого не требует ваша отрасль, избегайте поддержки всех этих усложнений. По крайней мере, вначале. А если в этом функционале нет острой необходимости, то всегда. JSON является простым, лаконичным и функциональным. Сделайте так, чтобы ваш XML выглядел так же, если это возможно.
Другими словами, сделайте возвращаемый XML более похожим на JSON — простым и легко читаемым, без сведений о схеме и пространстве имен, содержащим только данные и ссылки. Если ваш XML будет более сложным, стоимость поддержки будет неоправданно большой. Если судить по нашему опыту — никто никогда не отвечает в формате XML. Обрабатывать XML слишком затратно.
Обратите внимание, что JSON-Schema предлагает возможности по валидации XML, если вам все-таки нужен такой функционал.
Создавайте детальные ресурсы
Сначала гораздо проще создавать API, которые имитируют основной домен приложения или архитектуру базы данных вашей системы. В конце концов, вы захотите объединить сервисы, которые используют несколько основных ресурсов, чтобы избежать избыточности информации. Позже будет гораздо проще создать большие ресурсы из отдельных ресурсов, чем детальные ресурсы из более крупных составных ресурсов. Упростите себе задачу и начните с небольших, легко определяемых ресурсов, предоставив для них CRUD-функциональность.
Ресурсы без лишней информации, ориентированные на конкретные ситуации, можно сделать позже.
Учитывайте связность
Одним из принципов REST является связность через ссылки. Хотя сервисы остаются полезными и без них, API становится более самоописательным, когда в ответе содержатся ссылки. По крайней мере, ссылка «на себя» информирует клиентов, как данные были или могут быть получены. Кроме того, используйте заголовок Location, который должен содержать ссылку на создание ресурса с помощью POST (или PUT). Для коллекций возвращайте в ответе сведения о том, что поддерживается пагинация, а также, как минимум, ссылки «первая», «последняя», «следующая» и «предыдущая».
Что касается форматов ссылок, то их существует довольно много.
Спецификация HTTP веб-ссылок (RFC5988) определяет ссылку следующим образом:
Ссылка — это типизированное соединение между двумя ресурсами, идентифицируемыми интернационализированными идентификаторами ресурсов (IRI) [RFC3987]
Ссылка состоит из:
- контекстного IRI
- типа ссылки
- целевого IRI
- целевых атрибутов (опционально)
Ссылку можно рассматривать как утверждение вида {контекстный IRI} имеет ресурс {типа} в {целевоом IRI}, который имеет {целевые атрибуты}.
По меньшей мере, размещайте ссылки в HTTP-заголовке Link, как это рекомендовано в спецификации, или используйте JSON-представление данного стиля HTTP-ссылок (например, ссылки в стиле Atom, см. RFC4287). По мере того, как ваш API будет становиться более зрелым, вы сможете использовать более сложные стили ссылок, такие как HAL+JSON, Siren, Collection+JSON и/или JSON-LD и т.д.
URL-адресов ресурсов — HTTP | MDN
Нестандартный: Эта функция является нестандартной и не соответствует стандартам. Не используйте его на рабочих сайтах, выходящих в Интернет: он не будет работать для каждого пользователя. Также могут быть большие несовместимости между реализациями, и поведение может измениться в будущем.
URL-адреса ресурсов, URL-адреса с префиксом ресурса: схема , используются
Firefox и расширения браузера Firefox для внутренней загрузки ресурсов, но некоторые из
информация доступна и для сайтов, к которым подключается браузер.
URL-адреса ресурсов состоят из двух частей: префикса (ресурс : ) и URL-адреса.
указывая на ресурс, который вы хотите загрузить:
ресурс://
Пример:
resource://gre/res/svg.css
Когда в URL-адресе ресурса встречаются стрелки (‘->’), это означает, что первый файл загрузил следующий:
resource://->
Более общие сведения см. в разделе «Идентификация ресурсов в Интернете».
В этой статье мы сосредоточимся на URI ресурсов, которые используются внутри Firefox для указать на встроенные ресурсы.
Поскольку некоторая информация, передаваемая ресурсом : URL-адреса , доступна для
веб-сайты, веб-страница может запускать внутренние сценарии и проверять внутренние ресурсы
Firefox, включая настройки по умолчанию, которые могут быть серьезной проблемой безопасности и
проблема конфиденциальности.
Например, скрипт на Browserleaks выделяет то, что показывает Firefox при запросе с помощью простого скрипта.
работает на сайте (вы можете найти код в https://browserleaks.com/firefox#more).
Файл firefox.js передает имена и значения предпочтений функции pref(). Для пример:
http://searchfox.org/mozilla-central/rev/48ea452803907f2575d81021e8678634e8067fc2/browser/app/profile/firefox.js#575
Веб-сайты могут легко собирать настройки Firefox по умолчанию, переопределяя это функция pref() и использование скрипта ресурс:///defaults/preferences/firefox.js .
Кроме того, некоторые значения параметров по умолчанию различаются в зависимости от конфигурации сборки. таких как платформа и язык, что означает, что веб-сайты могут идентифицировать отдельных пользователей, используя эта информация.
Чтобы решить эту проблему, Mozilla изменила поведение загрузки ресурса: URI в Ошибка Firefox 863246, появившаяся в Firefox 57 (Quantum).
В прошлом веб-контент мог получить доступ к любому ресурсу : URI были доступны.
желательно — не только внутренние ресурсы Firefox, но и активы расширений. Теперь это
поведение запрещено по умолчанию.
Тем не менее, Firefox по-прежнему необходимо загружать ресурсы в веб-содержимом под
определенные обстоятельства. Например, если вы откроете исходную страницу представления (Просмотр исходного кода страницы
или View Selection Source), вы обнаружите, что для этого требуется viewsource.css через
ресурс : URI. Ресурсы, которые должны быть доступны для веб-контента,
был перемещен в новое место с именем resource://content-accessible/ , которое
изолирован и содержит только неконфиденциальные ресурсы. Таким образом, мы можем сохранить основные
раскрыты ресурсы и устранено большинство угроз.
Примечание: Разработчикам веб-сайтов и расширений не рекомендуется пытаться
больше использовать URL-адреса ресурсов. Их использование было в лучшем случае хакерским, и большинство из них не будут работать.
больше.
ресурс: не определен ни в одной спецификации.
ресурс: только Firefox.
- Идентификация ресурсов в Интернете
- Что такое URL?
- Список IANA схем URI (ресурс
:рассматривается здесь)
Обнаружили проблему с содержанием этой страницы?
- Отредактируйте страницу на GitHub.
- Сообщить о проблеме с содержимым.
- Посмотреть исходный код на GitHub.
Последний раз эта страница была изменена участниками MDN.
Идентификация ресурсов в Интернете — HTTP
Цель HTTP-запроса называется «ресурсом», природа которого далее не определяется; это может быть документ, фотография или что-то еще. Каждый ресурс идентифицируется с помощью универсального идентификатора ресурса (URI), используемого в протоколе HTTP для идентификации ресурсов.
URL-адреса
Наиболее распространенной формой URI является унифицированный указатель ресурсов (URL), известный как веб-адрес .
https://developer.mozilla.org https://developer.mozilla.org/en-US/docs/Learn/ https://developer.mozilla.org/en-US/search?q=URL
Любой из этих URL-адресов можно ввести в адресную строку браузера, чтобы указать ему загрузить соответствующую страницу (ресурс).
URL-адрес состоит из различных частей, некоторые из которых являются обязательными, а другие необязательными. Более сложный пример может выглядеть так:
http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument
URN
Единое имя ресурса (URN) — это URI, который идентифицирует ресурс по имени в определенном пространстве имен.
urn:isbn:9780141036144 урна: ietf: rfc: 7230
Два URN соответствуют
- книге Джорджа Оруэлла «1984»,
- спецификация IETF 7230, Протокол передачи гипертекста (HTTP/1. 1): синтаксис и маршрутизация сообщений.
1): синтаксис и маршрутизация сообщений.Схема или протокол
http://— это протокол. Он указывает, какой протокол должен использовать браузер. Обычно это протокол HTTP или его защищенная версия HTTPS. В Интернете требуется один из этих двух протоколов, но браузеры также умеют работать с другими протоколами, такими какmailto:(для открытия почтового клиента) илиftp:для обработки передачи файлов, так что не удивляйтесь, если увидите такие протоколы. Общие схемы:
| Схема | Описание |
|---|---|
| данные | URL-адреса данных |
| файл | Имена файлов, специфичные для хоста |
| фтп | Протокол передачи файлов |
| http/https | Протокол передачи гипертекста (безопасный) |
| JavaScript | Код JavaScript, встроенный в URL |
| почта на номер | Адрес электронной почты |
| сш | Безопасная оболочка |
тел. | телефон |
| урн | Единые имена ресурсов |
| вид-источник | Исходный код ресурса |
| вс/всс | Соединения WebSocket (безопасные) |
Управление
www.example.com— доменное имя или орган, управляющий пространством имен. Он указывает, какой веб-сервер запрашивается. В качестве альтернативы можно напрямую использовать IP-адрес, но поскольку он менее удобен, он не часто используется в Интернете.
Порт
:80— это порт в данном случае. Он указывает на технические «ворота», используемые для доступа к ресурсам на веб-сервере. Обычно он опускается, если веб-сервер использует стандартные порты протокола HTTP (80 для HTTP и 443 для HTTPS) для предоставления доступа к своим ресурсам. В противном случае это обязательно.
Путь
/path/to/myfile.html— это путь к ресурсу на веб-сервере. На заре Интернета такой путь представлял собой физическое местоположение файла на веб-сервере. В настоящее время это в основном абстракция, управляемая веб-серверами без какой-либо физической реальности.
Запрос
?key1=value1&key2=value2— дополнительные параметры, предоставляемые веб-серверу. Эти параметры представляют собой список пар ключ/значение, разделенных 9Символ 0007 и . Веб-сервер может использовать эти параметры для выполнения дополнительных действий, прежде чем вернуть ресурс пользователю. Каждый веб-сервер имеет свои собственные правила в отношении параметров, и единственный надежный способ узнать, как конкретный веб-сервер обрабатывает параметры, — это спросить владельца веб-сервера.
Фрагмент
#SomewhereInTheDocument— это якорь к другой части самого ресурса. Якорь представляет собой своего рода «закладку» внутри ресурса, давая браузеру указания показать содержимое, расположенное в этом «закладке». Например, в HTML-документе браузер будет прокручивать до точки, где определена привязка; в видео- или аудиодокументе браузер попытается перейти к тому времени, которое представляет якорь. Стоит отметить, что часть после #, также известная как идентификатор фрагмента, никогда не отправляется на сервер вместе с запросом.
Якорь представляет собой своего рода «закладку» внутри ресурса, давая браузеру указания показать содержимое, расположенное в этом «закладке». Например, в HTML-документе браузер будет прокручивать до точки, где определена привязка; в видео- или аудиодокументе браузер попытается перейти к тому времени, которое представляет якорь. Стоит отметить, что часть после #, также известная как идентификатор фрагмента, никогда не отправляется на сервер вместе с запросом.При использовании URL-адресов в содержимом HTML обычно следует использовать только некоторые из этих схем URL-адресов. При обращении к подресурсам, то есть к файлам, которые загружаются как часть более крупного документа, следует использовать только схемы HTTP и HTTPS. Все чаще браузеры удаляют поддержку использования FTP для загрузки подресурсов по соображениям безопасности.
FTP по-прежнему приемлем на верхнем уровне (например, при вводе непосредственно в строку URL-адреса браузера или в качестве цели ссылки), хотя некоторые браузеры могут делегировать загрузку содержимого FTP другому приложению.