По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Протокол маршрутизации OSPF (Open Shortest Path First) (про него можно прочитать тут, а про его настройку здесь) для обмена информации о топологии сети использует сообщения LSA (Link State Advertisement). Когда роутер получает LSA сообщение, он помещает его в базу Link-State DataBase (LSDB). Когда все базы между маршрутизаторами синхронизированы, OSPF использует алгоритм Shortest Path First, чтобы высчитать лучший маршрут между сетями.
LSA содержат в себе информацию о маршруте передается внутри Link State Update (LSU) пакета. Каждый LSU пакет содержит в себе один или несколько LSA, и когда LSU отправляется между маршрутизаторами OSPF, он распространяет информацию LSA через сеть. Каждый LSA используется в определенных границах сети OSPF.
Выглядит это вот так:
Типы LSA
OSPF в настоящее время определяет 11 различных типов LSA, однако, несмотря на большое разнообразие LSA, только около половины из них обычно встречаются в сетях OSPF, но мы рассмотрим их все.
LSA Тип 1 – OSPF Router LSA
Пакеты LSA Type 1 (Router LSA) отправляются между маршрутизаторами в пределах одной и той же зоны (area) где они были созданы и не покидают эту зону. Маршрутизатор OSPF использует пакеты LSA Type 1 для описания своих собственных интерфейсов, а также передает информацию о своих соседях соседним маршрутизаторам в той же зоне.
LSA Тип 2 – OSPF Network LSA
Пакеты LSA Type 2 (Network LSA) генерируются Designated Router’ом (DR) для описания всех маршрутизаторов, подключенных к его сегменту напрямую. Пакеты LSA Type 2 рассылаются между соседями в одной и той же зоны где они были созданы и остаются в пределах этой зоны.
LSA Тип 3 – OSPF Summary LSA
Пакеты LSA Type 3 (Summary LSA) генерируются с помощью пограничных маршрутизаторов Area Border Routers (ABR) и содержат суммарное сообщение о непосредственно подключенной к ним зоне и сообщают информацию в другие зоны, к которым подключен ABR. Пакеты LSA Type 3 отправляются в несколько зон по всей сети.
На рисунке показано как маршрутизатор R2 ABR создает Type 3 Summary LSA и отправляет их в зону Area 0. Таким же образом R3 ABR роутер создает пакеты Type 3 и отправляет их в Area 2. В таблице маршрутизации маршруты, полученные таким образом, отображаются как “O IA”
Видео: протокол OSPF (Open Shortest Path First) за 8 минут
LSA Тип 4 – OSPF ASBR Summary LSA
Пакеты LSA Type 4 (ASBR Summary LSA) - это LSA, которые объявляют присутствие автономного пограничного маршрутизатора Autonomous System Border Router (ASBR) в других областях.
На схеме, когда R2 (ABR) принимает пакет LSA Type 1 от R1, он создаст пакет LSA Type 4 (Summary ASBR LSA), который передает маршрут ASBR, полученный из Area 1, и вводит его в Area 0. Хотя пакеты LSA Type 4 используются ABR для объявления маршрута ASBR через их зоны, он не будет использоваться самим ASBR в пределах его локальной зоны (Area 1); ASBR использует LSA Type 1 для информирования своих соседей (в данном случае R2) в своих сетях.
LSA Тип 5 – OSPF ASBR External LSA
Пакеты LSA Type 5 (ASBR External LSA) генерируются ASBR для передачи внешних перераспределенных маршрутов в автономную систему (AS) OSPF. Типичным примером LSA Type 5 будет внешний префикс или маршрут по умолчанию (default router), как показано на схеме.
Этот внешний маршрут/префикс перераспределяется в OSPF-сеть ASBR (R1) и в таблице маршрутизации будет отображаться как "O E1" или "O E2".
LSA Тип 6 – OSPF Group Membership LSA
Пакеты LSA Type 6 (Group Membership LSA) были разработаны для протокола Multicast OSPF (MOSPF) , который поддерживает многоадресную маршрутизацию через OSPF. MOSPF не поддерживается Cisco и не пользуется широкой популярностью.
LSA Тип 7 – OSPF Not So Stubby Area (NSSA) External LSA
Пакеты LSA Type 7 (NSSA External LSA) используются для некоторых специальных типов зон, которые не позволяют внешним распределенным маршрутам проходить через них и таким образом блокируют распространение в них LSA Type 5. LSA Type 7 действуют как маска для LSA Type 5 пакетов, позволяя им перемещаться по этим специальным зоам и достигать ABR, который может переводить пакеты LSA Type 7 обратно в пакеты LSA Type 5.
На схеме ABR R2 переводит LSA Type 7 в LSA Type 5 и рассылает его в сеть OSPF.
LSA Тип 8 – OSPF External Attributes LSA (OSPFv2) / Link Local LSA (OSPFv3)
Пакеты LSA Type 8 в OSPFv2 (IPv4) называются внешними атрибутами LSA и используются для передачи атрибутов BGP через сеть OSPF, в то время как адреса BGP передаются через LSA Type 5 пакеты, однако, эта функция не поддерживается большинством маршрутизаторов. С OSPFv3 (IPv6) , LSA Type 8 переопределяется для передачи информации IPv6 через сеть OSPF.
LSA Тип 9, 10 и 11
Обычно LSA этих типов используются для расширения возможностей OSPF. Практическое применение этих LSA заключается в Traffic Engineering’е MPLS, где они используются для передачи параметров интерфейса, таких как максимальная пропускная способность, незанятая полоса пропускания и т.д.
LSA Тип 9 – OSPF Link Scope Opaque (OSPFv2) / Intra Area Prefix LSA (OSPFv3)
LSA Type 9 в OSPFv2 (IPv4) определяется как Link Scope Opaque LSA для передачи OSPF информации. Для OSPFv3 он переопределяется для обработки префикса связи для специального типа зоны, называемого Stub Area.
LSA Тип 10 – OSPF Area Scope Opaque LSA
Пакеты LSA Type 10 используются для потоковой передачи информации OSPF через маршрутизаторы других областей. Даже если эти маршрутизаторы не обрабатывают эту информацию, чтобы расширить функциональность OSPF, этот LSA используется для Traffic Engineering’а для объявлений MPLS и других протоколов.
LSA Тип 11– OSPF AS Scope Opaque LSA
Пакеты LSA Type 11 выполняют ту же задачу, что и пакеты LSA Type 10, но не пересылаются в специальные зоны (Stub зоны)
Протоколы API, как и все в этом мире, активно развиваются. Многие компании, включая GraphQL, gRPC и Thrift, пользуются классическими API SOAP и REST. В списке этих API есть и JSON-RPC.
JSON-RPC, созданный для быстрой разработки многофункциональных сайтов, быстро стал лучшим другом разработчиков.
Давайте разберемся, что это такое, и в чем оно полезно специалистам по разработке приложений и API. Знакомство с JSON-RPC начинается с азов JSON. Так что первая глава данной статьи посвящена общей информации о JSON.
JSON – что это такое, и как оно работает
JSON – это легковесный формат обмена сообщениями, который подходит для более быстрой передачи данных. Именно поэтому он так активно используется в современной разработке.
JSON (JavaScript Object Notation, или нотация объектов JavaScript) производит многократную разбивку данных до тех пор, пока они не примут удобный для обработки вид. В основе JSON лежит JavaScript, поэтому просматривая элементы данных, вы не раз встретите строки, нулевые символы, объекты и бинарные переменные.
JSON разбивает сложные сопоставленные данные на управляемые структуры, облегчая обработку данных на многих языках программирования, и считается независимым от языка ресурсом. Его придумал Дуглас Крокфорд в 2000 году с целью упрощения взаимодействия между веб-приложениями и сервером.
Что такое JSON RPC?
JSON-RPC – это не что иное, как преемник JSON, повсеместно признанный протокол для удаленного вызова процедур (RPC - Remote Procedure Calls). Работая на уровне разработки, JSON-RPC запускает различную структуру данных, определяя задачи для приложений. Это сравнительно новый протокол с узкой областью применения.
Наборы команд, гибкость и сценарии развертывания – все работает с ограничениями. Но, тем не менее, разработчики видят в нем идеальный вариант для простой и быстрой разработки. В простых сценариях данные ограничения не являются помехой и побуждают разработчиков переходить с REST на JSON-RPC. Стоит также добавить, что:
JSON-RPC определяет сетевые ограничения, связанные с обработкой данных.
Легкая конструкция и быстрая обработка – все это подходит для инициации передачи данных с узлами Ethereum.
Будучи транспортно-независимым протоколом, JSON-RPC может использовать для взаимодействия сокеты и HTTP.
Это отличное решение для разработки решений на базе Ethereum с использованием блокчейн.
В настоящий момент предлагается 2 стандарта JSON-RPC: JSON-RPC 1.0 и JSON-RPC 2.0:
JSON-RPC 1.0 не хватает возможностей сразу по нескольким пунктам. Отсутствие названий параметров и пояснений к ошибкам вызывает куда больше проблем, чем кажется. Скорее уж, это метод для одноранговой передачи данных.
Обновленный JSON RPC 2.0 значительно доработали, заполнив ряд пробелов предыдущей версии. Версию 1.0. заменили клиент-серверной 2.0. Кроме того, в 2.0. появились транспортные зависимости.
Разумеется, со временем добавили именованные параметры. Поля урезали. Нет ID для уведомлений; в качестве ответа отправляется только результат/ошибка. В обновленной версии есть дополнительные расширения с информацией об ошибках.
Как пользоваться JSON RPC?
Главная функция протокола заключается в отправке клиентских запросов на сервер (при поддержке JSON-RPC). Здесь под клиентом мы подразумеваем общепринятые приложения, которые развертываются для получения запроса от удаленной системы на консолидированный метод.
Введенные параметры передаются удаленной системе в формате массива или объекта. В зависимости от используемой версии JSON-RPC, удаленная система будет отправлять в источник запроса разные итоговые значения.
Все веб-передачи через JSON-RPC унифицированы и сериализированы с помощью JSON. Запрос JSON-RPC – это вызов удаленного метода. Он состоит из 3 элементов:
Метод. Указывает на строку, которая будет запрашиваться при вызове метода. Существует набор зарезервированных имен с префиксом ‘rpc’ – они предназначаются для внутренних вызовов RPC.
Параметры. Второй элемент JSON-RPC (объект или массив) со значением параметра, который будет переноситься. Параметры не вызываются в каждом вызове.
ID. Целое или строковое число, которое регулярно используется для поддержания баланса между запросами и ответами. Если на запрос нет ответа, то ID автоматически удаляется.
В запросе JSON-RPC получатель обязан вернуться к проверенному ответу на каждый полученный запрос. Добавляются 3 компонента:
Результат – первая и важнейшая часть запроса, передающая данные, которые возвращает вызываемый метод. Его часто называют JSON-stat, и при ошибке он остается пустым.
Ошибка – второй компонент. Появляется, если в процессе вызова что-то идет не так. В ошибке отображаются код и сообщение.
ID ответа указывает на запрос, по которому приходит ответ. Если ответов не требуется, то JSON-RPC использует уведомление, в котором написано, что запрос был без ID. В версии 1.0 ID уведомление приходит пустым, а в версии 2.0. оно полностью отсутствует.
Плюсы от использования JSON-RPC
JSON-RPC – это довольно «умный» протокол, который предлагает своим клиентам множество плюсов:
Простая обработка
JSON-RPC намного проще, чем REST. Его легко понимают люди и машины. Здесь нет сложных команд и наборов данных, так что JSON-RPC идеально подходит для начинающих разработчиков. Этот протокол Unicode предлагает компактную командную строку. Кроме того, он способен обрабатывать данные с именованными фразами или отдельными ключевыми словами. Таким образом, JSON-RPC считается простым и понятным инструментом для работы.
Быстрое время разработки
С JSON-RPC не надо ничего придумывать. Все источники доступны и понятны. Такая простота сокращает время разработки и сроки выхода на рынок. Это самое подходящее решение для разработки приложений в сжатые сроки.
Качественный обмен информацией
JSON-RPC гарантирует своевременный, быстрый и точный обмен данными, поскольку может обрабатывать уведомления и несколько вызовов. Чтобы продолжить свою работу, ему не нужно ждать ответа от сервера или клиента. Если сделан запрос сообщения, то JSON-RPC гарантированно доставит его «адресату». Не важно, насколько сложные компоненты приложения входят в цепочку коммуникации, JSON-RPC обеспечит должный обмен информацией.
Улучшенная производительность API
С помощью JSON-RPC можно создавать API, которые не зависят от развертываемого протокола. Такая возможность крайне важна для улучшения производительности API, т.к. заменяет HTTP и TCP, а также снижает рабочую нагрузку.
Описание результатов
JSON-RPC выдает понятные результаты запроса, которые легко прочитать и обработать. Создание пакетных запросов, объяснение body в HTTP и передача параметров – все это гораздо проще реализовать через JSON-RPC.
Улучшенная передача
JSON-RPC – это очень удобный для передачи инструмент, ведь поддерживает такие платформы, как XMPP, WebSockets, SFTP, SSH и SCP. Данное разграничение позволяет разрабатывать быстрые, простые в отладке и удобные для пользователя API. Кроме того, этот протокол полностью отделяет запрошенный контент от используемого процесса передачи. А любые ошибки в запросах, данные и предупреждения передаются через полезную информацию запроса.
REST и JSON-RPC: что выбрать для разработки API?
Богатый выбор API-ресурсов – это всегда хорошо, но остановиться на каком-то одном варианте бывает не так просто. Ниже мы постараемся помочь разработчикам и объясним ключевые особенности популярных протоколов.
JSON-RPC подходит для начинающих разработчиков с ограниченным количеством ресурсов. JSON-RPC – это очень ограниченный в ресурсах протокол, который отлично выполняет свою функцию. Кроме того, если цель разработчика хоть как-то связана с технологией распределенных реестров, то единственным жизнеспособным решением станет именно JSON-RPC. С таким развертыванием не сможет справиться ни один другой протокол.
Для разработки приложений, использующих технологии распределенных реестров, требуется независимый от протокола API, и JSON-RPC отлично подходит. Он позволяет разработчикам создавать API, которые могут взаимодействовать друг с другом с помощью любого протокола.
Есть еще одна область, в которой JSON-RPC превосходит REST. В REST доступен ограниченный набор глаголов, что приводит к ошибкам при выполнении операции. При использовании REST необходимо подробно описать HTTP-метод, и на это тратится много времени. Кроме того, в REST доступны только CRUD-операции. Так что лучше отдавать предпочтение JSON-RPC.
Тем не менее JSON-RPC нельзя назвать универсальным решением для всего. Его проблема заключается во взаимозависимости. Клиенты должны быть тесно связаны с реализацией служб, поэтому вносить изменения в эту реализацию довольно сложно. При попытке изменить что-то, клиенты чаще всего ломаются.
REST решает такие задачи намного лучше. Например, API на базе REST мало того, что легко создаются, так еще и не отслеживают состояния. Этот протокол совместим с HTTP и предлагает огромное множество HTTP-библиотек. REST позволяет создавать гибкие API. Это идеальное решение для CRUD-операций.
Оба протокола имеют свои плюсы и минусы. Разработчикам необходимо принять взвешенное решение, исходя из главной цели разработки. Например, если разработчику нужны высокопроизводительные вычисления, то стоит остановиться на JSON-RPC.
Если требуется независимая разработка приложения с удобным интерфейсом, то смело выбирайте REST. Не стоит также забывать о безопасности API.
JSON-RPC, graphql, grpc
Два самых известных аналога JSON-RPC – это GraphQL и gRPC. GraphQL – это полностью адаптивная система. Она используется для точной локализации данных запроса и получения только необходимых запрашиваемых данных. Основная черта – ориентация на клиента. Сервер практически никак не участвует в веб-передаче. Клиент сам устанавливает правила для обработки запрошенных данных.
GraphQL относится к языкам запросов, а JSON-RPC относится к удаленному вызову процедур.
Еще есть gRPC – легковесный протокол с акцентом на производительность. Это обновленная версия RPC. В JSON-RPC серверы и клиенты договариваются о запрашиваемых данных, а архитектура не важна. А в gRPC, наоборот, запросы обрабатываются по готовой схеме. Этот протокол может выполняться в любой экосистеме.
JSON-RPC интегрируется с MQTT, Python и Kallithea. Для gRPC доступны такие ресурсы, как .NET, JavaScript, C++, Swift и многие другие.
Главные отличия между всеми решениями заключаются в открытости кода и удобстве для клиентов.
Мы хотели бы поговорить про Quality of Service (QoS) в VoIP сетях, рассказать что это такое, как это работает, зачем это нужно и как это настраивать. В этой статье мы рассмотрим, какие проблемы мы можем иметь в сети, и как QoS может с ними помочь.
Для успешного функционирования VoIP сетей голосовой трафик (voice traffic) должен иметь приоритет над трафиком с данными (data traffic). Quality of Service можно определить как способность сети предоставить лучший или особый сервис для группы пользователей и приложений за счет других пользователей и приложений.
Звучит как то, что как раз необходимо для голосового трафика – “лучший” сервис необходим для VoIP не из-за больших требований по пропускной способности (VoIP трафик использует маленькую полосу пропускания, по сравнению с другими приложениями), а из-за требований по задержке. В отличие от трафика с данными, время за которое пакет проходит из одного конца сети в другой имеет значение. Если пакет с данными при прохождении через сеть испытал задержку (delay), то файловый сервер получит файл секундой позже или страничка в браузере будет загружаться чуть дольше, и с точки зрения пользователя не произойдет ничего страшного. Однако если голосовой трафик проходит по сети и испытывает задержку, то голоса начинают перекрываться (например, абонент начинает говорить одновременно с другим абонентом) и продолжать разговор становится невозможно.
Чтобы побороть эти проблемы нужно убедиться, что для голосового трафика подходит не только полоса пропускания, но и что голосовой трафик получает первую доступную полосу. Это означает что если бутылочное горлышко (самое узкое место) находится в сети, где маршрутизатор ставит трафик в очередь, то перед тем как его выслать, маршрутизатор будет перемещать голосовой трафик перед трафиком данных, чтобы отправить его в первом доступном интервале. И это как раз задача Quality of Service. QoS, по сути, является не отдельным инструментом, а классом инструментов, направленных на то чтобы дать администратору полный контроль над трафиком внутри сети. Как и когда использовать каждый инструмент QoS зависит от требований к сети от трафика и ее характеристик.
Понимание основных проблем
Перед тем как применять QoS, нужно разораться с тем, какие проблемы мы пытаемся решить. Рассмотрим основные:
Недостаток пропускной способности (Lack of bandwidth) – Множественные потоки голосового трафика и трафика с данными конкурируют за ограниченную полосу пропускания.
Задержка (Delay) – Для того чтобы пакет дошел из пункта отправления в пункт назначения требуется какое-то время. Задержка имеет три формы:
Фиксированная задержка (Fixed delay) – Значение задержки, которое нельзя изменить. Например, требуется определенное время, чтобы пакет добрался до определенной географической локации. Это значение считается фиксированным и QoS не может повлиять на него.
Переменная задержка(Variable delay) – Значения задержки, которые можно изменить. Например, задержка в очереди интерфейса маршрутизатора является переменной, потому что она зависит от того, сколько пакетов находится на данный момент в очереди. На эту задержку можно повлиять поставив голосовые пакеты перед пакетами с данными.
Джиттер (Jitter) – Разница задержек между пакетами. Например, первому пакету разговора потребовалось 100 мс чтобы добраться до точки назначения, в то время как второму потребовалось 110 мс. В этой ситуации джиттер составляет 10 мс.
Потеря пакетов (Packet loss) – пакеты теряются из-за переполненного или ненадежного сетевого подключения.
Очень важно понимать эти проблемы, поскольку они вызывают наложения звука, эхо, потрескивания и разорванные звонки.
Механизм QoS предназначен для того, чтобы обеспечить бесперебойную передачу голоса в течение временных перегрузок в сети. Однако это не волшебная палочка, которая сможет решить все проблемы в сети. Например, если в сети есть недостаток пропускной способности, то при добавлении голосовых пакетов не стоит ожидать что QoS сможет все решить – получится что либо приложения с данными будут работать так медленно, что перестанут быть функциональными, либо голосовой трафик будет испытывать проблемы с качеством.
Цель QoS – обеспечить постоянную пропускную способность для голосового трафика таким образом, чтобы была низкая постоянная задержка с одного конца сети в другой. Чтобы выполнить это требование необходимо иметь настроенные механизмы QoS в каждой точке сети, где существует перегрузка.
Требования к голосовому и видео трафику
Разный тип трафика, который используется в сети, имеет разные требования QoS. В отличие от трафика данных, голосовой трафик считается предсказуемым. В то время как трафик данных может значительно увеличиваться при скачивании или передачи большого объема данных, голосовой трафик остается постоянным для каждого звонка поступающего и покидающего сеть. Фактический объем полосы пропускания, требуемый для голоса сильно зависит от используемого кодека.
Помимо требований к пропускной способности, голосовой трафик имеет следующие дополнительные требования:
Задержка (End-to-end delay) : 150 мс или меньше
Джиттер: 30 мс или меньше
Потеря пакетов: 1% или меньше
Видео трафик имеет такие же требования по задержке, но потребляет большую полосу пропускания. Кроме того ширина полосы пропускания может меняться в зависимости от того, сколько движения происходит в видео (большее количество движений значительно увеличивают необходимую пропускную способность).
Требования к трафику данных
Невозможно подогнать весь трафик данных под одно требование, потому что каждое отдельное приложение имеет свои QoS требования. Приложения данных можно разделить на несколько категорий:
Критически важные приложения (Mission-critical applications) – эти приложения критически важны для организации и требуют выделенной полосы пропускания.
Транзакционные приложения (Transactional applications) – эти приложения обычно взаимодействуют с пользователями и требуют быстрого времени отклика. Например, сотрудник техподдержки может использовать приложение базы данных чтобы получать информацию о абоненте на основе ID предыдущих запросов.
Низкоприоритетные приложения (Best-effort applications) – эти приложения некритичны или некатегоризированы. Это может быть почта, веб и FTP.
“Мусорные ” приложения (Scavenger applications) – это непродуктивные приложения, в которых нет необходимости для работы, но которые поглощают значительные объемы полосы пропускания. Например, это могут быть p2p приложения типа BitTorrent
Каждой из этих категорий приложений можно назначить определенный уровень QoS.