# Протоколы — это то, как программы разговаривают

Экспресс-курс по протоколам обмена данными. 21 понятие — TCP, UDP, HTTP, TLS, HTTP/2 и HTTP/3, REST, GraphQL, gRPC, SOAP, Polling, SSE, WebSocket, Webhook, Message Broker, очереди (AMQP), Kafka, MQTT, JSON, Protobuf, XML — у каждого английское название, схема, карточка «что это → как работает → пример → цена» и связи с другими. В конце — шпаргалка на одной странице.

- **Author:** Фёдор Чищин
- **Level:** intro
- **Reading time:** ~30 минут чтения
- **Published:** 2026-06-02
- **Source:** https://fedorthinks.com/ru/learn/data-protocols-express

---

## 1. Что такое протокол

Протокол — это согласованный набор правил, по которым две программы разговаривают: как выглядит сообщение и кто что может сказать и когда. Правильные правила — и совершенно разные системы понимают друг друга.

### Protocol — язык плюс этикет

> Два дипломата без общего родного языка всё равно договариваются — потому что заранее условились об одном языке и о порядке, кто говорит. Сломай любое — и это просто шум.

**Протокол (protocol)** фиксирует две вещи: **формат (format)** сообщения — чтобы каждая сторона его прочитала, и **хореографию** — кто говорит первым, когда приходит ответ, как всё заканчивается. HTTP, gRPC, WebSocket — это всего лишь разные договорённости об этих двух вещах. Работа одна, манеры разные.

#### Protocol (протокол)

- **Что это:** Договор двух программ: форма сообщения + порядок разговора.
- **Пример:** HTTP: клиент шлёт `GET /users/42`, сервер отвечает `200 OK` и JSON. Никто не говорит вне очереди.
- **Подвох:** Если стороны понимают договор по-разному — получается шум, а не ошибка.
- **Связи:** Все остальные понятия курса — это конкретные протоколы и форматы.

### Protocol stack — протоколы устроены слоями

> Письмо: почта везёт конверт и не интересуется, что внутри; язык на странице — это между тобой и читателем. Две отдельные договорённости, сложенные стопкой.

Снизу лежит **транспортный протокол (transport)** — TCP или UDP, он просто переносит байты между машинами. Сверху — **прикладной протокол (application)** — HTTP, gRPC, MQTT, он придаёт этим байтам смысл. Между ними часто стоит **TLS**, который запечатывает конверт. Обычно ты работаешь наверху — но когда становится медленно или нестабильно, нижний слой даёт о себе знать.

_Diagram: Стек протоколов: снизу байты, сверху смысл. Каждый слой полагается на слой под ним._

#### Protocol stack (стек протоколов, слои)

- **Что это:** Протоколы лежат друг на друге: транспорт везёт байты, прикладной слой придаёт им смысл.
- **Пример:** HTTP едет поверх TLS, TLS — поверх TCP, TCP — поверх IP.
- **Подвох:** Тормоза и обрывы часто родом снизу — их не починить, глядя только на HTTP.
- **Связи:** **TCP / UDP** — низ, **HTTP, gRPC, MQTT** — верх, **TLS** — посередине.

### Каждый протокол отвечает на три вопроса

> Разговору нужно уладить три вещи: кто начинает, на каком языке и говорите ли вы по очереди или оба сразу.

**Кто инициирует** — клиент спрашивает или сервер может пушить? **Какую форму принимают данные** — текстовый JSON, компактный бинарь, непрерывный поток? **Тайминг** — один выстрел или долго живущая линия, где говорить может любая сторона? Почти любое различие между протоколами — это разный ответ на эти три вопроса.

### Карта: 21 понятие в пяти группах

> Карта метро: сначала видишь линии целиком, потом едешь по станциям.

Все понятия курса делятся на пять групп: **фундамент** (на чём всё едет), **запрос-ответ** (спросил — получил), **реальное время** (сервер говорит первым), **сообщения** (между сторонами стоит посредник) и **форматы** (в каком виде лежат данные внутри).

_Diagram: Пять групп понятий — по ним идут главы 2–6._

### Как читать каждое понятие

> Паспорт: одинаковые поля у всех, поэтому их легко сравнивать.

У каждого протокола дальше одно и то же: **английское название** (это термин, по нему ищут документацию), образ из жизни, **схема** и **карточка** с полями: _что это_, _как работает_, _пример_, _цена_ (что ты платишь), _когда брать_ и _связи_. Главное правило: **лучшего протокола нет — есть подходящий.** Ты не пошлёшь приглашение на свадьбу по рации и не будешь координировать спасательную операцию почтой.

