Како го пробивме Големиот кинески заштитен ѕид (Дел 3)

Здраво!
На сите добри приказни им доаѓа крајот. И нашата приказна за тоа како дојдовме до решение за брзо поминување на кинескиот заштитен ѕид не е исклучок. Затоа, побрзам да го споделам со вас последното, завршниот дел на оваа тема.

Во претходниот дел зборувавме за многу тест клупи до кои дојдовме и какви резултати дадоа. И се решивме за тоа што би било убаво да додадеме ЦДН! за вискозност во нашата шема.

Ќе ви кажам како ги тестиравме 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), останува само да се создаде 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

ЦЕН
99.75
16s
21s
27s

CEN/IPsec + GLB
99.79
13s
16s
25s

Али CDN + CEN/IPsec + GLB
99.75
10s
12.8s
17.3s

Ова се многу добри резултати, особено ако ги споредите со тоа какви беа бројките на почетокот. Но, знаевме дека тестот на прелистувачот на американската верзија на нашата веб-страница www.semrush.com работи од САД во просек од 8.3 секунди (многу приближна вредност). Има простор за подобрување. Покрај тоа, имаше и CDN провајдери кои беа интересни за тестирање.

Така, непречено преминуваме на друг гигант на кинескиот пазар - Tencent.

Облак на Тенсент

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

• дали имаат нешто слично на CEN?
• Како функционира IPSEC за нив? Дали е брз, колку е времето на работа?
• дали имаат Anycast?

Ајде да ги разгледаме овие прашања одделно.

Аналоген CEN

Tencent има производ Cloud Connect Network (CCN), овозможувајќи ви да поврзете VPC од различни региони, вклучително и региони внатре и надвор од Кина. Производот сега е во внатрешна бета верзија и треба да креирате билет со барање да се поврзете со него. Од поддршката дознавме дека глобалните сметки (не зборуваме за кинески граѓани или правни лица) не можат да учествуваат во програмата за бета тестирање и, генерално, да поврзат регион во Кина со регион надвор. 1-0 во корист на Али Облак

IPSEC

Најјужниот регион на Тенсент е Гуангжу. Составивме тунел и го поврзавме со регионот на Хонг Конг во GCP (тогаш овој регион веќе беше достапен). Во исто време беше подигнат и вториот тунел во Али Облак од Шенжен до Хонг Конг. Се покажа дека преку мрежата Tencent латентноста до Хонг Конг е генерално подобра (10 ms) отколку од Шенжен до Хонг Конг до Али (120 ms - што?). Но, ова на никаков начин не ја забрза работата на страницата насочена кон работа низ 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.
Но, генерално, ова беше прилично интересно решение кое заслужува подолго тестирање и решавање проблеми на овој проблем.

Акамаи

Последниот CDN провајдер што го тестиравме беше Акамаи. Ова е огромен провајдер кој има своја мрежа во Кина. Се разбира, не можевме да го поминеме.

Од самиот почеток се договоривме со Akamai за пробен период за да можеме да го префрлиме доменот и да видиме како ќе функционира на нивната мрежа. Ќе го опишам резултатот од сите тестирања во форма на „Што ми се допадна“ и „Што не ми се допадна“, а ќе ги дадам и резултатите од тестот.

Што ни се допадна:

• Момците од Акамаи беа многу корисни во сите прашања и не придружуваа во сите фази од тестирањето. Постојано се обидувавме да подобриме нешто на наша страна. Дадоа добри технички совети.
• Akamai е околу 10-15% побавен од нашето решение преку Ali Cloud CDN. Она што е импресивно е дека во Origin за Akamai ја наведовме IP адресата на GLB, што значи дека сообраќајот не поминува низ нашето решение (потенцијално би можеле да напуштиме дел од инфраструктурата). Но, сепак, резултатите од тестот покажаа дека ова решение е полошо од нашата сегашна верзија (компаративни резултати подолу).
• Тестирани и Origin GLB и Origin во Кина. И двете опции се приближно исти.
• Постои Сигурен пат (автоматска оптимизација на рутирање). Можете да хостирате тест објект на Origin, а серверите на Akamai Edge ќе се обидат да го подигнат (обичен GET). За овие барања се мерат брзината и другите метрики, врз основа на кои мрежата Akamai ги оптимизира маршрутите за сообраќајот да оди побрзо за нашата страница и беше јасно дека овозможувањето на оваа функција навистина имаше силно влијание врз брзината на страницата.
• Верзијата на конфигурацијата во веб-интерфејсот е одлична. Можете да направите Споредба за верзии, погледнете ги различностите. Погледнете ги претходните верзии.
• Најпрво можете да пласирате нова верзија само на мрежата Akamai Staging - истата мрежа како и производството, само на овој начин нема да влијае на вистинските корисници. За овој тест, треба да ги измамите записите на DNS на вашата локална машина.
• Многу брза брзина на преземање преку нивната мрежа за големи статични датотеки и, очигледно, какви било други датотеки. Датотеката од „ладниот“ кеш се презема многу пати побрзо од истата датотека од „ладната“ кеш на Ali CDN. Од „жешката“ кеш, брзината е веќе иста, плус или минус.

