HTTP-заголовки: диагностика запросов и ответов

Прямой ответ

Заголовки запроса и ответа содержат сведения, достаточные для определения причины задержки либо отказа без захвата пакетов.

# Заголовки и тайминги этапов
curl -sS -D - -o /dev/null -w '\n---\ndns: %{time_namelookup}\nconnect: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\ntotal: %{time_total}\n' \
  

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

Признаки в заголовках и интерпретация статусов

Заголовки ответа содержат признаки, которые определяют направление диагностики.

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

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

Признак сжатия. Заголовок кодирования содержимого показывает метод сжатия, поэтому фактический объём передачи отличается от объёма тела. О сжатии — в статье про сжатие HTTP-ответов.

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

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

Три признака, определяемые по заголовкам.

Задержка на этапе разрешения. Время разрешения сопоставимо с общим временем, поэтому кэш разрешения не используется.

Задержка до первого байта. Время до первого байта велико при малом времени соединения, поэтому обработка запроса на сервере занимает основную долю.

Отсутствие признака сжатия. Объём передачи равен объёму тела, поэтому сжатие не применяется к данному типу содержимого.

О распределении задержек по этапам — в статье про диагностику задержек.

Влияние промежуточных узлов на заголовки

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

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

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

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

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

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

Повторная проверка после изменения

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

Сравнение до и после. Тайминги этапов снимаются до изменения и после, поэтому эффект изменения подтверждается числами.

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

Практическое следствие: изменение подтверждается повторным измерением, а не предположением об эффекте.

Практика: диагностика по заголовкам и таймингам

1. Снимите тайминги этапов. Распределение времени показывает, где возникает задержка.

2. Проверьте код состояния. Класс кода определяет направление диагностики: клиентская либо серверная ошибка.

3. Проверьте признак повторного использования соединения. Нулевое время установки указывает на переиспользование соединения.

4. Сравните объём тела и объём передачи. Заголовок кодирования содержимого показывает, применяется ли сжатие.

5. Проверьте заголовки управления кэшем. Ответ из кэша не достигает сервера, поэтому время запроса сокращается.

6. Выполните запрос несколько раз. Первый запрос включает разрешение и установку соединения, повторные — нет.

7. Фиксируйте условие запроса. Метод, заголовки и тело влияют на результат, поэтому условие воспроизводится.

Рекомендации:

1. Различайте время соединения и время обработки. Задержка до первого байта при малом времени соединения указывает на обработку на сервере.
2. Учитываем влияние первого запроса. Разрешение и установка соединения выполняются один раз, поэтому повторные запросы быстрее.
3. Проверяйте фактический объём передачи. Сжатие сокращает объём, поэтому объём тела не отражает объём передачи.
4. Фиксируйте заголовки запроса. Заголовок принятия кодирования влияет на применение сжатия, поэтому условие воспроизводится.
5. Пересматривайте при изменении конечной точки. Изменение пути либо метода изменяет результат, поэтому диагностика повторяется.

Практический сценарий: запрос выполнялся долго без явной причины

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

1. Диагностика. Тайминги показали, что основная доля времени приходится на этап до первого байта, при этом время разрешения и установки соединения были малы. Обработка запроса на сервере занимала основную долю.
2. Причина. Запрос выполнял обращение к базе данных без использования индекса, поэтому время обработки росло с объёмом данных. Сетевые этапы не влияли на общее время.
3. Действия. (а) Сняли тайминги этапов и определили долю обработки; (б) проверили план запроса к базе и обнаружили полное сканирование; (в) добавили индекс по полю условия, чтобы сократить время обработки; (г) повторно сняли тайминги и убедились в сокращении доли обработки; (д) добавили метрику времени обработки как контролируемую величину.
4. Результат. Время запроса сократилось, поскольку доля обработки уменьшилась после добавления индекса.

Вывод: тайминги этапов показывают распределение времени между сетевыми операциями и обработкой. Задержка до первого байта при малом времени соединения указывает на обработку на сервере, а не на сеть.

FAQ

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

Как определить, что соединение переиспользуется? По нулевому времени установки соединения. Запрос выполняется без рукопожатия, поэтому этап отсутствует.

Показывает ли объём тела фактический объём передачи? Нет, при сжатии объём передачи меньше объёма тела. Заголовок кодирования содержимого показывает применённый метод.

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

Источники: curl man page, MDN HTTP headers, RFC 9110 — ссылки в шапке.