🥇Как пробихме Великия китайски огън (ч.1)

Здравейте на всички!

На свързване е Никита — системен инженер от компанията SEMrush. Днес ще ви разкажа как пред нас възникна задачата да осигурим стабилността на нашия сервиз semrush.com в Китай и с какви проблеми се сблъскахме по време на изпълнението ѝ (като се има предвид местоположението на нашия дата-център на източното крайбрежие на САЩ).

Това ще бъде дълга история, разделена на няколко статии. Ще разкажа как всичко това се разви при нас: от Напълно нефункциониращ сервиз от Китай до показателите на работата на сервиза на ниво на американската му версия за американците. Обещавам, че ще бъде интересно и полезно. И така, да започваме.

Проблемите на китайския интернет

Дори и най-далечният от спецификата на мрежовото администриране поне веднъж е чувал за Великия китайски защитен стена. Ууу, звучи яко, нали? Но какво представлява, как наистина работи — въпросът е доста сложен. В интернет можете да намерите много статии, посветени на това, но от техническа гледна точка устройството на тази защитна стена никъде не е описано. Както и да е, не е изненада. Признавам, че в края на годината работа няма да мога да кажа точно как работи, но мога да споделя наблюденията и практически заключенията си. И ще започнем със слуховете за тази защитна стена.

Има много слухове относно именно тази защитна стена. Нека съберем основните и най-интересните от тях в един списък:

Google, Facebook, Twitter и други подобни услуги са блокирани и не работят в Китай.
Всеки трафик, който идва ЗА пределите на Китай и В Китай, се анализира и ограничава с помощта на машинно обучение (в случай на подозрителен трафик), което значително забавя него (трафика), преминаващ през границата.
Китайските служби за сигурност могат да разбият всякакъв криптиран трафик, минаващ през тяхната защитна стена.
VPN тунели, IPSEC тунели са нестабилни, падат и постоянно се блокират.
Колкото по-просто е криптирането, толкова по-проста е паролата, използвана за аутентификация/криптиране на трафика, толкова по-бързо минава тя през китайската защитна стена.

Ето какво успяхме да установим за тези слухове:

Google, Facebook, Twitter и други подобни услуги наистина са блокирани (вашето КО), но много технически домейни на Google, например, не са забранени и работят (като gstatic.com). Оттук следва извод: не бива безразсъдно да изключвате всички Google и други, които изглеждат блокирани, ресурси.
Всеки трафик, преминаващ границата, наистина добавя значително забавяне към времето си. Погледнете двата резултата. Един сайт, една страница, прост GET curl’ом. Първото измерване е от самия Китай (прекрасния град Шенжен). Второто измерване е извън Хонг Конг (има суверенитет и между него и света няма защитна стена). Разстоянието между двата града по права линия е около 30-40 км.

nikita@china-shenzhen:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  381k    0  381k    0     0  71824      0 --:--:--  0:00:05 --:--:-- 82832
time_namelookup:  0.004500
time_connect:  0.169342
time_appconnect:  0.723189
time_pretransfer:  0.723499
time_redirect:  0.000000
time_starttransfer:  1.532912
----------
time_total:  5.443407
----------
size_download:  390968 Bytes
speed_download:  71824.000B/s

nikita@china-hongkong:~# curl -o /dev/null -w@curl_time "https://www.semrush.com/info/ebay.com"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  319k    0  319k    0     0  2555k      0 --:--:-- --:--:-- --:--:-- 2573k
time_namelookup:  0.029366
time_connect:  0.030742
time_appconnect:  0.047310
time_pretransfer:  0.047388
time_redirect:  0.000000
time_starttransfer:  0.120793
----------
time_total:  0.124871
----------
size_download:  326755 Bytes
speed_download:  2616740.000B/s

Обърнете внимание на time_connect. И като цяло, виждате резултата: защитната стена добавя 4 излишни секунди, което е ужасно дълго.

VPN и IPSEC тунелите наистина често падат. За това ще говоря малко по-късно и по-подробно. VPN сървърите, които използват потребителите, с времето се блокират (обикновено в рамките на ден след започване на употреба).
Има мнение, получено от хора, живеещи в Китай, че колкото по-просто е криптирането на трафика, толкова по-бързо преминава през границата, защото е лесно да се разбере, че в него няма нищо незаконно. И точно така „чистият“ трафик получава повече пропускна способност и скорости на преминаване, а „мръсният“ трафик, в който не може да се разбере нищо, получава обратно по-бавно преминаване. За пример ще дам curl до ifconfig.co по протокол HTTPS и HTTP.

curl -o /dev/null -w@curl_time "https://ifconfig.co/"
  % Общо    % Получено % Xferd  Средна Скорост   Време    Време     Време  Текущо
                                 Dload  Upload   Общо   Прекарано    Останало  Скорост
