Что такое служба rpc

Русские Блоги

Я не понял, как я на самом деле выяснить разницу между RPC (т.е. удаленного вызова процедур, Remote Procedure Call) и HTTP вызовов. Не написано ли услугу, а затем вызвать его на клиенте? Пожалуйста, позвольте мне смеяться здесь

Наивные! В этой статье кратко описываются две формы архитектуры C / S, первая беседа об их наиболее существенной разницы, то RPC базируется главным образом на основе протокола TCP / IP и HTTP сервисы главным образом на основе HTTP протоколы. Мы все знаем, что протокол HTTP является на протоколе TCP транспортного уровня, если эффективность, то RPC является, конечно, более лучше! Давайте возьмем конкретную службу RPC и HTTP службы.

Сеть I. Модель OSI семь слоев

Перед тем, как сказать, разницу между RPC и HTTP, мне нужно будет знать о семиуровневой сетевой структуре модели OSI (хотя это в основном пяти слоев в практических приложениях), его можно разделить на следующие слои: (сверху Нижний)

• Первый слой: Применение слоя. Определить интерфейс для связи и передачи данных в сети;
• Второй слой: указывает на слой. Определить транспортные форматы, кодирование, декодирование и спецификации данных в различных системах;
• Слой 3: сеансовый уровень. Управление сеансов пользователей для контроля за создание и прерывание пользователя логического соединения;
• Четвертый слой: Транспортный уровень. Управление от конца до конца передачи данных в сети;
• Пятый слой: сетевой уровень. Определить, как для передачи данных между сетевыми устройствами;
• Шестой этаж: Канальный. Блок данных указанного выше сетевого уровня инкапсулируются в кадр данных, которая удобна для передачи физического уровня;
• Седьмой этаж: Физический уровень. Этот слой в основном для передачи этих двоичных данных.

Во время фактического применения, структура протокола пятислойной не слой и слой сеанса. Надо сказать, чтобы объединить их с прикладным уровнем. Мы должны сосредоточиться на двух уровнях прикладного уровня и транспортного уровня. Поскольку HTTP представляет собой протокол прикладного уровня, TCP является протоколом транспортного уровня. Хорошо, я знаю, что после расслаивания модели сети, мы можем лучше понять, почему услуги RPC лучше, чем HTTP услуг!

Во-вторых, служба RPC

1, архитектура RPC

Это называется RPC, я вдруг понял!

RPC используется в основном на крупных предприятиях, потому что есть много систем в крупных компаниях, бизнес-линия усложнена, и преимущество эффективности очень важно. В это время, преимущество RPC является более очевидным, и реальным развитие делает это , проект , как правило , используется. Maven управляется. Например, мы имеем системную службу , которая обрабатывает заказы, сначала объявить все его интерфейсы ( в данном описании относится к интерфейсу в Java), а затем упаковать весь проект как пакет JAR, сервер вводит эти вторичные библиотеки, а затем осуществить соответствующее функция, клиент должен только ввести эту пограничную библиотеку, вы можете позвонить.

Почему ты делаешь это? В основном для того, чтобы уменьшить размер JAR пакетов здесь, потому что каждый раз, когда пакет будет отпущен, JAR мешок всегда влияет на эффективность. Кроме того, также разъединить клиента и на стороне сервера, улучшить переносимость кода.

2, синхронные вызовы и асинхронные вызовы

Синхронные вызовы Wait Time Client для исполнения полного и возвращает результат.

Асинхронный вызов является то, что клиент не ждет, чтобы выполнить вызов, чтобы выполнить обратное завершение результата, но он по-прежнему можно получить уведомление о результате возврата через функцию обратного вызова. Если клиент не заботится, он может стать одним из способов вызова. Этот процесс немного похож на отзывной и Runnable интерфейса в Java. Когда мы делаем асинхронную операцию, используйте отзывной интерфейс, если вам нужно знать результат, и вы можете получить информацию о результате асинхронного выполнения через класс будущего. Если результат не выполняется, вы можете использовать исполняемый интерфейс напрямую, потому что он не возвращает результат, конечно же, Callable также возможно, мы не получим будущее.

3, популярные рамки RPC

Dubbo является чрезвычайно известный рамки RPC для Open Source Али Group, которая широко используется во многих интернет-компаний и компаний. Структура протокола и сериализации может быть подключена. Удаленный интерфейс основан на Java-интерфейс и легко развиваться в рамках Spring. Она может быть легко упакована в один файл, независимый процесс запущен, и концепция текущего микро сервиса соответствует.

