🤖 📡 Базовые протоколы клиент-серверного взаимодействия (без обратной связи)

Хочется сделать серию постов по основам CS и system-design.
Если будет отклик, масштабируем в mind-map.
И начать хочется с сетевого взаимодействия.

Когда мы говорим про клиент-серверные запросы в большинстве приложений, мы почти всегда имеем в виду модель request → response.
Важно сразу зафиксировать: это не всегда про HTTP, хотя на практике часто выглядит именно так.

В первом посте разберём основные стили взаимодействия, которые используются для однонаправленных запросов с ответом.

📌 Немного про транспорт:
- SOAP — почти всегда поверх HTTP/HTTPS
- REST — по определению строится поверх HTTP
- GraphQL — чаще всего поверх HTTP, подписки через WebSocket (но об этом можно глубже, в другом посте)
- RPC — не обязан использовать HTTP

👉 Поэтому корректнее говорить не «HTTP-протоколы», а API-стили / протоколы поверх разных транспортов.

Небольшая затравка из практики:

В бородатых годах я использовал Apache Thrift на Objective-C
— тогда для меня это был "магический" опыт с RPC:
отличный кодген, строгие контракты, минимум ручной работы.

Это был классический пример RPC-подхода, задолго до хайпа gRPC, и он отлично показывал разницу между:
- «я работаю с ресурсами» (REST)
- и «я вызываю удалённые методы» (RPC)

Детальнее про протоколы:
🔹 SOAP (Simple Object Access Protocol)
Что это: Строгий протокол обмена сообщениями, основанный на XML и формальных контрактах (WSDL).
Транспорт: почти всегда HTTP
Когда применять:
- корпоративные и интеграционные системы
- среды с жёсткими требованиями к контрактам, безопасности и совместимости
Почему:
SOAP — это максимум формализма: строгая схема, строгие правила, минимум свободы.
Цена — высокая сложность и избыточность.
📍 SOAP — это «корпоративный стандарт», а не инструмент скорости.

🔹 REST (Representational State Transfer)
Что это: Архитектурный стиль, завязанный на HTTP, где всё крутится вокруг ресурсов и их состояний.
Транспорт: HTTP.
Когда применять:
- CRUD-сценарии
- публичные API
- системы, где важны кэширование, простота и масштабируемость
Почему: REST максимально использует возможности HTTP: методы, статусы, cache-control.
Он прост, прозрачен и отлично поддерживается инструментами.
📍 REST — дефолтный выбор, если нет веской причины делать иначе.

🔹 GraphQL
Что это: Язык запросов и runtime, где клиент сам описывает, какие данные ему нужны.
Транспорт:
- чаще всего HTTP
- иногда WebSocket (но это уже про real-time)
Когда применять:
- сложные графы данных
- разные клиенты с разными требованиями к payload
- желание сократить количество запросов
Почему: GraphQL снимает проблему overfetching/underfetching, но усложняет сервер и наблюдаемость.
📍 GraphQL — про гибкость клиента, а не про простоту системы.

🔹 RPC (gRPC, Thrift, JSON-RPC)
Что это: Удалённый вызов процедур: клиент вызывает метод, сервер его исполняет.
Транспорт: не привязан к HTTP
- gRPC — HTTP
- Thrift — TCP / HTTP / custom transport
Когда применять:
- межсервисное взаимодействие
- высокая производительность
- чёткие контракты и кодогенерация
Почему: RPC ближе к обычному программированию: вызвал метод — получил результат. Это эффективно, но хуже ложится на публичные API и браузный мир.
📍 RPC — лучший выбор для внутренних систем и платформенных API.

#L #Network #HTTP #TCP #REST #SOAP #GraphQL #RPC

👏

☝️ В прошлом посте мы говорили про клиент-серверное взаимодействие: API, REST, запрос-ответ.

Но прежде чем идти дальше (обсуждать двунаправленность), хочется сделать шаг вниз по стеку.
Потому что REST и прочее - это архитектурные стили.
А под ними живут транспорты и сетевые протоколы. Давайте разбираться.

С чего всё началось — TCP и UDP (транспортный уровень):
Когда два компьютера обмениваются данными, они делают это через транспортный протокол.

1️⃣ TCP — «передать всё и правильно»
TCP появился в 70-х. Его цель — гарантировать доставку данных.
- следит за порядком пакетов
- подтверждает получение
- переотправляет потерянные
- регулирует перегрузку сети

Это надёжно. Но за надёжность приходится платить задержками. Передача фрагметов данных - сложный процесс и достоин отдельного поста, на тему. Но, базово, из-за передачи пакетов и их согласования может возникать проблема - head-of-line blocking (если один сегмент потерялся — остальные ждут).

2️⃣ UDP — «передать быстро»
UDP появился примерно тогда же, но философия у него другая. Он просто отправляет пакет.
Без гарантий:
- дошёл ли
- в каком порядке
Зато:
- минимум задержек
- минимум оверхеда
Поэтому UDP любят там, где важнее скорость, чем идеальная надёжность: игры, голос, видео.

3️⃣ Дальше появился HTTP (прикладной уровень)
Когда понадобился стандарт для веба, поверх TCP построили HTTP. GET, POST и т.д. запросы с примитивами вроде header, body и т.д.

👨‍🦳 HTTP/1.1: запрос → ответ.
- каждый запрос зависел от предыдущего
- соединения открывались и закрывались
- производительность была далека от идеала (в т.ч. из-за текстового формата передачи данных)
Но для 90-х этого было достаточно.

👷‍♂️ HTTP/2 — попытка ускорить веб. Спустя почти 20 лет стало ясно, что HTTP/1 не справляется.
- стал бинарным
- добавил мультиплексирование (чтобы решать head-of-line blocking на уровне HTTP)
- позволил нескольким запросам идти параллельно в одном соединении
Это серьёзно ускорило загрузку страниц. Но есть нюанс. HTTP/2 всё ещё работает поверх TCP. А это значит, что на транспортном уровне все еще: если один пакет потерялся — потоки блокируются внутри соединения.

🤖 HTTP/3 отказался от TCP.
Он работает поверх QUIC. QUIC — новая философия транспорта, построеная поверх UDP. Но он добавляет то, чего UDP не умеет сам:
- надёжность
- управление потоками
- шифрование
- мультиплексирование
И делает это без проблем TCP.

Ключевые отличия:
- Нет head-of-line blocking между потоками
- Быстрый handshake (0-RTT)
- Встроенный TLS 1.3
- Лучше переносит смену сети (например, Wi-Fi → LTE)

То есть QUIC — это фактически современный транспорт, который:
- взял скорость UDP
- добавил надёжность
- встроил безопасность

А HTTP/3 — это просто HTTP-семантика поверх QUIC.

#L #HTTP #TCP #UPD #TLS

👏