Tracker.ru / Документация

Жауап уақытының waterfall-ы: DNS / Connect / TLS / TTFB

5 мин чтения
Обновлено 12 мая 2026

Клиент жағындағы HTTP-чек — бұл бір операция емес, фазалар тізбегі. Алдымен браузер (немесе мониторинг) доменді IP-ке шешеді, содан кейін TCP-қосылым орнатады, содан соң HTTPS үшін TLS handshake жасайды, осыдан кейін ғана сервердің жауабының бірінші байтын күте бастайды. Әрбір фазаның өз уақыты бар, ал жалпы «сайт жылдамдығы» — олардың қосындысы.

Tracker.ru әрбір HTTP-чек үшін барлық төрт фазаны өлшейді және оларды тексерулер журналында waterfall түрінде — түрлі түсті кесінділері бар көлденең график арқылы көрсетеді. Бұл «неге сайт баяу» деген сұраққа тікелей жауап береді: миллисекундтар нақты қай фазада жоғалатыны көрінеді.

Waterfall қандай фазалардан тұрады

Tracker.ru-да сұраудан бірінші байтқа дейінгі толық цикл тәуелсіз өлшенетін төрт фазаға бөлінген:

  • DNS — доменді IP-адреске шешу. Сұрау DNS resolver-ға кетеді (әдетте провайдер немесе сервис кэшіне), ол A/AAAA-жазбаны қайтарады. Жылы кэш үшін норма — 5–30 ms; ұзақ шешу (200+ ms) authoritative NS-тың мәселесін, гео-қашықтағы resolver-ды немесе TTL=0-ні көрсетеді.
  • Connect (TCP handshake) — мақсатты сервермен үш жақты SYN/SYN-ACK/ACK. Негізінен RTT (round-trip time) — физикалық қашықтық пен арна сапасына байланысты. Мәскеу ↔ Мәскеу — әдетте 5–15 ms; Мәскеу ↔ Франкфурт — 30–60 ms; Мәскеу ↔ АҚШ — 130–200 ms.
  • TLS (handshake) — шифрленген арнаның қол алысуы, тек HTTPS үшін. Заманауи TLS 1.3 1 RTT-қа сыяды, TLS 1.2 — 2 RTT-қа. Ұзақ TLS handshake (жақын серверде 300+ ms) — ауыр cipher suite, OCSP сертификат тексеру немесе жылынбаған сессиялардың белгісі. HTTP-чектер үшін (HTTPS емес) фаза 0-ге тең — handshake болмайды.
  • TTFB (Time To First Byte) — handshake аяқталғаннан жауаптың бірінші байтын алғанға дейінгі уақыт. Бұл серверлік өңдеу: framework ішіндегі маршрутизация, ДҚ-дағы сұраулар, template рендерлеу, header құрастыру. Статикалық беттер үшін норма — 50–200 ms; ДҚ-сұрауы бар динамикалық беттер үшін — 200–600 ms; 1 секундтан жоғары — әдетте backend-ті профайлдау керек.

Осы төрт мәннің қосындысы — HTTP-чектің жалпы ұзақтығы (журналдағы response_time өрісі). Егер сізде басты бет браузерде ашық болса, TTFB-тен кейін HTML денесін жүктеу, парсинг, ассеттерді дозагрузка, DOM рендері әлі болады — бірақ бәрі серверлік жауаптың шегінен тыс, Tracker.ru оны өлшемейді: біз басқарылатын серверлік бөлікке шоғырланамыз.

Tracker.ru-да waterfall-ды қалай оқу керек

Тексерулер журналында әрбір сәтті жазбада фазалар бойынша мәліметтер бар. Жолға курсорды апару жеткілікті — бөлініспен tooltip пайда болады:

Total: 487 ms
├─ DNS:     12 ms
├─ Connect: 38 ms
├─ TLS:     74 ms
└─ TTFB:   363 ms

URL бетін ашып, «Логи» қойындысына ауыссаңыз, сол нәрсе бағандармен қолжетімді. Ұзақ кезеңдер үшін (7/30 күн) трендтерді статистика бетінде қарау ыңғайлырақ — онда қай фаза уақыт өте өсіп жатқаны көрінеді.

UI-дан басқа, сол мәндер REST API арқылы қолжетімді: GET /api/urls/{id}/logs endpoint әрбір журнал жазбасы үшін dns_time, connect_time, tls_time, ttfb өрістерін қайтарады (миллисекунд). Бұл метрикаларды Grafana, Prometheus немесе өзіңіздің observability-стекіңізге экспорттасаңыз пайдалы.

Waterfall-ға не үшін қарау керек

Бір ортақ «response time» «нені түзету керек» деген сұраққа жауап бермейді. Waterfall — береді.

«Сайт соңғы айда баяулады»

URL бетінде response time-тың 30 күндік графигін ашыңыз. Жалпы тренд жоғары қарай жылжыса — әрі қарай фазалар бойынша қараңыз. DNS/Connect/TLS тұрақты кезде TTFB өседі — мәселе backend-те (ДҚ-ға жүктеме өсті, баяу сұрау пайда болды, кэш жұмыс істемейді). DNS өседі — authoritative NS күйін және жазбалардың TTL-ін тексеріңіз. TLS өседі — cipher suite-ге және жылынбаған сессиясыз OCSP must-staple бар-жоғын қараңыз. TTFB тұрақты кезде Connect өседі — маршрутизация немесе желілік провайдер өзгерді.

«Сайт кейде баяу ашылады»

Бір фазаның нүктелі шапшаулары — мәселенің басқа класы. DNS-тің 1–2 секундқа дейінгі шапшаулары — resolver кэштен мерзімді промахтайды және authoritative NS-қа барады. TLS-тің шапшаулары — серверге криптографияға CPU жетпейді (арзан VPS-ке тән). TTFB-тың шапшаулары — фондық тапсырмалар (cron, GC, бэкаптар) сұрау өңдеушіден ресурстарды алады.

Tracker.ru әрбір чекті сақтайды, сондықтан мұндай шапшаулар сағаттық орташаға орташаланбай, толық графикте көрінеді.

«Бір аймақ баяу, басқалары жоқ»

Егер сіз көп аймақты мониторинг — Мәскеу, Франкфурт, Алматы — пайдалансаңыз, әрбір аймақтың өз waterfall-ы бар. Бұл бірден екі себепті бөледі:

  • TTFB барлық жерде бірдей, ал бір аймақта Connect өсті — демек, мәселе сол аймақ пен сервер арасындағы желіде. Серверді жеңілдетудің қажеті жоқ, провайдерге немесе аралық hop-тарға қарау керек.
  • TTFB барлық жерде бірдей өсті — керісінше, серверлік жүктеме. Желінің еш қатысы жоқ.

«Сайт жылдам, бірақ Google Search Console баяу дейді»

Google TTFB-ты Core Web Vitals сигналдарының бірі ретінде пайдаланады (INP метрикасы ішінара корреляцияланады). PageSpeed Insights «Reduce server response times» десе, бірақ браузерде сіз баяулауды сезбесеңіз — TTFB-ты тұрақты чектерде дәл бақылаңыз. 7 күндік орташа Google-дың бір реттік өлшемдеріне қарағанда тұрақты сурет береді.

Үлкен мәндермен не істеу керек

Фаза Үлкен көрсеткіш не білдіреді Қайда қарау керек
DNS > 100 ms Resolver промахтайды немесе authoritative NS алыс DNS-жазбалардың TTL-і, NS гео-қашықтығы, жылдам DNS-провайдерге көшу
Connect > 200 ms (жақын сервер) Ұзын желілік жол немесе пакет жоғалту traceroute, провайдер, CDN/edge
TLS > 300 ms Ауыр cipher немесе stapling-сіз OCSP TLS 1.3, OCSP stapling, сессияларды қайта пайдалану
TTFB > 1000 ms Баяу backend Сұрауды профайлдау, ДҚ slow query log, бет кэші

Бұл шектер — бағдар, абсолютті ереже емес. Күрделі аналитикасы бар бастапқы дереккөз сайтының TTFB-ы 800 ms болуы мүмкін және ол норма; статикалық лендингтің TTFB-ы 400 ms болса — қазірдің өзінде күмәнді.

Басқа сервистермен салыстыру

Жауап уақытын фазаларға бөлу барлық мониторинг-сервистерде жоқ:

  • Tracker.ru — әрбір чек үшін барлық төрт фаза (DNS / Connect / TLS / TTFB), UI-да және API арқылы қолжетімді.
  • UptimeRobot — тек жалпы response time-ды көрсетеді, бөлініссіз.
  • Pingdom — иә, синтетикалық мониторингте ұқсас бөлініс бар.
  • Better Stack (Better Uptime) — иә, жоғары тарифтерде.
  • Healthchecks.io — жоқ (бұл heartbeat-сервис, URL-мониторинг емес).

Бұл production-сайттарға мониторинг таңдағанда маңызды бөлшек: фаза бойынша бөліссіз баяу сайтты диагностикалау болжамға айналады. Tracker.ru функционалын бәсекелестермен толық салыстыру салыстыру бөлімінде.

Tracker.ru деректерді қайда сақтайды

Барлық төрт өріс тексерулер журналының әрбір жазбасында сақталады:

  • dns_time — миллисекунд
  • connect_time — миллисекунд
  • tls_time — миллисекунд (TLS-сіз HTTP үшін 0)
  • ttfb — миллисекунд

Егер фаза орындалуға үлгермесе (мысалы, DNS шешілмеді — host_not_found), кейінгі барлық өрістер нөлдік болып қалады, ал чек күйі сәйкес error_status-пен қателі деп белгіленеді.

Тарих URL-дың бүкіл өмір мерзімінде сақталады: кешегі, бір ай бұрынғы чектердің waterfall-ын қарауға немесе екі кезеңді бір-бірімен салыстыруға болады.

Байланысты мақалалар