🥇අපි මහා චීන ගිනි පවුර බිඳ දැමූ ආකාරය (2 කොටස)

හෙලෝ!

නිකිටා නැවතත් ඔබ සමඟ සිටී, සමාගමේ පද්ධති ඉංජිනේරුවරියකි SEMrush. ඒ වගේම මේ ලිපියත් එක්ක මම කතාව දිගටම කරගෙන යනවා අපි විසදුමක් හොයාගත්ත විදිහ ගැන චීන ෆයර්වෝල් අපගේ සේවාව සඳහා semrush.com.

В පෙර කොටස මම කිව්වා:

“අපගේ සේවාව චීනයේ ක්‍රියාත්මක කිරීමට අවශ්‍ය” තීරණය ගත් පසු ඇති වන ගැටලු මොනවාද?
චීන අන්තර්ජාලයට ඇති ගැටළු මොනවාද?
ඔබට ICP බලපත්‍රයක් අවශ්‍ය වන්නේ ඇයි?
Catchpoint සමඟ අපගේ පරීක්ෂණ ඇඳන් පරීක්ෂා කිරීමට අපි තීරණය කළේ කෙසේද සහ ඇයි
Cloudflare China Network මත පදනම් වූ අපගේ පළමු විසඳුමේ ප්‍රතිඵලය කුමක්ද
අපි Cloudflare DNS හි දෝෂයක් සොයාගත් ආකාරය

මෙම කොටස වඩාත් සිත්ගන්නා සුළුය, මගේ මතය අනුව, එය වේදිකාගත කිරීමේ නිශ්චිත තාක්ෂණික ක්‍රියාත්මක කිරීම් කෙරෙහි අවධානය යොමු කරයි. අපි ආරම්භ කරන්නෙමු, නැතහොත් දිගටම කරගෙන යන්නෙමු අලිබාබා වලාකුළ.

අලිබාබා වලාකුළ

අලිබාබා වලාකුළ වලාකුළු සපයන්නා ලෙස අවංකව හැඳින්වීමට ඉඩ සලසන සියලුම සේවාවන් ඇති තරමක් විශාල වලාකුළු සපයන්නා වේ. විදේශීය පරිශීලකයින් සඳහා ලියාපදිංචි වීමට ඔවුන්ට අවස්ථාව ඇති බව හොඳ ය, බොහෝ වෙබ් අඩවිය ඉංග්රීසි භාෂාවට පරිවර්තනය කර ඇත (චීනය සඳහා මෙය සුඛෝපභෝගී වේ). මෙම වලාකුළ තුළ, ඔබට ලෝකයේ බොහෝ කලාප, චීනයේ ප්‍රධාන භූමිය මෙන්ම සාගර ආසියාව (හොංකොං, තායිවානය, ආදිය) සමඟ වැඩ කළ හැකිය.

IPSEC

අපි පටන් ගත්තේ භූගෝල විද්‍යාවෙන්. අපගේ පරීක්ෂණ අඩවිය Google Cloud හි පිහිටා ඇති බැවින්, අපට GCP සමඟ Alibaba Cloud "සම්බන්ධ" කිරීමට අවශ්‍ය විය, එබැවින් අපි Google සිටින ස්ථාන ලැයිස්තුවක් විවෘත කළෙමු. ඒ මොහොතේ ඔවුන්ට තවමත් හොංකොං හි ඔවුන්ගේම දත්ත මධ්‍යස්ථානයක් නොතිබුණි.
සමීපතම කලාපය බවට පත් විය ආසියාව-නැගෙනහිර1 (තායිවානය). අලි චීනයේ තායිවානයට ආසන්නතම කලාපය බවට පත් විය cn-shenzhen (ෂෙන්සෙන්).

සහාය ඇතිව භූමිෂ් .ය GCP සහ Ali හි සමස්ත යටිතල පහසුකම් විස්තර කර ඉහළ නැංවීය. වලාකුළු අතර 100 Mbit/s උමගක් ක්ෂණිකව පාහේ ඉහළ ගියේය. ෂෙන්සෙන් සහ තායිවානයේ පැත්තේ, ප්‍රොක්සිං අථත්‍ය යන්ත්‍ර මතු කරන ලදී. Shenzhen හි, පරිශීලක ගමනාගමනය අවසන් කර, උමගක් හරහා තායිවානයට ප්‍රොක්සි කර, එතැන් සිට එය අපගේ සේවාවේ බාහිර IP වෙත කෙලින්ම යයි. us-නැගෙනහිර (ඇමරිකා එක්සත් ජනපදයේ නැගෙනහිර වෙරළ). උමග හරහා අතථ්‍ය යන්ත්‍ර අතර පිං කරන්න 24ms, එය එතරම් නරක නැත.