100    13  100    13    0     0      2      0  0:00:06  0:00:05  0:00:01     3
time_namelookup:  0.004305
time_connect:  0.397465
time_appconnect:  5.149305
time_pretransfer:  5.149393
time_redirect:  0.000000
time_starttransfer:  5.568847
----------
time_total:  5.568893
----------
размер_изтегляне:  13 байта
скорост_изтегляне:  2.000B/s

curl -o /dev/null -w@curl_time "http://ifconfig.co/"
  % Общо    % Получено % Xferd  Средна Скорост   Време    Време     Време  Текущо
                                 Dload  Upload   Общо   Прекарано    Останало  Скорост
100    13  100    13    0     0     28      0 --:--:-- --:--:-- --:--:--    28
time_namelookup:  0.004282
time_connect:  0.212457
time_appconnect:  0.000000
time_pretransfer:  0.212484
time_redirect:  0.000000
time_starttransfer:  0.450565
----------
time_total:  0.450620
----------
размер_изтегляне:  13 байта
скорост_изтегляне:  28.000B/s

Разликата от 5 секунди в общото време за зареждане на 13 байта. При провеждане на такъв тест няколко пъти, можем да забележим, че GET на HTTP завършва по принцип за едно и също време всяки път, докато на HTTPS сайтът понякога отговаря за 3, 5, 10 и дори 17 секунди. Понякога се срещат грешки в SSL:

Неизвестна грешка в SSL протокола при свързване с ifconfig.co:443.

И така, какво имаме:

Проблемите, предизвикани от китайската защитна стена, описани по-горе.
Пинговете до външни ресурси и вътре в тунелите периодично отсъстват.
Забавянето между две точки постоянно варира и често е просто непредсказуемо. Свързвайки различни градове/региони, очакваш, че на база географското разположение на регионите, закъснението ще бъде по-малко, а получаваш точно обратната ситуация.
Интернет и комуникационните канали работят понякога бързо, понякога бавно. Има малка зависимост от времето на деня и деня от седмицата, но не винаги.
DNS запитванията към външния свят от Китай понякога надвишават допустимия таймаут.

Картината изглежда просто “отлична”.

Датацентърът, какъвто вече казах, е на изток в САЩ, а целият SEMrush се състои от десетки взаимосвързани продукти, бекенди, фронтенди, бази данни и всичко това в датацентрове и облаци. Пред нас, като екип от системни администратори, беше поставена задачата с малко усилия бързо да започнем работа в Китай.

Предстоеше ни да отговорим на важен въпрос: можем ли да се справим с малки усилия и да решим всички проблеми, свързани с китайския интернет и защитната стена, на ниво мрежа/облаци/сървъри?

Започнахме с получаването на ICP-лицензия.

ICP-лицензия

За да можем да хостваме услугата си в пределите на Китай (Mainland China) и да провеждаме тестове, първо трябва да получим ICP-лицензия за домейна.

Ако потребителският трафик на вашия сайт бъде терминиран в рамките на Mainland China и вашият домейн няма лицензия ICP, трафикът ви ще бъде блокиран от страната на доставчика/хостинга. Интересно е, че конкретен доставчик, било то Cloudflare или Alibaba Cloud, е вписан в лицензията ICP. Така че ако сте получили лицензия ICP за Cloudflare и сте хоствали своя сайт при тях, последващо „бесшовно“ мигриране на Alibaba Cloud няма да ви се получи. Ще трябва да добавите още един хостинг в тази лицензия.

Получавайки лицензия ICP за домена, успяхме да измислим и реализираме конкретни технически идеи и решения.

Тестване на решения

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

Нашият инструмент за тестване трябваше да отговаря на две основни изисквания:

той трябва да има възможност за стартиране на тестове от Китай,
той трябва да предлага браузерни тестове.

Така намерихме Catchpoint! Те имат отлично покритие с точки за тестване по целия свят. В Китай чрез този инструмент може да се стартират тестове също от 100500 провинции. Във всяка по няколко различни доставчици + възможност за правене на Backbone-тестове (нещо като виртуална машина в датацентъра) и Lastmile-тестове (максимално приближени до условията на потребителите, aka работна станция). Последният тип тестове струва повече.

Сключвайки годишен договор (по-малко не може), започнахме да изучаваме инструмента. Признавам, че бяхме приятно изненадани от функционалността му. Може да се стартират:

DNS тестове,
Web тестове (браузерни, прост GET/POST, емуляция на мобилен клиент и т.н.),
Транзакционни проверки (например, влизане),
API тестове,
Ping, traceroute, NTP и т.н.

