ProHoster > Blog > Administrim > Si si kishte bërë që të kalonim Murin e Madh të Kinës (pjesa 3)

Si si kishte bërë që të kalonim Murin e Madh të Kinës (pjesa 3)

đŸ„‡Si tĂ« arrish nĂ« qiell dhe tĂ« bĂ«hesh pilot | ProHoster
Çdo histori e mirĂ« ka njĂ« pĂ«rfundim. Dhe historia jonĂ« pĂ«r mĂ«nyrĂ«n se si gjetĂ«m njĂ« zgjidhje pĂ«r kalimin e shpejtĂ« tĂ« Murit tĂ« KinĂ«s nuk Ă«shtĂ« pĂ«rjashtim. Prandaj, po shpejtoj tĂ« ndaj me ju pjesĂ«n pĂ«rfundimtare, pjesa pĂ«rfundimtare nĂ« lidhje me kĂ«tĂ« temĂ«.

Në pjesën e mëparshme u tregua për shumë ambiente testi që ne i menduam dhe për rezultatet që ato sollën. Dhe we stopuam te ideja se do ishte mirë të shtonim CDN! për kohezion në skemën tonë.

Do t'ju tregoj si testuam Alibaba Cloud CDN, Tencent Cloud CDN dhe Akamai, dhe mbi çfarë rezultati u ndalëm. Natyrisht, do të bëjmë një përmbledhje.

Si si kishte bërë që të kalonim Murin e Madh të Kinës (pjesa 3)

Alibaba Cloud CDN

Ne jemi hostuar në Alibaba Cloud, përdorim IPSEC dhe CEN nga ata. Ka kuptim që së pari të provojmë zgjidhjet e tyre.

Alibaba Cloud ka dy lloje produktesh qĂ« mund tĂ« na pĂ«rshtaten: CDN dhe DCDN. Opsioni i parĂ« Ă«shtĂ« njĂ« CDN klasik pĂ«r njĂ« domain tĂ« caktuar (nĂ« subdomain). Opsioni i dytĂ« shpĂ«rndahet si Dynamic Route for CDN (unĂ« e quaj CDN dinamik), mund tĂ« aktivizohet nĂ« modalitetin Full-site (pĂ«r domain-e wildcard), gjithashtu ndihmon nĂ« ruajtjen e statikĂ«s dhe pĂ«rshpejton ngarkimin e pĂ«rmbajtjes dinamike, domethĂ«nĂ« dinamika e faqes gjithashtu do tĂ« ngarkohet pĂ«rmes rrjeteve tĂ« shpejta tĂ« ofruesit. Kjo Ă«shtĂ« e rĂ«ndĂ«sishme pĂ«r ne, sepse kryesisht kemi njĂ« faqe dinamike, me shumĂ« subdomains, dhe mĂ« mirĂ« Ă«shtĂ« tĂ« konfigurojmĂ« CDN njĂ« herĂ« pĂ«r “yllin” — *.semrushchina.cn.

Ne tashmë e kishim parë këtë produkt në fazat e hershme të projektit tonë në Kinë, por atëherë ai nuk funksiononte ende, dhe zhvilluesit kishin premtuar se shumë shpejt produkti do të bëhet i disponueshëm për të gjithë klientët. Dhe ai u bë.

Në DCDN mund të:

  • konfigurosh terminimin SSL me certifikatin tĂ«nd,
  • aktivizosh pĂ«rshpejtimin e pĂ«rmbajtjes dinamike,
  • konfigurosh ndjeshĂ«m ruajtjen e skedave statike,
  • tĂ« realizosh purge tĂ« caches,
  • tĂ« kalosh web-sockets,
  • tĂ« aktivizosh kompresimin dhe madje edhe HTML Beautifier.

Në përgjithësi, gjithçka është si te ofruesit e mëdhenj dhe të rritur CDN.

Pas caktimit të Origin (vendit ku do të shkojnë serverët edge të CDN), mbetet të krijosh një CNAME për yllin, i cili i referohet all.semrushchina.cn.w.kunluncan.com (ky CNAME u mor në konsolën e Alibaba Cloud), dhe CDN do të fillojë të funksionojë.

