Экспресс-курс · No. 05

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

21 понятие · схема у каждого · шпаргалка в конце

§ 01

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

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

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

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

ConceptProtocol· протокол

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

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

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

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

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

ConceptProtocol stack· стек протоколов, слои

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

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

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

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

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

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

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

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

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

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

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

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

§ 02

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

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

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

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

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

ProtocolTCP· Transmission Control Protocol

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

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

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

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

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

ProtocolUDP· 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) — каждый запрос сам по себе, — и именно это позволяет вебу масштабироваться до миллиардов вызовов.

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

ProtocolHTTP· 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 его подразумевают.

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

ProtocolTLS / 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 на сотовую сеть без обрыва.

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

ProtocolHTTP/2 · HTTP/3· multiplexing, QUIC

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

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

§ 03

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

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

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

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

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

API styleREST· 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. Блестяще, когда множество разных клиентов (веб, мобильные, партнёры) нуждаются в разных срезах сложного графа данных.

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

API styleGraphQL· язык запросов к API

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

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

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

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

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

ProtocolgRPC· Remote Procedure Call от Google

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

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

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

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

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

ProtocolSOAP· Simple Object Access Protocol

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

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

§ 04

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

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

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

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

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

TechniquePolling / Long-polling· опрос

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

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

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

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

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

ProtocolSSE· Server-Sent Events

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

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

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

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

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

ProtocolWebSocket· полнодуплексный канал

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

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

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

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

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

PatternWebhook· обратный вызов по HTTP

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

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

§ 05

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

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

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

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

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

ConceptMessage broker· брокер сообщений

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

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

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

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

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

ProtocolMessage queue· AMQP, RabbitMQ

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

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

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

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

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

ToolKafka· лог событий, event streaming

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

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

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

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

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

ProtocolMQTT· pub/sub для IoT

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

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

§ 06

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

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

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

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

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

FormatJSON· JavaScript Object Notation

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

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

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

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

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

FormatProtobuf· Protocol Buffers, MessagePack, Avro

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

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

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

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

FormatXML· eXtensible Markup Language

Что это

Текстовый формат на тегах со строгой схемой.

Пример

42Ann

Цена

Громоздкий: та же запись почти вдвое длиннее JSON.

Когда брать

Редко для нового — но он до сих пор несущий во множестве старых систем.

Связи

Язык SOAP; сменщик в вебе — JSON.

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

§ 07

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Основы

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

Фундамент

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

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

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

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

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

Сообщения

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

Форматы

JSONJavaScript Object Notation: Читаемый текст, дефолт веба. Чуть многословен.
ProtobufProtocol Buffers: Компактный бинарь по схеме. Быстро, но глазами не прочитать.
XMLeXtensible Markup Language: Теги и строгая схема. Громоздко, живёт в старых системах и SOAP.

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