В-третьих, HTTP

На самом деле, в очень давно, разработка модели предприятий была качественной для HTTP интерфейс разработки, который является интерфейс службы RESTful стиля. Действительно, в том случае, когда существует не так много интерфейса, система менее взаимодействие между системой, решить наиболее часто используемые средства связи в первоначальном использовании острова, преимущество является простым, простым и удобным развитием. Передача осуществляется с использованием готового протокола HTTP. Некоторые компании разрабатывают в основном интерфейсе, написать большое количество интерфейсов документов и строго указывают, что выход вход? Для того, чтобы сделать ясный метод запроса для каждого интерфейса, а также вопросы, требующие параметры, такие как в следующем примере:

Интерфейс может возвращать строку JSON или XML документ. Затем клиент деактивирует информацию возврата, которая может быть разработана достаточно быстро. Тем не менее, для крупных компаний, есть много внутренних подсистем и существует множество интерфейсов, преимущества рамок RPC отображается. Не первый длинный ссылка, не должны идти в 3 раза , как HTTP каждый раз, уменьшить передачу данных по сети, во- вторых, структура RPC , как правило , зарегистрированы, богатый мониторинг управления; релиз, автономный интерфейс, динамическое расширение Ожидать, нет inheat, единой операции вызывающего абонента.

В-четвертых, резюме

Услуги RPC и службы FTTP по-прежнему имеют много различий. В целом, услуги RPC в основном для крупных компаний, а HTTP-сервисы в основном для малого бизнеса, поскольку RPC более эффективной итерацией развития HTTP будет быстрее. Короче говоря, какая структура не должна определяться рынком, но для выполнения полной оценки всего проекта, так что две рамки развития имеют влияние всего проекта, и, наконец, решите, что является наиболее подходящим. Этот предмет имеет этот проект. Не используйте RPC, чтобы использовать RPC, но следует применять к земле, а конкретная ситуация специально проанализирована.

RPC и способы его мониторинга

Мы — команда исследователей‑аналитиков киберугроз в компании R‑Vision. Одной из наших задач является исследование возможных альтернативных и дополнительных источников событий для более точного детектирования атак.

И сегодня мы рассмотрим тему мониторинга RPC (Remote Procedure Call, удаленный вызов процедур), а также разберем возможные варианты логирования Microsoft Remote Procedure Call (MS‑RPC), связанного с актуальными и популярными на сегодняшний день атаками.

Но преждем чем приступить, предлагаем ознакомиться с базовой работой RPC и с тем, на каких механизмах она основывается. В дальнейшем это поможет нам понять, какую информацию необходимо собирать и отслеживать при детектировании атак с использованием удаленного вызова процедур.

Что такое RPC?

Remote Procedure Call или «удаленный вызов процедур» представляет собой технологию межпроцессного взаимодействия IPC. Она позволяет программам вызывать функции и процедуры удаленно таким образом, как‑будто они представлены локально. В среде Windows используется проприетарный протокол от Microsoft — MS‑RPC, который является производным от технологии DCE/RPC (Distributed Computing Environment/ Remote Procedure Calls). Для упрощения понимания мы будем называть MS‑RPC просто RPC.

Службы RPC используются во множестве процессов в операционных системах Windows. Например, с их помощью можно удалённо изменять значения в реестре, создавать новые задачи и сервисы. На вызовах RPC построена значимая часть работы Active Directory: функции аутентификации в домене, репликация данных и многие другие вещи — список грандиозно большой.

В виду того, что RPC используется в Windows практически во всех процессах, по понятным причинам она является предметом особого интереса для атакующих. В тоже время RPC фигурирует в большом количестве популярных и опасных атак. К ним относится PetitPotam, с чьей помощью можно произвести атаку типа Relay на машинный аккаунт контроллера домена. Еще одна атака — DCSync, позволяющая скомпрометировать всех пользователей в домене при наличии учетной записи с высокими привилегиями. Кроме того, в арсенале атакующих есть еще и фреймворк Impacket, который может задействовать RPC для отправки вредоносных команд на удаленный сервер.

Все это говорит нам о важности понимания механизмов работы RPC, а также о необходимости её мониторинга.

Механизмы работы RPC