Sipas rezultateve të testimeve, ky CDN na ndihmoi shumë. Statistikat e paraqitura më poshtë.

Zgjidhja
Uptime
Median
75 Percentile
95 Percentile

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

Këto janë rezultate shumë të mira, sidomos kur i krahasojmë me numrat që kishim në fillim. Por e dinim që testi i shfletuesit për versionin amerikan të faqes sonë www.semrush.com është realizuar në SHBA mesatarisht për 8.3s (një vlerë shumë e afërt). Ka ende për të arritur. Për më tepër, kishte edhe ofrues CDN që ishin interesante për t'u testuar.

KĂ«shtu kalojmĂ« nĂ« njĂ« gjigand tjetĂ«r nĂ« tregun kinez — Tencent.

Tencent Cloud

Tencent po e zhvillon ende cloud-in e tij — kjo duket nga numri i vogĂ«l i produkteve. GjatĂ« pĂ«rdorimit tĂ« tij, ne donim tĂ« testonim jo vetĂ«m CDN-in e tyre, por edhe nĂ« pĂ«rgjithĂ«si infrastrukturĂ«n rrjetĂ«sore:

  • a kanĂ« ndonjĂ« gjĂ« tĂ« ngjashme me CEN?
  • si funksionon IPSEC tek ata? A Ă«shtĂ« i shpejtĂ«, çfarĂ« uptime-i ka?
  • a kanĂ« Anycast?

Si si kishte bërë që të kalonim Murin e Madh të Kinës (pjesa 3)

Të shqyrtojmë këto çështje një për një.

E ngjashme me CEN

Tencent ka një produkt Cloud Connect Network (CCN), i cili lejon lidhjen e VPC-ve nga rajone të ndryshme, përfshirë rajonet brenda dhe jashtë Kinës. Produkti tani është në beta të brendshme, dhe duhet të krijoni një tiket për t'u lidhur me të. Nga mbështetje, mësuam se llogaritë globale (nuk flasim për qytetarët kinezë apo persona juridikë) nuk mund të marrin pjesë në programin e beta testimit dhe në përgjithësi të lidhin një rajon brenda Kinës me një rajon jashtë. 1-0 në favor të Ali Cloud

IPSEC

Rajoni mĂ« jugor te Tencent — Guangzhou. Ne ndĂ«rtuam njĂ« tunel dhe e lidhĂ«m atĂ« me rajonin e Hong Kongut nĂ« GCP (atĂ«herĂ« ky rajon ishte tashmĂ« i aksesueshĂ«m). Gjithashtu ngritĂ«m njĂ« tunel tĂ« dytĂ« nĂ« Ali Cloud nga Shenzhen nĂ« Hong Kong. Doli se latenca pĂ«rmes rrjetit Tencent ishte mĂ« e mirĂ« pĂ«r nĂ« Hong Kong (10ms), sesa nga Shenzhen nĂ« Hong Kong nĂ« Ali (120ms — çfarĂ«?). Por kjo nuk e pĂ«rshpejtonte punĂ«n e faqes, e cila ishte orientuar pĂ«r tĂ« punuar pĂ«rmes Tencent dhe kĂ«tij tuneli, qĂ« vetĂ« ishte njĂ« fakt pĂ«rcaktues dhe provonte sĂ«rish se: latenca — pĂ«r KinĂ«n nuk Ă«shtĂ« njĂ« tregues qĂ« vlen tĂ« merret parasysh gjatĂ« zhvillimit tĂ« zgjidhjeve pĂ«r kalimin e firewall-it kinez.

Anycast Internet Acceleration

NjĂ« produkt tjetĂ«r qĂ« lejon punĂ«n pĂ«rmes IP-ve anycast — AIA. Por ai gjithashtu nuk Ă«shtĂ« i aksesueshĂ«m pĂ«r llogaritĂ« globale, prandaj nuk do ta pĂ«rshkruaj, por tĂ« dish se njĂ« produkt i tillĂ« ekziston mund tĂ« jetĂ« i dobishĂ«m.