ඒ සමගම, අපි පරීක්ෂණ ප්රදේශයක් තැබුවෙමු Alibaba Cloud DNS. කලාපය NS අලි වෙත පැවරීමෙන් පසුව, විභේදන කාලය 470 ms සිට දක්වා අඩු විය 50 ms. මීට පෙර, කලාපය ක්ලවුඩ්ෆෙයාර් හි ද විය.

දක්වා උමඟට සමාන්තරව ආසියාව-නැගෙනහිර1 ෂෙන්සෙන් සිට කෙලින්ම තවත් උමගක් එසවීය us-නැගෙනහිර4. එහිදී ඔවුන් තවත් ප්‍රොක්සි අථත්‍ය යන්ත්‍ර නිර්මාණය කර විසඳුම් දෙකම පරීක්ෂා කිරීමට පටන් ගත් අතර, කුකීස් හෝ ඩීඑන්එස් භාවිතයෙන් පරීක්ෂණ ගමනාගමනය මෙහෙයවීය. පරීක්ෂණ බංකුව පහත රූපයේ ක්‍රමානුකූලව විස්තර කර ඇත:

උමං සඳහා ප්‍රමාදය පහත පරිදි විය:
අලි cn-shenzhen <—> GCP asia-east1 — 24ms
අලි cn-shenzhen <—> GCP us-east4 — 200ms

කැච්පොයින්ට් බ්‍රව්සර් පරීක්ෂණ විශිෂ්ට දියුණුවක් වාර්තා කළේය.

විසඳුම් දෙකක් සඳහා පරීක්ෂණ ප්රතිඵල සසඳන්න:

තීරණය
යුතයි
මධ්යධරණී
සියයට 75ක්
සියයට 95ක්

Cloudflare
86.6
18
30
60

IPsec
99.79
18
21
30

මෙය IPSEC උමං මාර්ගයක් භාවිතා කරන විසඳුමක දත්ත වේ ආසියාව-නැගෙනහිර1. us-east4 හරහා ප්‍රතිඵල වඩාත් නරක වූ අතර දෝෂ වැඩි විය, එබැවින් මම ප්‍රතිඵල ලබා නොදෙමි.

උමං මාර්ග දෙකක මෙම පරීක්ෂණයේ ප්‍රති results ල මත පදනම්ව, ඉන් එකක් චීනයට ආසන්නතම කලාපයේ සහ අනෙක අවසාන ගමනාන්තයේ අවසන් කර ඇති අතර, එය ඉක්මනින් චීන ෆයර්වෝලයට යටින් “ඉක්මවීම” වැදගත් බව පැහැදිලි විය. හැකි, පසුව වේගවත් ජාල භාවිතා කරන්න (CDN සපයන්නන් , වලාකුළු සපයන්නන්, ආදිය). ෆයර්වෝල් එක හරහා ගොස් එක පහරකින් ඔබේ ගමනාන්තයට යාමට උත්සාහ කිරීම අවශ්‍ය නොවේ. මෙය වේගවත්ම මාර්ගය නොවේ.

සාමාන්යයෙන්, ප්රතිඵල නරක නැත, කෙසේ වෙතත්, semrush.com මධ්යන්ය 8.8 ක්, සහ 75 ප්රතිශතය 9.4s (එකම පරීක්ෂණයකදී) ඇත.
ඉදිරියට යාමට පෙර, මම කෙටි ගීතමය අපගමනය කිරීමට කැමතියි.

පද රචනය

