CDN — не только для кеширования (jvns.ca) 16 мая 2016
Джулия Эванс рассказывает, как CDN приносят пользу помимо выполнения своей основной задачи — кеширования.
Предположим, что у нас есть сервер в Нью-Йорке, на котором лежит статический джаваскрипт-файл, который скачивают все посетители сайта. Если на сайт вдруг зайдет пользователь из Сиднея, то этот файл будет загружаться довольно долго. Между Нью-Йорком и Сиднеем 16 тысяч километров, свет проходит это расстояние за 50 мс, путь туда-обратно занимает 100 мс. С учетом возможных потерь пакетов время загрузки будет еще больше. Проблему можно решить, поставив второй сервер в Сиднее, чтобы сиднейцы могли скачать файл быстрее. Это и есть CDN. Но оказывается, что CDN помогает не только этим.
Ускорение TLS-хендшейка. Если на нашем сайте используется HTTPS, то каждый пользователь должен будет установить защищенное соединение с сервером перед тем, как начнется передача данных. Для этого клиенту и серверу потребуется обменяться 7 пакетами, то есть в случае с Сиднеем и Нью-Йорком процесс займет как минимум 350 мс. Но если у сервера в Сиднее есть наш SSL-сертификат, соединение можно установить между клиентом и этим сервером, что будет гораздо быстрее. А соединение между серверами будет установлено заранее, и тратить 350 мс не потребуется.
Умная маршрутизация. В обычном случае данные пойдут по такому пути: пользователь в Сиднее → общий интернет → сервер в Нью-Йорке. С CDN возможен другой вариант: пользователь в Сиднее → общий интернет → сервер в Сиднее → волшебная сеть CDN → сервер в Нью-Йорке. В волшебной сети можно использовать какие-то оптимизации, которые позволят передать данные быстрее по сравнению с общей сетью.
Защита от DDoS. CDN может выявлять вредные запросы и не пропускать их на основной сервер.
Безопасность. При использовании CDN часть ответственности за безопасность ложится на тех, кто предоставляет сервис. С одной стороны, в случае появления новой уязвимости вроде Heartbleed команда безопасности CDN может моментально всё запатчить. С другой стороны, может быть и наоборот. Например, Amazon ELB запатчили от Heartbleed только через сутки, и с этим ничего нельзя было сделать. Так что тут всё неоднозначно.
У CDN есть и недостатки, из-за которых сайт может стать менее надежным. Во-первых, это сложность настройки. Можно где-то ошибиться при конфигурировании либо передавать неправильные заголовки Cache-Control, и все пользователи сайта начнут получать какие-то не те данные. Во-вторых, вероятность падения CDN. Сайт будет лежать не только тогда, когда у него проблемы, но и когда есть проблемы на стороне сервиса CDN.