Të dhënat nga testi CDN treguan rezultate mjaft interesante. CDN-i te Tencent nuk mund të aktivizohet për faqen e plotë, vetëm për domain specifik. Ne regjistruam domainet dhe lejuam trafikun mbi to:

Si si kishte bërë që të kalonim Murin e Madh të Kinës (pjesa 3)

Doli se ky CDN ka këtë funksion: Optimizimi i Trafikut Ndërkufitar. Ky funksion duhet të ulë kostot kur trafiku kalon përmes firewall-it të Kinës. Si Origjina u caktua adresa IP e GLB të Google (GLB anycast). Kështu ne do të thjeshtojmë arkitekturën e projektit.

Rezultatet ishin shumĂ« tĂ« mira — nĂ« nivelin e Ali Cloud CDN, dhe ndonjĂ«herĂ« edhe mĂ« mirĂ«. Kjo Ă«shtĂ« befasuese, sepse nĂ« rastin e suksesit tĂ« testeve, mund tĂ« heqim dorĂ« nga njĂ« pjesĂ« e konsiderueshme e infrastrukturĂ«s, tuneleve, CEN, mahnive virtuale etj.

Nuk qëndruam gjatë në gëzim, pasi doli në pah një problem: testet në Catchpoint dështuan për operatorin e Internetit China Mobile. Nga çdo vendndodhje merrnim kohëzgjatje përmes CDN të Tencent-it. Korrespondenca me mbështetje teknike nuk shpuri në asgjë. Rreth një ditë përpiqeshim të zgjidhnim këtë problem, por asgjë nuk arritëm.

Isha në atë moment në Kinë, por nuk arrita të gjeja Wi-Fi publik në rrjetin e këtij operatori, për të verifikuar problemin personalisht. Përndryshe, gjithçka dukej e shpejtë dhe mirë.
Megjithatë, për shkak se operatori China Mobile është një nga tre operatorët më të mëdhenj, u detyruam të rikthejmë trafikun në Ali CDN.
Por në përgjithësi, ishte një zgjidhje mjaft interesante, e cila meriton më shumë testime dhe troubleshooting të këtij problemi.

Akamai

CDN i fundit që testuam ishte Akamai. Ky është një ofrues i madh, i cili ka rrjetin e tij në Kinë. Sigurisht, nuk mundëm të kalojmë përtej tij.

Si si kishte bërë që të kalonim Murin e Madh të Kinës (pjesa 3)

QĂ« nga fillimi, u dakorduam me Akamai pĂ«r njĂ« periudhĂ« testimi, kĂ«shtu qĂ« mund tĂ« kalojmĂ« domenin dhe tĂ« shikojmĂ« se si do tĂ« funksionojĂ« nĂ« rrjetin e tyre. Do tĂ« pĂ«rshkruaj rezultatet e gjithĂ« testimeve nĂ« formĂ«n e “ÇfarĂ« na pĂ«lqeu” dhe “ÇfarĂ« nuk na pĂ«lqeu”, si dhe do tĂ« jap rezultatet e testeve.

