கிரேட் சைனீஸ் ஃபயர்வாலை நாங்கள் எப்படி உடைத்தோம் (பகுதி 2)

வாழ்த்துக்கள்!

நிகிதா மீண்டும் உங்களுடன் இருக்கிறார் - நிறுவனத்தைச் சேர்ந்த ஒரு சிஸ்டம்ஸ் இன்ஜினியர். SEMrushஇந்தக் கட்டுரையின் மூலம், நாங்கள் எப்படி ஒரு தீர்வைக் கண்டுபிடித்தோம் என்ற கதையைத் தொடர்கிறேன். சீன ஃபயர்வால் எங்கள் சேவை semrush.com க்கு.

В முந்தைய பகுதி நான் சொன்னேன்:

• "எங்கள் சேவையை சீனாவில் செயல்பட வைக்க வேண்டும்" என்ற முடிவு எடுக்கப்பட்ட பிறகு என்னென்ன பிரச்சனைகள் எழுகின்றன?
• சீன இணையத்தில் என்னென்ன பிரச்சனைகள் உள்ளன?
• ICP உரிமம் ஏன் தேவைப்படுகிறது?
• எப்படி, ஏன் கேட்ச்பாயிண்ட் மூலம் எங்கள் சோதனைப் படுக்கைகளை சோதிக்க முடிவு செய்தோம்
• கிளவுட்ஃப்ளேர் சீனா நெட்வொர்க்கை அடிப்படையாகக் கொண்ட எங்கள் முதல் தீர்வின் விளைவு என்ன?
• Cloudflare இன் DNS இல் ஒரு பிழையை நாங்கள் எவ்வாறு கண்டறிந்தோம்

இந்தப் பகுதி, என் கருத்துப்படி, மிகவும் சுவாரஸ்யமானது, ஏனென்றால் இது மேடையேற்றத்தின் குறிப்பிட்ட தொழில்நுட்ப செயலாக்கங்களில் கவனம் செலுத்துகிறது. மேலும் நாம் தொடங்குவோம், அல்லது தொடர்வோம், இதிலிருந்து அலிபா கிளவுட்.

அலிபா கிளவுட்

அலிபா கிளவுட் — ஒரு மிகப் பெரிய கிளவுட் வழங்குநர், தன்னை ஒரு கிளவுட் வழங்குநர் என்று சட்டப்பூர்வமாக அழைக்க அனுமதிக்கும் அனைத்து சேவைகளையும் வழங்குகிறது. அவர்கள் வெளிநாட்டு பயனர்களை பதிவு செய்ய அனுமதிப்பது நல்லது, மேலும் பெரும்பாலான வலைத்தளங்கள் ஆங்கிலத்தில் மொழிபெயர்க்கப்பட்டுள்ளன (சீனாவில் ஒரு ஆடம்பரம்). இந்த கிளவுட் சீனாவின் பிரதான நிலப்பகுதி மற்றும் ஓசியானியா (ஹாங்காங், தைவான், முதலியன) உட்பட உலகின் பல பகுதிகளுக்கு அணுகலை அனுமதிக்கிறது.

IPSEC

நாங்கள் புவியியலுடன் தொடங்கினோம். எங்கள் சோதனை தளம் கூகிள் கிளவுட்டில் ஹோஸ்ட் செய்யப்பட்டதால், அலிபாபா கிளவுட்டை ஜிசிபியுடன் இணைக்க வேண்டியிருந்தது, எனவே கூகிள் இருக்கும் இடங்களின் பட்டியலைத் திறந்தோம். அந்த நேரத்தில், அவர்களுக்கு ஹாங்காங்கில் இன்னும் சொந்த தரவு மையம் இல்லை.
அருகிலுள்ள பகுதி மாறியது ஆசியா-கிழக்கு1 (தைவான்). சீனாவின் பிரதான நிலப்பகுதியில் தைவானுக்கு மிக அருகில் உள்ள பகுதி என்று அலி கண்டறிந்தார் சிஎன்-ஷென்சென் (ஷென்சென்).