Невъзможно е да се изброят всички. И най-важното, всеки тест може да бъде доста добре персонализиран, добавяйки куп заглавия и други параметри. В резултата получавате огромно количество информация, напълно описваща теста ви. Ако говорим за най-интензивното за нас (браузерни тестове), то резултатът включва:

Свързване, Изчакване, Зареждане, SSL, Време за DNS,
TTFB, TTLB, Завършен документ, Време за рендериране, Зареждане на DOM,
Отговор (нещо близо до Време до Първи Байт), Уеб страничен Отговор (нещо близо до Време до Последен Байт),
Всеки процентил, Средно, Медиано време
И т.н.

Съответно, всички тези метрики чудесно помагат за наблюдение на промените и разбиране дали е станало по-добре. Ние основно гледахме на Response, Webpage Response, Median, 75 и 95 Percentiles.

Важно питане, което виси във въздуха от самото начало: може ли да се вярва на Catchpoint? Отражает ли этот инструмент реальную скорость загрузки сайта в Китае из разных городов или же это просто какой-то тест в вакууме, не имеющий ничего общего с real user experience?
Това е голям проблем, защото, като си в Русия, е почти невъзможно да се разбере как работи сайт от Китай. Правейки socks-proxy през виртуална машина, на изхода получаваш зареждане на сайта за няколко минути, което е абсолютно неприемливо за тестове, затова единственият вариант за ръчно тестване остават curl и простите GET от конзолата със замерване на времето. Това помага, защото този тест добре отразява скоростта на мрежовото решение, а ако има и браузерни тестове, е още по-добре.

По-късно ние сами отидохме в Китай и се уверихме, че на Catchpoint може да се вярва, той доста точно отразява реалните показатели за скорост на работа.

Cloudflare China Network

Тъй като за основния домейн semrush.com успешно използваме Cloudflare, решихме веднага да опитаме тяхната функция, наречена China Network. Тази опция се активира само за Enterprise сайтове по отделна заявка и за отделна такса. Също така е налична само за сайтове, притежаващи съответстваща ICP лицензия, в която Cloudflare е посочен като доставчик. След активацията на опцията, за сайта става достъпен “китайски CDN” от Cloudflare — трафикът от китайските региони достига до най-близките PoP (Points of Presence) на CF, а след това по неговите мрежи или мрежите на доставчици/партньори се доставя до origin.

Схемата на този тестов стенд е представена по-долу.

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

Стартирахме браузерни тестове и ето какво се получи:

Червените ромбове — това са фейл тестове. Фейлите отдолу — DNS грешки (resolve timeout). Фейлите отгоре — таймаут.

Uptime: 86.6
Median: 18s
75 Percentile: 29.3s
95 Percentile: 60s

Медийната стойност, след като беше премахнато зареждането reCaptcha (услуга на Google, блокирана в Китай), спадна от 28 на 18 секунди. Но все пак това са ужасни показатели, ако се вземе предвид, че аналогичен тест за semrush.com (от САЩ) даваше под 10 секунди за 95% от потребителите (от САЩ) на същата страница (статика + динамика).

В всеки тест може да се влезе и да се види Waterfall и други по-подробни параметри. Започнахме да изследваме причините за грешките, и ако таймаутите са относително ясни: интернетът в Китай "то се свива, то се разширява", поради което скоростта на свързване и зареждане на ресурси от чужбина е нестабилна и променлива, то DNS грешките сериозно ни изненадаха. Установихме, че PoP в Cloudflare наистина се намират в Китай, адресът на сайта се резолвира в един anycast IP, но DNS сървърите са американски, поради което DNS запитванията трябва да преминат през границата, затова понякога те не успяват.

След уточняване на този въпрос с CF, се установи, че нямат собствени DNS сървъри в Китай, а кога ще имат — все още не се знае.

Поради това решихме да тестваме само DNS на Cloudflare и променихме механизма на работа на Cloudflare за нашия сайт на режим "Само DNS". Това е такъв режим, в който Cloudflare не проксира трафика през себе си, а следователно не предоставя защита от DDoS, CDN и други функции, и работи в режим на обикновен DNS сървър.

Този стенд е схематично представен на следващата рисунка. На рисунка са взети предвид новите познания, че DNS сървърите на Cloudflare са зад фаервола.

В Catchpoint стартирахме прости GET тестове (не браузърни), които показаха много неуспехи. Причината за тях бяха същите тези DNS грешки.

Започнахме да дебъгваме тези грешки с помощта на dig и установихме, че при първото запитване адресът се определя правилно, а при повторното запитване получаваме всеки път SERVFAIL и не е намерен. Какво става тук?

