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

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

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

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

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

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

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

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

IPSEC

நாங்கள் புவியியலில் தொடங்கினோம். எங்கள் சோதனைத் தளம் Google Cloud இல் அமைந்திருப்பதால், GCP உடன் Alibaba Cloud ஐ "இணைக்க" வேண்டும், எனவே Google இருக்கும் இடங்களின் பட்டியலைத் திறந்தோம். அந்த நேரத்தில் அவர்களுக்கு ஹாங்காங்கில் இன்னும் சொந்த தரவு மையம் இல்லை.
நெருங்கிய பகுதி மாறியது ஆசியா-கிழக்கு1 (தைவான்). அலி, தைவானுக்கு சீனாவின் பிரதான நிலப்பகுதியின் மிக நெருக்கமான பகுதியாக மாறியது cn-shenzhen (ஷென்சென்).

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

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

சுரங்கப்பாதைக்கு இணையாக ஆசியா-கிழக்கு1 ஷென்செனில் இருந்து நேரடியாக மற்றொரு சுரங்கப்பாதையை உயர்த்தியது us-east4. அங்கு அவர்கள் அதிக ப்ராக்ஸி மெய்நிகர் இயந்திரங்களை உருவாக்கி, இரண்டு தீர்வுகளையும் சோதிக்கத் தொடங்கினர், குக்கீகள் அல்லது 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

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

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

பொதுவாக, முடிவுகள் மோசமாக இல்லை, இருப்பினும், semrush.com சராசரியாக 8.8s மற்றும் 75 Percentile 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 ஐ எதிர்பார்க்கின்றன. அதன்படி, ஒரு வழி மாற்றீடு செய்யப்படும் அதே சேவையகத்தில், ஒரு எளிய வழக்கமான வெளிப்பாட்டைப் பயன்படுத்தி, கோரிக்கையிலிருந்து துணை டொமைனைப் பெறுகிறோம், பின்னர் நாங்கள் செய்கிறோம் ப்ராக்ஸி_பாஸ் மாறி கொண்டு $புரவலன், இல் காட்சிப்படுத்தப்பட்டது $subdomain.semrush.com. இது குழப்பமாகத் தோன்றலாம், ஆனால் அது வேலை செய்கிறது. அது நன்றாக வேலை செய்கிறது. வெவ்வேறு தர்க்கம் தேவைப்படும் தனிப்பட்ட டொமைன்களுக்கு, உங்கள் சொந்த சர்வர் பிளாக்குகளை உருவாக்கி தனியான உள்ளமைவை உருவாக்கவும். இந்த திட்டத்தின் தெளிவு மற்றும் விளக்கத்திற்காக கீழே சுருக்கப்பட்ட nginx கட்டமைப்புகள் உள்ளன.

பின்வரும் கட்டமைப்பு சீனாவிலிருந்து அனைத்து கோரிக்கைகளையும் செயல்படுத்துகிறது .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 (கிளவுட் எண்டர்பிரைஸ் நெட்வொர்க்).

இது CEN

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

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

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

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

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

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

CloudFlare
86.6
18
30
60

IPsec- ஐ
99.79
18
21
30

இது CEN
99.75
16
21
27

செயல்திறன் IPSEC ஐ விட சற்று சிறப்பாக உள்ளது. ஆனால் IPSEC மூலம் நீங்கள் 100 Mbit/s வேகத்திலும், CEN மூலம் 5 Mbit/s மற்றும் அதற்கு மேற்பட்ட வேகத்திலும் பதிவிறக்கம் செய்யலாம்.

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

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

ஜி.எல்.பி.

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

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

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

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

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

• Cloudflare + GLB

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

• அலி + GLB

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

• GLB மட்டும்

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

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

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

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

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

இதையடுத்து, இருபுறமும் போக்குவரத்து மாற்றப்பட்டது anycast IP GLB, அதாவது, கூகுள் இருக்கும் இடத்திற்கு அருகில் சென்று, அதன் நெட்வொர்க்குகள் வழியாக அப்பகுதிக்கு சென்றது us-east4 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