Изучение механизмов работы RPC мы начнем с краткого разбора сетевого трафика, поскольку протокол RPC в первую очередь является сетевым. На рисунке 1 мы видим подключение к удалённой машине: оно начинается с Bind запроса (выделен красным), после которого фигурирует второй Bind запрос (выделен синим). Первый используется для подключения к службе Endpoint Mapper (EPM), про него мы поговорим дальше. Второй инициирует подключение к самому RPC интерфейсу. После прохождения аутентификации устанавливается сессия, а уже дальше осуществляется вызов нужной функции и возвращение результата.

Рисунок 1. Вызов функции на удалённой машине с помощью RPC

Эволюция, конечно, могла бы остановиться здесь, если бы для RPC применялись только протоколы TCP и UDP, но в Microsoft пошли немного дальше и применяют так называемую последовательность из протоколов. К ней мы вернемся позднее, а сейчас рассмотрим, что такое EPM.

Endpoint Mapper

Одним из важных механизмов взаимодействия с RPC сервисами является служба Endpoint Mapper (EPM), расположенная на стороне сервера. Её главная задача помочь определить параметры дальнейшего подключения к нужному сервису для клиента. Сам EPM, как это ни странно, является таким же RPC сервисом, использующим для транспорта порты TCP/135 или TCP/593 (RPC over HTTP).

Рисунок 2. Служба *RPC Endpoint Mapper на устройстве

EPM‑cервис расположен на каждой Windows машине и содержит базу зарегистрированных RPC интерфейсов. За каждый из интерфейсов чаще всего отвечает свой исполняемый файл или динамически подгружаемая библиотека (DLL). Посмотреть список всех доступных интерфейсов можно с помощью утилиты rcpdump.py из упомянутого нами ранее фреймворка Impacket.

На рисунке 3 приведен пример вывода по одному из доступных интерфейсов.

Рисунок 3. Пример интерфейса, выводимый командой rpcdump.py

Здесь мы можем увидеть:

Название интерфейса: Netlogon Remote Protocol;

Библиотеку провайдера, отвечающего за нужные нам функции: netlogon.dll;

Уникальный идентификатор интерфейса: UUID;

Список точек подключения к данному интерфейсу, которые записываются в формате:

Отметим в приведенном выше интерфейсе два протокола:

ncacn_np — отражает подключение по именованному каналу Named Pipes (NPs). В связи с этим у него вместо порта указан путь.

Может возникнуть вполне резонный вопрос: всегда ли нужно обращаться к EPM? Нет, не всегда, так как существуют статические точки подключения, остающиеся неизменными. К ним, например, относится NPs \pipe\lsass .

Можно также посмотреть на RPC интерфейсы процессов не только снаружи, но и «изнутри». Они выглядят примерно так.

Что дальше?

После того как клиент определил куда он будет дальше подключаться, в процесс вступает сериализация данных. Если клиентом является Windows система, то эту работу будет выполнять компонент NDR (Network Data Representation). Он также отвечает за десериализацию данных со стороны RPC сервера. После чего данные попадают в качестве аргументов функции и другой информации для вызова этой самой функции в DLL библиотеку, ответственную за определённый RPC функционал. На финальном этапе функция выполняется, а её вывод передаётся обратно в RPC для отправки клиенту.

Протоколы в RPC

Разобравшись как работает RPC, подробнее изучим протоколы, которые активно эксплуатируются в интерфейсах RPC и, следовательно, доступны атакующему. И первым мы рассмотрим протокол Named Pipes (NPs).

Named Pipes

Данный протокол следует принципам передачи данных через чтение и запись: используя NPs можно записывать, а также сразу читать наименование и аргументы функций. Более того, это даже можно делать одновременно. NPs проще всего представлять в виде файлов: в Windows взаимодействие с ними происходит с помощью функций CreateFile, ReadFile, WriteFile, что в некоторой степени намекает нам на схожесть этих технологий. NPs выполняет роль интеграционного слоя между RPC и другими служебными компонентами.

Со стороны клиента NPs можно представить как точки подключения для выполнения какого‑то конкретного функционала. Например, точка подключения \pipe\svcctl направлена на управление службами на конечном устройстве. Однако Microsoft не всегда следует такому разделению. Так, при подключении к \pipe\lsass можно вызвать функции EFS сервиса, если передать корректный UUID при выполнении bind запроса.
На стороне сервера, на который происходит обращение, выполняется импорт библиотеки, отвечающий за EFS ( C:\Windows\System32\efslsaext.dll ) в процесс lsass . Стоит отметить, что у EFS существует свой собственный интерфейс \pipe\efsr .
Также EFS функционал может быть вызван с помощью других точек, например через samr или lsarpc , за каждым из которых стоит процесс lsass . Это в свою очередь наталкивает на мысль о некоторой «универсальности» процессов — интерфейсов, так как каждый процесс может импортировать нужную библиотеку и существует возможность вызывать функции любых других сервисов.