root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn има адрес 220.170.186.192
Хост semrushchina.cn не е намерен: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn има адрес 220.170.186.192
Хост semrushchina.cn не е намерен: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn има адрес 220.170.186.192
Хост semrushchina.cn не е намерен: 2(SERVFAIL)
root@iZwz97n2wgbp61qucbfrjsZ:~# host semrushchina.cn
semrushchina.cn има адрес 220.170.186.192
Хост semrushchina.cn не е намерен: 2(SERVFAIL)

При запитване на NS сървърите на Cloudflare директно няма такива грешки:

root@iZwz97n2wgbp61qucbfrjsZ:~# for i in `seq 1 2`; do host semrushchina.cn ray.ns.cloudflare.com.; done
Използвайки домейн сървър:
Име: ray.ns.cloudflare.com.
Адрес: 173.245.59.138#53
Псевдоними: 

semrushchina.cn има адрес 220.170.186.192
semrushchina.cn има адрес 220.170.186.192
Използвайки домейн сървър:
Име: ray.ns.cloudflare.com.
Адрес: 173.245.59.138#53
Псевдоними: 

semrushchina.cn има адрес 220.170.186.192
semrushchina.cn има адрес 220.170.186.192

Следователно проблемът е на страната на "локалния" DNS сървър или сървъра на доставчика.
Допълнителното разследване показа, че SERVFAIL получаваме на резолва AAAA-записи.

Оказа се, че при запитване на Cloudflare АААА-запис, която не съществува в домейна, Cloudflare отговори И-запис, който е грешка и несъответствие на RFC. Поради това локалният резолвер (x.x.x.x) не можеше да я приеме и отговори SERVFAIL. В лог файла по-долу това поведение е ясно видимо:

root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @x.x.x.x

; <> DiG 9.10.3-P4-Ubuntu <> -t AAAA semrushchina.cn @x.x.x.x
;; глобални опции: +cmd
;; Получен отговор:
;; ->>HEADER<<- opcode: QUERY, статус: SERVFAIL, id: 55467
;; флагове: qr rd ra; QUERY: 1, ОТГОВОР: 0, АВТОРИТЕТ: 0, ДОПЪЛНИТЕЛНИ: 1

;; OPT PSEUDOSECTION:
; EDNS: версия: 0, флагове:; udp: 4096
;; ВЪПРОС ЗА СЕКЦИЯ:
;semrushchina.cn.               IN      AAAA

;; ВРЕМЕ ЗА ЗАПИТВАНЕ: 334 мс
;; СЪРВЪР: x.x.x.x#53(x.x.x.x)
;; КОГА: Вт Авг 14 23:38:50 CST 2018
;; РАЗМЕР НА СЪОБЩЕНИЕТО, получено: 44

root@iZwz97n2wgbp61qucbfrjsZ:~# dig -t AAAA semrushchina.cn @dana.ns.cloudflare.com.

; <> DiG 9.10.3-P4-Ubuntu <> -t AAAA semrushchina.cn @dana.ns.cloudflare.com.
;; глобални опции: +cmd
;; Получен отговор:
;; ->>HEADER<<- opcode: QUERY, статус: NOERROR, id: 63944
;; флагове: qr aa rd; QUERY: 1, ОТГОВОР: 1, АВТОРИТЕТ: 0, ДОПЪЛНИТЕЛНИ: 1
;; ВНИМАНИЕ: рекурсията е искана, но не е налична

;; OPT PSEUDOSECTION:
; EDNS: версия: 0, флагове:; udp: 512
;; ВЪПРОС ЗА СЕКЦИЯ:
;semrushchina.cn.               IN      AAAA

;; СЕКЦИЯ ЗА ОТГОВОР:
semrushchina.cn.        300     IN      A       220.170.186.192

;; ВРЕМЕ ЗА ЗАПИТВАНЕ: 185 мс
;; СЪРВЪР: 173.245.58.105#53(173.245.58.105)
;; КОГА: Вт Авг 14 23:43:03 CST 2018
;; РАЗМЕР НА СЪОБЩЕНИЕТО, получено: 60

Изпратихме доклад за грешка на Cloudflare и те го поправиха след известно време. Оказа се интересно: към момента в Китай все още няма поддръжка за IPv6, затова Cloudflare не можеше да предостави IPv6 адрес в отговора на запитването АААА-записи. В крайна сметка всичко се реши по такъв начин, че за Китай Cloudflare започна да отговаря NODATA на такива запитвания.

По този начин, DNS грешките в тестовете Catchpoint рязко намаляха, но не напълно. Таймаутите също не изчезнаха:

И започнахме да търсим друго решение.

В следващата част ще разкажа как тествахме китайското облако Alibaba Cloud, как с помощта на малко „магия“ Nginx успяхме бързо да създадем PoC (Proof of Concept) решения, как създавахме Multi-Cloud решения, едно от които в крайна сметка много помогна за ускоряване работата на услугата от Китай.

Следите за новостями!