உதவியுடன் terraform GCP மற்றும் Ali இல் உள்ள முழு உள்கட்டமைப்பையும் நாங்கள் விவரித்து அமைத்தோம். மேகங்களுக்கு இடையே 100 Mbps சுரங்கப்பாதை கிட்டத்தட்ட உடனடியாக இயங்கத் தொடங்கியது. ஷென்சென் மற்றும் தைவான் பக்கங்களில் ப்ராக்ஸி மெய்நிகர் இயந்திரங்கள் அமைக்கப்பட்டன. ஷென்செனில், பயனர் போக்குவரத்து நிறுத்தப்பட்டு, சுரங்கப்பாதை வழியாக தைவானுக்கு ப்ராக்ஸி செய்யப்பட்டு, அங்கிருந்து நேரடியாக எங்கள் சேவையின் வெளிப்புற IP முகவரிக்குச் செல்கிறது. அமெரிக்க கிழக்கு (அமெரிக்க கிழக்கு கடற்கரை). சுரங்கப்பாதை வழியாக மெய்நிகர் இயந்திரங்களுக்கு இடையில் பிங் செய்யுங்கள். 24ms, இது அவ்வளவு மோசமானதல்ல.

அதே நேரத்தில், நாங்கள் ஒரு சோதனை மண்டலத்தை வைத்தோம் அலிபாபா கிளவுட் டிஎன்எஸ்மண்டலத்தை என்.எஸ். அலிக்கு ஒப்படைத்த பிறகு, தீர்மான நேரம் 470 எம்.எஸ். இலிருந்து 50 எம்எஸ்இதற்கு முன்பு, இந்த மண்டலம் கிளவுட்ல்ஃபேரிலும் இருந்தது.

சுரங்கப்பாதைக்கு இணையாக ஆசியா-கிழக்கு1 மற்றொரு சுரங்கப்பாதை ஷென்செனிலிருந்து நேராக கட்டப்பட்டது அமெரிக்கா-கிழக்கு4அவர்கள் கூடுதல் ப்ராக்ஸி மெய்நிகர் இயந்திரங்களை உருவாக்கி, இரண்டு தீர்வுகளையும் சோதிக்கத் தொடங்கினர், குக்கீகள் அல்லது DNS ஐப் பயன்படுத்தி சோதனை போக்குவரத்தை ரூட்டிங் செய்தனர். சோதனை அமைப்பு பின்வரும் படத்தில் திட்டவட்டமாக சித்தரிக்கப்பட்டுள்ளது:

சுரங்கப்பாதைகளுக்கான தாமதம் பின்வருமாறு:
அலி cn-shenzhen <—> GCP ஆசிய-கிழக்கு1 — 24ms
அலி cn-shenzhen <—> GCP us-east4 — 200ms

கேட்ச்பாயிண்டின் உலாவி சோதனைகள் குறிப்பிடத்தக்க முன்னேற்றங்களைப் பதிவு செய்தன.

இரண்டு தீர்வுகளுக்கான சோதனை முடிவுகளை ஒப்பிடுக:

முடிவு
முடிந்தநேரம்
சராசரி
75 சதவீதம்
95 சதவீதம்

CloudFlare
86.6
18
30
60

IPsec- ஐ
99.79
18
21
30

இது IPSEC சுரங்கப்பாதையைப் பயன்படுத்தி தீர்வின் தரவு ஆகும் ஆசியா-கிழக்கு1us-east4 மூலம் முடிவுகள் மோசமாக இருந்தன, மேலும் பிழைகள் அதிகமாக இருந்தன, எனவே நான் முடிவுகளை வழங்க மாட்டேன்.

இரண்டு சுரங்கப்பாதைகளின் இந்த சோதனையின் முடிவுகளின் அடிப்படையில், ஒன்று சீனாவிற்கு அருகிலுள்ள ஒரு பகுதியிலும் மற்றொன்று இறுதி இலக்கிலும் முடிவடைகிறது, சீன ஃபயர்வாலின் கீழ் இருந்து விரைவாக "வெளியேறி" பின்னர் வேகமான நெட்வொர்க்குகளைப் பயன்படுத்துவது முக்கியம் என்பது தெளிவாகியது (CDN வழங்குநர்கள், கிளவுட் வழங்குநர்கள், முதலியன). ஃபயர்வாலைத் தவிர்த்து, ஒரே அடியில் உங்கள் இலக்கை அடைய முயற்சிக்காதீர்கள். அது வேகமான பாதை அல்ல.

