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

Привіт!
Будь-які добрі історії закінчуються. І наша історія про те, як ми вигадували рішення швидкого проходу Китайського Фаєрвола, не є винятком. Тому поспішаю поділитися з вами останньою, завершальною частиною на цю тему.

У попередній частині було розказано безліч тестових стендів, придуманих нами, і які результати вони дали. І ми зупинилися на тому, що непогано було б додати CDN! для в'язкості до нашої схеми.

Я розповім вам, як ми тестували Alibaba Cloud CDN, Tencent Cloud CDN та Akamai, і на чому зупинилися. Ну і звичайно, підіб'ємо підсумок.

Хмарний CDN Alibaba

Ми хостимся в Alibaba Cloud, використовуємо IPSEC і CEN від них. Логічно спочатку спробуватиме їх вирішення.

Alibaba Cloud має два види продукту, які можуть нам підійти: CDN и DCDN. Перший варіант є класичний CDN на конкретний домен (піддомен). Другий варіант розшифровується як Динамічний маршрут для 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
Медіана
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

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. Ця фіча повинна знижувати витрати під час проходження трафіку через китайський фаєрвол. В якості Походження була вказана 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 видно подібні сполохи високої продуктивності і дуже низькою (це стосується і CDN, і Ali CEN, і Ali IPSEC), то у Akamai щоразу, як би я не тестував їх мережу, все працює стабільно.
Akamai дійсно мають велике покриття у Китаї та працюють через багатьох провайдерів.

Що не сподобалося:

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

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

Провайдер CDN
Медіана
75%
95%
відповідь
Webpage Response
Uptime
DNS
З'єднуватися
Почекай
Навантаження
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):

Процентний
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
Медіана
75 Percentile
95 Percentile

Cloudflare
86.6
18s
30s
60s

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

Рішення
Uptime
Медіана
75 Percentile
95 Percentile

Ali CDN + CEN / IPsec + GLB
99.86
8.8s
9.5s
13.7s

Як видно, аптайму в 100% добитися поки що не вдалося, але ми щось придумаємо, а потім розповімо вам про результати в новій статті:)

Тому, хто дочитав до кінця всі три частини, — респект. Сподіваюся, вам це було так само цікаво, як і мені, коли я це робив.

PS Попередні частини

Частина 1
Частина 2

Джерело: habr.com