> **Прежде чем выбирать протокол:** «Кому нужно говорить, как часто и как быстро — и кто на другом конце?»

> Протокол — это договор. Выбирай его по форме разговора, а не по тому, что сейчас в моде.

## 2. Фундамент

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

### TCP — надёжная линия с гарантией доставки

> Телефонный звонок, где собеседник после каждой фразы говорит «принял» — медленнее, зато ничего не теряется и не путается.

**TCP (Transmission Control Protocol)** сначала устанавливает соединение — это **рукопожатие (handshake)**. Потом он гарантирует, что каждый байт дойдёт и по порядку: получатель подтверждает приём, а потерянное отправляется заново. Это рабочая лошадка под вебом, почтой и большинством API.

_Diagram: TCP: рукопожатие SYN → SYN-ACK → ACK, потом данные с подтверждениями. Потерялось — отправим ещё раз._

#### TCP (Transmission Control Protocol)

- **Что это:** Транспорт с гарантией: всё дойдёт, по порядку, без потерь.
- **Как работает:** Рукопожатие, подтверждения (ACK), повтор потерянного.
- **Пример:** Под HTTP/1.1 и HTTP/2, почтой, базами данных, большинством API.
- **Цена:** Немного задержки на установку и ожидание повторов. **Обычно отличная сделка.**
- **Когда брать:** Когда важен каждый байт — почти всегда.
- **Связи:** Противоположность — **UDP**. Сверху едут **HTTP**, **TLS**, брокеры.

### UDP — отправил и забыл, быстро и с потерями

> Крик через шумную комнату — быстро, но если слово не расслышали, ты не останавливаешься его повторить, а идёшь дальше.

**UDP (User Datagram Protocol)** шлёт пакеты без рукопожатия и без гарантии доставки и порядка. Звучит плохо — пока тебе не нужна скорость важнее точности: **видеозвонки, живые игры, DNS-запросы**. Там потерянный кадр лучше заминки в ожидании повтора.

_Diagram: UDP: пакет №3 потерялся — и никто его не перешлёт. Зато ничего не ждёт._

#### UDP (User Datagram Protocol)

- **Что это:** Транспорт без гарантий: отправил и забыл.
- **Как работает:** Нет соединения, нет подтверждений, нет повторов, нет порядка.
- **Пример:** Видеозвонок: старый кадр уже не нужен — лучше показать следующий.
- **Цена:** Потери и путаницу порядка решаешь сам (или терпишь).
- **Когда брать:** Когда свежесть важнее полноты: голос, видео, игры, DNS.
- **Связи:** На нём построен **QUIC**, а на QUIC — **HTTP/3**.

### HTTP — язык запрос-ответ всего веба

> Прилавок в магазине: ты просишь одну вещь, получаешь один ответ, и продавец забывает о тебе, как только ты отходишь.

**HTTP (HyperText Transfer Protocol)** едет поверх TCP и задаёт привычный запрос/ответ: **глаголы (methods)** `GET`, `POST`, `PUT`, `DELETE` и **коды статуса (status codes)** `200`, `404`, `500`. Он **без состояния (stateless)** — каждый запрос сам по себе, — и именно это позволяет вебу масштабироваться до миллиардов вызовов.

_Diagram: HTTP: один запрос — один ответ. Глагол говорит, что сделать; код статуса — чем кончилось._

#### HTTP (HyperText Transfer Protocol)

- **Что это:** Прикладной протокол «спросил — получил ответ».
- **Как работает:** Запрос = глагол + адрес + заголовки + тело. Ответ = код статуса + заголовки + тело.
- **Пример:** `GET /users/42` → `200 OK` и JSON с пользователем.
- **Цена:** Сервер не может заговорить первым — только отвечать.
- **Когда брать:** Почти любой API говорит на нём.
- **Связи:** Основа для **REST**, **GraphQL**, **SSE**, **Webhook**; **WebSocket** стартует с него.

### TLS и HTTPS — то же самое, но запечатанное

> То же письмо, но теперь в защищённом от вскрытия конверте с проверенной подписью отправителя снаружи.

**TLS (Transport Layer Security)** оборачивает HTTP (и другие протоколы) в **шифрование (encryption)** и **идентичность (identity)**: никто посередине не прочитает и не подделает трафик, а **сертификат (certificate)** доказывает, что сервер — тот, за кого себя выдаёт. Это та самая «S» в **HTTPS**. И это больше не опция: браузеры, сторы и API его подразумевают.

_Diagram: HTTPS = HTTP внутри TLS. Злоумышленник в той же Wi-Fi видит только шифрованные байты._

#### TLS / HTTPS (Transport Layer Security)

- **Что это:** Слой шифрования и проверки личности поверх транспорта.
- **Как работает:** Сертификат подтверждает сервер; дальше весь трафик зашифрован.
- **Пример:** Замок в адресной строке браузера — это TLS.
- **Цена:** Сертификаты надо выпускать и продлевать (сегодня это почти бесплатно).
- **Когда брать:** **Если данные покидают твою машину, они должны быть внутри TLS.**
- **Связи:** Оборачивает **HTTP**, **gRPC**, **WebSocket**, брокеры.

### HTTP/2 и HTTP/3 — та же труба, только шире

> Однополосная дорога, ставшая многополосной трассой, — а потом перестроенная так, что одна заглохшая машина больше не блокирует все полосы.

**HTTP/1.1** обрабатывал по одному запросу за раз на соединение. **HTTP/2** гоняет много запросов по одному соединению — это **мультиплексирование (multiplexing)**. Но под ним TCP, и один потерянный пакет тормозит все потоки — это **head-of-line blocking**. **HTTP/3** переезжает на **QUIC** (поверх UDP): потеря тормозит только свой поток, соединение открывается примерно за один круг, а телефон может переключиться с Wi-Fi на сотовую сеть без обрыва.

_Diagram: HTTP/1.1 — по одному. HTTP/2 — параллельно, но одна потеря стопорит всех. HTTP/3 — потеря задевает только свой поток._

#### HTTP/2 · HTTP/3 (multiplexing, QUIC)

- **Что это:** Новые версии HTTP: те же запросы, более быстрая дорога под ними.
- **Как работает:** HTTP/2 — много потоков в одном TCP. HTTP/3 — независимые потоки на QUIC поверх UDP.
- **Пример:** Страница с сотней картинок грузит их параллельно по одному соединению.
- **Цена:** Почти никакой для тебя — включается на сервере или CDN.
- **Когда брать:** По умолчанию, где поддерживается. Код приложения не меняется.
- **Связи:** **gRPC** работает поверх HTTP/2; HTTP/3 — поверх **UDP**.

> **Вопрос про фундамент:** «Мне нужна гарантия каждого байта (TCP) — или скорость, где редкая потеря не страшна (UDP)?»

> Ты строишь наверху стека, но низ решает, что возможно. И шифрование — это не слой, который прикручивают потом.

## 3. Запрос и ответ

Бóльшая часть общения «приложение — сервер» и «сервис — сервис» — это «задай вопрос, получи ответ». Доминируют три стиля, и каждый по-своему меняет простоту на мощь. Плюс один старейшина, которого ещё придётся встретить.

### REST — ресурсы через обычные глаголы HTTP

> Хорошо организованная библиотека, где у каждой книги фиксированный адрес, и везде ты используешь одни и те же четыре действия: посмотреть, добавить, изменить, убрать.

**REST (Representational State Transfer)** моделирует всё как **ресурсы (resources)** по адресам вроде `/users/42`, над которыми действуют глаголами HTTP, обычно возвращая JSON. Просто, кэшируемо, отлаживается в браузере и понятно везде — **дефолт для публичных API.**

_Diagram: REST: один ресурс — один адрес, четыре глагола на всё. Слабое место — много вызовов на один экран._

#### REST (Representational State Transfer)

- **Что это:** Стиль API: ресурсы по URL + глаголы HTTP + обычно JSON.
- **Пример:** `GET /users/42` — прочитать, `DELETE /users/42` — удалить.
- **Цена:** Часто получаешь больше данных, чем нужно (**over-fetching**), или делаешь несколько вызовов, чтобы собрать один экран (**under-fetching**).
- **Когда брать:** Публичный API для многих клиентов. Почти всегда — старт.
- **Связи:** Едет на **HTTP**, говорит **JSON**. Слабые места закрывает **GraphQL**.

### GraphQL — запрашивай ровно те поля, что нужны

> Шведский стол, где вместо фиксированных комплексных меню ты подаёшь кухне точный список и получаешь ровно это — не больше и не меньше.

**GraphQL** даёт одну точку входа, где **клиент пишет запрос (query)** ровно на те поля, что ему нужны, за один круг — без лишних и недостающих данных, как бывает в REST. Блестяще, когда множество разных клиентов (веб, мобильные, партнёры) нуждаются в разных срезах сложного графа данных.

_Diagram: GraphQL: клиент перечисляет поля, один эндпоинт собирает их из разных источников и возвращает ровно это._

#### GraphQL (язык запросов к API)

- **Что это:** Один эндпоинт, клиент сам описывает форму ответа.
- **Пример:** Мобильному экрану нужны имя и суммы заказов — он просит только их.
- **Цена:** Кэшировать сложнее, а гибкость перекладывает реальную сложность на твой сервер.
- **Когда брать:** Много разных клиентов и сложный, связанный граф данных.
- **Связи:** Ответ на слабости **REST**; обычно едет на **HTTP** с **JSON**.

### gRPC — вызови удалённую функцию как локальную

> Интерком между двумя комнатами одного здания — кратко, быстро и приватно, потому что обе стороны уже знают один и тот же сокращённый язык.

**gRPC** — это **RPC (Remote Procedure Call)**, удалённый вызов функции. Он использует **Protocol Buffers** (компактный бинарь) поверх HTTP/2, чтобы один сервис вызывал методы другого напрямую, по **типизированному контракту (contract)** и со встроенным стримингом. Быстро и строго — **идеально для внутреннего трафика «сервис — сервис».**

_Diagram: gRPC: общий .proto-контракт, из него генерируется код. Сервис A зовёт метод B, будто он локальный._

#### gRPC (Remote Procedure Call от Google)

- **Что это:** Вызов функции другого сервиса по сети, по строгому контракту.
- **Пример:** Сервис заказов зовёт `inventory.Reserve(item, 2)` у сервиса склада.
- **Цена:** Из браузера напрямую не работает; бинарь глазами не прочитать — отлаживаешь инструментами.
- **Когда брать:** Свои сервисы говорят между собой много и быстро.
- **Связи:** Едет на **HTTP/2**, говорит **Protobuf**.

### SOAP — старейшина

> Формальный договор в трёх экземплярах, с печатями и нотариусом — тяжело, зато однозначно.

До REST **SOAP (Simple Object Access Protocol)** заворачивал вызовы в строгие XML-**конверты (envelope)** с формальным контрактом **WSDL**. Он многословен и старомоден, но его строгость до сих пор работает в банках, платежах и корпоративных интеграциях.

_Diagram: SOAP: каждый вызов — XML-конверт с заголовком и телом, а WSDL описывает, что можно вызывать._

#### SOAP (Simple Object Access Protocol)

- **Что это:** Строгий протокол вызовов на XML с формальным контрактом.
- **Пример:** Банковская интеграция: `GetBalance` в `soap:Envelope`.
- **Цена:** Многословно, тяжело, мало современных инструментов.
- **Когда брать:** Новый ты вряд ли построишь — но вполне можешь столкнуться с необходимостью с ним говорить.
- **Связи:** Говорит **XML**; его место в новых системах заняли **REST** и **gRPC**.

> **Вопрос про API:** «Это публичный API, которым пользуется много клиентов (REST), голодный клиент, выбирающий поля (GraphQL), или два моих сервиса, говорящих быстро (gRPC)?»

> REST — чтобы тебя понял каждый. GraphQL — чтобы клиент выбирал. gRPC — чтобы быстро между своими сервисами.

## 4. Реальное время и push

У обычного запрос-ответа есть пробел: сервер не может заговорить первым. Когда клиенту нужно узнавать о событиях по мере их наступления, тянешься за одним из этих.

### Polling — всё спрашивать «есть что-нибудь новое?»

> Ребёнок в дороге, спрашивающий «мы уже приехали?» каждые две минуты. Просто — и в основном впустую.

**Polling (опрос)** — самый грубый вариант: клиент перезапрашивает по таймеру. **Long-polling (длинный опрос)** улучшает его: сервер держит каждый запрос открытым, пока реально не появится что сказать, после чего клиент тут же спрашивает снова. Работает везде и не требует особого протокола.

_Diagram: Сверху polling: три пустых «нет» ради одного «да». Снизу long-polling: сервер молчит, пока не будет новостей._

#### Polling / Long-polling (опрос)

- **Что это:** Клиент сам раз за разом спрашивает сервер о новостях.
- **Пример:** Страница статуса заказа спрашивает сервер каждые 10 секунд.
- **Цена:** Расточительно и с задержкой по сравнению с настоящим потоком.
- **Когда брать:** **Нормальный запасной вариант, плохой дефолт.**
- **Связи:** Настоящие замены — **SSE** и **WebSocket**.

### SSE — односторонний поток от сервера

> Радиовещание — станция льёт тебе поток непрерывно; ты просто слушаешь, на том же канале в ответ не говоришь.

**SSE (Server-Sent Events)** держит один HTTP-ответ открытым и даёт **серверу пушить поток обновлений клиенту**, с автоматическим переподключением и почти без накладных. Идеально для односторонних лент: живые счета матчей, уведомления, тикающий дашборд — и именно так **LLM стримит токены** в чат-интерфейс.

_Diagram: SSE: сервер шлёт события по одному открытому HTTP-ответу. Ответить по той же линии клиент не может._

#### SSE (Server-Sent Events)

- **Что это:** Односторонний поток событий от сервера к браузеру по обычному HTTP.
- **Пример:** Ответ чат-бота появляется по словам, пока модель его пишет.
- **Цена:** Только в одну сторону; ответы клиента идут отдельными запросами.
- **Когда брать:** Если клиенту не нужно отвечать по той же линии, **SSE — самый простой инструмент реального времени**.
- **Связи:** Едет на **HTTP**; двусторонний брат — **WebSocket**.

### WebSocket — двусторонняя линия, открытая в обе стороны

> Открытая телефонная линия, оставленная снятой с рычага, — любая сторона может заговорить в тот же миг, как появилось что сказать, без перенабора.

**WebSocket** повышает HTTP-соединение (**upgrade**) до **постоянного полнодуплексного (full-duplex) канала**, где клиент и сервер шлют сообщения свободно, с минимальной задержкой и крошечными накладными на сообщение. Правильный инструмент, когда обе стороны говорят постоянно: **чаты, мультиплеер, совместное редактирование, живая торговля.**

_Diagram: WebSocket: HTTP-запрос с Upgrade, ответ 101 — и дальше обе стороны пишут когда хотят._

#### WebSocket (полнодуплексный канал)

- **Что это:** Постоянный канал, где говорить могут обе стороны в любой момент.
- **Пример:** Чат: «печатает…», новые сообщения и курсоры коллег летят в обе стороны.
- **Цена:** Сложнее эксплуатировать, чем SSE: долгие соединения, переподключения, балансировка.
- **Когда брать:** Когда тебе **правда** нужна двусторонность.
- **Связи:** Стартует с **HTTP**; односторонняя альтернатива — **SSE**.

### Webhook — не звоните нам, мы позвоним вам

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

**Webhook** переворачивает направление: **ты регистрируешь URL, а другой сервис делает на него HTTP-запрос, когда происходит событие.** Это стандартный способ сервисам уведомлять друг друга без того, чтобы кто-то сидел в цикле опроса.

_Diagram: Webhook: один раз отдал свой URL — дальше Stripe сам делает POST, когда платёж прошёл._

#### Webhook (обратный вызов по HTTP)

- **Что это:** Сервис сам шлёт тебе HTTP-запрос, когда у него что-то случилось.
- **Пример:** Stripe делает `POST` на твой эндпоинт в момент успешного платежа; GitHub пингует твой сервер на каждый пуш.
- **Цена:** Твой эндпоинт должен быть доступен извне и уметь переживать повторы и сбои.
- **Когда брать:** Один сервис сообщает другому: «событие произошло».
- **Связи:** Это обычный **HTTP**, только в обратную сторону; заменяет **Polling**.

> **Вопрос про реальное время:** «Серверу нужно только пушить клиенту (SSE), говорят обе стороны (WebSocket) или это один сервис уведомляет другой (webhook)?»

> Если сервер должен заговорить первым — перестань опрашивать. В одну сторону стримь через SSE, в обе — через WebSocket.

## 5. Сообщения и асинхронность

Иногда A вообще не должен звать B напрямую. Поставь между ними брокер — и отправитель сможет отправить и забыть, пока получатель работает в своём темпе.

### Message broker — посредник, который держит сообщения

> Почта между отправителем и получателем — ты бросаешь письмо и уходишь; они забирают его, когда готовы. Никому не нужно быть на месте в один и тот же момент.

Вместо прямого вызова **отправитель (producer)** передаёт сообщение **брокеру (message broker)**, который доставляет его одному или нескольким **получателям (consumers)**. Это развязывает их **во времени** (получатель может тормозить или ненадолго лежать) и **в знании** (отправителю не нужно знать, кто слушает). Это становой хребет устойчивых, рваных, **асинхронных (async)** систем.

_Diagram: Брокер посередине: отправитель отдал и ушёл, получатели забирают в своём темпе._

#### Message broker (брокер сообщений)

- **Что это:** Посредник, который принимает, хранит и раздаёт сообщения.
- **Пример:** Веб-сервер кладёт «заказ создан», а склад и почта забирают сами.
- **Цена:** Ещё одна система в эксплуатации; ответа «сразу» больше нет.
- **Когда брать:** Медленная работа, пики нагрузки, много получателей.
- **Связи:** Его формы — **очередь (AMQP)**, **лог (Kafka)**, **pub/sub (MQTT)**.

### Message queue (AMQP / RabbitMQ) — одна задача, один воркер

> Наплыв заказов в забегаловке — чеки копятся на рейке, и свободный повар хватает следующий.

**Очередь сообщений (message queue)** держит задачи, пока **воркер (worker)** не возьмёт одну, обработает и **подтвердит (ack)**. Протоколы вроде **AMQP** (его говорит **RabbitMQ**) добавляют умную маршрутизацию, повторы и гарантии доставки.

_Diagram: Очередь: веб-приложение сразу отвечает пользователю, а свободный воркер берёт следующую задачу._

#### Message queue (AMQP, RabbitMQ)

- **Что это:** Задачи ждут в очереди; каждую берёт ровно один воркер.
- **Пример:** Бросить «отправить приветственное письмо» или «сгенерировать счёт» в очередь, чтобы веб-запрос вернулся мгновенно, а воркер занялся медленной частью.
- **Цена:** Сделанная задача исчезает — перечитать историю нельзя.
- **Когда брать:** Фоновые задачи, которые не должны тормозить пользователя.
- **Связи:** Форма **брокера**; если читателей много и нужна история — **Kafka**.

### Kafka — долговечный лог, который многие могут переиграть

> Газетный архив — каждый выпуск хранится по порядку, и любое число читателей может начать откуда угодно и читать вперёд в своём темпе.

**Kafka** — это не столько очередь, сколько **долговечный упорядоченный лог событий (log)**, который многие потребители читают независимо и который остаётся после прочтения. Каждый читатель помнит свою позицию — **offset**. Построен под огромную пропускную способность.

_Diagram: Kafka: события дописываются в конец лога, а каждый потребитель читает со своей позиции._

#### Kafka (лог событий, event streaming)

- **Что это:** Журнал событий, который хранится и читается многими независимо.
- **Пример:** Один поток «заказ размещён» кормит аналитику, индексацию поиска и письма сразу.
- **Цена:** Тяжёлая система; для пары сотен сообщений в день — перебор.
- **Когда брать:** Огромные объёмы событий и много читателей, которым нужна история.
- **Связи:** **Очередь: сообщение исчезает, как обработано. Kafka: история остаётся.**

### MQTT — крошечный pub/sub для ненадёжных сетей

> Канал рации для парка курьерских фургонов — короткие очереди слов, мало энергии, нормально, если один ненадолго въедет в тоннель.

**MQTT** — ультралёгкий протокол **публикация/подписка (publish/subscribe, pub/sub)**, созданный для **IoT**: устройства публикуют сообщения в **топики (topics)**, а брокер раздаёт их подписчикам. Крошечные сообщения, минимум батареи и трафика, терпимость к нестабильным каналам.

_Diagram: MQTT: датчики публикуют в топики, брокер раздаёт всем, кто подписан._

#### MQTT (pub/sub для IoT)

- **Что это:** Лёгкий pub/sub-протокол для слабых устройств и слабых сетей.
- **Пример:** Тысячи датчиков, устройств умного дома или машин шлют телеметрию по сотовой сети.
- **Цена:** Нужен брокер; для обычного веба — не тот инструмент.
- **Когда брать:** Когда «клиент» — дешёвый чип на слабой сети, **MQTT влезает туда, где HTTP не справится**.
- **Связи:** Форма **брокера**; транспорт — **TCP**.

> **Вопрос про сообщения:** «Может ли получатель поработать позже, в своём темпе, — и нужен событию один обработчик (очередь) или много читателей со временем (лог)?»

> Не заставляй вызывающего ждать медленной работы. Передай её брокеру и иди дальше.

## 6. Данные на проводе

Протокол — это конверт; нагрузке внутри всё равно нужна форма, о которой обе стороны договорились. Этот выбор — тихий размен между читаемостью и скоростью.

### JSON — читаемый, универсальный, по умолчанию

> Рукописная записка, которую любой прочитает с ходу, — чуть длинновата, но декодер не нужен.

**JSON (JavaScript Object Notation)** — это текст, читаемый человеком и поддерживаемый везде, — тело по умолчанию для веба и REST API. Его можно глянуть в браузере и отлаживать чтением. Ниже — одна и та же запись в трёх форматах: разница в размере видна сразу.

_Diagram: Одна запись {id: 42, name: Ann}: JSON — 22 байта, XML — 40, Protobuf — 7._