ÇfarĂ« na pĂ«lqeu:

  • DjemtĂ« nga Akamai na ndihmuan shumĂ« me tĂ« gjitha çështjet dhe na shoqĂ«ruan nĂ« tĂ« gjitha fazat e testimit. Po mundoheshin vazhdimisht tĂ« pĂ«rmirĂ«sonin disa gjĂ«ra nga ana e tyre. Jepte kĂ«shilla tĂ« mira teknike.
  • Akamai punon rreth 10-15% mĂ« ngadalĂ« se zgjidhja jonĂ« pĂ«rmes Ali Cloud CDN. E habitshme Ă«shtĂ« se nĂ« OrigjinĂ« pĂ«r Akamai caktuam adresĂ«n IP tĂ« GLB, qĂ« do tĂ« thotĂ« trafiku nuk shkonte pĂ«rmes zgjidhjes sonĂ« (potencialisht mund tĂ« heqim dorĂ« nga njĂ« pjesĂ« e infrastrukturĂ«s). Por megjithatĂ« rezultatet e testeve treguan se kjo zgjidhje ishte mĂ« e keqe se opsioni ynĂ« aktual (rezultatet krahasuese mĂ« poshtĂ«).
  • Iu testua si OrigjinĂ« GLB, ashtu edhe OrigjinĂ« nĂ« KinĂ«. TĂ« dyja opsionet ishin mĂ« ose pak tĂ« njĂ«jta.
  • Ka Ruga e SigurtĂ« (optimizimi automatik i routingut). Mund tĂ« vendosni njĂ« objekt testues nĂ« Origin, dhe serverĂ«t Edge tĂ« Akamai do tĂ« pĂ«rpiqen ta marrin atĂ« (GET i zakonshĂ«m). PĂ«r kĂ«to kĂ«rkesa matet shpejtĂ«sia dhe metrika tĂ« tjera, nĂ« bazĂ« tĂ« tĂ« cilave rrjeti Akamai optimizon rrugĂ«t, qĂ« trafik tĂ« kalojĂ« mĂ« shpejt pĂ«r faqen tonĂ« dhe tĂ« duket se aktivizimi i kĂ«saj karakteristike vĂ«rtet ka ndikuar ndjeshĂ«m nĂ« shpejtĂ«sinĂ« e punĂ«s sĂ« faqes.
  • Versionimi i konfigurimit nĂ« ndĂ«rfaqen e uebit – Ă«shtĂ« fantastike. Mund tĂ« bĂ«ni Krahasoni pĂ«r versionet, tĂ« shihni diferencat. Shihni versionet e kaluara.
  • Mund tĂ« shĂ«rbehet njĂ« version i ri fillimisht vetĂ«m nĂ« rrjetin Staging tĂ« Akamai – njĂ« rrjet tĂ« njĂ«jtĂ« si prokurimi, vetĂ«m qĂ« kjo rrugĂ« nuk ndikon te pĂ«rdoruesit e vĂ«rtetĂ«. PĂ«r kĂ«tĂ« test duhet tĂ« bĂ«ni spufing tĂ« regjistrave DNS nĂ« makinĂ«n lokale.
  • ShpejtĂ«si shumĂ« e shpejtĂ« ngarkimi pĂ«rmes rrjetit tĂ« tyre tĂ« statikĂ«s sĂ« madhe, dhe, duket, çdo skedari tjetĂ«r. NjĂ« skedar nga "cache e ftohtĂ«" merret me shumĂ« shpejtĂ«si mĂ« shumĂ« se po tĂ« ishte po ai skedar nga "cache e ftohtĂ«" i Ali CDN. Nga "cache e ngrohtĂ«", shpejtĂ«sia tashmĂ« Ă«shtĂ« mĂ« shumĂ«-mĂ« pak e njĂ«jtĂ«.

Testi 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

Testi 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

Kemi vënë re se situata në shembullin e mësipërm varet nga faktorë të ndryshëm. Në momentin kur e shkruaj këtë pikë, kam bërë një test tjetër. Rezultatet për të dy platformat dolën rreth të njëjtave. Kjo na thotë se interneti në Kinë, madje edhe për operatorët e mëdhenj dhe ofruesit e cloud, vepron herë pas here ndryshe.

Përsa i përket pikës paraprake, do të shtoja një avantazh të madh për Akamai: nëse në Ali shihen shpërthime të tilla të performancës së lartë dhe shumë të ulët (kjo vlen si për Ali CDN, ashtu edhe për Ali CEN dhe Ali IPSEC), për Akamai çdo herë, sa herë që testeve rrjetin e tyre, gjithçka funksionon stabilisht.
Akamai në të vërtetë ka një mbulim të madh në Kinë dhe punon përmes shumë ofruesve.

