🥇Как пробихме Великия Китайски Фаервол (ч.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 ни помогна значително. Статистиката е представена по-долу.

Решение
Uptime
Медии
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.3 секунди (много приблизителна стойност). Има къде да се стремим. Още повече, имаше и 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 и този тунел, което само по себе си беше удивителен факт и отново доказваше следното: латентност — за Китай това не е показател, на който реално трябва да се обърне внимание при разработване на решение за преминаване през китайския фаервол.

Anycast Internet Acceleration

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

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

Оказа се, че този CDN има такава функция: Оптимизация на трансграничния трафик. Тази функция трябва да намали разходите при преминаване на трафика през китайския фаервол. Като Произход беше посочен 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    % Получено % Xferd  Средна Скорост   Време    Време     Време  Текущо
                                 Dload  Upload   Общо   Изразходвано  Оставащо  Скорост
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    % Получено % Xferd  Средна Скорост   Време    Време     Време  Текущо
                                 Dload  Upload   Общо   Изразходвано  Оставащо  Скорост
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.
Не предоставят свои IP диапазони -> няма възможност да бъдат зададени коректно set_real_ip_from на нашите сървъри.

Метрики (~3626 изпълнения; всички метрики, с изключение на Uptime, в ms; статистика за един времеви интервал):

CDN доставчик
Медии
75%
95%
Отговор
Отговор на уеб страницата
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

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

Бонус: окончателна схема на решението

Резюме

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

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

Решение
Uptime
Медии
75 Перцентил
95 Перцентил

Cloudflare
86.6
18s
30s
60s

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

Решение
Uptime
Медии
75 Перцентил
95 Перцентил

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

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

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