ஒட்டுமொத்தமாக, முடிவுகள் மோசமாக இல்லை, இருப்பினும், semrush.com இன் சராசரி 8.8 வினாடிகள், மற்றும் 75வது சதவீதம் 9.4 வினாடிகள் (அதே சோதனையில்) உள்ளன.
மேலும் தொடர்வதற்கு முன், நான் ஒரு சிறிய பாடல் வரிகளைத் திசைதிருப்ப விரும்புகிறேன்.

பாடல் வரி விலக்கு

பயனர் தளத்தைப் பார்வையிட்ட பிறகு www.semrushchina.cn முகவரி"வேகமான" சீன DNS சேவையகங்கள் மூலம் தீர்க்கப்படும் HTTP கோரிக்கை எங்கள் வேகமான தீர்வு வழியாக செல்கிறது. பதில் அதே பாதை வழியாகத் திரும்பும், ஆனால் அனைத்து JS ஸ்கிரிப்டுகள், HTML பக்கங்கள் மற்றும் பிற வலைப்பக்க கூறுகளும் டொமைனைக் குறிப்பிடுகின்றன. semrush.com பக்கத்தை ரெண்டர் செய்யும் போது ஏற்றப்பட வேண்டிய கூடுதல் ஆதாரங்களுக்கு. அதாவது, கிளையன்ட் "முக்கிய" A-பதிவை தீர்க்கிறது. www.semrushchina.cis உருவாக்கியது www.semrushchina.c,.com,.n ஒரு வேகமான சுரங்கப்பாதையில் சென்று, விரைவாக ஒரு பதிலைப் பெறுகிறது - இது கூறும் ஒரு HTML பக்கம்:

• sso.semrush.com இலிருந்து such-and-such js ஐப் பதிவிறக்கவும்,
• cdn.semrush.com இலிருந்து CSS கோப்புகளைப் பதிவிறக்கவும்.
• மேலும் dab.semrush.com இலிருந்து சில படங்களைப் பெறுங்கள்.
• மற்றும் பல.

இந்த ஆதாரங்களுக்காக உலாவி "வெளிப்புற" இணையத்திற்குச் செல்லத் தொடங்குகிறது, ஒவ்வொரு முறையும் மறுமொழி நேரத்தை உண்ணும் ஃபயர்வால் வழியாகச் செல்கிறது.

ஆனால் முந்தைய சோதனை பக்கத்தில் எந்த ஆதாரங்களும் இல்லாதபோது முடிவுகளைக் காட்டுகிறது. semrush.com, மட்டும் செம்ருஷ்சினா.சிஎன், மற்றும் *.semrushchina.cn ஷென்செனில் உள்ள ஒரு மெய்நிகர் இயந்திரத்தின் முகவரிக்குத் தீர்வு கண்டு, பின்னர் சுரங்கப்பாதையில் நுழைகிறது.

சீன ஃபயர்வாலை விரைவாக ஊடுருவுவதற்கு உங்கள் சொந்த தீர்வு மூலம் சாத்தியமான அனைத்து போக்குவரத்தையும் செலுத்துவதன் மூலம் மட்டுமே ஏற்றுக்கொள்ளக்கூடிய வேகம் மற்றும் வலைத்தள கிடைக்கும் தன்மையையும், நேர்மையான தீர்வு சோதனை முடிவுகளையும் அடைய முடியும்.
குழு தயாரிப்பு பக்கத்தில் ஒரு குறியீடு மாற்றம் கூட இல்லாமல் இதைச் செய்தோம்.

துணை வடிகட்டி

இந்தப் பிரச்சினை தோன்றிய உடனேயே தீர்வு பிறந்தது. எங்களுக்குத் தேவைப்பட்டது POC (கருத்துச் சான்று) எங்கள் ஃபயர்வால் டிராவர்சல் தீர்வுகள் உண்மையில் நன்றாக வேலை செய்கின்றன. இதைச் செய்ய, இந்தத் தீர்விற்குள் முடிந்தவரை தளத்தின் போக்குவரத்தை நாம் இணைக்க வேண்டும். மேலும் நாங்கள் துணை வடிகட்டி nginx இல்.