#### JSON (JavaScript Object Notation)

- **Что это:** Текстовый формат «ключ — значение», понятный человеку и любой машине.
- **Пример:** `{"id": 42, "name": "Ann"}`
- **Цена:** **Многословный и не самый быстрый** в разборе — обычно нормально, иногда узкое место на масштабе.
- **Когда брать:** По умолчанию для веба и публичных API.
- **Связи:** Язык **REST** и **GraphQL**; бинарная альтернатива — **Protobuf**.

### Protocol Buffers и компания — маленькие, быстрые, бинарные

> Штрихкод — тебе нечитаем, но сканируется мгновенно и упакован плотно. Чтобы раскодировать, нужна схема.

Бинарные форматы вроде **Protocol Buffers (Protobuf)** — его использует gRPC, — плюс **MessagePack** и **Avro**, **сериализуют (serialize)** данные по общей **схеме (schema)** в компактную быструю нагрузку. Выигрыш — размер и скорость; цена в том, что **глазами это не прочитать**, и обе стороны должны делить схему.

_Diagram: Protobuf: схема говорит, что поле 1 — это id, а поле 2 — name. Без неё 7 байт — просто цифры._

#### Protobuf (Protocol Buffers, MessagePack, Avro)

- **Что это:** Компактный бинарный формат по заранее описанной схеме.
- **Пример:** `message User { int32 id = 1; string name = 2; }` → 7 байт на проводе.
- **Цена:** Не прочитать глазами; схему надо держать общей у обеих сторон.
- **Когда брать:** Высокообъёмный, внутренний, критичный к скорости трафик.
- **Связи:** Язык **gRPC**; читаемая альтернатива — **JSON**.

### XML — многословный, формальный, всё ещё рядом

> Юридический документ — тяжёлый от тегов и структуры, точный, и ничей не первый выбор для быстрой записки.

**XML (eXtensible Markup Language)** старше JSON и несёт богатую **схему и валидацию (schema, validation)** ценой громоздкости — каждое значение в открывающем и закрывающем теге. Ты встретишь его в SOAP-сервисах, форматах документов и конфигурации.

#### XML (eXtensible Markup Language)

- **Что это:** Текстовый формат на тегах со строгой схемой.
- **Пример:** ` <user> <id>42</id> <name>Ann</name> </user> `
- **Цена:** Громоздкий: та же запись почти вдвое длиннее JSON.
- **Когда брать:** Редко для нового — но **он до сих пор несущий во множестве старых систем**.
- **Связи:** Язык **SOAP**; сменщик в вебе — **JSON**.

> **Вопрос про формат:** «Мне ценнее читать и отлаживать это глазами (текст) — или чистый размер и скорость (бинарь)?»

> Текст — чтобы понимали, бинарь — чтобы было быстро. Большинство API правы, что по умолчанию выбирают читаемое.

## 7. Как выбирать

Ты не выбираешь один протокол на всю систему — ты выбираешь правильный для каждого разговора. Реальные приложения крутят несколько сразу.

### Подбирай протокол под разговор

> Ящик с инструментами: молоток, отвёртка, ключ. Ты не споришь, что лучше, — ты смотришь на работу перед тобой.

Решай по форме разговора. Вопрос никогда не «какой протокол», а «какой именно — для этой линии».

_Diagram: Слева форма разговора, справа протокол, который под неё заточен._

### Начинай с простого; тянись за экзотикой, только когда болит

> Ты не прокладываешь железную дорогу, чтобы перенести один мешок муки через двор.

Большинство продуктов уезжают очень далеко на **REST + JSON поверх HTTPS, плюс очередь для фоновых задач.** gRPC, GraphQL, Kafka и WebSocket — это ответы на конкретные боли: задержка «сервис — сервис», голодные клиенты, огромные объёмы событий, живое взаимодействие. Бери их, когда чувствуешь именно эту боль, а не потому что звучит современно. **Самый простой протокол, подходящий под разговор, обычно побеждает.**

### Как всё связано

> Слоёный пирог: каждый слой лежит на предыдущем, и сверху видно только крем.

Форматы лежат внутри стилей API, стили едут на HTTP или брокерах, всё это заворачивается в TLS, а снизу — TCP или UDP. Одно реальное приложение легко использует половину этой схемы сразу.

_Diagram: Связи: формат → стиль API → протокол → TLS → транспорт. gRPC держится на HTTP/2 и Protobuf, HTTP/3 — на UDP._

#### Прежде чем выбрать протокол

