wifiwireles
Just Hatched
Зачем нам протокол RPC, если у нас есть HTTP? Прежде чем объяснять, сначала нам нужно понять, что такое протокол HTTP и что такое протокол RPC.
Что такое протокол HTTP?
HTTP — это широко используемый протокол сетевой передачи. Он определяет формат и метод связи между клиентами (например, браузерами, мобильными пользовательскими приложениями и т. д.) и серверами (веб-сайтами и т. д., которые предоставляют услуги, серверами). Он основан на запросе. -response — это модель связи, в которой сервер возвращает ответ в соответствии с запросом. И запрос, и ответ содержат некоторую информацию о взаимодействии между двумя концами (клиентом и сервером), например методы, заголовки, текст и т. д.
HTTP имеет множество преимуществ. Он поддерживает множество форматов данных и методов кодирования, может осуществлять межплатформенную и межъязыковую связь, а связь проста, гибка и легко расширяется. Но в то же время у него есть и некоторые недостатки:
(1) HTTP не сохраняет состояние, и соединение необходимо повторно устанавливать для каждого запроса, что увеличивает нагрузку на сеть и задержку.
(2) Передача данных основана на тексте, что приводит к большому объему данных и низкой эффективности анализа.
(3) Он имеет низкую безопасность и поэтому уязвим для атак типа «человек посередине», атак повторного воспроизведения и т. д.
(4) Семантика слаба. HTTP может выражать только базовые операции добавления, удаления, изменения и запроса и не может удовлетворить сложную бизнес-логику.
Что такое протокол RPC?
RPC означает удаленный вызов процедур, который представляет собой протокол удаленного вызова процедур, который позволяет клиенту вызывать функции на удаленном сервере так же, как вызов локальных функций.
Преимущества RPC заключаются в том, что он эффективен, мощен и прост в использовании, но у него также есть некоторые недостатки, такие как:
(1) В отличие от HTTP, RPC сохраняет состояние и должен поддерживать состояние соединения между клиентом и сервером, что увеличивает сложность и потребление ресурсов системы.
(2) Передача данных RPC основана на двоичном формате, что затрудняет чтение и отладку данных.
(3) RPC имеет плохую совместимость, и между различными платформами RPC могут быть несоответствия протоколов и интерфейсов.
(4) RPC имеет плохую масштабируемость и с трудом поддерживает такие функции, как динамическое обнаружение сервисов и балансировка нагрузки.
Выбор обоих
HTTP и различные протоколы RPC, основанные на TCP, определяют только протоколы прикладного уровня с разными форматами сообщений. Протокол HTTP — это протокол передачи гипертекста, а сам RPC — это не конкретный протокол, а метод вызова.
Хотя HTTP теперь называется протоколом гипертекста и поддерживает аудио и видео, HTTP изначально был разработан для отображения текста веб-страницы, поэтому передаваемый им контент представляет собой в основном строки, и в контенте много избыточности. Протокол RPC более настраиваемый и может использовать меньший protobuf или другие протоколы сериализации для сохранения данных структуры. В то же время ему не нужно учитывать различные варианты поведения браузера, такие как HTTP, и его производительность выше. Поэтому во внутренних микросервисах компании отказались от HTTP и вместо этого используют протокол RPC. Хотя позже HTTP был значительно улучшен, поскольку многие компании использовали протокол RPC в течение многих лет, по историческим причинам они обычно не заменяют его HTTP.
В реальных приложениях, будь то HTTP или RPC, они имеют свои преимущества и недостатки, и не существует абсолютного добра или зла. Выберите подходящий протокол для различных сценариев использования. например:
(1) В микросервисной архитектуре между службами требуются частые внутренние вызовы, и RPC может обеспечить более высокую производительность и надежность.
(2) При распределенных вычислениях большое количество вычислительных задач необходимо распределить по разным узлам для выполнения. RPC может реализовать более гибкий механизм балансировки нагрузки и отказоустойчивости.
(3) При общении в реальном времени необходимо обеспечить обмен данными с низкой задержкой и высокой степенью параллелизма, а RPC может поддерживать различные протоколы передачи и режимы связи.
А если вам необходимо обеспечить кросс-платформенную и межъязыковую связь, или вам необходимо поддерживать несколько форматов данных и методов кодирования, или вам необходимо использовать существующую инфраструктуру и инструменты HTTP, вы можете выбрать протокол HTTP.
Конечно, это не абсолютно фиксированная комбинация. Два протокола также можно объединить для достижения лучшей сети, например:
(1) Мы можем инкапсулировать протокол RPC в протоколе HTTP, чтобы запросы RPC можно было пересылать и обрабатывать через прокси-сервер или шлюз HTTP.
(2) Протокол HTTP может использоваться в качестве транспортного уровня протокола RPC, чтобы запросы RPC могли использовать характеристики HTTP для реализации таких функций, как кэширование, сжатие и шифрование.
В общем, RPC появился для работы с сетевыми сценариями, в которых требования к производительности не могут быть удовлетворены протоколом HTTP. Они не являются взаимоисключающими, а могут выбираться и комбинироваться в соответствии с различными сценариями и потребностями.
Что такое протокол HTTP?
HTTP — это широко используемый протокол сетевой передачи. Он определяет формат и метод связи между клиентами (например, браузерами, мобильными пользовательскими приложениями и т. д.) и серверами (веб-сайтами и т. д., которые предоставляют услуги, серверами). Он основан на запросе. -response — это модель связи, в которой сервер возвращает ответ в соответствии с запросом. И запрос, и ответ содержат некоторую информацию о взаимодействии между двумя концами (клиентом и сервером), например методы, заголовки, текст и т. д.
HTTP имеет множество преимуществ. Он поддерживает множество форматов данных и методов кодирования, может осуществлять межплатформенную и межъязыковую связь, а связь проста, гибка и легко расширяется. Но в то же время у него есть и некоторые недостатки:
(1) HTTP не сохраняет состояние, и соединение необходимо повторно устанавливать для каждого запроса, что увеличивает нагрузку на сеть и задержку.
(2) Передача данных основана на тексте, что приводит к большому объему данных и низкой эффективности анализа.
(3) Он имеет низкую безопасность и поэтому уязвим для атак типа «человек посередине», атак повторного воспроизведения и т. д.
(4) Семантика слаба. HTTP может выражать только базовые операции добавления, удаления, изменения и запроса и не может удовлетворить сложную бизнес-логику.
Что такое протокол RPC?
RPC означает удаленный вызов процедур, который представляет собой протокол удаленного вызова процедур, который позволяет клиенту вызывать функции на удаленном сервере так же, как вызов локальных функций.
Преимущества RPC заключаются в том, что он эффективен, мощен и прост в использовании, но у него также есть некоторые недостатки, такие как:
(1) В отличие от HTTP, RPC сохраняет состояние и должен поддерживать состояние соединения между клиентом и сервером, что увеличивает сложность и потребление ресурсов системы.
(2) Передача данных RPC основана на двоичном формате, что затрудняет чтение и отладку данных.
(3) RPC имеет плохую совместимость, и между различными платформами RPC могут быть несоответствия протоколов и интерфейсов.
(4) RPC имеет плохую масштабируемость и с трудом поддерживает такие функции, как динамическое обнаружение сервисов и балансировка нагрузки.
Выбор обоих
HTTP и различные протоколы RPC, основанные на TCP, определяют только протоколы прикладного уровня с разными форматами сообщений. Протокол HTTP — это протокол передачи гипертекста, а сам RPC — это не конкретный протокол, а метод вызова.
Хотя HTTP теперь называется протоколом гипертекста и поддерживает аудио и видео, HTTP изначально был разработан для отображения текста веб-страницы, поэтому передаваемый им контент представляет собой в основном строки, и в контенте много избыточности. Протокол RPC более настраиваемый и может использовать меньший protobuf или другие протоколы сериализации для сохранения данных структуры. В то же время ему не нужно учитывать различные варианты поведения браузера, такие как HTTP, и его производительность выше. Поэтому во внутренних микросервисах компании отказались от HTTP и вместо этого используют протокол RPC. Хотя позже HTTP был значительно улучшен, поскольку многие компании использовали протокол RPC в течение многих лет, по историческим причинам они обычно не заменяют его HTTP.
В реальных приложениях, будь то HTTP или RPC, они имеют свои преимущества и недостатки, и не существует абсолютного добра или зла. Выберите подходящий протокол для различных сценариев использования. например:
(1) В микросервисной архитектуре между службами требуются частые внутренние вызовы, и RPC может обеспечить более высокую производительность и надежность.
(2) При распределенных вычислениях большое количество вычислительных задач необходимо распределить по разным узлам для выполнения. RPC может реализовать более гибкий механизм балансировки нагрузки и отказоустойчивости.
(3) При общении в реальном времени необходимо обеспечить обмен данными с низкой задержкой и высокой степенью параллелизма, а RPC может поддерживать различные протоколы передачи и режимы связи.
А если вам необходимо обеспечить кросс-платформенную и межъязыковую связь, или вам необходимо поддерживать несколько форматов данных и методов кодирования, или вам необходимо использовать существующую инфраструктуру и инструменты HTTP, вы можете выбрать протокол HTTP.
Конечно, это не абсолютно фиксированная комбинация. Два протокола также можно объединить для достижения лучшей сети, например:
(1) Мы можем инкапсулировать протокол RPC в протоколе HTTP, чтобы запросы RPC можно было пересылать и обрабатывать через прокси-сервер или шлюз HTTP.
(2) Протокол HTTP может использоваться в качестве транспортного уровня протокола RPC, чтобы запросы RPC могли использовать характеристики HTTP для реализации таких функций, как кэширование, сжатие и шифрование.
В общем, RPC появился для работы с сетевыми сценариями, в которых требования к производительности не могут быть удовлетворены протоколом HTTP. Они не являются взаимоисключающими, а могут выбираться и комбинироваться в соответствии с различными сценариями и потребностями.