🥇Как пробихме Великия Китайски Firewall (ч.3)

Здравейте!
Всяка добра история има своя край. И нашата история за това как разработихме решението за бързо преминаване през Китайската стена не е изключение. Затова бързам да споделя с вас последната, завършваща част по тази тема.

В предишната част разказахме за многото тестови стендове, които създадохме, и какви резултати постигнахме. И стигнахме до заключението, че е добре да добавим CDN! за да увеличим свързаността в нашата схема.

Ще ви разкажа как тестваме Alibaba Cloud CDN, Tencent Cloud CDN и Akamai, и на какво в крайна сметка се спираме. И, разбира се, ще обобщим.

Alibaba Cloud CDN

Ние хостим в 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 сървърите), остава само да създадете CNAME за звездичка, сочещ към all.semrushchina.cn.w.kunluncan.com (този CNAME беше получен в конзолата на Alibaba Cloud), и CDN ще заработи.

Според резултатите от тестовете, този CDN ни помогна много. Статистиката е представена по-долу.

Решение
Время безотказной работы
Медиана
75 Перцентил
95 Перцентил

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 от различни региони, включително региони вътре в Китай и отвън. Продуктът сега е в вътрешна бета версия и трябва да се създаде тикет с искане за достъп до него. От поддръжката научихме, че на глобалните акаунти (не става дума за граждани на Китай и юридически лица) не им е позволено да участват в програмата за бета тестване и изобщо да свързват регион вътре в Китай с регион отвън. 1-0 в полза на Ali Cloud

IPSEC

Най-южният регион на Tencent — Гуанджоу. Създадохме тунел и го свързахме с региона Хонконг в GCP (тогава този регион вече беше достъпен). Също така стартирахме едновременно втори тунел в Ali Cloud от Шенжен към Хонконг. Оказа се, че през мрежата на Tencent латентността до Хонконг е по-добра (10ms), отколкото от Шенжен до Хонконг в Ali (120ms — какво?). Но това не ускори работата на сайта, предназначен за работа с Tencent и този тунел, което само по себе си беше удивителен факт и още веднъж доказваше следното: латентността — за Китай не е показател, на който наистина си заслужава да се обръща внимание при разработването на решение за преминаване през китайския firewall.

Anycast Internet Acceleration

Още един продукт, който позволява работа през Anycast IP — AIA. Но той също не е достъпен за глобалните акаунти, затова няма да говоря за него, но да знаеш, че такъв продукт съществува, може да е полезно.

Но тестът на CDN показа доста интересни резултати. CDN на Tencent не може да се включи за целия сайт, само за конкретни домейни. Създадохме домейни и пуснахме трафик на тях:

Оказа се, че този CDN има такава функция: Оптимизация трансграничного трафика. Тази функция трябва да намали разходите при преминаване на трафика през китайската защитна стена. Като Origin бе посочен IP адрес на гугловия GLB (GLB anycast). По този начин искахме да опростим архитектурата на проекта.

Резултатите бяха много добри — на ниво Ali Cloud CDN, а на места дори и по-добри. Това е удивително, защото при успешни тестове можем да се откажем от значителна част от инфраструктурата, тунелите, CEN, виртуалките и т.н.

Не се радвахме дълго, защото се появи проблем: тестовете в Catchpoint не успяха за интернет-доставчика China Mobile. От всякакви локации получавахме таймаут през CDN на Tencent. Комуникацията с техническата поддръжка не доведе до нищо. Около 24 часа се опитвахме да разрешим този проблем, но нищо не стана.

