Медленный HTTPS-запрос: раскладываем время curl на DNS, TCP, TLS и ожидание ответа

Проверка API занимает три секунды, но число само по себе не объясняет задержку. Клиент мог долго разрешать имя, ждать TCP-соединения, согласовывать TLS или получать первый байт от приложения. curl умеет показать временные отметки этих этапов за один запрос. Чтобы прочитать их правильно, нужно помнить: большинство значений считаются от начала операции.

Снимите один запрос без перенаправлений

curl --connect-timeout 5 --max-time 20 -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' https://api.example/health

Параметр o отправляет тело в пустое устройство Linux, но запрос и получение ответа выполняются. sS убирает индикатор прогресса и сохраняет сообщения об ошибках. Не добавляйте следование перенаправлениям на первом измерении: несколько последовательных запросов усложняют смысл времени. Если получен redirect, сначала выясните его назначение и измерьте конечный URL отдельно.

Допустим, наблюдение выглядит так: dns=0.020, connect=0.050, tls=0.120, first=1.120, total=1.220. Это условный пример для чтения полей. Разрешение имени заняло около 20 миллисекунд, промежуток до завершения TCP после него — около 30, согласование TLS после TCP — около 70. Складывать все пять чисел нельзя: в них уже включено предыдущее время.

Вычитайте соседние отметки

В примере промежуток между TLS и первым байтом составляет одну секунду. Он включает отправку запроса и ожидание начала ответа; это ещё не чистое время выполнения обработчика. Здесь могут участвовать прокси, очереди и сеть. Чтобы узнать серверную часть, сопоставьте запрос с журналом приложения или балансировщика.

Разница total и first около 100 миллисекунд описывает оставшуюся передачу ответа. Для большого файла она полезнее, чем длительность небольшого health-запроса. Если первый байт приходит быстро, а total велико, исследуйте размер и скорость передачи, чтение клиента и потоковую выдачу сервера.

Сделайте сравнение воспроизводимым

Повторите измерение несколько раз с одной машины, одним URL и одинаковым способом подключения. Первый запуск может включать холодный DNS-кэш, а дальнейшие — пользоваться кэшем инфраструктуры. Запишите, проходил ли запрос через прокси. Он меняет интерпретацию TCP- и TLS-этапов: клиент может соединяться сначала с промежуточным узлом.

Не переносите результаты одного короткого curl на всё приложение. Браузер открывает дополнительные соединения, выполняет скрипты и загружает ресурсы. Для исходной задачи выберите конкретный API-запрос и измеряйте именно его. Если запрос авторизованный, передавайте секреты привычным защищённым способом и не сохраняйте их в публичном отчёте.

После изменения повторите тот же вызов и сравните нужный промежуток, а не только total. Если ожидание первого байта уменьшилось, но выросло DNS-время, это две отдельные истории. Такой разбор позволяет объяснить, какой эффект дали изменения и куда идти дальше.

Научитесь связывать сетевые измерения с работой сервиса. Откройте программу Linux и Bash для DevOps-инженеров. В ней предусмотрены DNS, HTTP и диагностика учебного приложения — основа для перехода от общего «медленно» к конкретной проверке.

Ещё по теме

• Тестируем отдельный backend по HTTPS: curl --connect-to сохраняет имя сервиса
• Сверка двух списков в awk: почему NR == FNR ломается на пустом справочнике