Перейдем к следующему протоколу — SMB.

Если отойти немного от протокола RPC и посмотреть на NPs отдельно, мы обнаружим, что NPs может вполне заменить RPC, так как первый исполняет функции удаленно даже без второго. Для этих целей он использует протокол SMB (Server Message Block). При этом фактически SMB нужен только для доступа к служебной директории IPC$ , аббревиатура которой расшифровывается как Interprocess Communication. Через эту «папку» можно читать, записывать, но только NPs, что вполне в духе SMB, и вызывать таким образом удаленные функции.

До этого мы говорили про протоколы, которые используются в удаленным вызове, но есть и локальный вариант RPC — протокол LRPC, у которого существует две трактовки: Local RPC или Lightweight RPC. Этот протокол предназначен только для локальных вызовов. Конечно, при использовании подключений по NPs или RPC на адрес localhost эффект будет тот же. Более того, некоторые программы так и делают, но для локальных вызовов LRPC работает куда быстрее и он удобнее в использовании. В выводе rpcdump.py мы его видели «зашифрованным» под ncalrpc . При этом LRPC работает поверх ALPC — еще одного протокола, о котором будет сказано чуть позже.
Но сначала про LPC.

LPC (Local Procedure Call) — также отвечает за механизм общения процессов в одной и той же системе. Данный протокол является недокументированным и используется (использовался) только внутри самой Microsoft. БОльшую часть информации об этом протоколе мы можем узнать исходя из работ реверс специалистов. Сторонний софт использует его не напрямую, а взаимодействует через документированный LRPC.

А теперь вернемся к ALPC.

LPC — это все же устаревшая технология и в явном виде уже не используется. На смену ей пришел ALPC (Advanced Local Procedure Call), являющийся асинхронным и также недокументированным протоколом. Работает он по принципу клиент‑серверной модели. В качестве сервера выступает процесс, принимающий соединения на определённый порт. Порт для подключения открывается с помощью функции NtAlpcCreatePort . Любой процесс имеет возможность подключиться к этому порту в качестве клиента, используя функцию NtAlpcConnectPort . Один «процесс‑сервер» может взаимодействовать сразу с несколькими клиентами одновременно.

Рассмотрим последний протокол, который фигурирует в RPC — DCOM, чья аббревиатура расшифровывается как Distributed COM. Фактически эта технология вызова COM‑интерфейсов удалённо. Тут нет больших отличий со стороны трафика, но есть различия в механизме вызова удаленных функций. DCOM не вызывает функции напрямую, а сначала инициализирует COM‑объект, функционал которого будет использовать. Концептуально это похоже на NPs с их разделением функционала на отдельные именованные каналы. Если рассматривать алгоритм общения клиента и сервера, то здесь не так много отличий от «чистого» RPC, но есть два исключения — вызов функций ISystemActivator и IDispatch.

Для вызова функции определённого COM объекта, такой объект сначала нужно вызвать, чтобы затем он «запустился»: загрузился в оперативную память и был доступен для работы. В локальном мире этим занимается COM интерфейс IUnknown. Он позволяет также узнать функции неизвестных COM интерфейсов для работы с ними.

При работе с DCOM ту же функцию выполняет ISystemActivator, позволяя обратиться к неизвестным DCOM интерфейсам, являющимися по сути теми же COM объектам, и работать с ними. ISystemActivator вызывается каждый раз при новом DCOM подключении.

Рисунок 4. Пример, как выглядит DCOM в Wireshark

Также IUnknown интерфейс дает возможность вызывать и другие функции COM объекта напрямую, фактически сводя всю работу с COM объектами до одной лишь функции IUnknown интерфейса. Тоже самое выполняет и интерфейс IDispatch для DCOM, позволяя выполнять любую функцию в мире DCOM через него. Поэтому, если мы взглянем на трафик, то увидим сначала вызов ISystemActivator, а потом только лишь обращения к IDispatch, вне зависимости от того какую DCOM функцию использует клиент.