පරිශීලකයා වෙබ් අඩවියට ඇතුළු වූ පසු www.semrushchina.cn, "වේගවත්" චීන DNS සේවාදායකයන් හරහා විසඳන, HTTP ඉල්ලීම අපගේ වේගවත් විසඳුම හරහා යයි. ප්‍රතිචාරය එකම මාර්ගය ඔස්සේ ආපසු එවනු ලැබේ, නමුත් වසම සියලුම JS ස්ක්‍රිප්ට්, HTML පිටු සහ වෙබ් පිටුවේ අනෙකුත් අංගවල සඳහන් වේ. semrush.com පිටුව විදැහුම් කරන විට පූරණය කළ යුතු අමතර සම්පත් සඳහා. එනම්, සේවාලාභියා "ප්රධාන" A-වාර්තාව විසඳයි www.semrushchina.cn සහ වේගවත් උමඟට ගොස් ඉක්මනින් ප්‍රතිචාරයක් ලැබේ - HTML පිටුවක් මෙසේ සඳහන් කරයි:

sso.semrush.com වෙතින් එවැනි සහ එවැනි js බාගන්න,
cdn.semrush.com වෙතින් CSS ගොනු ලබා ගන්න,
සහ dab.semrush.com වෙතින් පින්තූර කිහිපයක් ගන්න
සහ යනාදි.

බ්රවුසරය මෙම සම්පත් සඳහා "බාහිර" අන්තර්ජාලය වෙත යාමට පටන් ගනී, සෑම අවස්ථාවකදීම ප්රතිචාර දැක්වීමේ කාලය අනුභව කරන ෆයර්වෝලයක් හරහා ගමන් කරයි.

නමුත් පෙර පරීක්ෂණය පිටුවේ සම්පත් නොමැති විට ප්රතිඵල පෙන්වයි semrush.comපමණි semrushchina.cn, සහ *.semrushchina.cn ෂෙන්සෙන් හි ඇති අථත්‍ය යන්ත්‍රයේ ලිපිනයට පසුව උමඟට ඇතුළු වේ.

මේ ආකාරයෙන් පමණක්, චීන ෆයර්වෝලය ඉක්මනින් සම්මත කිරීම සඳහා ඔබේ විසඳුම හරහා හැකි සෑම ගමනාගමනයක්ම උපරිමයට තල්ලු කිරීමෙන්, ඔබට පිළිගත හැකි වේගයන් සහ වෙබ් අඩවි ලබා ගැනීමේ දර්ශක මෙන්ම විසඳුම් පරීක්ෂණවල අවංක ප්‍රතිඵල ලබා ගත හැකිය.
කණ්ඩායමේ නිෂ්පාදන පැත්තේ එක කේත සංස්කරණයක් නොමැතිව අපි මෙය කළෙමු.

උප පෙරහන

මෙම ගැටලුව මතු වූ වහාම විසඳුම උපත ලැබීය. අපට අවශ්‍ය විය PoC (සංකල්පයේ සාධනය) අපගේ ෆයර්වෝල් විනිවිද යාමේ විසඳුම් ඇත්තෙන්ම හොඳින් ක්‍රියා කරන බව. මෙය සිදු කිරීම සඳහා, ඔබ හැකිතාක් දුරට මෙම විසඳුම තුළට සියලුම අඩවි ගමනාගමනය ඔතා ගත යුතුය. ඒ වගේම අපි අයදුම් කළා උප පෙරහන nginx හි.

උප පෙරහන nginx හි තරමක් සරල මොඩියුලයක් වන අතර එමඟින් ප්‍රතිචාරයේ එක් රේඛාවක් වෙනත් රේඛාවකට වෙනස් කිරීමට ඔබට ඉඩ සලසයි. ඒ නිසා අපි සියලු සිදුවීම් වෙනස් කළා semrush.com මත semrushchina.cn සියලුම පිළිතුරු වල.

සහ... අපට පසුපෙළෙන් සම්පීඩිත අන්තර්ගතය ලැබුණු නිසා එය ක්‍රියා කළේ නැත, එබැවින් උප පෙරහනට අවශ්‍ය රේඛාව සොයාගත නොහැකි විය. මට nginx වෙත තවත් දේශීය සේවාදායකයක් එක් කිරීමට සිදු වූ අතර, එය ප්‍රතිචාරය විසංයෝජනය කර එය ඊළඟ දේශීය සේවාදායකය වෙත ලබා දී ඇත, එය දැනටමත් තන්තුව ප්‍රතිස්ථාපනය කිරීම, එය සම්පීඩනය කිරීම සහ දාමයේ ඊළඟ ප්‍රොක්සි සේවාදායකයට යැවීමේ කාර්යබහුල විය.

එහි ප්‍රතිඵලයක් වශයෙන්, සේවාදායකයාට ලැබෙන්නේ කොතැනින්ද .semrush.com, ඔහුට ලැබුණි .semrushchina.cn සහ කීකරුව අපගේ තීරණය හරහා ගමන් කළා.

කෙසේ වෙතත්, වසම එක් ආකාරයකින් වෙනස් කිරීම පමණක් ප්‍රමාණවත් නොවේ, මන්ද පසුපෙළ තවමත් සේවාදායකයාගෙන් පසු ඉල්ලීම් වලදී semrush.com අපේක්ෂා කරයි. ඒ අනුව, එක්-මාර්ග ප්‍රතිස්ථාපනය සිදු කරන එකම සේවාදායකයේ, සරල නිත්‍ය ප්‍රකාශනයක් භාවිතයෙන් අපි ඉල්ලීමෙන් උප ඩොමේනය ලබා ගනිමු, පසුව අපි කරන්නෙමු. proxy_pass විචල්යය සමඟ $host, ප්‍රදර්ශනය කෙරේ $subdomain.semrush.com. එය අවුල් සහගත බවක් පෙනෙන්නට ඇත, නමුත් එය ක්රියා කරයි. ඒ වගේම එය හොඳින් ක්රියා කරයි. විවිධ තාර්කික අවශ්‍ය තනි වසම් සඳහා, ඔබේම සර්වර් බ්ලොක් සාදා වෙනම වින්‍යාසයක් සාදන්න. මෙම යෝජනා ක්‍රමයේ පැහැදිලිකම සහ නිරූපණය සඳහා පහත nginx configs කෙටි කර ඇත.

පහත වින්‍යාසය චීනයෙන් ලැබෙන සියලුම ඉල්ලීම් ක්‍රියාවට නංවයි .semrushchina.cn:

    listen 80;

    server_name ~^(?<subdomain>[w-]+).semrushchina.cn$;

    sub_filter '.semrush.com' '.semrushchina.cn';
    sub_filter_last_modified on;
    sub_filter_once off;
    sub_filter_types *;

    gzip on;
    gzip_proxied any;
    gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript;

    location / {
        proxy_pass http://127.0.0.1:8083;
        proxy_set_header Accept-Encoding "";
        proxy_set_header Host $subdomain.semrush.com;
        proxy_set_header X-Accept-Encoding $http_accept_encoding;
    }
}

මෙම වින්‍යාසය ප්‍රොක්සි කරයි දේශීයව වරාය 83 වෙත, සහ පහත වින්‍යාසය එහි රැඳී ඇත:

    listen 127.0.0.1:8083;

    server_name *.semrush.com;

    location / {
        resolver 8.8.8.8 ipv6=off;
        gunzip on;
        proxy_pass https://$host;
        proxy_set_header Accept-Encoding gzip;
    }
}

මම නැවත කියනවා, මේවා කපන ලද වින්යාසය.

ඒ වගේ. එය සංකීර්ණ බවක් පෙනෙන්නට ඇත, නමුත් එය වචන වලින් වේ. ඇත්ත වශයෙන්ම, තැම්බූ ටර්නිප් වලට වඩා සියල්ල සරල ය :)

අපගමනය අවසානය

IPSEC උමං කඩා වැටීම පිළිබඳ මිථ්යාව තහවුරු නොකළ නිසා අපි ටික වේලාවක් සතුටු වුණා. නමුත් පසුව උමං කඩා වැටීමට පටන් ගත්තේය. මිනිත්තු කිහිපයක් සඳහා දිනකට කිහිප වතාවක්. ටිකක්, නමුත් එය අපට ගැලපෙන්නේ නැත. උමං දෙකම එකම රවුටරයේ අලි පැත්තේ අවසන් කර ඇති බැවින්, සමහර විට මෙය කලාපීය ගැටළුවක් විය හැකි බව අපි තීරණය කළ අතර අපට උපස්ථ කලාපය ඉහළ නැංවීමට අවශ්‍ය විය.

