company_banner

Как мы пробивали Великий Китайский Фаервол (ч.3)

    Привет!
    Любые хорошие истории заканчиваются. И наша история про то, как мы придумывали решение быстрого прохода Китайского Фаервола, не исключение. Поэтому спешу поделиться с вами последней, завершающей частью на эту тему.


    В предыдущей части было рассказано про множество тестовых стендов, придуманных нами, и какие результаты они дали. И мы остановились на том, что неплохо было бы добавить CDN! для вязкости в нашу схему.


    Я расскажу вам, как мы тестировали Alibaba Cloud CDN, Tencent Cloud CDN и Akamai, и на чем в итоге остановились. Ну и конечно, подведем итог.



    Alibaba Cloud CDN


    Мы хостимcя в Alibaba Cloud, используем IPSEC и CEN от них же. Логично будет сначала попробовать их решения.


    У Alibaba Cloud есть два вида продукта, которые могут нам подойти: CDN и DCDN. Первый вариант представляет собой классический CDN на конкретный домен (поддомен). Второй вариант расшифровывается как Dynamic Route for 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 нам очень помог. Статистика приведена ниже.


    Решение Uptime Median 75 Percentile 95 Percentile
    Cloudflare 86.6 18s 30s 60s
    IPsec 99.79 18s 21s 30s
    CEN 99.75 16s 21s 27s
    CEN/IPsec + GLB 99.79 13s 16s 25s
    Ali CDN + CEN/IPsec + GLB 99.75 10s 12.8s 17.3s

    Это очень хорошие результаты, тем более, если их сравнить с тем, какие цифры были вначале. Но мы знали, что браузерный тест американской версии нашего сайта 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. Данная фича должна снижать издержки при прохождении трафика через китайский фаервол. В качестве Origin был указан 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 в Китае. Оба варианта примерно одинаковые.
    • Есть 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 действительно имеют большое покрытие в Китае и работают через многих провайдеров.


    Что не понравилось:


    • Не нравится веб-интерфейс и схема работы — такие нулевые. Но в принципе привыкаешь (наверное).
    • Результаты тестов хуже нашей площадки.
    • Ошибок при тестах больше, чем на нашей площадке (uptime ниже).
    • Нет своих DNS-серверов в Китае. Отсюда много ошибок в тестах из-за DNS resolve timeout.
    • Не предоставляют свои IP ranges -> нет возможности прописать корректные set_real_ip_from на наших серверах.

    Метрики (~3626 runs; все метрики, кроме Uptime, в ms; статистика за один промежуток времени):


    CDN Provider Median 75% 95% Response Webpage Response Uptime DNS Connect Wait Load SSL
    Ali CDN 9195 10749 17489 1,715 10,745 99.531 57 17 927 479 200
    Akamai 9783 11887 19888 2,352 11,550 98.980 424 91 1408 381 50

    Распределение по Percentile (в ms):


    Percentile Akamai Ali CDN
    10 7,092 6,942
    20 7,775 7,583
    30 8,446 8,092
    40 9,146 8,596
    50 9,783 9,195
    60 10,497 9,770
    70 11,371 10,383
    80 12,670 11,255
    90 15,882 13,165
    100 91,592 91,596

    Вывод такой: вариант с 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. Есть еще помельче, но их доля на рынке несущественна

    Бонус: итоговая схема решения



    Итог


    Прошел год с момента старта проекта. Мы начали с того, что наш сайт вообще в принципе отказывался нормально работать из Китая, а просто GET curl’ом занимал 5.5 секунд.


    Потом, с таких показателей при первом решении (Cloudflare):


    Решение Uptime Median 75 Percentile 95 Percentile
    Cloudflare 86.6 18s 30s 60s

    Мы в итоге дошли до таких результатов (статистика за последний месяц):


    Решение Uptime Median 75 Percentile 95 Percentile
    Ali CDN + CEN/IPsec + GLB 99.86 8.8s 9.5s 13.7s

    Как видно, аптайма в 100% добиться пока что не удалось, но мы что-нибудь придумаем, а потом расскажем вам о результатах в новой статье:)


    Тому, кто дочитал до конца все три части — респект. Надеюсь, вам все это было так же интересно, как и мне, когда я это делал.


    P.S. Предыдущие части


    Часть 1
    Часть 2

    SEMrush
    177,54
    Компания
    Поделиться публикацией

    Комментарии 3

      +1

      Спасибо что поделились ценным опытом, с интересом прочитал все три статьи, т.к. есть планы на работе по продвижению продукта в Китай.

        0
        Скажите, получается что часть, которая переходит через Китайский Фаервол, полностью настраивается и принадлежит Ali Cloud?
          0
          Ну, если очень упрощать, то да. IPSEC как сервис, CEN как сервис

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое