Paano namin nalampasan ang Great Firewall ng China (Bahagi 3)
Привет!
Любые хорошие истории заканчиваются. И наша история про то, как мы придумывали решение быстрого прохода Китайского Фаервола, не исключение. Поэтому спешу поделиться с вами последней, завершающей частью sa paksang ito.
В предыдущей части было рассказано про множество тестовых стендов, придуманных нами, и какие результаты они дали. И мы остановились на том, что неплохо было бы добавить CDN! для вязкости в нашу схему.
Я расскажу вам, как мы тестировали Alibaba Cloud CDN, Tencent Cloud CDN и Akamai, и на чем в итоге остановились. Ну и конечно, подведем итог.
Alibaba Cloud CDN
Мы хостимcя в Alibaba Cloud, используем IPSEC и CEN от них же. Логично будет сначала попробовать их решения.
У Alibaba Cloud есть два вида продукта, которые могут нам подойти: CDN и DCDN. Первый вариант представляет собой классический CDN на конкретный домен (поддомен). Второй вариант расшифровывается как Dynamic na Ruta para sa CDN (я его зову динамический CDN), его можно включать в режиме Full-site (для wildcard доменов), он также кэширует статику и акселерирует на себе динамический контент, то есть динамика страницы также будет грузиться через быстрые сети провайдера. Это для нас важно, потому что в основном у нас сайт динамический, в нем используется множество поддоменов, и удобнее настроить CDN один раз для “звездочки” — *.semrushchina.cn.
Мы уже видели этот продукт на более ранних этапах нашего китайского проекта, но тогда он еще не работал, и разработчики обещали, что вот-вот продукт станет доступен для всех клиентов. И он стал.
В DCDN можно:
настроить терминирование SSL со своим сертификатом,
включить акселерацию динамического контента,
гибко настроить кэширование статических файлов,
делать кэшу purge,
прокидывать вэб-сокеты,
включить сжатие и даже HTML Beautifier.
В общем, все как у взрослых и больших CDN-провайдеров.
После того, как Origin (то место, куда пойдут CDN edge servers) указан, далее остается создать CNAME для звездочки, ссылающийся на all.semrushchina.cn.w.kunluncan.com (данный CNAME был получен в консоли Alibaba Cloud), и CDN заработает.
По результатам тестов, данный CDN нам очень помог. Статистика приведена ниже.
Это очень хорошие результаты, тем более, если их сравнить с тем, какие цифры были вначале. Но мы знали, что браузерный тест американской версии нашего сайта www.semrush.com отрабатывает из США в среднем за 8.3s (очень приближенное значение). Есть куда стремиться. Тем более, были еще CDN-провайдеры, которых интересно было потестить.
Так мы плавно переходим к еще одному гиганту на китайском рынке — Tencent.
Tencent Cloud
Tencent свое облако только развивает — это видно по небольшому количеству продуктов. В ходе его использования, мы хотели протестировать не только их CDN, но и в целом сетевую инфраструктуру:
есть ли у них что-то похожее на CEN?
как у них работает IPSEC? Быстро ли, какой uptime?
есть ли у них Anycast?
Разберем эти вопросы по отдельности.
Аналог CEN
У Tencent есть продукт Cloud Connect Network (CCN), позволяющий соединять между собой VPC из разных регионов, в том числе регионы внутри Китая и снаружи. Продукт сейчас во внутренней beta, и нужно создавать тикет с просьбой подключиться к ней. От саппорта мы узнали, что global-аккаунтам (речь не о гражданах Китая и не юридических лицах) нельзя участвовать в программе beta тестирования и в целом соединить регион внутри Китая с регионом снаружи. 1-0 в пользу Ali Cloud
IPSEC
Самый южный регион у Tencent — Гуаньчжоу. Мы собрали туннель и соединили его с регионом Гонконг в GCP (тогда этот регион уже стал доступен). Также подняли одновременно второй туннель в Ali Cloud из Шеньчженя в Гонконг. Оказалось, что через сеть Tencent latency до Гонконга в целом лучше (10ms), чем из Шеньчженя в Гонконг в Ali (120ms — what?). Но это никак не ускоряло работу сайта, направленного на работу через Tencent и этот туннель, что само по себе было удивительным фактом и еще раз доказывало следующее: latency — для Китая это не показатель, на который реально стоит обращать внимание в ходе разработки решения прохождения китайского фаервола.
Anycast Internet Acceleration
Еще один продукт, позволяющий работать через anycast IP — AIA. Но он также недоступен глобальным аккаунтам, поэтому о нем не расскажу, но знать, что такой продукт есть, может быть полезно.
А вот тест CDN показал довольно интересные результаты. CDN у Tencent нельзя включить на full-site, только на конкретные домены. Мы завели домены и пустили на них трафик:
Оказалось, что данный CDN имеет такую функцию: Cross Border Traffic Optimization. Данная фича должна снижать издержки при прохождении трафика через китайский фаервол. В качестве Pinagmulan был указан IP адрес гуглового GLB (GLB anycast). Таким образом мы хотели упростить архитектуру проекта.
Результаты были очень хорошими — на уровне Ali Cloud CDN, а местами даже и лучше. Это удивительно, потому что в случае успеха тестов, можно отказаться от весомой части инфраструктуры, туннелей, CEN, виртуалок и тд.
Радовались недолго, так как вскрылась проблема: тесты в Catchpoint фейлились для интернет-провайдера China Mobile. Из любых локаций мы получали таймаут через CDN Tencent’а. Переписка с технической поддержкой ни к чему не привела. Около суток мы пытались решить эту проблему, но ничего так и не вышло.
Я находился в тот момент в Китае, но не смог найти публичный Wi-Fi в сети этого провайдера, чтобы убедиться в проблеме лично. В остальном все выглядело быстро и хорошо.
Однако, из-за того, что оператор China Mobile входит в тройку самых крупных операторов, мы были вынуждены вернуть трафик на Ali CDN.
Но в целом это было довольно интересным решением, которое заслуживает более долгого тестирования и траблшутинга данной проблемы.
Akamai
Последний CDN-провайдер, который мы тестировали — это Akamai. Это огромный провайдер, который имеет свою сеть в Китае. Конечно, мы не смогли пройти мимо него.
С самого начала мы договорились с Akamai о тестовом периоде, чтобы мы могли переключить домен и посмотреть, как он будет работать на их сети. Результат всего тестирования я опишу в виде “Что понравилось” и “Что не понравилось”, а также приведу результаты тестов.
Что понравилось:
Ребята из Akamai очень помогали во всех вопросах и сопровождали нас на всех этапах тестирования. Постоянно пытались улучшить что-то на своей стороне. Давали неплохие технические советы.
Akamai работает примерно на 10-15% медленнее нашего решения через Ali Cloud CDN. Впечатляет то, что в Origin для Akamai мы указывали IP-адрес GLB, то есть трафик шел не через наше решение (потенциально можно отказаться от части инфраструктуры). Но все-таки результаты тестов показали, что этот вариант решения хуже нашего текущего варианта (сравнительные результаты ниже).
Тестировался как Origin GLB, так и Origin в Китае. Оба варианта примерно одинаковые.
Mayroon Sure Route (автоматическая оптимизация маршрутизации). Можно разместить у себя тестовый объект на Origin, и Edge сервера Akamai будут пробовать его забрать (обычный GET). Для этих запросов измеряется скорость и прочие метрики, на основе чего сеть Akamai оптимизирует маршруты, чтобы трафик шел быстрее для нашего сайта и было видно, что включение этой фичи действительно сильно сказывалось на скорости работы сайта.
Версионирование конфигурации в вэб-интерфейсе — это круто. Можно сделать Compare для версий, посмотреть diff. Посмотреть предыдущие версии.
Можно выкатывать новую версию сначала только на Staging сеть Akamai — такую же сеть как и production, только такой путь не аффектит реальных пользователей. Для этого теста нужно сделать спуфинг DNS-записей на локальной машине.
Очень быстрая скорость загрузки через их сеть большой статики, ну и, видимо, любых других файлов. Файл из “холодного” кэша забирается в разы быстрее, чем тот же файл из “холодного” кэша Ali CDN. Из “горячего” кэша скорость уже плюс-минус одинаковая.
Ali CDN test:
root@shenzhen1:~# curl -o /dev/null -w@curl_time https://en.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5757k 0 5757k 0 0 513k 0 --:--:-- 0:00:11 --:--:-- 526k
time_namelookup: 0.004286
time_connect: 0.030107
time_appconnect: 0.117525
time_pretransfer: 0.117606
time_redirect: 0.000000
time_starttransfer: 0.840348
----------
time_total: 11.208119
----------
size_download: 5895467 Bytes
speed_download: 525999.000B/s
Akamai test:
root@shenzhen1:~# curl -o /dev/null -w@curl_time https://www.semrushchina.cn/my_reports/build/scripts/simpleInit.js?v=1551879212
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 5757k 0 5757k 0 0 1824k 0 --:--:-- 0:00:03 --:--:-- 1825k
time_namelookup: 0.509005
time_connect: 0.528261
time_appconnect: 0.577235
time_pretransfer: 0.577324
time_redirect: 0.000000
time_starttransfer: 1.327013
----------
time_total: 3.154850
----------
size_download: 5895467 Bytes
speed_download: 1868699.000B/s
Мы заметили, что ситуация из примера выше зависит от разных факторов. На момент написания этого пункта я провел тест еще раз. Результаты для обеих платформ оказались примерно одинаковыми. Это говорит нам о том, что интернет в Китае даже для крупных операторов и облачных провайдеров ведет себя время от времени по-разному.
К предыдущему пункту добавлю большой плюс Akamai: если у Ali видны подобные всполохи высокой производительности и очень низкой (это касается и Ali CDN, и Ali CEN, и Ali IPSEC), то у Akamai каждый раз, как бы я не тестил их сеть, все работает стабильно.
Akamai действительно имеют большое покрытие в Китае и работают через многих провайдеров.
Ang hindi ko nagustuhan:
Не нравится веб-интерфейс и схема работы — такие нулевые. Но в принципе привыкаешь (наверное).
Результаты тестов хуже нашей площадки.
Ошибок при тестах больше, чем на нашей площадке (uptime ниже).
Нет своих DNS-серверов в Китае. Отсюда много ошибок в тестах из-за DNS resolve timeout.
Не предоставляют свои IP ranges -> нет возможности прописать корректные set_real_ip_from на наших серверах.
Метрики (~3626 runs; все метрики, кроме Uptime, в ms; статистика за один промежуток времени):
Nagbibigay ng CDN
panggitna
75%
95%
tugon
Webpage Response
Uptime
DNS
Ikabit
Maghintay
Load
SSL
Вывод такой: вариант с Akamai жизнеспособен, но не дает те же показатели стабильности и скорости, как наше собственное решение вкупе с Ali CDN.
Маленькие заметки
Некоторые моменты не вошли в повествование, но мне хотелось бы про них написать тоже.
Пекин + Токио и Гонконг
Как я уже говорил выше, мы тестировали IPSEC туннель до Гонконга (HK). Но также мы тестировали и CEN до HK. Он стоит немного дешевле, и было интересно, как он будет работать между городами с расстоянием ~100км. Интересным оказалось то, что latency между этими городами на 100ms выше, чем в нашем изначальном варианте (до Тайваня). Скорость, стабильность также была лучше для Тайваня. В итоге, мы оставили HK как бэкапный IPSEC регион.
Кроме того, мы пробовали поднимать такую инсталляцию:
терминирование клиентов в Пекине,
IPSEC и CEN до Токио,
в Ali CDN указывался в качестве origin сервер в Пекине.
Эта схема была не такой стабильной, хотя по скорости в целом не уступала нашему решению. Что касается туннеля, я видел периодические падения даже для CEN, который должен был быть стабильным. Поэтому мы вернулись на старую схему и разобрали этот стейджинг.
Ниже приведена статистика по latency между разными регионами по разным каналам. Может быть, кому-то она будет интересна.
IPsec
Ali cn-beijing <—> GCP asia-northeast1 — 193ms
Ali cn-shenzhen GCP asia-east2 — 91ms
Ali cn-shenzhen GCP us-east4 — 200ms
CEN
Ali cn-beijing <—> Ali ap-northeast-1 — 54ms (!)
Ali cn-shenzhen <—> Ali cn-hongkong — 6ms (!)
Ali cn-shenzhen <—> Ali us-east1 — 216ms
Общая информация про интернет в Китае
Как дополнение к проблемам с интернетом, описанным в самом начале, в первой части статьи.
Интернет в Китае работает довольно быстро внутри.
Вывод сделан на основе тестирования публичных сетей Wi-Fi в различных локациях, где данные сети используются большим количеством человек.
Скорость скачки и закачки на серверы внутри Китая была около 20 мбит/с и 5-10 мбит/с соответственно.
Скорость до серверов снаружи Китая просто мизерная, меньше 1 мбит/c.
Интернет в Китае не очень стабилен.
Иногда сайты могут открываться быстро, иногда медленно (в одно и то же время суток в разные дни), при условии, что конфигурация не меняется. Мы это наблюдали на примере semrushchina.cn. Это можно списать на Ali CDN, который тоже работает то так, то сяк в зависимости от времени суток, положения звезд и т.д.
Мобильный интернет практически везде 4G или 4G+. Ловит в метро, лифтах — короче, везде.
То, что китайские пользователи верят только доменам в зоне .cn — миф. Мы узнавали это непосредственно у пользователей.
Можно увидеть, как http://baidu.cn редиректит на www.baidu.com (в mainland China также).
Многие ресурсы действительно заблокированы. Примитивно: google.com, Facebook, Twitter. Но многие гугловые ресурсы работают (конечно, не на всех Wi-Fi и VPN при этом не используется (на стороне роутера тоже, это точно).
Многие “технические” домены заблокированных корпораций также работают. Это значит, что не всегда следует безрассудно выпиливать все подряд гугловые и прочие кажущиеся заблокированными ресурсы. Нужно поискать какой-то список запрещенных доменов.
У них всего три основных интернет-оператора: China Unicom, China Telecom, China Mobile. Есть еще помельче, но их доля на рынке несущественна
Бонус: итоговая схема решения
Kabuuan
Прошел год с момента старта проекта. Мы начали с того, что наш сайт вообще в принципе отказывался нормально работать из Китая, а просто GET curl’ом занимал 5.5 секунд.
Потом, с таких показателей при первом решении (Cloudflare):