Рассказывая про ALPC, мы упомянули, что эта технология используется только локально. Но это, конечно, не совсем правда, так как ALPC задействован чуть ли не во всех компонентах Windows. Поэтому, так или иначе, любое действие, в том числе и удалённое, будет прямо или косвенно применять ALPC. Это особенно интересно в контексте DCOM, потому что он напрямую использует ALPC на локальной машине, при этом будучи вызванным удалённым пользователем.

Схема вариантов RPC-подключений

Подведем итог вышесказаного в виде схемы вариантов подключения к удалённой машине, отражающей возможные пути со стороны клиента, которые в том числе доступны и для атакующего. Как видим из рисунка 5, все не так просто.

Рисунок 5. Возможные способы подключения к RPC серверу

Способы мониторинга

Разобравшись с вариантами RPC‑подключений, и, как следствие, с потенциально возможными действиями со стороны атакующего, рассмотрим, варианты мониторинга, которые нам может предоставить сама операционная система: ETW, журналы безопасности, SACL, RPC Filtering, RPC Firewall и сетевой трафик.

И начнем с технологии, на базе которой строится функционал для логирования событий в операционной системе Windows — Event Tracing for Windows (ETW).

Event Tracing for Windows

Event Tracing for Windows или сокращено ETW имеет множество, так называемых, провайдеров, которых в ОС более нескольких тысяч. Они позволяют отслеживать через события как отдельные технологии, так и конкретные процессы. Часть провайдеров формируют вполне понятные для обыденного пользователя события, другая же, бОльшая часть, используется исключительно только самой Microsoft для отладки.

ETW предоставляет возможность смотреть события вызовов RPC функций через стандартную оснастку Event Viewer. ETW провайдеры, связанные с RPC, представлены в таблице ниже.

Что такое сервер RPC и как исправить ошибку «сервер RPC недоступен»

На компьютерах достаточно часто возникают разного рода ошибки. Проблема, связанная с недоступностью RPC сервера не исключение. В основном она появляется при обновлении драйверов, но бывают случаи, когда ошибки «сервер RPC недоступен» возникает и при запуске операционной системы (ОС) Windows 7, 8, 10, а также XP или Server 2003, 2008, 2012. Также ошибка может возникать при печати или установке принтера.

Принцип работы RPC

RPC — это просто метод для передачи информации между различными процессами или клиентом (техника, что начинает связь) и сервером (устройством, которое пытается связаться с клиентом) в рамках системы или сети. Очень много компонентов ОС Виндовс использует этот способ “общения”. RPC в качестве точек связи использует разные порты чтобы связывать системы между собой.

В случае нарушения работы сервера, когда он недоступен, обмен пакетов данных между системами нарушается, теряется связь с удаленным объектом и функции просто перестают ее выполнять. Поэтому и возникает ошибка.

Что за ошибка и почему возникает

Проблема появляется, когда связь между системами нарушается, так как сервер не может отправить адрес порта точке связи. Появиться она может по следующим причинам:

1. Работа службы PRC была приостановлена или вовсе не запущена.
2. Наименование сервера может быт по ошибке связано с не тем адресом. Получается, что клиент пытается связаться с не тем “собеседником”. Также бывает, что связь пытаются наладить через порт, который не используется или имя сервера просто не распознается системой.
3. Трафик был заблокирован брандмауэром или другим приложением для обеспечения безопасности.
4. Есть проблемы с сетью, которые мешают связи между клиентом и сервером.
5. Недавно были установлены драйвера на принтер, МФУ, звуковую карту и т.д.

Поиск причины

Причину, которая вызвала ошибку легко выявить по ее коду. Ее возможно посмотреть в журнале событий, только делать это рекомендуется сразу после обнаружения проблемы:

1. Открыть меню “Пуск”.
2. Перейти в панель управления.
3. Зайти на вкладку администрирования и открыть окно просмотра событий.
4. Поискать в журнале сообщение об ошибке (обычно помечено красным крестом). Как правило, если сделать все действия сразу после первого появления ошибки, то она будет в первой строке. В ней будет находится расшифровка и устройство, которое вызывает неполадки.
5. Найти описание проблемы в интернете, а также способы решения.

Общие способы решения

Есть универсальные способы, которые помогают быстро устранить проблему с сервером РПЦ. На их выполнения потребуется немного времени, но результат не заставит ждать.

Перезапуск службы RPC

Для начала рекомендуется просто перезапустить службу. Возможно, что неполадки в работе при этом будут устранены. Сделать это можно следующим образом:

1. Открыть диспетчер задач.
2. Перейти на вкладку “Службы”.
3. Найти необходимое. Для удобства рекомендуется выстроить элементы по алфавиту, что можно сделать одним кликом на столбик “Имена”.
4. Кликнуть правой кнопкой мышки по службе и выбрать пункт “Перезапустить”.

После этого процесс прекратит работу и тут же запустится.

Отключение брандмауэра

Этот защитник может попросту не пропускать важные пакеты данных. Именно поэтому рекомендуется отключить его на время, чтобы точно удостовериться, что это не его вина.

Сделать это можно через панель управления, в разделе системы и безопасности.

Проверка времени компьютера

Если ошибка появилась в момент запуска какой-то программы или ее остановки, то вероятно все связанно с синхронизацией времени. Решить эту проблемы можно таким образом:

1. Зайти в диспетчер задач. Перейти в последнюю вкладку. Внизу окна будет ссылка “Открыть Службы”.
2. Откроется окно, в котором требуется найти службу времени.
3. Если она была приостановлена, то ее требуется запустить. При активной службе рекомендуется выполнить перезапуск.

Устранение неполадок системы

В случае, если ошибка «сервер РПЦ недоступен» появилась при запуске ОС, необходимо сделать следующее:

1. Перезагрузить компьютер.
2. Нажать кнопку F8 при загрузке.
3. Выбрать пункт «Устранение неполадок компьютера».
4. Дождаться окончания процесса.

Проверка на вирусы

Также можно просканировать систему на наличие вредоносного программного обеспечения (ПО). Также, если антивирус обнаружит что-то, то его рекомендуется заменить. Дело в том, что если программа не обнаружила вирус самостоятельно, а только после ручного запуска сканирования, то значит, что она не выполняет своих функций.

При обнаружении вируса, его необходимо удалить.

Ошибка с кодом 1722

Ошибка «Сервер RPC недоступен» наиболее часто встречается при проблемах с отсутствием звука. Решается следующим образом:

1. Открыть диспетчер задач.
2. Перейти на вкладку “Службы”.
3. Внизу окна будет ссылка, кликнуть на нее для открытия всех служб.
4. Найти «Средство построения точек аудио».
5. Сделать тип запуска “Вручную” и сохранить изменения.

Ошибка в FineReader

Многие пользователи используют FineReader для поиска и распознавания текста на картинках. Она может вызывать проблемы, а устранить их можно следующим образом:

1. Зайти в “Службы” через диспетчер задач или панель управления.
2. Оставить службу FineReader.
3. Перезагрузить компьютер и запустить приостановленный процесс.

Проблемы с Bitlocker

Битлокер защищает информацию на носителях информации, например, флешках. И иногда работа этой технологии может вызывать ошибки с сервером RPC. Исправить это можно отключением технологии или просто обновлением. Это можно сделать через центр обновлений Виндовс или скачав необходимые файлы с интернета.

Remote Procedure Call

Удалённый вызов процедур (или Вызов удалённых процедур) (от англ. Remote Procedure Call (RPC) ) — класс технологий, позволяющих компьютерным программам вызывать функции или процедуры в другом адресном пространстве (как правило, на удалённых компьютерах). Обычно, реализация RPC технологии включает в себя два компонента: сетевой протокол для обмена в режиме клиент-сервер и язык сериализации объектов (или структур, для необъектных RPC). Различные реализации RPC имеют очень отличающуюся друг от друга архитектуру и разнятся в своих возможностях: одни реализуют архитектуру SOA, другие CORBA или DCOM. На транспортном уровне RPC используют в основном протоколы TCP и UDP, однако, некоторые построены на основе HTTP (что нарушает архитектуру ISO/OSI, так как HTTP изначально не транспортный протокол).

Содержание

Реализации

Существуют множество технологий, обеспечивающих RPC:

(бинарный протокол на базе TCP и UDP и XDR) RFC-1831 второе название ONC RPCRFC-1833 (бинарный протокол на базе TCP, UDP, HTTP)  — Simple Object Access Protocol (текстовый протокол на базе HTTP) см. спецификацию: RFC-4227 (текстовый протокол на базе HTTP) см. спецификацию: RFC-3529  — Java Remote Method Invocation — см. спецификацию: http://java.sun.com/j2se/1.5.0/docs/guide/rmi/index.html
• JSON-RPC JavaScript Object Notation Remote Procedure Calls (текстовый протокол на базе HTTP) см. спецификацию: RFC-4627
• DCE/RPC — Distributed Computing Environment / Remote Procedure Calls (бинарный протокол на базе различных транспортных протоколов, в том числе TCP/IP и Named Pipes из протокола SMB/CIFS)  — Distributed Component Object Model известный как MSRPC Microsoft Remote Procedure Call или «Network OLE» (объектно-ориентированное расширение DCE RPC, позволяющее передавать ссылки на объекты и вызывать методы объектов через таковые ссылки)

