Compression и производительность

Сжатие grpc-сообщений в классическом стеке — это церемония: компрессор регистрируется на сервере через encoding.RegisterCompressor, клиент выбирает его call-опцией grpc.UseCompressor, и всё это надо не забыть на обеих сторонах. В Connect из коробки работает gzip: хендлер принимает сжатые запросы и умеет сжимать ответы, клиент принимает сжатые ответы — без единой строки конфигурации. Механика — стандартная HTTP-договорённость. Клиент анонсирует, что понимает, заголовком Accept-Encoding: gzip; сервер, решив сжать ответ, ставит Content-Encoding: gzip; клиент распаковывает до десериализации. Для запросов в обратную сторону то же самое: клиент, которому сказали сжимать исходящее, шлёт тело с Content-Encoding: gzip, и хендлер распаковывает его до передачи кодеку. Отсюда первое следствие: чтобы получать сжатые ответы, вам обычно не нужно ничего — gzip в списке поддержанных алгоритмов обеих сторон с первого дня. Чтобы отправлять сжатые запросы, есть опция connect.WithSendGzip: клиент сжимает исходящие сообщения unary-вызовов и стримов. Если алгоритмов хочется больше — например, zstd ради скорости — пул компрессоров подключается опцией WithCompression с именем, а клиент выбирает алгоритм через WithCompressionName; gzip при этом остаётся нулевой ценой входа. Второе следствие важнее: сжатие в Connect действует на сообщение, а не на соединение. В стримах из восьмого урока каждое сообщение конверта сжимается отдельно — мелкие сообщения внутри длинного стрима порог не пройдёт и поедет как есть, крупные сожмутся. Это отличает connect-модель от идеи «сжать весь HTTP-ответ целиком» и делает порог осмысленным на уровне каждого сообщения. И третье: сжатие — не флаг «включить или выключить», а переговоры. Если клиент не анонсировал gzip, сервер не будет жать; если анонсированного алгоритма у сервера нет, уедет identity — сырое сообщение без Content-Encoding. Всю эту механику вы не увидите в логах — только в трафике, поэтому ниже мы закрепим её порогами и тестами.

Порог называется connect.WithCompressMinBytes: сообщения меньше указанного размера уходят без сжатия, даже если обе стороны gzip анонсировали. По умолчанию порог равен нулю — сжимается всё согласованное, включая сообщения в десятки байт. Почему это плохо: gzip не знает про RPC — он сжимает поток байт, и на крошечном входе его выхлоп исчезает. Сообщение в двести байт после gzip-а занимает примерно столько же или больше: словарь, заголовок блока и минимальный размер сжатого блока съедают выигрыш, а CPU потрачен на оба конца — сжатие на сервере, распаковка на клиенте. На миллионах мелких вызовов это чистый убыток и по CPU, и по латентности: p99 растёт на доли миллисекунды, которых у тикового трафика нет. Отсюда рабочая настройка: WithCompressMinBytes(1<<10) как старт — всё, что меньше килобайта, едет сырое, всё, что больше, имеет шанс окупиться. Точная цифра зависит от профиля: для сервиса, пересылающего логи и вложения, порог смело поднимается; для интерактивного API с мелкими ответами сжатие может не окупаться вовсе — и это тоже валидное решение, зафиксированное в конфигурации. Второй нюанс — чей порог. Опция стоит и на клиенте, и на хендлере, и это два независимых числа: клиентский решает, сжимать ли исходящие запросы, серверный — сжимать ли ответы. В стримах порог применяется к каждому сообщению отдельно, поэтому длинный стрим из восьмого урока ведёт себя как лента: мелкие сообщения едут сырыми, крупные — сжатыми, и это ровно то, чего хочется. И помните про identity из прошлого абзаца: сообщение ниже порога уезжает с identity, а не с ошибкой — это штатный путь, а не деградация сервиса.

Окупается ли gzip — вопрос про данные, а не про флаги. Прото-бинарник уже плотный: varint-числа, теги полей в один-два байта, никакого XML-заполнителя — повторяющихся шаблонов для словаря gzip-а мало, поэтому типичное сжатие бинарных сообщений скромное, в разы, а не в десятки раз. JSON-кодек из четвёртого урока — другое дело: текстовые имена полей и пробелы жмутся отлично, и на JSON-трафике выигрыш заметнее. Тексты, логи, вложения — лучший случай; маленькие структурные ответы — худший. Вторая сторона сделки — CPU и латентность: сжатие стоит на отправителе, распаковка на получателе, и оба вносят задержку до того, как байты вообще уйдут в сеть. На больших payload-ах сеть доминирует и сделка выгодна; на мелких частых вызовах CPU и латентность доминируют, и сделка убыточна. Третий фактор — загрузка: сжатие конкурирует с вашим хендлером за те же ядра. Если сервис упирается в CPU, gzip на каждом ответе урежет пропускную способность сильнее, чем выиграет сеть; если упирается в сеть — наоборот. Отсюда метод, а не догма: включите порог, прогоните бенчмарки на реалистичных данных — benchstat покажет дельту, pprof укажет, сколько CPU съел gzip, а тест полного стека из шестнадцатого урока зафиксирует поведение порога. В проде доверяйте метрикам: размеры сообщений и латентности из семнадцатого урока покажут, окупился ли эксперимент, — и откатите опцию, если нет: это одна строка конфигурации, а не переписывание кода. Отдельный случай — компрессия на границе: ingress и прокси умеют сжимать сам HTTP-трафик, и иногда правильное место для gzip-а именно там, а не в приложении; это решение двадцать второго урока, где деплой-топология определит, кто жмёт.

Теперь ручка, которая даёт больше, чем всё сжатие вместе: транспорт. Главный источник латентности в RPC — не байты, а рукопожатия: TCP-коннект, затем TLS-рукопожатие на https-адресах — единицы и десятки миллисекунд на каждый новый запрос, если соединения не переиспользуются. HTTP/2 решает это мультиплексированием: множество параллельных вызовов идут в одном TCP-соединении, и повторное использование бесплатно — но только пока соединение живёт. За жизнь соединений отвечает http.Client, и вот где живут самые дорогие баги производительности. Первая ошибка — создавать клиент на каждый запрос: новый http.Client с нулевым Transport-ом не разделяет пул ни с кем, каждое обращение платит рукопожатие заново. Правило канона из пятого урока — один http.Client на процесс, первый аргумент сгенерированного клиента. Вторая ошибка тоньше: дефолтный http.DefaultTransport держит MaxIdleConnsPerHost равным двум — под параллельной нагрузкой простаивающие сверх двух соединения закрываются, и мультиплексирование HTTP/2 начинает соседствовать с новыми рукопожатиями. Лечение — свой Transport с повышенным MaxIdleConnsPerHost: клиент из тринадцатого урока с TLSClientConfig уже строился на собственном Transport — сюда же добавьте и пул. Третий нюанс — HTTP/2 сам по себе: поверх TLS он включается автоматически, и у двунаправленных стримов из восьмого урока нет выбора — они требуют HTTP/2. По открытому http:// HTTP/2 в Go включается флагом ForceAttemptHTTP2 и требует согласования с сервером; на границе инфраструктуры протокол может рваться на hop-е — это история про ingress и деплой, вернёмся к ней в двадцать втором уроке. Заметьте иерархию: правильный транспорт экономит десятки миллисекунд на вызов и не стоит ничего; gzip экономит килобайты и стоит CPU. Настраивайте в этом порядке.

Обещание тринадцатого урока пора исполнить: у лимита чтения есть вторая роль, кроме DoS-защиты, — decompression-бомбы. Идея атаки проста: тело, которое сжимается в сорок килобайт, распаковывается в сотни мегабайт и гигабайты — gzip-у всё равно, он честно сжимает длинные повторяющиеся последовательности. Атакующий шлёт крошечный сжатый запрос, а сервер обязан где-то удержать распакованный результат до десериализации — классическая амплитудная атака, и сжатие здесь не защита, а оружие: сжатый трафик ещё и дешевле отправлять. Что с этим делает Connect: WithReadMaxBytes из тринадцатого урока ограничивает объём, который хендлер примет и распакует, — ресурсный отказ приходит раньше вашего хендлера, и память сервиса не видит гигантского результата. Механика проверки у протоколов различается: в стриминговых жанрах размер сообщения объявлен в префиксе конверта, и превышение видно сразу; в unary тело читается с ограничением — но гарантия на выходе одна: сколько бы байт ни обещал gzip, дальше лимита вы не прочитаете. Поэтому связка урока — порог сжатия и лимит чтения — не два независимых тюнинга, а пара «экономия и защита»: WithCompressMinBytes бережёт CPU от бессмысленной компрессии, WithReadMaxBytes бережёт память от злонамеренной декомпрессии. Практический вывод: любой сервис, принимающий сжатые запросы, обязан иметь лимит чтения — дефолт «без лимита», как мы говорили в тринадцатом, это потенциальный DoS, а при компрессии цена ошибки растёт в тысячи раз. Проверяется всё это тестом полного стека: тело бомбы уходит сырым POST-ом с Content-Encoding: gzip, тест ожидает ресурсный отказ — тот же приём, которым в шестнадцатом уроке проверяются коды ошибок вообще.

Ручки собраны: порог бережёт CPU, лимит держит бомбы, транспорт держит соединения. Дальше по курсу: пятнадцатый урок — документация API, где в том же buf-конвейере появятся OpenAPI и доки из proto-комментариев — пятнадцатый; метрики семнадцатого покажут, окупилась ли настройка, на живом трафике. Для повторения: лимиты и TLS — в тринадцатом уроке, протоколы и кодеки — в четвёртом, клиент и http.Client — в пятом. Программа всех двадцати пяти уроков — на странице курса.