Комментарии 14
Во-первых, при правильной настройке это "второе подключение" используется только при первом посещении сайта, а дальше всё это оказывается в кеше браузера.
Во-вторых, на картинке в начале статьи задержки вызваны вовсе не cdn'ом. Потому что из неё же видно что браузер и не пытался грузить всё через одно соединение а открыл к кажому запросу своё, пусть даже они и в одинаковом домене. И чей это домен — cdn или основной — тут роли не играет. Единственная задержка которая там реально из-за cdn это резолв домена который там зелёным цветом и очень маленький.
Так загрузка с холодным браузером (без кэша и подключения) и есть самый критичный момент в скорости, который нужно тестировать.
Задержки вызваны тем, что используется частичная загрузка с CDN (в данном случае с самодельного и без HTTP/2), но картинку это никак не меняет. Избежать этих задержек можно было загрузкой всего контента с одного домена по HTTP/2.
Задержки вызваны тем, что используется частичная загрузка с CDN (в данном случае с самодельного и без HTTP/2), но картинку это никак не меняет. Избежать этих задержек можно было загрузкой всего контента с одного домена по HTTP/2.
Resource Hints (preconnect) обнулил бы эту задержку, судя по диаграмме — фазы dns/connect/tls выполнялись бы параллельно с загрузкой остатка самой страницы. www.w3.org/TR/resource-hints
Не очень-то понятно, почему на первом скрине все соединения долго обрабатывают SSL-хэндшейк, хотя по идее так должно быть только с первым. На втором: 360 мсек для DNS-запроса — это катастрофа. К сути статьи это, конечно, имеет опосредованное отношение, просто бросилось в глаза.
Как раз понятно: браузер одновременно инициирует несколько соединений (это HTTP 1.1), при этом никаких тикетов или кэша сессий на этот момент нет, поэтому полный хэндшейк.
В DNS-запросе никакой катастрофы нет — это 2RTT, в идеале было бы 1RTT (150 мс).
В DNS-запросе никакой катастрофы нет — это 2RTT, в идеале было бы 1RTT (150 мс).
Дальнейшие различия определяются функциональностью конкретной CDN – для первого типа это всего лишь хостинг статического файла, для пятого это изменение нескольких типов контента сайта с целью оптимизации.
Открою масонскую тайну — первый, третий и четвертый тип CDN это одно и то же.
Четвертый и пятый отличаются не принципиально, добавляется преобразование контента во время транзита (сюда же и «защита от копирования», которое вы почему-то не указали), по сути это отдельный вид услуг, непосредственно к CDN не относящийся. Т.е. вы тут намешали разные классификации (по бесплатности, по доп.услугам, по контенту), которые могут комбинирваться с друг другом (а не противопоставляться).
Если мы разделяем ресурсы на основной хост (origin) и CDN, то необходимо разводить запросы по нескольким доменам и создавать несколько ТСP-соединений.
Сути это не меняет (создается несколько соединений), но технически можно не разделять по доменам, зависит от балансировки. Например можно со своего домена отдавать айпишник CDN хоста.
В худшем случае это: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT. В этой формуле не учитываются задержки в мобильных сетях на активацию радио-канала устройства (если он не был активен) и задержки на сотовой вышке.
Так вы сравниваете «прогретое» соединение (с рассчетом что пользователь обязательно посетил вашу страницу на origin) и непрогретое на cdn.
Если это прямая ссылка на изображение (например в соцсети), то с CDN скорее всего загрузится быстрее, чем ссылка на то же изображение с origin и не с большим количеством RTT.
На практике же CDN используют для уменьшения времени начала и окончания загрузки контента, а не замеров абстрактных RTT. Потери на RTT на непрогретых соединениях минимальны (на практике, в большинстве случаев), а ускорение на остальных аспектах гораздо существеннее выиграша в несколько RTT + снижение трафика на origin, что тоже существенная экономия на масштабировании.
Наиболее актуальный заголовок cache-control, устаревший – expires.
С чего это expires устаревший?
Может быть полезно знать, что в cache-control можно указать перевалидацию только для прокси tools.ietf.org/html/rfc7234#section-5.2.2.7.
Для некоторых применений стоит обратить внимание на вопросы безопасности: обычно трафик расшифровывается на узлах CDN, а это потенциальная возможность для перехвата трафика. Вариант работы без раскрытия трафика обычно предлагается в топовых тарифных планах за отдельную плату.
Это вообще про что? Расшифрование какого трафика? Более того, CDN может зашифровывать трафик.
Если вы уже используете какой-то CDN, проверьте его на предмет эффективности
А лучше перед использованием!
Если ваша основная аудитория сосредоточена в радиусе 1-2 тысяч километров, вам не требуется CDN по основному назначению – снижению задержек. Вместо этого, вы можете разместить свой сервер ближе к пользователям и настроить его должным образом, получая большинство оптимизаций, описанных в статье (бесплатно и постоянно).
Суть в предоставлении сервиса. Если вы хотите и можете размещать и поддерживать сервера по всей географии своей аудитории, настраивать правильно кэширование, балансировку, выбирать и договариваться о пиринге и находить время на исследование и оптимизацию всего этого, то поздравляю, вы можете создать свой CDN. Но у CDN сервиса больше клиетов, больше закупок, больше пользователей, можно мощности перераспределять между клиетами, у него больше возможностей для увеличения эффективности.
Ну и географические расстояния не равны сетевым замерам. Вполне реальная (хоть и редкая) ситуация, когда с CDN узла в том же городе контент раздается для некоторых абонентов (а то и для всех) лучше, чем с origin (по разным причинам). Хотя конечно предназначение CDN именно в распределенности.
Открою масонскую тайну — первый, третий и четвертый тип CDN это одно и то же.
Четвертый и пятый отличаются не принципиально, добавляется преобразование контента во время транзита (сюда же и «защита от копирования», которое вы почему-то не указали), по сути это отдельный вид услуг, непосредственно к CDN не относящийся. Т.е. вы тут намешали разные классификации (по бесплатности, по доп.услугам, по контенту), которые могут комбинирваться с друг другом (а не противопоставляться).
Согласен, здесь скорее не чистая классификация CDN как систем, а их сценариев использования со стороны потребителя.
С чего это expires устаревший?
Может быть полезно знать, что в cache-control можно указать перевалидацию только для прокси tools.ietf.org/html/rfc7234#section-5.2.2.7.
При наличии cache-control с max-age заголовок expires игнорируется. Устаревший он потому, что появился раньше и сейчас заменяется cache-control. MDN и RFC
Это вообще про что? Расшифрование какого трафика? Более того, CDN может зашифровывать трафик.
Трафика между origin и хостом CDN. Он сначала будет расшифрован на узле CDN, потом заново зашифрован и отправлен в браузер пользователя. Но узел CDN имеет доступ к открытому тексту (HTML, например).
Трафика между origin и хостом CDN. Он сначала будет расшифрован на узле CDN, потом заново зашифрован и отправлен в браузер пользователя. Но узел CDN имеет доступ к открытому тексту (HTML, например).
Если контент должен быть доступен только одному пользователю, то нет смысла его кэшировать и пускать через CDN.
Если он доступен всем (пускай и зашифрован), то все равно мы решаем давать ли ключ конечному пользователю на расшифрование или нет.
CDN приходится в любом случае доверять, ведь что будет раздаваться по вашей CDN ссылке, будет решать CDN, независимо от того имеется ли доступ к открытому тексту или нет. Но это касается и остальных сторонних сервисов.
Абсолютно согласен. Для «обычного» сайта использование CDN замедляет отдачу контента. У себя настроил всё что надо — статику пожал заранее gzip 9 level и btotli 11, включил в nginx TCP Fast Open и TLS 1.3 0-RTT (early_data), скрипты и стили собранные в два файла отдаются http/2 server push. А через CDN будет всё медленне тупо.
Блин, Вась, где ты раньше был? Я думал, что нужно смотреть на настройки кэширования, на распределенность аудитории, на нагрузку, утилизацию каналов и рентабельность расширения всего этого добра, тестировать, сравнивать с разными CDN из регионов где мало-мальски значимое количество пользователей сидят (+из региона где гендиректор отпуск проводит). А надо было тебе позвонить и ты бы сразу объяснил что «для обычного сайта через CDN будет всё медленне тупо». Слушай, Вась, а мой сайт на битриксе, он «обычный»?
То что ваш сайт на Битрикс это как-то влияет на то «обычный» он или нет? Странно как-то это подчёркивание.
Ну да ладно — у меня тоже на Битриксе сайт — и он «обычный». Хорошо — давайте расшифрую что в моём понимании «обычный» — «небольшая» посещаемость, от 75% аудитории расположено в том же регионе / городе где сейчас сервер (как правило это Москва).
Ну да ладно — у меня тоже на Битриксе сайт — и он «обычный». Хорошо — давайте расшифрую что в моём понимании «обычный» — «небольшая» посещаемость, от 75% аудитории расположено в том же регионе / городе где сейчас сервер (как правило это Москва).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
[Не] используйте CDN