Али 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

Акамаи тест:

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 има многу покриеност во Кина и работи преку многу провајдери.

Што не ми се допадна:

• Не ми се допаѓа веб-интерфејсот и начинот на кој функционира - толку е лош. Но, во основа се навикнуваш на тоа (веројатно).
• Резултатите од тестот се полоши од нашата страница.
• Има повеќе грешки за време на тестовите отколку на нашата страница (време на работа подолу).
• Ние немаме сопствени DNS сервери во Кина. Оттука, има многу грешки во тестовите поради истекот на времето за решавање на DNS.
• Тие не ги обезбедуваат нивните опсези на IP -> не постои начин да се регистрираат точните set_real_ip_from на нашите сервери.

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

ЦДН провајдер
Средна
75%
95%
Одговор
Одговор на веб-страница
Uptime
DNS
Поврзете се
Почекајте
Товар
SSL

AliCDN
9195
10749
17489
1,715
10,745
99.531
57
17
927
479
200

Акамаи
9783
11887
19888
2,352
11,550
98.980
424
91
1408
381
50

Дистрибуција по проценти (во ms):

Процент
Акамаи
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 тунел до Хонг Конг (Хонг Конг). Но, ние исто така тестиравме CEN на HK. Малку помалку чини, а јас се прашував како ќе функционира помеѓу градови со растојание од ~100 км. Се покажа дека е интересно што доцнењето помеѓу овие градови е 100 ms повисока отколку во нашата оригинална верзија (до Тајван). Брзината, стабилноста беа подобри и за Тајван. Како резултат на тоа, го напуштивме HK како резервен регион IPSEC.

Дополнително, се обидовме да ја инсталираме следната инсталација:

• престанок на клиенти во Пекинг,
• IPSEC и CEN до Токио,
• во Ali CDN серверот во Пекинг беше наведен како потекло.

Оваа шема не беше толку стабилна, иако во однос на брзината генерално не беше инфериорна во однос на нашето решение. Во врска со тунелот, видов периодични падови дури и за CEN, кој требаше да биде стабилен. Затоа, се вративме на старата шема и ја демонтиравме оваа постановка.

Подолу се дадени статистички податоци за доцнењето помеѓу различни региони за различни канали. Можеби некој ќе биде заинтересиран за тоа.

IPsec
Али cn-пекинг <—> GCP азија-североисток1 — 193ms
Али цн-Шенжен <—> GCP asia-east2 — 91ms
Али cn-Шенжен <—> GCP us-east4 — 200ms

ЦЕН
Али цн-пекинг <—> Али ап-североисток-1 — 54 ms (!)
Али цн-Шенжен <—> Али цн-хонгконг — 6 ms (!)
Али цн-Шенжен <—> Али ус-исток1 — 216 ​​ms

Општи информации за интернетот во Кина

Како додаток на проблемите со Интернет опишани на самиот почеток, во првиот дел од статијата.

• Интернетот во Кина е доста брз внатре.
  • Заклучокот е направен врз основа на тестирање на јавните Wi-Fi мрежи на различни локации каде што овие мрежи ги користат голем број луѓе.
  • Брзините на преземање и испраќање на серверите во Кина беа околу 20 Mbit/s и 5-10 Mbit/s, соодветно.
  • Брзината на серверите надвор од Кина е едноставно слаба, помала од 1 Mbit/s.
• Интернетот во Кина не е многу стабилен.
  • Понекогаш сајтовите може да се отворат брзо, понекогаш бавно (во исто време од денот во различни денови), под услов конфигурацијата да не се промени. Ова го забележавме со примерот на семрушчина.цн. Ова може да се припише на Али ЦДН, кој исто така функционира вака и онака во зависност од времето од денот, положбата на ѕвездите итн.
• Мобилниот интернет е речиси насекаде 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 Процентил

Али CDN + CEN/IPsec + GLB
99.86
8.8s
9.5s
13.7s

Како што можете да видите, сè уште не успеавме да постигнеме 100% uptime, но ќе смислиме нешто, а потоа ќе ви кажеме за резултатите во нова статија :)

Почит до оние кои ги прочитаа сите три дела до крај. Се надевам дека сето ова ви беше интересно како и јас кога го правев.

PS Претходни делови

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

Извор: www.habr.com