ÇfarĂ« nuk mĂ« pĂ«lqeu:

  • Nuk mĂ« pĂ«lqen ndĂ«rfaqja e internetit dhe skema e punĂ«s — janĂ« tĂ« tilla tĂ« dobĂ«ta. Por nĂ« parim, e merr me mend (ndoshta).
  • Rezultatet e testeve janĂ« mĂ« tĂ« kĂ«qija se platforma jonĂ«.
  • Gabimet gjatĂ« testeve janĂ« mĂ« tĂ« shumta se nĂ« platformĂ«n tonĂ« (uptime mĂ« i ulĂ«t).
  • Nuk ka serverĂ« DNS tĂ« tyre nĂ« KinĂ«. Nga kjo, ka shumĂ« gabime nĂ« teste pĂ«r shkak tĂ« DNS resolve timeout.
  • Nuk ofrojnĂ« gama tĂ« tyre tĂ« IP-ve -> nuk ka mundĂ«si pĂ«r tĂ« shkruar korrektisht set_real_ip_from nĂ« serverĂ«t tanĂ«.

Metrikat (~3626 të pastra; të gjitha metrikat, përveç Uptime, në ms; statistika për një interval kohor):

Ofruesi i CDN
Median
75%
95%
PĂ«rgjigjja
PĂ«rgjigjja e Webfaqes
Uptime
DNS
Lidhja
Pritja
Ngarko
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