ඔවුන් එය අහුලා ගත්තා. විවිධ කාලවලදී උමං මාර්ග අසාර්ථක වීමට පටන් ගත් නමුත්, nginx හි උඩුගං මට්ටමේදී අසාර්ථක වීම අපට හොඳින් ක්‍රියාත්මක විය. නමුත් පසුව එම අවස්ථාවේදීම උමං කඩා වැටීමට පටන් ගත්තේය 🙂 සහ 502 සහ 504 නැවත ආරම්භ විය.උත්කාලය පිරිහීමට පටන් ගත් අතර, ඒ නිසා අපි විකල්පය සමඟ වැඩ කිරීමට පටන් ගත්තෙමු. අලිබබා CEN (Cloud Enterprise Network).

වැනි සියවසේ

වැනි සියවසේ - මෙය Alibaba Cloud තුළ විවිධ ප්‍රදේශවලින් VPC දෙකක සම්බන්ධතාවයකි, එනම්, ඔබට වලාකුළ තුළ ඇති ඕනෑම කලාපයක පුද්ගලික ජාල එකිනෙකා සමඟ සම්බන්ධ කළ හැකිය. සහ වඩාත්ම වැදගත් දෙය: මෙම නාලිකාව තරමක් දැඩි ලෙස ඇත SLA. එය වේගය සහ අතිකාල යන දෙකම ඉතා ස්ථායී වේ. නමුත් එය කිසි විටෙකත් එතරම් සරල නැත:

ඔබ චීන පුරවැසියන් හෝ නීත්‍යානුකූල ආයතනයක් නොවේ නම් එය ලබාගැනීම ඉතා අපහසුය.
නාලිකා ධාරිතාවයේ එක් එක් මෙගාබිට් සඳහා ඔබ ගෙවිය යුතුය.

සම්බන්ධ වීමට අවස්ථාව ලැබීම චීනය и විදෙස්, අපි Ali කලාප දෙකක් අතර CEN එකක් නිර්මාණය කළෙමු: cn-shenzhen и us-east-1 (අපට ආසන්නතම ස්ථානය-නැගෙනහිර4). අලි දී us-east-1 තවත් අථත්‍ය යන්ත්‍රයක් ඇති නිසා තවත් එකක් ඇති කළේය හොප්.

එය මෙසේ සිදු විය:

බ්‍රවුසර පරීක්ෂණ ප්‍රතිඵල පහත දැක්වේ.

තීරණය
යුතයි
මධ්යධරණී
සියයට 75ක්
සියයට 95ක්

Cloudflare
86.6
18
30
60

IPsec
99.79
18
21
30

වැනි සියවසේ
99.75
16
21
27

කාර්ය සාධනය IPSEC ට වඩා තරමක් හොඳයි. නමුත් IPSEC හරහා ඔබට 100 Mbit/s වේගයකින් බාගත කළ හැකි අතර CEN හරහා 5 Mbit/s සහ ඊට වැඩි වේගයකින් පමණි.

හයිබ්‍රිඩ් එකක් වගේ නේද? IPSEC වේගය සහ CEN ස්ථාවරත්වය ඒකාබද්ධ කරන්න.

IPSEC උමග අසාර්ථක වූ විට IPSEC සහ CEN යන දෙකම හරහා ගමනාගමනයට ඉඩ දෙමින් අප කළේ මෙයයි. අතිකාල බොහෝ වැඩි වී ඇත, නමුත් වෙබ් අඩවිය පැටවීමේ වේගය තවමත් අපේක්ෂා කිරීමට බොහෝ දේ ඉතිරි කරයි. ඉන්පසුව මම අප දැනටමත් භාවිතා කර පරීක්ෂා කර ඇති සියලුම පරිපථ ඇද ගත් අතර, මෙම පරිපථයට තව ටිකක් GCP එකතු කිරීමට උත්සාහ කිරීමට තීරණය කළෙමි. ජීඑල්බී.

ජීඑල්බී

ජීඑල්බී - මෙය Global Load Balancer (හෝ Google Cloud Load Balancer) එය අපට වැදගත් වාසියක් ඇත: CDN සන්දර්භය තුළ එය ඇත ඕනෑම IP, එය ඔබට සේවාලාභියාට සමීපතම දත්ත මධ්‍යස්ථානය වෙත ගමනාගමනය ගෙන යාමට ඉඩ සලසයි, එවිට ගමනාගමනය ඉක්මනින් Google හි වේගවත් ජාලයට ඇතුළු වන අතර “සාමාන්‍ය” අන්තර්ජාලය හරහා අඩු වේ.