துணை வடிகட்டி — என்பது nginx இல் உள்ள மிகவும் எளிமையான தொகுதியாகும், இது மறுமொழிப் பகுதியில் உள்ள ஒரு சரத்தை மற்றொரு சரத்தால் மாற்ற உங்களை அனுமதிக்கிறது. எனவே, அனைத்து நிகழ்வுகளையும் மாற்றியமைத்துள்ளோம். semrush.com மீது செம்ருஷ்சினா.சிஎன் எல்லா பதில்களிலும்.

மேலும்... அது வேலை செய்யவில்லை, ஏனென்றால் நாங்கள் பின்தளங்களில் இருந்து சுருக்கப்பட்ட உள்ளடக்கத்தைப் பெறுகிறோம், எனவே துணை வடிகட்டியால் தேவையான சரத்தைக் கண்டுபிடிக்க முடியவில்லை. நாங்கள் nginx இல் மற்றொரு உள்ளூர் சேவையகத்தைச் சேர்க்க வேண்டியிருந்தது, இது பதிலை டிகம்பரஸ் செய்து அடுத்த உள்ளூர் சேவையகத்திற்கு அனுப்பியது, பின்னர் அது சரத்தை மாற்றி, அதை சுருக்கி, சங்கிலியில் உள்ள அடுத்த ப்ராக்ஸி சேவையகத்திற்கு அனுப்பியது.

இறுதியில், வாடிக்கையாளர் எங்கு பெறுவார் .செம்ரஷ்.காம், அவர் பெற்றார் .செம்ருஷ்சினா.சிஎன் மேலும் எங்கள் முடிவைக் கீழ்ப்படிதலுடன் பின்பற்றினர்.

இருப்பினும், டொமைனை ஒரு திசையில் மாற்றுவது மட்டும் போதாது, ஏனெனில் பின்தளங்கள் இன்னும் கிளையண்டிலிருந்து வரும் கோரிக்கைகளில் semrush.com ஐ எதிர்பார்க்கின்றன. எனவே, ஒரு வழி மாற்றம் செய்யப்படும் அதே சேவையகத்தில், கோரிக்கையிலிருந்து துணை டொமைனைப் பெற எளிய வழக்கமான வெளிப்பாட்டைப் பயன்படுத்துகிறோம், பின்னர் ப்ராக்ஸி_பாஸ் மாறியுடன் $ஹோஸ்ட், இல் காட்சிப்படுத்தப்பட்டது $சப்டொமைன்.செம்ரஷ்.காம்இது குழப்பமானதாகத் தோன்றலாம், ஆனால் அது வேலை செய்கிறது. மேலும் இது நன்றாக வேலை செய்கிறது. வெவ்வேறு தர்க்கம் தேவைப்படும் தனிப்பட்ட டொமைன்களுக்கு, அவற்றின் சொந்த சர்வர் தொகுதிகளை உருவாக்கி அவற்றை தனித்தனியாக உள்ளமைக்கவும். இந்த திட்டத்தின் தெளிவு மற்றும் செயல் விளக்கத்திற்காக கீழே சில சுருக்கப்பட்ட nginx உள்ளமைவுகள் உள்ளன.

பின்வரும் கட்டமைப்பு சீனாவிலிருந்து வரும் அனைத்து கோரிக்கைகளையும் கையாளுகிறது .செம்ருஷ்சினா.சிஎன்:

    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 (கிளவுட் எண்டர்பிரைஸ் நெட்வொர்க்).

இது CEN

இது CEN — என்பது அலிபாபா கிளவுட்டுக்குள் வெவ்வேறு பகுதிகளைச் சேர்ந்த இரண்டு VPC-களின் இணைப்பு, அதாவது கிளவுட்டுக்குள் உள்ள எந்தப் பகுதியின் தனியார் நெட்வொர்க்குகளையும் நீங்கள் இணைக்க முடியும். மிக முக்கியமாக, இந்த சேனல் மிகவும் கண்டிப்பானது இலங்கை இராணுவத்தின்வேகம் மற்றும் இயக்க நேரம் இரண்டிலும் இது மிகவும் நிலையானது. ஆனால் விஷயங்கள் ஒருபோதும் அவ்வளவு எளிதானவை அல்ல:

• நீங்கள் ஒரு சீன குடிமகனாகவோ அல்லது சட்டப்பூர்வ நிறுவனமாகவோ இல்லாவிட்டால் அதைப் பெறுவது மிகவும் கடினம்,
• சேனல் அலைவரிசையின் ஒவ்வொரு மெகாபிட்டிற்கும் நீங்கள் பணம் செலுத்த வேண்டும்.

இணைக்க வாய்ப்பு உள்ளது சீனா и வெளிநாட்டு, இரண்டு அலி பிராந்தியங்களுக்கு இடையில் ஒரு CEN ஐ உருவாக்கினோம்: சிஎன்-ஷென்சென் и அமெரிக்க கிழக்கு-1 (நமக்கு மிக நெருக்கமான புள்ளி-கிழக்கு4). அலியில் அமெரிக்க கிழக்கு-1 இன்னொன்று இருக்கும்படி நாங்கள் இன்னொரு மெய்நிகர் இயந்திரத்தை உருவாக்கினோம். தாவலாம்.

இது இப்படி மாறியது:

உலாவி சோதனை முடிவுகள் கீழே:

முடிவு
முடிந்தநேரம்
சராசரி
75 சதவீதம்
95 சதவீதம்

CloudFlare
86.6
18
30
60

IPsec- ஐ
99.79
18
21
30

இது CEN
99.75
16
21
27

செயல்திறன் IPSEC ஐ விட சற்று சிறப்பாக உள்ளது. இருப்பினும், IPSEC 100 Mbps பதிவிறக்க வேகத்தை வழங்க முடியும், அதே நேரத்தில் CEN 5 Mbps மற்றும் அதற்கு மேற்பட்ட வேகத்தை மட்டுமே வழங்க முடியும்.

ஒரு கலப்பினம் தான் தெளிவான தேர்வு, இல்லையா? IPSEC இன் வேகத்தை CEN இன் நிலைத்தன்மையுடன் இணைக்கவும்.

நாங்கள் அதைத்தான் செய்தோம், IPSEC சுரங்கப்பாதை செயலிழந்தால் IPSEC மற்றும் CEN இரண்டிலும் போக்குவரத்தை வழிவகுத்தோம். இயக்க நேரம் கணிசமாக மேம்பட்டது, ஆனால் தளத்தின் ஏற்றுதல் வேகம் இன்னும் விரும்பத்தக்கதாக இல்லை. பின்னர் நாங்கள் ஏற்கனவே பயன்படுத்திய மற்றும் சோதித்த அனைத்து திட்டங்களையும் வரைந்து, கலவையில் இன்னும் கொஞ்சம் GCP ஐச் சேர்க்க முயற்சிக்க முடிவு செய்தேன், அதாவது ஜி.எல்.பி..

ஜி.எல்.பி.

ஜி.எல்.பி. - அது உலகளாவிய சுமை சமநிலைப்படுத்தி (அல்லது கூகிள் கிளவுட் லோட் பேலன்சர்). இது நமக்கு ஒரு முக்கியமான நன்மையைக் கொண்டுள்ளது: CDN சூழலில், இது எனிகாஸ்ட் ஐபி, இது வாடிக்கையாளருக்கு மிக நெருக்கமான தரவு மையத்திற்கு போக்குவரத்தை வழிநடத்த அனுமதிக்கிறது, இது கூகிளின் வேகமான நெட்வொர்க்கிற்கு போக்குவரத்து வேகமாகச் செல்வதையும் "வழக்கமான" இணையத்தில் குறைவாகப் பயணிப்பதையும் உறுதி செய்கிறது.

இரண்டு முறை யோசிக்காமல், நாங்கள் வளர்த்தோம் HTTP/HTTPS LB நாங்கள் எங்கள் மெய்நிகர் இயந்திரங்களை GCP-யில் துணை வடிகட்டியுடன் நிறுவி, பின்தளமாகப் பயன்படுத்தினோம்.

பல திட்டங்கள் இருந்தன:

• பயன் Cloudflare சீனா நெட்வொர்க், ஆனால் இந்த முறை, தோற்றத்தை உலகளாவியதாகக் குறிப்பிடவும் ஐபி ஜிஎல்பி.
• வாடிக்கையாளர்களை நிறுத்து சிஎன்-ஷென்சென், அங்கிருந்து போக்குவரத்தை நேரடியாக ப்ராக்ஸி செய்யவும் ஜி.எல்.பி..
• சீனாவிலிருந்து நேராகச் செல்லுங்கள் ஜி.எல்.பி..
• வாடிக்கையாளர்களை நிறுத்து சிஎன்-ஷென்சென், அங்கிருந்து ப்ராக்ஸி வரை ஆசியா-கிழக்கு1 IPSEC வழியாக (இல் அமெரிக்கா-கிழக்கு4 CEN வழியாக), அங்கிருந்து GLB க்குச் செல்லவும் (கவலைப்பட வேண்டாம், கீழே ஒரு படமும் விளக்கமும் இருக்கும்)

இந்த அனைத்து விருப்பங்களையும், இன்னும் சில கலப்பின விருப்பங்களையும் நாங்கள் சோதித்தோம்:

• கிளவுட்ஃப்ளேர் + ஜிஎல்பி

இந்த அமைப்பு இயக்க நேரம் மற்றும் DNS பிழைகள் அடிப்படையில் எங்களை திருப்திப்படுத்தவில்லை. இருப்பினும், CF பிழை சரி செய்யப்படுவதற்கு முன்பே சோதனை நடத்தப்பட்டது, எனவே இப்போது அது மேம்படுத்தப்பட்டிருக்கலாம் (இருப்பினும், இது HTTP நேர முடிவின் சாத்தியத்தை நிராகரிக்கவில்லை).

• அலி + ஜிஎல்பி

இந்த அமைப்பும் இயக்க நேரத்தின் அடிப்படையில் எங்களை திருப்திப்படுத்தவில்லை, ஏனெனில் GLB பெரும்பாலும் ஒரு நியாயமான நேரத்திற்குள் இணைக்க இயலாமை அல்லது காலக்கெடு காரணமாக அப்ஸ்ட்ரீமில் இருந்து வெளியேறியது. சீனாவிற்குள் இருக்கும் ஒரு சேவையகத்திற்கு, GLB இன் முகவரி வெளிப்புறமாகவே இருக்கும், அதாவது அது சீன ஃபயர்வாலுக்குப் பின்னால் உள்ளது. எந்த மாயாஜாலமும் நடக்கவில்லை.

• GLB மட்டும்

இது முந்தையதைப் போன்ற ஒரு தீர்வாக இருந்தது, ஆனால் இது சீனாவிலேயே சேவையகங்களைப் பயன்படுத்தவில்லை: போக்குவரத்து நேரடியாக GLBக்கு அனுப்பப்பட்டது (DNS பதிவுகள் மாற்றப்பட்டன). இதன் விளைவாக, முடிவுகள் திருப்தியற்றவை, ஏனெனில் வழக்கமான இணைய வழங்குநர்களைப் பயன்படுத்தும் வழக்கமான சீன வாடிக்கையாளர்கள் அலி கிளவுட்டை விட மிக மோசமான ஃபயர்வால் ஊடுருவலைக் கொண்டுள்ளனர்.

• ஷென்சென் -> (CEN/IPSEC) -> ப்ராக்ஸி -> GLB

இங்கே நாங்கள் எல்லா தீர்வுகளிலும் சிறந்ததைப் பயன்படுத்த முடிவு செய்தோம்:

• CEN இலிருந்து நிலைத்தன்மை மற்றும் உத்தரவாதமான SLA
• IPSEC இலிருந்து அதிவேகம்
• கூகிளின் "வேகமான" நெட்வொர்க் மற்றும் அதன் எனிகாஸ்ட்.

இந்த திட்டம் இதுபோல் தெரிகிறது: ஒரு மெய்நிகர் கணினியில் பயனர் போக்குவரத்து நிறுத்தப்பட்டது ச்-ஷென்சென். NGINX அப்ஸ்ட்ரீம்கள் அங்கு கட்டமைக்கப்படுகின்றன, அவற்றில் சில IPSEC சுரங்கப்பாதையின் மறுமுனையில் அமைந்துள்ள தனியார் IP சேவையகங்களைச் சுட்டிக்காட்டுகின்றன, மேலும் சில அப்ஸ்ட்ரீம்கள் CEN இன் மறுபுறத்தில் உள்ள தனியார் சேவையக முகவரிகளைச் சுட்டிக்காட்டுகின்றன. IPSEC பிராந்தியத்திற்குக் கீழே கட்டமைக்கப்பட்டது. ஆசியா-கிழக்கு1 GCP-யில் (தீர்வு உருவாக்கப்பட்ட நேரத்தில் சீனாவிற்கு மிக நெருக்கமான பிராந்தியமாக இருந்தது. GCP இப்போது ஹாங்காங்கிலும் ஒரு இருப்பைக் கொண்டுள்ளது). CEN — பிராந்தியத்திற்கு அமெரிக்கா-கிழக்கு1 அலி கிளவுட்டில்.

பின்னர் இரு முனைகளிலிருந்தும் போக்குவரத்து திருப்பி விடப்பட்டது எனிகாஸ்ட் ஐபி ஜிஎல்பி, அதாவது, கூகிள் இருப்பின் மிக நெருக்கமான இடத்திற்கு, அதன் நெட்வொர்க்குகள் வழியாக பிராந்தியத்திற்குச் சென்றது அமெரிக்கா-கிழக்கு4 GCP இல், மாற்று மெய்நிகர் இயந்திரங்கள் இருந்தன (nginx இல் துணை வடிப்பானுடன்).

இந்த கலப்பின தீர்வு, நாங்கள் எதிர்பார்த்தது போலவே, ஒவ்வொரு தொழில்நுட்பத்தின் நன்மைகளையும் பயன்படுத்திக் கொள்ள எங்களுக்கு அனுமதித்தது. பொதுவாக, போக்குவரத்து வேகமான IPSEC வழியாக பாய்கிறது, ஆனால் சிக்கல்கள் ஏற்பட்டால், இந்த சேவையகங்களை சில நிமிடங்களுக்கு மேல்நிலையிலிருந்து விரைவாக அகற்றி, சுரங்கப்பாதை நிலையாகும் வரை CEN வழியாக மட்டுமே போக்குவரத்தை வழிநடத்துகிறோம்.

மேலே உள்ள பட்டியலிலிருந்து 4வது தீர்வைச் செயல்படுத்துவதன் மூலம், நாங்கள் விரும்பியதையும், அந்த நேரத்தில் வணிகம் எங்களிடமிருந்து என்ன தேவைப்பட்டது என்பதையும் அடைந்தோம்.

முந்தைய தீர்வுகளுடன் ஒப்பிடும்போது புதிய தீர்வுக்கான உலாவி சோதனை முடிவுகள்:

முடிவு
முடிந்தநேரம்
சராசரி
75 சதவீதம்
95 சதவீதம்

CloudFlare
86.6
18
30
60

IPsec- ஐ
99.79
18
21
30

இது CEN
99.75
16
21
27

CEN/IPsec + GLB
99.79
13
16
25

வலம்புரி

நாங்கள் செயல்படுத்திய தீர்வு நன்றாக வேலை செய்கிறது, ஆனால் பிராந்திய மற்றும் நகர மட்டத்தில் கூட போக்குவரத்தை துரிதப்படுத்தக்கூடிய CDN எதுவும் இல்லை. கோட்பாட்டளவில், இது CDN வழங்குநரின் வேகமான அலைவரிசையைப் பயன்படுத்தி இறுதி பயனர்களுக்கு தளத்தை விரைவுபடுத்த வேண்டும். இதைப் பற்றி நாங்கள் தொடர்ந்து யோசித்து வருகிறோம். எனவே, திட்டத்தின் அடுத்த மறு செய்கைக்கான நேரம் வந்துவிட்டது: சீனாவில் CDN வழங்குநர்களைக் கண்டுபிடித்து சோதித்தல்.

இதைப் பற்றி அடுத்த, இறுதிப் பகுதியில் நான் உங்களுக்குச் சொல்கிறேன் 🙂

ஆதாரம்: www.habr.com