Как сравнить один безопасный запрос Telegram Bot API с двух серверов по этапам DNS, TCP, TLS, первого байта и общего времени, не публикуя токен и не принимая HTTP 429 за сетевую задержку.
Почему общего времени недостаточно
Одинаковое total time может скрывать разные причины. Задержка до разрешения имени относится к DNS-этапу; ожидание после него до соединения — к TCP; интервал до завершения защищённого рукопожатия — к TLS; пауза после отправки запроса до первого байта — к TTFB. Официальная справка curl определяет метрики time_namelookup, time_connect, time_appconnect, time_starttransfer и time_total. Они позволяют описать место ожидания, но сами по себе не называют виновника. Официальная спецификация Telegram подтверждает HTTPS endpoint Bot API. Поэтому сравнение строится для одного и того же метода, в близкое время и с одинаковым объёмом ответа, а не по случайным операциям двух разных ботов.
Синхронный тест двух хостов
Выберите безопасный метод с малым ответом и заранее подготовьте способ измерения, который не выводит полный URL в историю, process list, терминал или отчёт. На каждом сервере выполните серию в одинаковые минуты и сохраните только код ответа и пять времён. Добавьте UTC-время, hostname хоста и версию клиента, но удалите токен, chat ID и содержимое сообщений. Сопоставляйте медиану и отдельные выбросы, а не один удачный запрос. Если DNS-время растёт только на одном хосте, следующая проверка относится к резолверу; если разница начинается на connect или appconnect, нужен сетевой путь; если только на starttransfer — нужен серверный и прикладной контекст.
Отдельная ветка для 429
HTTP 429 нельзя смешивать с таймаутом. Спецификация Bot API описывает параметр retry_after при flood control: это прикладной ответ с указанием ожидания, а не доказательство медленного DNS или TLS. В таблице заведите отдельные колонки status и retry_after. Не повторяйте запросы быстрее в попытке «пробить» задержку и не игнорируйте указанное ожидание. Если оба хоста получают 429 на одном боте, исследуйте режим вызовов и лимиты отдельно от сети. Если один хост не получает HTTP-ответ вовсе, сравнивайте его водопад до последней достигнутой стадии. Так ошибка управления частотой не превращается в ложный диагноз маршрута.
Стоп-условия и пакет эскалации
Остановите эксперимент, если инструмент может раскрыть токен, если тест начинает отправлять реальные сообщения или если частота вызывает 429. Не публикуйте IP-адреса серверов, внутренние DNS-настройки и сырые трассировки. Для провайдера хостинга или сетевой команды достаточно обезличенной таблицы: время, регион сервера, код ответа, пять метрик, доля таймаутов и результат контрольного запроса к другому разрешённому HTTPS endpoint. Для поддержки Telegram сохраните точный метод и время, но секрет перед отправкой замените. Вывод должен оставаться измеримым: «задержка возникает до такой-то стадии на одном хосте», а не «Telegram замедляет сервер».
Материал подготовлен редакцией VOne с применением ИИ для структурирования; факты вручную сверены с официальными спецификациями Telegram и curl, а Habr Q&A использован только как обезличенный сигнал симптома.
Источники и проверка
- Telegram — Bot API проверено 2026-07-31
- curl — command line reference проверено 2026-07-31
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.