Бях в момента в Китай, но не успях да намеря публичен 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 оптимизира маршрутите, за да трафикът да протича по-бързо за нашия сайт и да е видимо, че активирането на тази функция действително оказва силно влияние върху скоростта на работа на сайта.
Версионирането на конфигурацията в уеб интерфейса е страхотно. Можете да направите сравнение за версиите и да видите diff. Можете да прегледате предишните версии.
Можете да разпространите новата версия първо само на Staging мрежата на Akamai - същата мрежа като продукционната, просто този път не засяга реалните потребители. За този тест трябва да направите спуфинг на DNS записите на локалната машина.
Много бърза скорост на зареждане през тяхната мрежа за голяма статична информация, и вероятно всякакви други файлове. Файлът от 'студения' кеш се зарежда значително по-бързо отколкото същият файл от 'студения' кеш на Ali CDN. От 'горещия' кеш скоростта вече е плюс-минус еднаква.

Ali CDN тест:

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 тест:

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 опита; всички метрики, освен Uptime, в ms; статистика за един времеви интервал):

CDN Provider
Медиана
75%
95%
Response
Webpage Response
Время безотказной работы
DNS
Свържете се
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км. Интересното беше, че латентността между тези градове е с 100ms по-висока, отколкото в нашия първоначален вариант (до Тайван). Скоростта и стабилността също бяха по-добри за Тайван. В крайна сметка оставихме HK като резервен IPSEC регион.

Освен това, опитахме да изградим такава инсталация:

терминиране на клиенти в Пекин,
IPSEC и CEN до Токио,
в Ali CDN се указваше в качеството на origin сървър в Пекин.

Тази схема не беше толкова стабилна, въпреки че по скорост общо не отстъпваше на нашето решение. Що се отнася до тунела, видях периодични спадове дори за CEN, който трябваше да бъде стабилен. Затова се върнахме на старата схема и раз拆им този стейджинг.

По-долу е представена статистика за латентността между различни региони по различни канали. Може би, някому ще бъде интересна.

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 мегабита/с съответно.
- Скоростта до сървъри извън China е просто мизерна, по-малко от 1 мегабит/с.
Интернет в Китай не е много стабилен.
- Понякога сайтовете могат да се отварят бързо, понякога бавно (в едно и също време на денонощието в различни дни), при условие, че конфигурацията не се променя. Ние наблюдавахме това на примера на semrushchina.cn. Може да се отдаде на Ali CDN, който също работи ту така, ту сяк в зависимост от времето на деня, положението на звездите и т.н.
Мобилният интернет практически навсякъде е 4G или 4G+. Има покритие в метрото, асансьорите — накратко, навсякъде.
Това, че китайските потребители вярват само на домейни в зона .cn — мит. Ние проверихме това непосредствено с потребителите.
- Може да се види как http://baidu.cn пренасочва на www.baidu.com (в континентален Китай също).
Много ресурси действително са блокирани. Примитивно: google.com, Facebook, Twitter. Но много ресурсите на Google работят (разбира се, не на всички Wi-Fi и VPN в това не се използва (на страната на рутера също, това е сигурно).
Много "технически" домейни на блокирани корпорации също работят. Това означава, че не всегда трябва на сляпо да премахвате всички гуглови и други изглеждащи блокирани ресурси. Трябва да се потърси за някакъв списък на забранени домейни.
Имаме само три основни интернет оператора: China Unicom, China Telecom, China Mobile. Има и по-малки, но техният дял на пазара е незначителен.

Бонус: крайна схема за решение

Резюме

Измина година от старта на проекта. Започнахме с това, че нашият сайт изобщо не работеше нормално от Китай, а просто GET curl-ът отнемаше 5.5 секунди.

След това, от такива показатели при първото решение (Cloudflare):

Решение
Время безотказной работы
Медиана
75 Перцентил
95 Перцентил

Cloudflare
86.6
18s
30s
60s

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

Решение
Время безотказной работы
Медиана
75 Перцентил
95 Перцентил

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

Както се вижда, достигането на 100% аптайм за момента не беше възможно, но ще измислим нещо, а след това ще ви разкажем за резултатите в нова статия :)

На онзи, който прочете всичките три части до края — респект. Надявам се, че това ви беше толкова интересно, колкото и на мен, когато го правех.