Принцип

Идея вызова удалённых процедур (Remote Procedure Call — RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удалённого вызова процедур предназначены для облегчения организации распределённых вычислений и создания распределенных клиент-серверных информационных систем. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удалёнными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.

Характерными чертами вызова локальных процедур являются:

• Асимметричность, то есть одна из взаимодействующих сторон является инициатором;
• Синхронность, то есть выполнение вызывающей процедуры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры.

Реализация удалённых вызовов существенно сложнее реализации вызовов локальных процедур. Можно обозначить следующие проблемы и задачи, которые необходимо решить при реализации RPC:

• Так как вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины находятся под управлением различных операционных систем или имеют различную архитектуру (например, используется прямой или обратный порядок байтов). Так как RPC не может рассчитывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Для копирования параметров процедуры и результата выполнения через сеть выполняется их сериализация.
• В отличие от локального вызова удалённый вызов процедур обязательно использует транспортный уровень сетевой архитектуры (например TCP), однако это остается скрытым от разработчика.
• Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса. Но в реализации RPC участвуют как минимум два процесса — по одному в каждой машине. В случае, если один из них аварийно завершится, могут возникнуть следующие ситуации: при аварии вызывающей процедуры удалённо вызванные процедуры станут «осиротевшими», а при аварийном завершении удалённых процедур станут «обездоленными родителями» вызывающие процедуры, которые будут безрезультатно ожидать ответа от удалённых процедур.
• Существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках. Таким образом имеется проблема совместимости, до сих пор не решённая ни с помощью введения одного общепринятого стандарта, ни с помощью реализации нескольких конкурирующих стандартов на всех архитектурах и во всех языках.

Подсистемы

• Транспортная подсистема

— управление исходящими и входящими соединениями. — поддержка понятия «граница сообщения» для транспортных протоколов, не поддерживающих его непосредственно (TCP). — поддержка гарантированной доставки для транспортных протоколов, не поддерживающих ее непосредственно (UDP).

• Пул потоков (только для вызываемой стороны). Предоставляет контекст выполнения для вызванного по сети кода.

(также называется «сериализация»). Упаковка параметров вызовов в поток байт стандартным образом, не зависящим от архитектуры (в частности, от порядка байт в слове). В частности, ему могут подвергаться массивы, строки и структуры, на которые указывают параметры-указатели.

• Шифрование пакетов и наложение на них цифровой подписи.

• Аутентификация и авторизация. Передача по сети информации, идентифицирующей субъект, осуществляющий вызов.

В некоторых реализациях RPC (.NET Remoting) границы подсистем являются открытыми полиморфными интерфейсами, и возможно написать свою реализацию почти всех перечисленных подсистем. В других реализациях (DCE RPC в Windows) это не так.

См. также

Вызов удаленных процедур (RPC) Концепция удаленного вызова процедур

Идея вызова удаленных процедур (Remote Procedure Call — RPC) состоит в расширении хорошо известного и понятного механизма передачи управления и данных внутри программы, выполняющейся на одной машине, на передачу управления и данных через сеть. Средства удаленного вызова процедур предназначены для облегчения организации распределенных вычислений. Наибольшая эффективность использования RPC достигается в тех приложениях, в которых существует интерактивная связь между удаленными компонентами с небольшим временем ответов и относительно малым количеством передаваемых данных. Такие приложения называются RPC-ориентированными.

Характерными чертами вызова локальных процедур являются:

• Асимметричность, то есть одна из взаимодействующих сторон является инициатором;
• Синхронность, то есть выполнение вызывающей процедуры приостанавливается с момента выдачи запроса и возобновляется только после возврата из вызываемой процедуры.

Реализация удаленных вызовов существенно сложнее реализации вызовов локальных процедур. Начнем с того, что поскольку вызывающая и вызываемая процедуры выполняются на разных машинах, то они имеют разные адресные пространства, и это создает проблемы при передаче параметров и результатов, особенно если машины не идентичны. Так как RPC не может рассчитывать на разделяемую память, то это означает, что параметры RPC не должны содержать указателей на ячейки нестековой памяти и что значения параметров должны копироваться с одного компьютера на другой. Следующим отличием RPC от локального вызова является то, что он обязательно использует нижележащую систему связи, однако это не должно быть явно видно ни в определении процедур, ни в самих процедурах. Удаленность вносит дополнительные проблемы. Выполнение вызывающей программы и вызываемой локальной процедуры в одной машине реализуется в рамках единого процесса. Но в реализации RPC участвуют как минимум два процесса — по одному в каждой машине. В случае, если один из них аварийно завершится, могут возникнуть следующие ситуации: при аварии вызывающей процедуры удаленно вызванные процедуры станут «осиротевшими», а при аварийном завершении удаленных процедур станут «обездоленными родителями» вызывающие процедуры, которые будут безрезультатно ожидать ответа от удаленных процедур.

Кроме того, существует ряд проблем, связанных с неоднородностью языков программирования и операционных сред: структуры данных и структуры вызова процедур, поддерживаемые в каком-либо одном языке программирования, не поддерживаются точно так же во всех других языках.

Эти и некоторые другие проблемы решает широко распространенная технология RPC, лежащая в основе многих распределенных операционных систем. Базовые операции RPC

Чтобы понять работу RPC, рассмотрим вначале выполнение вызова локальной процедуры в обычной машине, работающей автономно. Пусть это, например, будет системный вызов

count=read (fd, buf, nbytes);

где fd — целое число, buf — массив символов, nbytes — целое число.

Чтобы осуществить вызов, вызывающая процедура заталкивает параметры в стек в обратном порядке (рисунок 3.1). После того, как вызов read выполнен, он помещает возвращаемое значение в регистр, перемещает адрес возврата и возвращает управление вызывающей процедуре, которая выбирает параметры из стека, возвращая его в исходное состояние. Заметим, что в языке С параметры могут вызываться или по ссылке (by name), или по значению (by value). По отношению к вызываемой процедуре параметры-значения являются инициализируемыми локальными переменными. Вызываемая процедура может изменить их, и это не повлияет на значение оригиналов этих переменных в вызывающей процедуре.

Если в вызываемую процедуру передается указатель на переменную, то изменение значения этой переменной вызываемой процедурой влечет изменение значения этой переменной и для вызывающей процедуры. Этот факт весьма существенен для RPC.

Существует также другой механизм передачи параметров, который не используется в языке С. Он называется call-by-copy/restore и состоит в необходимости копирования вызывающей программой переменных в стек в виде значений, а затем копирования назад после выполнения вызова поверх оригинальных значений вызывающей процедуры.

Решение о том, какой механизм передачи параметров использовать, принимается разработчиками языка. Иногда это зависит от типа передаваемых данных. В языке С, например, целые и другие скалярные данные всегда передаются по значению, а массивы — по ссылке.

Применение

Значительная часть инструментов удаленного управления операционной системой Windows (Event Viewer, Server Manager, управление печатью, списками пользователей) использует DCE RPC как средство общения по сети между управляемой службой и управляющим приложением пользовательского интерфейса. Поддержка DCE RPC присутствовала в Windows NT с самой первой версии 3.1. Клиенты DCE RPC поддерживались и в облегченной линии операционных системы Windows 3.x/95/98/Me.

Системные библиотеки Windows, предоставляющие возможности такого управления и служашие базовым уровнем для управляюших приложений пользовательского интерфейса (netapi32.dll и отчасти advapi32.dll), на деле содержат в себе клиентский код интерфейсов DCE RPC, осуществляющих это управление.

Это архитектурное решение было предметом активной критики в адрес Microsoft. Универсальные процедуры маршаллинга, присутствующие в DCE RPC, очень сложны и имеют огромный потенциал наличия дефектов, эксплуатируемых в сети путем посылки умышленно искаженного пакета DCE RPC. Значительная часть дефектов безопасности Windows, обнаруженных с конца 90-х до середины 2000-х годов, представляла собой именно ошибки в коде маршаллинга DCE RPC.

Помимо DCE RPC, в Windows активно применяется технология DCOM. Так, например, она используется как средство общения между инструментами управления веб-сервером IIS и собственно управляемым сервером. Полнофункциональный интерфейс общения с почтовой системой MS Exchange Server — MAPI — также основан на DCOM.