Shpërndarja sipas Percentile (në 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

Përfundimi është se varianti me Akamai është i aftë për jetesë, por nuk ofron ato të njëjtat tregues të stabilitetit dhe shpejtësisë si zgjidhja jonë vetë së bashku me Ali CDN.

Shënime të vogla

Disa momente nuk u përfshinë në narracion, por do të doja të shkruaja gjithashtu për to.

Pekin + Tokio dhe Hong Kong

Siç kam thënë më lart, ne testuam tunelin IPSEC deri në Hong Kong (HK). Por gjithashtu e testuam edhe CEN deri në HK. Ai kushton pak më lirë, dhe ishte interesante se si do të funksiononte mes qyteteve me një distancë ~100km. E veçanta ishte se latenca mes këtyre qyteteve ishte 100ms më e lartë se në variantin tonë origjinal (deri në Tajvan). Shpejtësia, stabiliteti gjithashtu ishin më të mira për Tajvanin. Si përfundim, ne e lanë HK si një rajon backup IPSEC.

Për më tepër, provuam të ngrinim një instalim të tillë:

  • terminimi i klientĂ«ve nĂ« Pekin,
  • IPSEC dhe CEN deri nĂ« Tokio,
  • nĂ« Ali CDN u shĂ«nua si server origjinal nĂ« Pekin.

Kjo skemë nuk ishte kaq e qëndrueshme, megjithatë, në përgjithësi nuk iu dorëzua zgjidhjes sonë. Sa i përket tunelit, kam parë rënie periodike edhe për CEN-in, i cili duhej të ishte stabil. Prandaj u kthyem në skemën e vjetër dhe e shqyrtuam këtë staging.

Më poshtë është statistika mbi latencën midis rajoneve të ndryshme për kanale të ndryshme. Ndoshta do t'i interesojë dikujt.

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

Informacion e përgjithshme rreth internetit në Kinë

Si një shtesë për problemet me internetin, të përshkruara në fillim, në pjesën e parë të artikullit.

  • Internet nĂ« KinĂ« funksionon mjaft shpejt brenda vendit.
    • Kjo pĂ«rfundim buron nga testimi i rrjeteve publike Wi-Fi nĂ« vende tĂ« ndryshme, ku kĂ«to rrjete pĂ«rdoren nga shumĂ« njerĂ«z.
    • ShpejtĂ«sia e shkarkimit dhe ngarkimit nĂ« serverĂ«t brenda KinĂ«s ishte rreth 20 mb/s dhe 5-10 mb/s pĂ«rkatĂ«sisht.
    • ShpejtĂ«sia drejt serverĂ«ve jashtĂ« KinĂ«s Ă«shtĂ« thjesht minimale, mĂ« pak se 1 mb/s.
  • Internet nĂ« KinĂ« nuk Ă«shtĂ« shumĂ« stabil.
    • Disa herĂ« faqet mund tĂ« hapen shpejt, disa herĂ« ngadalĂ« (nĂ« tĂ« njĂ«jtĂ«n periudhĂ« kohore nĂ« ditĂ« tĂ« ndryshme), pĂ«r sa kohĂ« qĂ« konfigurimi nuk ndryshon. Kjo Ă«shtĂ« vĂ«rejtur nĂ« shembullin semrushchina.cn. Kjo mund tĂ« shkaktohet nga Ali CDN, i cili gjithashtu punon ndonjĂ«herĂ« mirĂ«, ndonjĂ«herĂ« keq, nĂ« varĂ«si tĂ« orĂ«s dhe pozitat e yjeve, etj.
  • Internet celular Ă«shtĂ« praktikisht 4G ose 4G+ kudo. Kapet nĂ« metro, ashensorĂ« — nĂ« shkurt, kudo.
  • Miti Ă«shtĂ« se pĂ«rdoruesit kinezĂ« besojnĂ« vetĂ«m nĂ« domenet nĂ« zonĂ«n .cn. Ne e verifikuam kĂ«tĂ« drejtpĂ«rdrejt nga pĂ«rdoruesit.
    • Mund tĂ« shihni se http://baidu.cn redirekton nĂ« www.baidu.com (edhe nĂ« mainland China).
  • ShumĂ« burime janĂ« vĂ«rtet tĂ« bllokuara. NĂ« mĂ«nyrĂ« primitive: google.com, Facebook, Twitter. Por shumĂ« burime tĂ« Google funksionojnĂ« (sigurisht, jo nĂ« tĂ« gjithĂ« Wi-Fi dhe VPN nuk pĂ«rdoret (as nga routeri, kjo Ă«shtĂ« e sigurt).
  • ShumĂ« 'domenet teknike' e kompanive tĂ« bllokuara gjithashtu funksionojnĂ«. Kjo do tĂ« thotĂ« se nuk duhet tĂ« hidhen nĂ« mĂ«nyrĂ« tĂ« paarsyeshme tĂ« gjitha burimet e dukshme tĂ« bllokuara. Duhet tĂ« kĂ«rkoni njĂ« listĂ« tĂ« domainĂ«ve tĂ« ndaluar.
  • Ata kanĂ« vetĂ«m tre operatorĂ« tĂ« mĂ«dhenj tĂ« internetit: China Unicom, China Telecom, China Mobile. Ka disa tĂ« vogla, por pjesa e tyre nĂ« treg Ă«shtĂ« e papĂ«rfillshme.

Bonus: skema përfundimtare e zgjidhjes

Si si kishte bërë që të kalonim Murin e Madh të Kinës (pjesa 3)

PĂ«rfundimi

Ka kaluar një vit nga fillimi i projektit. Filluam me faktin se faqja jonë refuzonte të funksiononte normalisht nga Kina, dhe thjesht një GET curl merrte 5.5 sekonda.

Pastaj, nga këto tregues në zgjidhjen e parë (Cloudflare):

Zgjidhja
Uptime
Median
75 Percentile
95 Percentile

Cloudflare
86.6
18s
30s
60s

Më në fund arritëm në këto rezultate (statistika për muajin e fundit):

Zgjidhja
Uptime
Median
75 Percentile
95 Percentile

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

Siç duket, derisa nuk kemi arritur tĂ« arrijmĂ« njĂ« kohĂ«zgjatje prej 100%, por ne do tĂ« gjejmĂ« ndonjĂ«herĂ« njĂ« zgjidhje, dhe mĂ« pas do t’ju tregojmĂ« rezultatet nĂ« njĂ« artikull tĂ« ri :)

Atij qĂ« e lexoi deri nĂ« fund tĂ« tre pjesĂ«ve — respekt. Shpresoj se gjithçka ishte po aq e interesante pĂ«r ju sa ishte pĂ«r mua kur e bĂ«ja kĂ«tĂ«.

P.S. Pjesët e mëparshme

Pjesa 1
Pjesa 2

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster