CDNmon измеряет несколько этапов доставки CDN-контента.
GET-запрос, обычно по уже установленному соединению.Так CDNmon отдельно показывает задержку первого ответа, задержку обмена по соединению, фактическую скорость загрузки и доступность CDN.
CDNmon фиксирует фактический HTTP-статус CDN-ответа или техническую ошибку.
200 OK на тестовый объект.301 или 302, не проходятся автоматически: они сохраняются как отдельный статус и не учитываются как успешная доставка объекта.Timeout означает, что точка проверки не получила ожидаемый сетевой ответ за установленное время. Для CDNmon лимит составляет 10 секунд.
Нет. Мониторинг осуществляется только из сетей ЦОД.
CDNmon выполняет регулярные проверки CDN с высокой частотой: примерно раз в несколько секунд для каждого тестового CDN-объекта с активных точек мониторинга.
На графиках данные агрегируются, поэтому отображаемые значения зависят от выбранного периода просмотра.
В CDNmon TTFB измеряется по служебному HEAD-запросу к тестовому CDN-объекту.
В замер входит время до получения HTTP-ответа с заголовками. Для HTTPS туда может входить установка соединения и TLS-handshake.
Редиректы не проходятся. TTFB учитывается только если CDN сразу вернул 200 OK.
RTT в CDNmon измеряется не как ICMP-ping, а как время ответа на последующий GET-запрос к тому же тестовому объекту.
Обычно этот GET выполняется в той же HTTP-сессии после HEAD, то есть по уже установленному соединению.
Если ответ GET успешный (200 OK), RTT сохраняется в миллисекундах. Если ответ неуспешный или произошел таймаут либо ошибка соединения, такая точка не участвует в графиках RTT.
Throughput показывает фактическую скорость загрузки тестового объекта CDN.
Алгоритм измерения:
HEAD-запрос и измеряет TTFB.GET-запрос к тому же объекту.Размер тестового объекта делится на время загрузки его тела. Так получается пропускная способность CDN для этой точки проверки.
Каждая CDN-сеть, находящаяся на мониторинге, хранит тестовый файл размером около 100 KB, например /img/r20-100KB.png.