- **Кто начинает разговор** — клиент или сервер?
- **Как часто и насколько большие** сообщения?
- **Один-на-один или один-ко-многим** со временем?
- **Должно ли это быть читаемым** — или как можно меньше и быстрее?
- **Кто клиент** — браузер, мобильное приложение, ещё один мой сервис, крошечное устройство?
- **Хватает ли обычного REST + JSON**, прежде чем тянуться за чем-то навороченным?

#### Признаки, что ты перегнул

- Ты выбрал **gRPC для публичного API**, который должны звать браузеры.
- **WebSocket** там, где хватило бы кнопки «обновить».
- **Kafka**, чтобы перегонять пару сотен сообщений в день.
- **GraphQL** для одного клиента, который каждый раз тянет одни и те же три поля.
- **Бинарный формат** для данных, которые тебе постоянно нужно читать и отлаживать руками.

#### Признаки, что ты выбрал хорошо

- **Клиент и сервер договариваются** без клеящего кода, переводящего между ними.
- Протокол **подходит трафику** — стрим для потоков, запрос-ответ для вопросов.
- Ты можешь **отлаживать это** инструментами, которых протокол ждёт, — браузером, логами или proto-тулзами.
- **Шифрование включено** по умолчанию, везде.
- Каждый разговор использует **самый простой подходящий протокол** — и не более.

## Шпаргалка: все 21 понятие

### Основы

- **Protocol** (протокол): Договор двух программ: форма сообщения + порядок разговора.
- **Protocol stack** (стек протоколов): Слои: транспорт везёт байты, прикладной протокол придаёт им смысл.

### Фундамент

- **TCP** (Transmission Control Protocol): Надёжная доставка по порядку: рукопожатие, подтверждения, повторы.
- **UDP** (User Datagram Protocol): Отправил и забыл: быстро, но с потерями. Видео, игры, DNS.
- **HTTP** (HyperText Transfer Protocol): Запрос-ответ без состояния: глаголы и коды статуса.
- **TLS / HTTPS** (Transport Layer Security): Шифрование + проверка личности сервера. HTTPS = HTTP внутри TLS.
- **HTTP/2 · HTTP/3** (multiplexing, QUIC): Много запросов по одному соединению; HTTP/3 на QUIC поверх UDP.

### Запрос и ответ

- **REST** (Representational State Transfer): Ресурсы по URL + глаголы HTTP + JSON. Дефолт для публичных API.
- **GraphQL** (язык запросов к API): Один эндпоинт, клиент просит ровно нужные поля.
- **gRPC** (Remote Procedure Call): Вызов функции другого сервиса: HTTP/2 + Protobuf, строгий контракт.
- **SOAP** (Simple Object Access Protocol): Строгие XML-конверты и WSDL. Живёт в банках и корпорациях.

### Реальное время и push

- **Polling** (опрос, long-polling): Клиент сам спрашивает «есть новое?». Запасной вариант.
- **SSE** (Server-Sent Events): Поток от сервера к клиенту по одному HTTP-ответу. Стрим токенов LLM.
- **WebSocket** (полнодуплексный канал): Открытая линия, обе стороны говорят когда хотят. Чаты, игры.
- **Webhook** (обратный вызов по HTTP): Сервис сам делает POST на твой URL, когда случилось событие.

### Сообщения

- **Message broker** (брокер сообщений): Посредник: развязывает отправителя и получателя во времени и в знании.
- **Message queue** (AMQP, RabbitMQ): Задача ждёт в очереди; её берёт ровно один воркер.
- **Kafka** (лог событий): Долговечный лог: много читателей, у каждого своя позиция, история остаётся.
- **MQTT** (pub/sub для IoT): Лёгкие сообщения по топикам для слабых устройств и сетей.

### Форматы

- **JSON** (JavaScript Object Notation): Читаемый текст, дефолт веба. Чуть многословен.
- **Protobuf** (Protocol Buffers): Компактный бинарь по схеме. Быстро, но глазами не прочитать.
- **XML** (eXtensible Markup Language): Теги и строгая схема. Громоздко, живёт в старых системах и SOAP.

> Современные приложения построены не на одном протоколе. Они построены на правильном протоколе для каждого разговора — и на TLS вокруг них всех.

Конец экспресс-курса · 7 глав · 21 понятие

Дальше — глубина: спецификации HTTP и TLS, документация gRPC и GraphQL, «High Performance Browser Networking» Ильи Григорика. Но прежде деталей — представь разговор. Кто говорит, как часто, как быстро и с кем. Протокол — это всего лишь договор, который делает этот разговор возможным.