По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Ожидания от технологии и что в итоге?
Изначально, широкое применение биометрических технологий в бизнесе планировалось в финансовых организациях, в частности, в банках. Профит от биометрии именно в этом сегменте казался наиболее ощутимым: решение задач по автоматизированной и достоверной идентификации и аутентификации клиентов ведет к прямому срезу операционных «костов» на работу контактного центра. Так и вышло.
Основной интерес к голосовой биометрии исходит именно от банков и телекоммуникационных организаций. Однако, не стоит забывать, что биометрии имеет разные модальности: голос, лицо, дактилоскопия, сетчатка и радужная оболочка глаза. Именно поэтому, сейчас интерес к технологии начинают проявлять медицинские организации, государственные структуры, крупные транспортные организации и автопроизводители.
Посмотреть доклад про голосовую биометрию
Затраты на внедрение голосовой биометрии и окупаемость?
Все кейсы безусловно разные: например, в 2017 году Сбербанк потратил 260 млн. рублей на проект голосовой биометрии с планируемым сроком окупаемости через 2 года. Биометрия помогла Почта – Банку предотвратить мошенничество на ~10 млн. рублей.
Вот типовой кейс: Обычная инсталляция стоит в районе +- 10 млн. рублей, но безусловно сильно зависит от объемов и требований к каждой конкретной инсталляции. Посчитать окупаемость такой системы не сложно: представим, среднее время на авторизацию и идентификацию клиента составляет 1 минута и 3 минуты на решение клиентского запроса – суммарно 4 минуты. При средней заработной плате в 50 000 руб./месяц и выработке 160 часов в месяц, минута оператора стоит ~5 рублей. При 5 000 обращений в день (20 000 минут разговора), вы экономите 5 000 минут работы оператора, маршрутизируя авторизацию или идентификацию на биометрическую систему. Это 25 000 рублей в день, 750 000 рублей в месяц (КЦ без выходных). При таких параметрах типичная окупаемость системы наступит через 13 месяцев с момента ввода в эксплуатацию.
Биометрические процессы отлажены?
Нет. Технологии безусловно есть куда расти. Как с точки зрения бизнес – процессов компаний, в чьих сетевых ландшафтах внедряется система, так и возможностей ПО. К тому же, имеет место пользовательское недоверие к технологии, как, в прочем, ко всему новому. Это уйдет только со временем. К тому же, на текущем этапе Правительство РФ не рекомендует использовать биометрию для всех типов банковских операций, где она теоретически применима.
Кто уже в клубе?
Сейчас 5 банков в Российской Федерации оказывают услуги потребителям с помощью технологий биометрии. Среди них Альфа, Хоум Кредит, Тинькофф, Почта Банк (ранее Лето Банк) и Совкомбанк. Сейчас это в основном услуги, связанные с обслуживание. Опять же, как сказал ранее, технология растет и требует тесного взаимодействия с государственным аппаратом, а Правительство РФ пока не рекомендует использовать биометрические системы для всех типов операций.
Схема такова: оставив свои биометрические данные в одном банке, вы сможете иметь доступ к продуктам другой кредитной организации. Это достигается за счет ЕБС (Единой биометрической системы). По распоряжению правительства № 293-р от 22 февраля 2018 года «Ростелеком» назначен оператором Единой биометрической системы (ЕБС). ЕБС будет использовать дополнительную связку с системой ЕСИА (Госуслуги), что дополнительно повысит безопасность системы.
Какие трудности?
Технология новая, и одной из самых больших трудностей для повсеместного распространения биометрических систем является отсутствие полной биометрической базы населения в централизованном виде. Тут, как уже сказал ранее, решением данного вопроса станет Единая биометрическая система. Но, безусловно, на ее сбор понадобится время. Важным фактором развития технологии может стать пользовательское недоверие и отсутствие понимания принципов работы.
Тут можно обратиться к кейсам: Индия и система Aadhaar, в которой собрано около 1.15 млрд. слепков жителей страны – примерно 86% экземпляров. Менее сложные для решения факторы, такие как устаревание биометрического шаблона или медицинские травмы предмета аутентификации/идентификации (например, структуры радужной оболочки, лица, травмы голосовых связок или естественное устаревание голоса) преодолеваются путем простого обновления шаблона раз в 5 – 10 лет.
Что в перспективе 3 лет?
С ростом ML технологий (машинное обучение) направление развития систем останется прежним на протяжении ближайших 3 лет, а механизмы биометрической аутентификации и идентификации будет все более и более совершенными. Особенный акцент на применение систем будет сделан в банках и телекоме. Помимо этого, биометрия все более плотно будет интегрирована в государственный сектор, начиная от комплексов оперативно - розыскных мероприятий, заканчивая предоставлением услуг и медициной.
Кстати, 2020 год обещает быть интересным уже в июле, на Олимпиаде в Токио. Visa готовит возможность биометрической оплаты по отпечатку пальца для болельщиков, которые приедут в Японию. Сделать привязку отпечатка пальца и привязать их к банковской карте по прибытию в страну – прямо в аэропорту.
Протоколы 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 и многие другие.
Главные отличия между всеми решениями заключаются в открытости кода и удобстве для клиентов.
Приходишь ты такой в офис, уже налил чашечку кофе, поболтал у кулера, садишься за рабочее место и начинаешь писать: “уважаемые коллеги, бла бла бла”, и тут, после того, как все коллеги уважены в твоем обращении, ты вдруг задумываешься - а как это работает? Почему моя почта доходит до уважаемых коллег? Очень просто - сейчас расскажем как.
Для начала разделим работу электронной почты на две части - отправка и получение.
Отправка
Начнём с отправки. Как только ты дописал своё письмо и нажал на кнопку “Отправить”, твой почтовый клиент (Outlook, Thunderbird, Gmail или Yandex Mail) отправит его на сервер по протоколу SMTP - Simple Mail Transfer Protocol, что переводится как простой протокол передачи почты. И тут начинаются первые проблемы. Дело в том, что этот протокол действительно “простой”. Он увидел свет аж в 1982 году, а как ты помнишь, тогда на безопасность было вообще пофиг, поэтому все письма отправлялись в открытом виде, пользователи никак не аутентифицировались, а хакеры успешно применяли его для рассылки спама.
Поэтому, в 2008 году ему решили добавить фич в виде поддержки шифрования, авторизации, 8-битных наборов символов и ещё много всего полезного и назвали это все ESMTP, где Е означает extended, то есть расширенный. Но даже после этого протокол называют просто - SMTP.
Короче, SMTP работает по клиент серверной модели. Он передает на почтовый сервер команды и получает от него ответы с результатами их обработки.
Ответы от сервера - это кодовые значения, которые делятся на 5 типов. Те у которых код 200, означают что всё ок, а те что с кодом 500 - не ок.
Ничего не напоминает? Да, очень похоже на HTTP
При стандартной отправке письма происходит следующее:
Твой клиент подключается к серверу
Сервер выдаёт ему список доступных команд
Твой клиент отправляет команды, которые содержат адрес отправителя, получателя и собственно само сообщение
Сервер помещает твоё сообщение в очередь на отправку и если всё ок - отправляет его.
А в случае если ты сын маминой подруги и позаботился о безопасности, клиент также пройдёт процедуру аутентификации и шифрования, прежде чем отправить письмо.
Кстати, ты можешь указать в адресе отправителя что угодно и тебе за это ничего не будет. Дело в том, что в SMTP нет встроенных проверок подлинности отправителя, для этого используются внешние механизмы. Самый простой - это сопоставление домена и IP-адреса отправителя через DNS-запрос. Так что если ты решишь прикинуться Илоном Маском и написать кому нибудь письмо с просьбой отсыпать немножко биткоинов, то скорее всего оно попадёт в спам.
SMTP используется не только для отправки писем от клиента к серверу, но и для передачи твоего письма между почтовыми серверами.
Допустим, если ты напишешь Илону, то сначала твоё письмо попадёт на твой локальный сервер, который скорее всего не находится в домене spacex.com, поэтому твой сервер будет по тому же DNS искать в Интернетах почтовый сервер, отвечающий за маршрутизацию электронной почты домена Space X. Это кстати называется MX-запись. Когда эта информация будет найдена, то сервер пульнёт туда твоё письмо по протоколу SMTP.
Для работы SMTP был зарезервирован TCP порт 25, но есть ещё 2 порта - это 465 и 587, оба они предназначены для связи клиента с сервером по защищенным механизмам, а 25 предназначался только для связи между собой почтовых серверов.
Отлично, теперь твоё письмо, пройдя все системы антиспама и проверки лежит на почтовом сервере получателя и дожидается когда же его прочитают, а мы переходим ко второму действию - получение.
Получение
Тут возможны 2 варианта. Либо твой клиент будет получать почту по протоколу IMAP - Internet Message Access Protocol, либо по протоколу с не очень приличным названием POP3 - Post Office Protocol 3.
Для POP3 почтовый сервак выступает в роли временного хранилища писем. Клиент, настроенный на работу с POP3, будет периодически обращаться на сервак и спрашивать: - “Есть чё по письмам?”, Сервер ответит ему: - “Ага есть”, тогда клиент ответит: - “Зашибись, а ну гони всё сюда и удали все копии, чтоб письма были только у меня”
Именно так, в случае POP3 клиент будет хранить все письма только у себя, но в этом есть плюс - даже если у тебя пропадёт Интернет, ты всё равно сможешь получить доступ к своим письмам. Надо сказать, что с помощью самого клиента (но не POP3), можно попросить сервер всё таки хранить копии писем.
А вот тебе ещё несколько неприятных фактов про POP3:
Он работает только на одном клиенте, то есть если ты открыл клиент с POP3 на компе, то с мобильного телефона уже не сможешь посмотреть свою почту.
А ещё нельзя разнести письма по папкам, настроить фильтры, пометить важность и т.д.
А? Ну как тебе, удобно? Ладно, давай посмотрим какие ещё есть варианты.
Ты можешь настроить свой клиент на работу с протоколом IMAP, тогда всем движем будет управлять почтовый сервак. В этом случае, твой почтовый клиент будет нужен только как интерфейс для работы с почтой. Зато ты сможешь получить доступ к своему почтовому ящику откуда угодно и с чего угодно. Сидишь за рабочим местом - читаешь почту с компа, отошёл в уборную - с мобилки, можно использовать веб-клиент и заходить через Интернет.
Ах да, приятным бонусом будет то, что с помощью IMAP ты можешь настроить под себя папки, помечать письма как важные, запрашивать статус о прочтении письма, выполнять сложные поиски по письмам и многое другое.
Но в этом есть и недостатки. Из-за того, что с IMAP всё слишком сложно, обработка писем серваком происходит гораздо дольше и “вообще то место на нём не резиновое”. Если постоянно хранить все письма без ротации, то рано или поздно почтовый ящик забьётся.