В чем разница между gRPC и HTTP/1.1 Keep-Alive?

gRPC vs HTTP/1.1 Keep-Alive: Ключевые различия

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

HTTP/1.1 с Keep-Alive

Как это работает:

• HTTP/1.1 по умолчанию использует TCP соединение для каждого запроса
• Keep-Alive расширение позволяет переиспользовать одно TCP соединение для множества HTTP запросов-ответов
• Соединение остаётся открытым после ответа сервера (с таймаутом)
• Клиент может отправить следующий запрос без переустановления TCP соединения

Характеристики:

• REST API стиль (GET, POST, PUT, DELETE)
• Текстовый формат (JSON, XML)
• Синхронный request-response паттерн
• Легко отлаживаемо (видно в Developer Tools)
• Поддерживает кэширование (HTTP кеш-контроль)

Производительность:

• TCP 3-way handshake всё ещё нужен для первого соединения
• Latency: ~100ms+ на установку соединения (при Keep-Alive экономится на последующих запросах)
• Пропускная способность: средняя, текстовый формат требует больше памяти
• Примерный overhead: ~100-500 байт на HTTP заголовки

Примеры использования:

Клиент → [TCP Connect]
Клиент → [GET /api/users] → Сервер
Сервер → [200 OK с users] → Клиент
(Соединение остаётся открытым)
Клиент → [GET /api/posts] → Сервер
Сервер → [200 OK с posts] → Клиент
(Соединение закрывается после таймаута)

gRPC

Как это работает:

• построен на HTTP/2 (мультиплексирование)
• использует Protocol Buffers (протобуф) для сериализации: компактный бинарный формат
• поддерживает четыре типа вызовов:
  • Unary: один запрос, один ответ (как REST)
  • Server streaming: один запрос, поток ответов
  • Client streaming: поток запросов, один ответ
  • Bidirectional streaming: поток запросов и ответов одновременно

Характеристики:

• Использует HTTP/2 с постоянным соединением
• Бинарный протокол, а не текстовый (более компактный)
• Асинхронный и потоковый по природе
• Строгая типизация через .proto файлы
• Автоматическая генерация кода (client и server stubs)

Производительность:

• Одно постоянное TCP соединение для всех RPC вызовов (HTTP/2 multiplexing)
• Latency: ~10-50ms (в 3-10 раз меньше, чем HTTP/1.1)
• Пропускная способность: очень высокая, бинарный формат компактнее
• Overhead: ~5-50 байт на RPC вызов
• Отлично для микросервисной архитектуры

Пример использования:

service UserService {
  rpc GetUser(UserId) returns (User);
  rpc ListUsers(Empty) returns (stream User);
  rpc CreateUser(stream UserInput) returns (CreateResponse);
  rpc StreamBidirectional(stream Request) returns (stream Response);
}

Сравнительная таблица

Когда использовать HTTP/1.1 Keep-Alive

Плюсы:

• Простота: REST API, понятный стиль
• Совместимость: браузеры, любые HTTP-клиенты
• Отладка: Developer Tools, curl, Postman
• Кэширование: встроенное HTTP кэширование
• UI интеграция: fetch API в браузере

Минусы:

• Более высокий latency
• Больше traffic (текстовые заголовки)
• Нет встроенного streaming
• Polling для real-time (неэффективно)

Используй для:

• Публичные API (браузер-клиенты)
• Web приложения (SPA, Next.js)
• Прототипирование и MVP
• Простые CRUD операции
• Когда нужна быстрая разработка

Когда использовать gRPC

Плюсы:

• Очень низкий latency (10-50ms)
• Высокая пропускная способность
• Встроенное streaming (server/client/bidirectional)
• Типобезопасность через .proto контракты
• Автоматическая генерация кода
• Отлично для микросервисов
• Поддержка load balancing и health checks

Минусы:

• Более сложная кривая обучения
• Не поддерживается старыми браузерами
• Требует grpc-web для браузера
• Сложнее отлаживать
• Нет встроенного кэширования

Используй для:

• Микросервисная архитектура
• Real-time коммуникация (чаты, игры)
• Streaming данных (логи, метрики)
• Высокопроизводительные системы
• Service-to-service коммуникация
• IoT и embedded системы

Практические примеры

HTTP/1.1 Keep-Alive:

curl -v https://api.example.com/users
# Соединение: 1 TCP handshake, 1 запрос-ответ, соединение остаётся открытым

gRPC:

conn, _ := grpc.Dial("localhost:50051")
client := pb.NewUserServiceClient(conn)
user, _ := client.GetUser(ctx, &UserId{Id: 123})
// Все вызовы идут по одному TCP соединению

Гибридный подход

В крупных системах часто используют оба:

• gRPC для внутренней коммуникации микросервисов
• HTTP/1.1 (REST) для публичных API и браузер-клиентов
• gRPC-Web для браузеров (если нужна real-time)

Выбор между ними — это trade-off между простотой и производительностью. gRPC быстрее и эффективнее, но HTTP проще и более универсален.