දෙපාරක් හිතන්නේ නැතුව අපි නැගිට්ටා HTTP/HTTPS LB අපි අපගේ අතථ්‍ය යන්ත්‍ර GCP හි උප පෙරහන සමඟ සහ පසුබිමක් ලෙස ස්ථාපනය කළෙමු.

යෝජනා ක්රම කිහිපයක් විය:

භාවිතා කරන්න Cloudflare චීන ජාලය, නමුත් මෙවර සම්භවය ගෝලීය වශයෙන් සඳහන් කළ යුතුය IP GLB.
ගනුදෙනුකරුවන් අවසන් කරන්න cn-shenzhen, සහ එතැන් සිට ගමනාගමනය කෙලින්ම ප්‍රොක්සි කරන්න ජීඑල්බී.
චීනයේ සිට කෙලින්ම යන්න ජීඑල්බී.
ගනුදෙනුකරුවන් අවසන් කරන්න cn-shenzhen, එතනින් proxy to ආසියාව-නැගෙනහිර1 IPSEC හරහා (in us-නැගෙනහිර4 CEN හරහා), එතැන් සිට GLB වෙත යන්න (සන්සුන්ව, පහත පින්තූරයක් සහ පැහැදිලි කිරීමක් ඇත)

අපි මෙම සියලු විකල්ප සහ තවත් දෙමුහුන් කිහිපයක් පරීක්ෂා කළෙමු:

Cloudflare + GLB

අතිකාල සහ DNS දෝෂ හේතුවෙන් මෙම යෝජනා ක්‍රමය අපට නොගැලපේ. නමුත් CF පැත්තේ දෝෂය නිවැරදි කිරීමට පෙර පරීක්ෂණය සිදු කරන ලදී, සමහර විට එය දැන් වඩා හොඳය (කෙසේ වෙතත්, මෙය HTTP කල් ඉකුත්වීම් බැහැර නොකරයි).

අලි + GLB

පිළිගත හැකි වේලාවක හෝ කල් ඉකුත්වීමකදී සම්බන්ධ වීමට නොහැකි වීම හේතුවෙන් GLB බොහෝ විට උඩුගං බලා වැටුණු බැවින්, චීනය තුළ ඇති සේවාදායකයක් සඳහා, GLB ලිපිනය පිටතින් පවතින බැවින්, මෙම යෝජනා ක්‍රමය අප්‍රමාදය අනුව අපට නොගැලපේ. චීන ගිනි පවුර. මායාව සිදු වූයේ නැත.

GLB පමණි

පෙර විකල්පයට සමාන විකල්පයක්, එය චීනයේම සේවාදායකයන් භාවිතා නොකළේ පමණි: ගමනාගමනය කෙලින්ම GLB වෙත ගියේය (DNS වාර්තා වෙනස් කර ඇත). ඒ අනුව, සාමාන්‍ය අන්තර්ජාල සපයන්නන්ගේ සේවාවන් භාවිතා කරන සාමාන්‍ය චීන සේවාදායකයින්ට ෆයර්වෝලය පසුකර යාමේදී අලි ක්ලවුඩ් වලට වඩා නරක තත්වයක් ඇති බැවින් ප්‍රතිඵල සතුටුදායක නොවීය.

Shenzhen -> (CEN/IPSEC) -> Proxy -> GLB

මෙන්න අපි සියලු විසඳුම් වලින් හොඳම දේ භාවිතා කිරීමට තීරණය කළෙමු:

CEN වෙතින් ස්ථාවරත්වය සහ සහතික කළ SLA
IPSEC වෙතින් අධික වේගය
Google හි "වේගවත්" ජාලය සහ එහි ඕනෑම විකාශනය.

මෙම යෝජනා ක්‍රමය මේ වගේ දෙයක් පෙනේ: පරිශීලක ගමනාගමනය අථත්‍ය යන්ත්‍රයක් මත අවසන් වේ ch-shenzhen. Nginx upstreams එහි වින්‍යාස කර ඇත, ඒවායින් සමහරක් IPSEC උමගෙහි අනෙක් කෙළවරේ පිහිටා ඇති පුද්ගලික IP සේවාදායකයන් වෙත යොමු කරයි, සහ සමහර upstreams CEN හි අනෙක් පැත්තේ සේවාදායකයන්ගේ පුද්ගලික ලිපින වෙත යොමු කරයි. IPSEC කලාපයට වින්‍යාස කර ඇත ආසියාව-නැගෙනහිර1 GCP හි (විසඳුම නිර්මාණය කරන විට චීනයට සමීපතම කලාපය විය. GCP දැන් හොංකොංහි ද පවතී). CEN - කලාපයට us-නැගෙනහිර1 Ali Cloud හි.

ඉන්පසු දෙපැත්තෙන් ගමනාගමනය යොමු කරන ලදී ඕනෑම IP GLB, එනම්, Google හි ළඟම ඇති ස්ථානයට, සහ එහි ජාල හරහා කලාපයට ගියේය us-නැගෙනහිර4 GCP හි, ප්‍රතිස්ථාපන අථත්‍ය යන්ත්‍ර තිබූ (nginx හි උප පෙරහන සහිත).

මෙම දෙමුහුන් විසඳුම, අප අපේක්ෂා කළ පරිදි, එක් එක් තාක්ෂණයේ ප්රතිලාභ ලබා ගත්තේය. සාමාන්‍යයෙන්, ගමනාගමනය වේගවත් IPSEC හරහා ගමන් කරයි, නමුත් ගැටළු ආරම්භ වුවහොත්, අපි ඉක්මනින් සහ මිනිත්තු කිහිපයක් සඳහා මෙම සේවාදායකයන් උඩු ගංවතුරෙන් ඉවත් කර උමග ස්ථාවර වන තෙක් CEN හරහා පමණක් ගමනාගමනය යවන්නෙමු.

ඉහත ලැයිස්තුවෙන් 4 වන විසඳුම ක්‍රියාත්මක කිරීමෙන්, එම අවස්ථාවේ දී අපට අවශ්‍ය දේ සහ ව්‍යාපාරයට අපෙන් අවශ්‍ය දේ අපි සාක්ෂාත් කර ගත්තෙමු.

පෙර ඒවාට සාපේක්ෂව නව විසඳුම සඳහා බ්‍රව්සර් පරීක්ෂණ ප්‍රතිඵල:

තීරණය
යුතයි
මධ්යධරණී
සියයට 75ක්
සියයට 95ක්

Cloudflare
86.6
18
30
60

IPsec
99.79
18
21
30

වැනි සියවසේ
99.75
16
21
27

CEN/IPsec + GLB
99.79
13
16
25

සීඩීඑන්

අපි ක්‍රියාත්මක කළ විසඳුමේ සෑම දෙයක්ම හොඳයි, නමුත් ප්‍රාදේශීය සහ නගර මට්ටමින් පවා ගමනාගමනය වේගවත් කළ හැකි CDN නොමැත. න්‍යායාත්මකව, මෙය CDN සපයන්නාගේ වේගවත් සන්නිවේදන නාලිකා භාවිතා කිරීමෙන් අවසාන පරිශීලකයින් සඳහා වෙබ් අඩවිය වේගවත් කළ යුතුය. ඒ වගේම අපි ඒ ගැන නිතරම හිතුවා. දැන්, ව්‍යාපෘතියේ මීළඟ පුනරාවර්තනය සඳහා කාලය පැමිණ තිබේ: චීනයේ CDN සපයන්නන් සෙවීම සහ පරීක්ෂා කිරීම.

ඒ වගේම මම මේ ගැන ඊළඟ, අවසාන කොටසින් කියන්නම් :)

මූලාශ්රය: www.habr.com

අපි චීනයේ මහා ගිනි පවුර බිඳ දැමූ ආකාරය (2 කොටස)

අලිබාබා වලාකුළ

IPSEC

පද රචනය

උප පෙරහන

අපගමනය අවසානය

වැනි සියවසේ

ජීඑල්බී

සීඩීඑන්

අදහස් එක් කරන්න

අපි චීනයේ මහා ගිනි පවුර බිඳ දැමූ ආකාරය (2 කොටස)

අලිබාබා වලාකුළ

IPSEC

පද රචනය

උප පෙරහන

අපගමනය අවසානය

වැනි සියවසේ

ජීඑල්බී

සීඩීඑන්

අදහස් එක් කරන්න ඊ-මේල් මගින් පිලිතුරු දෙන්න අවලංගු

අදහස් එක් කරන්න