Comments 11
Во всех этих CDN бесит то, что приходится в NoScript постоянно указывать очередной поддомен, которые постоянно меняются.
Делаем или первое или второе — снижаем нагрузку на канал, а так же чутка на CPU (NGINX же должен принимать решение, что отдавать из кеша). И живём дальше пока не упрёмся в ресурсы опять.
Но раз Вы не способны понять: для чего, для кого и в каких целях нужен CDN — может быть не стоило такой глупый комментарий оставлять?
обычно вордпресс без плагинов, изображений около секунды грузится.
если это диви какой нибудь — то и 1.5
Вы слишком критичны в своем комментарии. Возможно, внедрение CDN и не изменит картину координально, однако, все же может вносить ощутимый профит. Существует достаточно много проектов с тяжелыми ассетами и порой сервер, находящийся в твоей стране гораздо быстрее сможет отдать его вам, вместо того, чтобы тянуть из другого конца света.
Берем тестовый сайт на Вордпрессе, о котором никто кроме нас не знает.
А теперь берем проект, на котором чуть больше, чем 1 пользователь. И каждая загрузка страницы влечет за собой с десяток обращений веб-сервера к файловой системе (без учета браузерного кеша). Когда таких запросов становится 100/1000/10000rps, то не так уже и весело тратить на ресурсы сервера на отдачу статического контента.
Да, оптимизация одного часто используемого SQL запроса может привнести куда заметнее эффект, но и CDN никто не отменяет. Особенно там, где пользователи регионально разбросаны.
На заре Рунета, в самом начале 2000-х, жители Южно-Сахалинска или Петропавловска-Камчатского могли дожидаться полной загрузки простой веб-страницы полновесные 5, а то и все 10, минут.
У вас это личный опыт или фантазии на тему? Может быть дело было в плохой древней АТС и модеме на 14400? Или тощих магистральных каналах через спутник, потому что кабелей ещё не завезли? По моему опыту в конце 90-х американские сайты вполне себе быстро загружались на европейской части этой страны и на тощем модемном соединении.
IP-пакетам по большей части всё равно, на какие расстояния они будут передаваться, планета у нас не такая большая. Задержки в основном набираются в очередях маршрутизаторов, и чем их количество меньше, тем быстрее пакеты доезжают.
При передаче больших файлов задержка передачи IP-пакетов HTTP-запроса практически исчезает на фоне времени передачи всего файла, которая напрямую коррелирует только с быстродействием файловой системы сервера и толщиной самого узкого канала на пути к клиенту. При больших нагрузках на промежуточные маршрутизаторы и каналы пакеты могут отбрасываться (сейчас можно считать, что у нас практически идеальные каналы и в них нет ошибок передачи) и тогда добавится время на TCP-таймауты и перепосылку IP-пакетов.
Поэтому не стоит приплетать взаимное географическое расположение CDN-серверов и клиентов. CDN-это всего лишь один из видов горизонтального шардинга дисковых и сетевых ресурсов с минимизацией хопов до клиента. Перенос файлов в географическом пространстве нужен не для уменьшения временных задержек из-за конечной скорости света в оптоволокне, а уменьшения количества хопов и нагрузки на магистральные каналы с распределением удельной нагрузки на диски серверов.
IP-пакетам по большей части всё равно, на какие расстояния они будут передаваться, планета у нас не такая большая. Задержки в основном набираются в очередях маршрутизаторов, и чем их количество меньше, тем быстрее пакеты доезжают.
не могу с вами согласиться.
смотрю в гугле расстояние до NY, делю на скорость света в оптоволокне, умножаю на два — получаю идеальный RTT 80мс. пингую — получаю 120мс.
до москвы получаю идеальный RTT 7мс, реальный — 13мс.
нужно учесть, что реальная длина оптоволокна заметно больше, чем расстояние от точки до точки по прямой, так что основной вклад в RTT вносят «временные задержки из-за конечной скорости света в оптоволокне», а не маршрутизаторы (конечно, бывают и исключения, спорить глупо).
При передаче больших файлов
CDN — это не только многогигабайтные файлы, картинки на сайте или фоточки в условном инстаграмме на телефоне вполне могут тянуться с CDN. установка https-соединения при RTT 100мс уже вносит вполне ощутимую задержку.
P.S. работу CDN осложняет то, что «географически близко» ещё не гарантирует малых задержек. трафик между провайдерами в нашем городе бегает через Москву, а раньше, помнится, зачастую и через европу бегал.
А уж если говорить о стриминговом медиаконтенте, на который так упирают в статье, то ему эти задержки передачи по кабелю вообще не ощутимы из-за предварительной буферизации контента в плеерах.
PS. Работу сайтов осложняет в основном слабо технически обученные генераторы контента, которые вместо 50 кБайт картинки заливают её оригинал на пару-тройку метров ;) Если я глазами вижу, как картинка загружается, то это именно такой клинический случай. Из-за больших дисков и толстых каналов многим стало наплевать, что у них на сайте за контент и какого он там размера. Ну а мода на длинные бэкграунды да с видео помогает CDN-провайдерам успешно зарабатывать.
ИМХО, хорошая общая обзорная статья. Хотелось бы попросить дополнительно осветить темы:
потоковый CDN
синхронизация (в итоге, я понимаю) содержимого между оригинальным сервером и точками распространения
Считаю это важными темами, т.к. размеры нашей страны требуют CDN даже внутри страны (т.е. их придётся создавать самим, руками. Мы же, вроде как, программисты?..). Спасибо!
Что такое CDN и как это работает?