Как пробихме Великата китайска защитна стена (част 3)

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

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

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

Alibaba Cloud CDN

Ние сме хоствани на Alibaba Cloud и използваме IPSEC и CEN от тях. Би било логично първо да опитате техните решения.

Alibaba Cloud има два вида продукти, които може да са ни подходящи: CDN и DCDN. Първият вариант е класически CDN за определен домейн (поддомейн). Вторият вариант означава Динамичен маршрут за CDN (Наричам го динамичен CDN), може да се активира в режим на пълен сайт (за домейни с заместващи символи), също така кешира статично съдържание и ускорява динамичното съдържание върху себе си, тоест динамиката на страницата също ще се зарежда през доставчика бързи мрежи. Това е важно за нас, защото по принцип нашият сайт е динамичен, използва много поддомейни и е по-удобно да настроите CDN веднъж за „звездичката“ - *.semrushchina.cn.

Вече бяхме виждали този продукт в по-ранните етапи на нашия китайски проект, но тогава той все още не работеше и разработчиците обещаха, че продуктът скоро ще стане достъпен за всички клиенти. И той го направи.

В DCDN можете да:

• конфигурирайте прекратяването на SSL с вашия сертификат,
• позволяват ускоряване на динамично съдържание,
• гъвкаво конфигуриране на кеширане на статични файлове,
• изчистете кеша,
• напред уеб сокети,
• активирайте компресията и дори HTML Beautifier.

Като цяло всичко е същото като при възрастни и големи CDN доставчици.

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

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

• имат ли нещо подобно на CEN?
• Как работи IPSEC за тях? Бързо ли е, какъв е времето за работа?
• имат ли Anycast?

Нека разгледаме тези въпроси поотделно.

Аналогов CEN

Tencent има продукт Мрежа за свързване на облак (CCN), което ви позволява да свързвате VPC от различни региони, включително региони в и извън Китай. Продуктът вече е във вътрешна бета версия и трябва да създадете билет с молба за свързване с него. От поддръжката научихме, че глобалните акаунти (не говорим за китайски граждани или юридически лица) не могат да участват в програмата за бета тестване и като цяло да свързват регион в Китай с регион извън него. 1-0 в полза на Али Клауд

IPsec

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

Anycast Интернет ускорение

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

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

Оказа се, че този CDN има следната функция: Оптимизация на трансграничния трафик. Тази функция трябва да намали разходите, когато трафикът преминава през китайската защитна стена. Като Произход Беше посочен IP адресът на Google 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 в Китай. И двата варианта са приблизително еднакви.
• Има Сигурен маршрут (автоматична оптимизация на маршрутизиране). Можете да хоствате тестов обект в Origin и сървърите на Akamai Edge ще се опитат да го вземат (обикновен GET). За тези заявки се измерва скоростта и други показатели, въз основа на които мрежата на Akamai оптимизира маршрутите, така че трафикът да върви по-бързо за нашия сайт и беше ясно, че активирането на тази функция наистина има силно въздействие върху скоростта на сайта.
• Версионирането на конфигурацията в уеб интерфейса е страхотно. Можете да направите Сравнение за версии, погледнете разл. Вижте предишни версии.
• Можете да пуснете нова версия първо само в мрежата на Akamai Staging - същата мрежа като производствената, само че по този начин няма да засегне реалните потребители. За този тест трябва да подправите 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 наистина има голямо покритие в Китай и работи чрез много доставчици.

Какво не ми хареса:

• Не харесвам уеб интерфейса и начина, по който работи - толкова е лош. Но по принцип се свиква с него (вероятно).
• Резултатите от теста са по-лоши от нашия сайт.
• По време на тестовете има повече грешки, отколкото на нашия сайт (време за работа по-долу).
• Ние нямаме собствени DNS сървъри в Китай. Следователно има много грешки в тестовете, дължащи се на таймаут за разрешаване на DNS.
• Те не предоставят своите IP диапазони -> няма начин да регистрирате правилните set_real_ip_from на нашите сървъри.

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

CDN доставчик
Медиана
75%
95%
Отговор
Отговор на уеб страница
Uptime
DNS
Свържете
Чакам
Натоварване
SSL

AliCDN
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
AliCDN

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 сървърът в Пекин беше посочен като източник.

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

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

IPsec
Али cn-beijing <—> GCP азия-североизток1 — 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 Mbit/s и 5-10 Mbit/s.
  • Скоростта до сървъри извън Китай е просто мизерна, под 1 Mbit/s.
• Интернет в Китай не е много стабилен.
  • Понякога сайтовете могат да се отварят бързо, понякога бавно (по едно и също време на деня в различни дни), при условие че конфигурацията не се променя. Наблюдавахме това с примера на 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% ъптайм, но ще измислим нещо и след това ще ви разкажем за резултатите в нова статия :)

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

PS Предишни части

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

Източник: www.habr.com