протокол удалённого вызова процедур

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

История

Концепция удалённого вызова процедур была впервые формализована в 1970-х годах в рамках исследований в области распределённых вычислений. Одним из первых практических воплощений стала система Birrell–Nelson RPC, разработанная в 1984 году в Xerox PARC. Она заложила основы для синхронного вызова, сериализации данных и обработки ошибок. В 1980-х годах компания Sun Microsystems внедрила протокол ONC RPC (Open Network Computing Remote Procedure Call), который стал стандартом для Unix-систем и использовался в таких службах, как NFS (Network File System). В 1990-х годах корпорация Microsoft разработала DCE/RPC (Distributed Computing Environment / Remote Procedure Call) и его расширение — COM/DCOM (Component Object Model / Distributed COM), которые активно применялись в Windows-среде. С развитием интернета и веб-сервисов в начале 2000-х годов появились протоколы XML-RPC и SOAP (Simple Object Access Protocol), основанные на XML-сообщениях. В 2010-х годах с ростом популярности микросервисных архитектур и высокопроизводительных систем был разработан gRPC (от Google), использующий Protocol Buffers для сериализации и HTTP/2 для транспорта.

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

Протокол RPC реализует модель «клиент-сервер», где клиентская программа вызывает удалённую процедуру, а серверная — выполняет её и возвращает результат. Процесс включает несколько этапов:

Сериализация параметров — преобразование данных (например, чисел, строк, структур) в формат, пригодный для передачи по сети (например, JSON, XML, Protocol Buffers).
Передача запроса — отправка сериализованных данных на сервер через транспортный протокол (TCP, UDP, HTTP/2).
Демультиплексирование — сервер идентифицирует вызываемую процедуру по идентификатору, переданному в запросе.
Выполнение процедуры — сервер запускает соответствующую функцию, передавая ей десериализованные параметры.
Сериализация ответа — результат выполнения процедуры преобразуется в формат для передачи обратно.
Передача ответа — сервер отправляет сериализованный результат клиенту.
Десериализация и возврат — клиент получает ответ, преобразует его в локальные типы данных и возвращает вызывающему коду.

Для обеспечения прозрачности RPC использует стаб-функции (stubs): на стороне клиента — клиентский стаб (proxy), который имитирует локальную процедуру, а на стороне сервера — серверный стаб (skeleton), который вызывает реальную реализацию. Стабы генерируются автоматически на основе интерфейсного описания (например, IDL — Interface Definition Language).

Классификация протоколов RPC

Протоколы RPC могут классифицироваться по нескольким признакам:

По типу синхронности

Синхронные — клиент блокирует выполнение до получения ответа от сервера. Это классический и наиболее распространённый тип.
Асинхронные — клиент отправляет запрос и продолжает работу, не дожидаясь ответа. Результат может быть получен через callback, future или опрос.
Однонаправленные (fire-and-forget) — клиент отправляет запрос без ожидания ответа, что используется для уведомлений или событий.

По формату сериализации

Текстовые — данные передаются в читаемом формате (XML, JSON). Примеры: XML-RPC, SOAP, JSON-RPC. Медленнее, но удобнее для отладки.
Бинарные — данные передаются в компактном бинарном формате (Protocol Buffers, Thrift, Avro). Быстрее и эффективнее по размеру, но сложнее в отладке.

По транспортному протоколу

На основе TCP — обеспечивают надёжную доставку, но могут быть медленнее из-за установки соединения.
На основе UDP — быстрее, но не гарантируют доставку или порядок сообщений.
На основе HTTP/2 — современные протоколы (например, gRPC) используют HTTP/2 для мультиплексирования и потоковой передачи.

По архитектуре

Двухзвенные — прямое взаимодействие клиента и сервера.
Многоуровневые — запросы могут проходить через промежуточные серверы (например, в микросервисных архитектурах с балансировщиками нагрузки).

Основные протоколы и реализации

ONC RPC (Open Network Computing RPC)

Разработан Sun Microsystems в 1980-х годах. Использует XDR (External Data Representation) для сериализации. Широко применялся в NFS и NIS (Network Information Service). Работает поверх TCP или UDP. Является одним из старейших стандартов.

DCE/RPC (Distributed Computing Environment RPC)

Стандарт, разработанный Open Software Foundation (OSF) в 1990-х годах. Использует IDL для описания интерфейсов. Лёг в основу Microsoft RPC и COM/DCOM. Применялся в Windows-среде для межпроцессного взаимодействия.

XML-RPC

Протокол, созданный в 1998 году компанией UserLand Software. Использует XML для кодирования вызовов и HTTP в качестве транспорта. Прост и удобен, но менее производителен из-за текстового формата. Применялся в ранних веб-сервисах и системах управления контентом (например, WordPress).

