secure rpc что это
Secure rpc что это
Overview of Secure RPC
Secure RPC (Remote Procedure Call) protects remote procedures with an authentication mechanism. The Diffie-Hellman authentication mechanism authenticates both the host and the user who is making a request for a service. The authentication mechanism uses Data Encryption Standard (DES) encryption. Applications that use Secure RPC include NFS and the naming services, NIS and NIS+.
NFS Services and Secure RPC
NFS enables several hosts to share files over the network. Under the NFS service, a server holds the data and resources for several clients. The clients have access to the file systems that the server shares with the clients. Users who are logged in to the client systems can access the file systems by mounting the file systems from the server. To the user on the client system, it appears as if the files are local to the client. One of the most common uses of NFS allows systems to be installed in offices, while storing all user files in a central location. Some features of the NFS service, such as the -nosuid option to the mount command, can be used to prohibit the opening of devices and file systems by unauthorized users.
The NFS service uses Secure RPC to authenticate users who make requests over the network. This process is known as Secure NFS. The Diffie-Hellman authentication mechanism, AUTH_DH, uses DES encryption to ensure authorized access. The AUTH_DH mechanism has also been called AUTH_DES. For more information, see the following:
For an outline of the transactions that are involved in RPC authentication, see Implementation of Diffie-Hellman Authentication.
DES Encryption With Secure NFS
The Data Encryption Standard (DES) encryption functions use a 56-bit key to encrypt data. If two credential users or principals know the same DES key, they can communicate in private by using the key to encipher and decipher text. DES is a relatively fast encryption mechanism. A DES chip makes the encryption even faster. However, if the chip is not present, a software implementation is substituted.
The risk of using just the DES key is that an intruder can collect enough cipher-text messages that were encrypted with the same key to be able to discover the key and decipher the messages. For this reason, security systems such as Secure NFS need to change the keys frequently.
Kerberos Authentication
Kerberos is an authentication system that was developed at MIT. Some encryption in Kerberos is based on DES. Kerberos V4 support is no longer supplied as part of Secure RPC. However, a client-side and server-side implementation of Kerberos V5, which uses RPCSEC_GSS, is included with this release. For more information, see Chapter 21, Introduction to the Kerberos Service.
Diffie-Hellman Authentication and Secure RPC
The Diffie-Hellman (DH) method of authenticating a user is nontrivial for an intruder to crack. The client and the server have their own private key, which they use with the public key to devise a common key. The private key is also known as the secret key. The client and the server use the common key to communicate with each other. The common key is encrypted with an agreed-upon encryption function, such as DES.
Authentication is based on the ability of the sending system to use the common key to encrypt the current time. Then, the receiving system can decrypt and check against its current time. The time on the client and the server must be synchronized. For more information, see Managing Network Time Protocol (Tasks) in System Administration Guide: Network Services.
The public keys and private keys are stored in an NIS or NIS+ database. NIS stores the keys in the publickey map. NIS+ stores the keys in the cred table. These files contain the public key and the private key for all potential users.
The system administrator is responsible for setting up NIS maps or NIS+ tables, and for generating a public key and a private key for each user. The private key is stored in encrypted form with the user’s password. This process makes the private key known only to the user.
Implementation of Diffie-Hellman Authentication
This section describes the series of transactions in a client-server session that use Diffie-Hellman authentication (AUTH_DH).
Generating the Public Keys and Secret Keys for Secure RPC
Sometime prior to a transaction, the administrator runs either the newkey or the nisaddcred command to generate a public key and a secret key. Each user has a unique public key and secret key. The public key is stored in a public database. The secret key is stored in encrypted form in the same database. The chkey command changes the key pair.
Running the keylogin Command for Secure RPC
Normally, the login password is identical to the Secure RPC password. In this case, the keylogin command is not required. However, if the passwords are different, the users have to log in and then run the keylogin command.
The keylogin command prompts the user for a Secure RPC password. The command then uses the password to decrypt the secret key. The keylogin command then passes the decrypted secret key to the keyserver program. The keyserver is an RPC service with a local instance on every computer. The keyserver saves the decrypted secret key and waits for the user to initiate a Secure RPC transaction with a server.
If both the login password and the RPC password are the same, the login process passes the secret key to the keyserver. If the passwords are required to be different, then the user must always run the keylogin command. When the keylogin command is included in the user’s environment configuration file, such as the
/.profile file, the keylogin command runs automatically whenever the user logs in.
Generating the Conversation Key for Secure RPC
When the user initiates a transaction with a server, the following occurs:
The keyserver randomly generates a conversation key.
The kernel uses the conversation key, plus other material, to encrypt the client’s timestamp.
The keyserver looks up the server’s public key in the public key database. For more information, see the publickey(4) man page.
The keyserver uses the client’s secret key and the server’s public key to create a common key.
The keyserver encrypts the conversation key with the common key.
Initially Contacting the Server in Secure RPC
The transmission, which includes the encrypted timestamp and the encrypted conversation key, is then sent to the server. The transmission includes a credential and a verifier. The credential contains three components:
The client’s network name
The conversation key, which is encrypted with the common key
A “window,” which is encrypted with the conversation key
The window is the difference in time that the client says should be allowed between the server’s clock and the client’s timestamp. If the difference between the server’s clock and the timestamp is greater than the window, the server rejects the client’s request. Under normal circumstances, this rejection does not happen, because the client first synchronizes with the server before starting the RPC session.
The client’s verifier contains the following:
The encrypted timestamp
An encrypted verifier of the specified window, which is decremented by 1
The window verifier is needed in case somebody wants to impersonate a user. The impersonator can write a program that, instead of filling in the encrypted fields of the credential and verifier, just inserts random bits. The server decrypts the conversation key into some random key. The server then uses the key to try to decrypt the window and the timestamp. The result is random numbers. After a few thousand trials, however, the random window/timestamp pair is likely to pass the authentication system. The window verifier lessens the chance that a fake credential could be authenticated.
Decrypting the Conversation Key in Secure RPC
When the server receives the transmission from the client, the following occurs:
The keyserver that is local to the server looks up the client’s public key in the public key database.
The keyserver uses the client’s public key and the server’s secret key to deduce the common key. The common key is the same common key that is computed by the client. Only the server and the client can calculate the common key because the calculation requires knowing one of the secret keys.
The kernel uses the common key to decrypt the conversation key.
The kernel calls the keyserver to decrypt the client’s timestamp with the decrypted conversation key.
Storing Information on the Server in Secure RPC
After the server decrypts the client’s timestamp, the server stores four items of information in a credential table:
The client’s computer name
The conversation key
The client’s timestamp
The server stores the first three items for future use. The server stores the client’s timestamp to protect against replays. The server accepts only timestamps that are chronologically greater than the last timestamp seen. As a result, any replayed transactions are guaranteed to be rejected.
Returning the Verifier to the Client in Secure RPC
The server returns a verifier to the client, which includes the following:
The index ID, which the server records in its credential cache
The client’s timestamp minus 1, which is encrypted by the conversation key
The reason for subtracting 1 from the client’s timestamp is to ensure that the timestamp is out of date. An out-of-date timestamp cannot be reused as a client verifier.
Authenticating the Server in Secure RPC
The client receives the verifier and authenticates the server. The client knows that only the server could have sent the verifier because only the server knows what timestamp the client sent.
Handling Transactions in Secure RPC
With every transaction after the first transaction, the client returns the index ID to the server in its next transaction. The client also sends another encrypted timestamp. The server sends back the client’s timestamp minus 1, which is encrypted by the conversation key.
Русские Блоги
Введение в основы RPC: введение в принципы и простые примеры
1. RPC
1. Что такое RPC
2. Зачем использовать RPC?
Фактически это обусловлено высоким спросом на разработку приложений до определенной стадии.
1. Если мы разрабатываем простое одиночное приложение, логика проста, пользователей не так много, а трафик не велик, тогда нам это не нужно;
2. Когда число посещений нашей системы увеличивается, бизнес растет, и мы обнаружим, что один компьютер с этой системой больше не может себе позволить. В настоящее время мы можем разделить бизнес на несколькоНесвязанные приложенияОтдельно развернуты на своих соответствующих машинах для уточнения логики и снижения давления. В это время нам также может не понадобиться RPC, поскольку приложения не связаны друг с другом.
3. Естественно, когда у нас будет все больше и больше приложений и все больше и больше приложений, мы обнаружим, что некоторые функцииНельзя легко разделить или нет, В это время общедоступная бизнес-логика может быть извлечена и объединена в независимое сервисное приложение службы. Как исходные, так и вновь добавленные приложения могут взаимодействовать с этими независимыми приложениями-службами для выполнения полных бизнес-функций. Так что в это время нам срочно нужноЭффективное средство связи между приложениямиКак видите, для того, чтобы удовлетворить эту потребность, пришло время RPC показать свою силу!
На самом деле сценарий, описанный в 3, также Сервис, микросервис сАрхитектура распределенной системы Основная сцена. Таким образом, структура RPC является мощным способом достижения вышеуказанной структуры.
Во-вторых, принцип и рамки RPC
В документе Нельсона указывалось, что процедура внедрения СРП состоит из пяти частей:
Соотношение между этими пятью частями показано на рисунке ниже
Здесь пользователь является клиентской стороной, когда пользователь хочет инициировать удаленный вызов, он фактически вызывается локальноuser-stub, Пользовательская заглушка отвечает за кодирование вызываемых интерфейсов, методов и параметров через согласованные спецификации протокола и передачу их удаленному экземпляру через локальный экземпляр RPCRuntime. После получения запроса удаленный экземпляр RPCRuntime передает его заглушке на сервер для декодирования и инициирует локальный вызов, и результат вызова возвращается пользователю.
Крупнозернистый RPC реализует концептуальную структуру, здесь мы дополнительно уточним, из каких компонентов он должен состоять, как показано на следующем рисунке.
Сервер RPC использует RpcServer для экспорта метода удаленного интерфейса, а клиент использует RpcClient для импорта метода удаленного интерфейса. Клиент вызывает метод удаленного интерфейса, как локальный метод. Структура RPC обеспечивает реализацию интерфейса через прокси. Фактический вызов будет делегирован прокси RpcProxy. Агент инкапсулирует информацию о вызове и перенаправляет вызов в RpcInvoker для фактического выполнения. RpcInvoker на клиенте поддерживает канал RpcChannel с сервером через соединитель RpcConnector и использует RpcProtocol для выполнения кодирования (кодирования) протокола и отправляет закодированное сообщение запроса на сервер через канал.
Приемник RpcAcceptor сервера RPC получает запрос вызова клиента, а также использует RpcProtocol для выполнения декодирования (декодирования) протокола. Декодированная информация о вызове передается в RpcProcessor для управления процессом вызова, и, наконец, вызов делегируется в RpcInvoker для фактического выполнения и возврата результата вызова. Ниже приведены подробные обязанности каждой части:
1. RpcServer
Ответственный за экспорт (экспорт) удаленного интерфейса
2. RpcClient
Реализация прокси, отвечающая за импорт удаленных интерфейсов
3. RpcProxy
Прокси-реализация удаленного интерфейса
4. RpcInvoker
Реализация клиента: отвечает за кодирование информации о вызове и отправку запроса вызова на сервер и ожидание возврата результата вызова
Реализация сервера: отвечает за вызов конкретной реализации интерфейса сервера и возврат результата вызова
5. RpcProtocol
Ответственный за протокол кодирования / декодирования
6. RpcConnector
Отвечает за поддержание канала связи между клиентом и стороной обслуживания и отправку данных стороне обслуживания
7. RpcAcceptor
Отвечает за получение клиентских запросов и возврат результатов запроса.
8. RpcProcessor
Он отвечает за управление вызывающим процессом на стороне службы, включая управление пулом вызывающих потоков, временем ожидания и т. Д.
9. RpcChannel
Канал передачи данных
В-третьих, обычно используемая среда RPC в Java
Текущая обычно используемая среда RPC выглядит следующим образом:
3. Spring Cloud Spring Cloud состоит из множества подпроектов, таких как Spring Cloud Config, Spring Cloud Netflix, Spring Cloud Consul и т. Д., Которые предоставляют инструменты, обычно используемые для создания распределенных систем и микросервисов, такие как управление конфигурацией, обнаружение служб, прерыватели цепи, интеллектуальная маршрутизация, Прокси, шина управления, одноразовый токен, глобальная блокировка, выбор мастера, распределенный сеанс и состояние кластера и т. Д. Соответствуют всем решениям, необходимым для построения микросервисов. Spring Cloud основан на Spring Boot, что делает разработку и развертывание чрезвычайно простыми.
В-четвертых, разница между RPC и очередью сообщений
1. Функциональные различия
В архитектуре разница между RPC и Message заключается в том, что Message имеет очередь сообщений промежуточного узла, которая может хранить сообщения.
Особенности сообщения
1. Очередь сообщений сохраняет давление запроса и постепенно освобождает его, позволяя процессору обрабатывать его в своем темпе.
2. Очередь сообщений вводит новый узел. Надежность системы будет зависеть от узла очереди сообщений.
3. Очередь сообщений Асинхронный односторонний Новости. Отправка сообщений разработана таким образом, что нет необходимости ждать завершения обработки сообщения.
Так что для Синхронный возврат Использование очереди сообщений становится проблематичным.
Особенности RPC
Синхронный вызов. Для сценариев, в которых вы хотите дождаться возвращаемого результата / результата обработки, RPC является очень естественным и интуитивно понятным способом (RPC также может быть асинхронным вызовом).
В результате ожидания Consumer (клиент) будет потреблять потоки. При использовании в асинхронном RPC потребление потоков клиента (клиента) может быть устранено. Тем не менее, невозможно временно хранить сообщения / запросы, такие как сообщения, и давление будет напрямую передано поставщику услуг.
2. Различия в применимых случаях
1. RPC подходит, если вы хотите получить результат синхронно.
2. Если вы хотите использовать простой, то RPC; операция RPC основана на простом в использовании интерфейсе, используйте режим для имитации локальных вызовов. Программирование в асинхронном режиме является более сложным.
3. Не хочу отправителя (получатель RPC, отправитель сообщения) Ограничено стороной обработки (RPC Provider, Message Receiver), используйте очередь сообщений.
По мере роста бизнеса некоторые вычислительные мощности станут узким местом и будут продолжаться Синхронный вызов асинхронного сообщения Ремонт. Такая трансформация фактически меняет способ использования бизнеса. Например, после отправки исходной страницы операции на следующей странице будет показан результат обработки, а после преобразования асинхронного сообщения следующая страница станет «операция отправлена, и вы получите уведомление о ее завершении».
3. Описание неподходящих случаев
1. Синхронный вызов RPC использует очередь сообщений для передачи информации о вызове. Приведенный выше анализ показывает, что таким образом отправитель ожидает, занимая промежуточную точку ресурсов. Это становится сложным, но нет эквивалентного усиления.
2. Для вызова, возвращаемое значение которого равно void, вы можете сделать это, потому что фактически этому бизнесу вызовов часто не нужно получать результат обработки синхронно, если он может быть обработан. (Метод RPC может гарантировать, что вызов возвращается и обработка завершена. Это невозможно гарантировать после использования метода сообщения.)
3. Возвращаемое значение является вызовом void и используется сообщение. По сути, метод использования сообщения Wrap становится вызовом службы (метод использования вызова службы прост, основан на бизнес-интерфейсе).
V. Основные технические аспекты структуры RPC
Несколько основных технических моментов, реализованных в рамках RPC:
(1) Сервисное воздействие:
Удаленный поставщик должен предоставить в некоторой формеИнформация о сервисном звонке,в том числе, но не ограничиваетсяОпределение интерфейса сервиса、структура данныхИли промежуточныйФайл определения сервиса, Например, Facebook ThriftФайл IDL, Веб-сервисФайл WSDLВызывающий службу должен получать информацию, связанную с удаленным вызовом службы, определенным образом.
Существует также специальный звонок в JavaПолиморфизмТо есть, может быть несколько реализаций интерфейса, так что из них вызывается при удаленном вызове? Семантика этого локального вызова неявно реализуется посредством ссылочного полиморфизма, предоставляемого jvm, поэтому для RPC межпроцессные вызовы не могут быть реализованы неявно. Если есть две реализации интерфейса DemoService выше, вам необходимо экспортировать интерфейсСпециальные теги для разных нужд реализации, Затем вам нужно передать тег при удаленном вызове, чтобы вызвать правильный класс реализации, который решаетПолиморфный звонокСемантическая проблема.
(2) Удаленный прокси-объект:
Служба, используемая вызывающей стороной службы, фактически является локальным агентом удаленной службы. Говоря прямо, значит пройтиДинамический проксивыполнить.
(3) Связь:
Структура RPC не имеет ничего общего с конкретным протоколом. RPC может быть основан наПротокол HTTP или TCPВеб-служба представляет собой RPC на основе протокола HTTP, имеет хорошую кроссплатформенность, но ее производительность не так хороша, как RPC на основе протокола TCP.
3. Режим ввода-вывода: Для поддержки высокого параллелизма традиционная блокировка ввода-вывода явно не подходит, поэтому нам нужноАсинхронный ввод-выводКоторый является НИО. Java предоставляет решение NIO, а Java 7 также обеспечивает лучшую поддержку NIO.2.
(4) Сериализация:
1. СериализацияВ конце концов, это связь на большие расстояния, и объект должен быть преобразован в двоичный поток для передачи. Различные среды RPC имеют разные сценарии применения и будут использовать разные технологии в сериализации. Что касается сериализации, Java предоставляет метод сериализации по умолчанию, но в случае высокого параллелизма этот метод принесет некоторые узкие места производительности, поэтому на рынке появилась серия отличных платформ сериализации, таких как : Protobuf, Kryo, Hessian, Jackson и т. Д., Которые могут заменить сериализацию по умолчанию в Java, тем самым обеспечивая более эффективную производительность.
2. Закодированный контентПо соображениям эффективности, чем меньше закодированная информация, тем лучше (меньше передаваемых данных) и чем проще правила кодирования, тем лучше (высокая эффективность выполнения). Ниже приведена информация, необходимая для кодирования:
6. Простая реализация фреймворка RPC и анализ его примеров
Сервер предоставляет услуги, ожидаемые клиентом, которые обычно включают в себя три части: интерфейс службы, внедрение службы и возможность регистрации службы, а именно: интерфейс службы
Предоставление сервиса: только когда сервис открыт, клиент может сделать вызов. Это одна из функций инфраструктуры RPC.
Служба, предоставляемая клиентским сервером-потребителем, обычно включает две части: интерфейс службы и ссылку на службу, две части, а именно: интерфейс службы: совместно использовать один и тот же интерфейс службы с сервером
Ссылка на сервис: потребитель делает удаленные вызовы через инфраструктуру RPC, которая также является одной из функций инфраструктуры RPC
(3). Реализация прототипа фреймворка RPC
Инфраструктура RPC в основном включает две основные функции: одну для служб предоставления информации на стороне сервера и одну для справочных служб на стороне клиента. Сервер выставлен сервис
Из простой реализации инфраструктуры RPC логика сервера RPC заключается в следующем: сначала создайте ServerSocket, отвечающий за прослушивание определенного порта и получение запросов на подключение клиента, а затем используйте собственный механизм сериализации / десериализации Java для анализа запроса, включая вызываемый метод. Имя, список параметров и фактические параметры, и, наконец, отражают конкретную реализацию интерфейса службы, вызывая сервер и возвращая результат клиенту. На этом процесс сервера простого вызова PRC завершен. Клиентская справочная служба
Выше приведен простой и полный код, реализованный простой структурой RPC.
VII. Объяснение некоторых вопросов о структуре СРП
(1). Как инфраструктура RPC обеспечивает прозрачный вызов удаленного сервиса?
(2). Как опубликовать свой сервис?
Как позволить другим использовать наш сервис? Можно ли напрямую написать сервисный IP и порт, как в коде выше? На самом деле, в реальной производственной реализации способ использования уведомлений о человеческой плоти нереален, потому что в реальном производстве служебные машины слишком часто подключены к сети или отключены. Если вы обнаружите, что один компьютер не предоставляет достаточно услуг, вам нужно добавить еще один. В это время вы должны сообщить вызывающему абоненту, что у меня теперь есть два IP-адреса. Вы должны опросить вызов для достижения балансировки нагрузки; Когда машина зависает, вызывающая сторона обнаруживает, что половина службы недоступна, и он может только вручную изменить код, чтобы удалить ip, который зависает на этой машине. Это должно быть довольно больно!
(3). Сериализация и десериализация
Мы знаем, что объекты Java не могут быть переданы напрямую по сети. Итак, как можно отправить наш RPC-запрос на сервер и как клиент может получить ответ от сервера? Ответ заключается в том, что при передаче объектов Java сначала сериализуйте их, а затем десериализуйте и восстановите объекты на соответствующем терминале для обработки. Фактически, существует много видов технологий сериализации / десериализации, таких как собственный метод сериализации Java, JSON, сериализация Али Hessian и ProtoBuff и т. Д. Они имеют различия в эффективности, но имеют свои собственные характеристики.