SOAP (Simple Object Access Protocol)

Разработан консорциумом W3C в начале 2000-х годов. Основан на XML и поддерживает сложные типы данных, безопасность (WS-Security) и транзакции. Использует HTTP, SMTP или другие протоколы. Был популярен в корпоративных приложениях, но впоследствии вытеснен более лёгкими решениями.

JSON-RPC

Лёгкий протокол, использующий JSON для сериализации. Работает поверх HTTP, TCP или WebSockets. Поддерживает как синхронные, так и асинхронные вызовы. Применяется в веб-приложениях и API.

gRPC

Разработан компанией Google в 2015 году. Использует Protocol Buffers для сериализации и HTTP/2 для транспорта. Поддерживает потоковую передачу (однонаправленную, двунаправленную) и асинхронные вызовы. Написан на C++, но имеет клиентские библиотеки для многих языков (Go, Java, Python, C# и др.). Активно применяется в микросервисных архитектурах, облачных вычислениях и системах реального времени.

Apache Thrift

Разработан Facebook (продукт Meta, признанной экстремистской и запрещённой в РФ) в 2007 году, открыт в 2008 году. Позволяет определять типы данных и интерфейсы в IDL, генерировать код для различных языков. Поддерживает бинарные и текстовые протоколы, а также транспортные уровни (TCP, HTTP, сжатие). Используется в крупных распределённых системах, таких как Apache Cassandra и Apache Hadoop.

Применение

Протоколы RPC широко применяются в различных областях информационных технологий:

Микросервисные архитектуры — gRPC и Thrift используются для взаимодействия между микросервисами благодаря высокой производительности и поддержке потоковой передачи.
Облачные вычисления — RPC-протоколы лежат в основе API облачных провайдеров (например, Google Cloud Pub/Sub, AWS Lambda).
Базы данных — распределённые базы данных (например, CockroachDB, TiDB) используют RPC для координации узлов и репликации данных.
Системы реального времени — gRPC с двунаправленной потоковой передачей применяется в чатах, онлайн-играх и IoT-системах.
Веб-сервисы — SOAP и XML-RPC используются в корпоративных веб-сервисах, особенно в финансовом и банковском секторах.
Операционные системы — DCE/RPC и Microsoft RPC применяются для межпроцессного взаимодействия в Windows.

Преимущества и недостатки

Преимущества

Прозрачность — разработчик может вызывать удалённые процедуры так же, как локальные, что упрощает создание распределённых приложений.
Стандартизация — многие протоколы (gRPC, Thrift) имеют чёткие спецификации и генераторы кода, что снижает вероятность ошибок.
Производительность — бинарные протоколы (Protocol Buffers, Thrift) обеспечивают высокую скорость сериализации и малый размер сообщений.
Кроссплатформенность — RPC-протоколы поддерживают множество языков программирования и операционных систем.

Недостатки

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

Сравнение с другими технологиями

Протоколы RPC часто сравнивают с REST (Representational State Transfer) — архитектурным стилем для веб-сервисов. REST использует HTTP-методы (GET, POST, PUT, DELETE) и ресурсно-ориентированный подход, в то время как RPC фокусируется на вызове процедур. RPC обычно быстрее и эффективнее для сложных операций, но REST более гибок и прост в кэшировании. В микросервисных архитектурах часто используют комбинацию: gRPC для внутренних вызовов и REST для внешних API.

Интересные факты

Протокол gRPC был разработан Google для внутренних нужд, но открыт в 2015 году. Он используется в таких продуктах, как Google Cloud, Kubernetes и Netflix.
Apache Thrift изначально создавался для решения проблем с производительностью в Facebook, где требовалось обрабатывать миллионы запросов в секунду.
XML-RPC считается предшественником SOAP и был одним из первых протоколов, позволивших веб-приложениям взаимодействовать через HTTP.
В 2020 году компания Microsoft объявила о прекращении поддержки Windows Communication Foundation (WCF), который базировался на SOAP, в пользу gRPC и REST.

Источники

Birrell, A. D., & Nelson, B. J. (1984). Implementing Remote Procedure Calls. ACM Transactions on Computer Systems, 2(1), 39–59.
Tanenbaum, A. S., & Van Steen, M. (2007). Distributed Systems: Principles and Paradigms (2nd ed.). Pearson.
gRPC Documentation. (2023). gRPC: A high-performance, open-source universal RPC framework. Google.
Apache Thrift. (2023). Apache Thrift: A software framework for scalable cross-language services development. Apache Software Foundation.
W3C. (2007). SOAP Version 1.2 Part 1: Messaging Framework (2nd ed.). World Wide Web Consortium.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →