અમે ચીનની ગ્રેટ ફાયરવોલ કેવી રીતે તોડી નાખી (ભાગ 2)

હેલો!

નિકિતા ફરીથી તમારી સાથે છે, કંપનીની સિસ્ટમ એન્જિનિયર SEMrush. અને આ લેખ સાથે હું કેવી રીતે વર્કઅરાઉન્ડ સોલ્યુશન સાથે આવ્યા તે વિશેની વાર્તા ચાલુ રાખું છું ચિની ફાયરવોલ અમારી સેવા semrush.com માટે.

В અગાઉનો ભાગ મેં કહ્યું:

• નિર્ણય લેવામાં આવ્યા પછી કઈ સમસ્યાઓ ઊભી થાય છે "અમારે ચીનમાં અમારી સેવા કાર્ય કરવાની જરૂર છે"
• ચાઇનીઝ ઇન્ટરનેટને કઈ સમસ્યાઓ છે?
• તમારે શા માટે ICP લાયસન્સની જરૂર છે?
• કેવી રીતે અને શા માટે અમે કેચપોઇન્ટ સાથે અમારા ટેસ્ટબેડ્સનું પરીક્ષણ કરવાનું નક્કી કર્યું
• Cloudflare ચાઇના નેટવર્ક પર આધારિત અમારા પ્રથમ ઉકેલનું પરિણામ શું હતું
• અમને Cloudflare DNS માં બગ કેવી રીતે મળ્યો

મારા મતે, આ ભાગ સૌથી રસપ્રદ છે, કારણ કે તે સ્ટેજીંગના ચોક્કસ તકનીકી અમલીકરણ પર ધ્યાન કેન્દ્રિત કરે છે. અને અમે શરૂ કરીશું, અથવા તેના બદલે ચાલુ રાખીશું, સાથે અલીબાબા મેઘ.

અલીબાબા મેઘ

અલીબાબા મેઘ એકદમ મોટું ક્લાઉડ પ્રદાતા છે, જેની પાસે બધી સેવાઓ છે જે તેને પ્રામાણિકપણે પોતાને ક્લાઉડ પ્રદાતા તરીકે ઓળખવાની મંજૂરી આપે છે. તે સારું છે કે તેમની પાસે વિદેશી વપરાશકર્તાઓ માટે નોંધણી કરવાની તક છે, અને મોટાભાગની સાઇટ અંગ્રેજીમાં અનુવાદિત છે (ચીન માટે આ એક વૈભવી છે). આ ક્લાઉડમાં, તમે વિશ્વના ઘણા પ્રદેશો, મેઇનલેન્ડ ચાઇના, તેમજ ઓશનિક એશિયા (હોંગકોંગ, તાઇવાન, વગેરે) સાથે કામ કરી શકો છો.

આઈપીએસઈસી

અમે ભૂગોળથી શરૂઆત કરી. અમારી ટેસ્ટ સાઇટ Google ક્લાઉડ પર આવેલી હોવાથી, અમારે GCP સાથે અલીબાબા ક્લાઉડને "લિંક" કરવાની જરૂર હતી, તેથી અમે તે સ્થાનોની સૂચિ ખોલી જેમાં Google હાજર છે. તે ક્ષણે તેમની પાસે હજી સુધી હોંગકોંગમાં પોતાનું ડેટા સેન્ટર નહોતું.
સૌથી નજીકનો પ્રદેશ નીકળ્યો એશિયા-પૂર્વ1 (તાઇવાન). અલી મુખ્ય ભૂમિ ચીનનો તાઇવાનનો સૌથી નજીકનો પ્રદેશ બન્યો cn-શેનઝેન (શેનઝેન).

ની મદદ સાથે ટેરાફોર્મ GCP અને અલીમાં સમગ્ર ઈન્ફ્રાસ્ટ્રક્ચરનું વર્ણન અને ઉછેર કર્યું. વાદળો વચ્ચે 100 Mbit/s ની ટનલ લગભગ તરત જ ઉપર ગઈ. શેનઝેન અને તાઇવાનની બાજુએ, પ્રોક્સીંગ વર્ચ્યુઅલ મશીનો ઉભા કરવામાં આવ્યા હતા. શેનઝેનમાં, વપરાશકર્તા ટ્રાફિકને સમાપ્ત કરવામાં આવે છે, ટનલ દ્વારા તાઇવાન તરફ પ્રૉક્સી કરવામાં આવે છે, અને ત્યાંથી તે સીધી અમારી સેવાના બાહ્ય IP પર જાય છે. યુએસ-પૂર્વ (યુએસએ ઇસ્ટ કોસ્ટ). ટનલ દ્વારા વર્ચ્યુઅલ મશીનો વચ્ચે પિંગ કરો 24ms, જે એટલું ખરાબ નથી.

તે જ સમયે, અમે એક પરીક્ષણ વિસ્તાર મૂક્યો અલીબાબા ક્લાઉડ DNS. એનએસ અલીને ઝોન સોંપ્યા પછી, રિઝોલ્યુશનનો સમય 470 ms થી ઘટ્યો 50 મિ.એસ.. આ પહેલા આ ઝોન ક્લાઉડલેફેર પર પણ હતો.

થી ટનલની સમાંતર એશિયા-પૂર્વ1 શેનઝેનથી સીધી બીજી ટનલ ઊભી કરી us-east4. ત્યાં તેઓએ વધુ પ્રોક્સી વર્ચ્યુઅલ મશીનો બનાવ્યાં અને કૂકીઝ અથવા DNS નો ઉપયોગ કરીને ટેસ્ટ ટ્રાફિકને રૂટીંગ કરીને બંને ઉકેલોનું પરીક્ષણ કરવાનું શરૂ કર્યું. નીચેની આકૃતિમાં પરીક્ષણ બેંચનું યોજનાકીય રીતે વર્ણન કરવામાં આવ્યું છે:

ટનલ માટે લેટન્સી નીચે મુજબ હોવાનું બહાર આવ્યું:
અલી cn-શેનઝેન <—> GCP asia-east1 — 24ms
અલી cn-શેનઝેન <—> GCP us-east4 — 200ms

કેચપોઇન્ટ બ્રાઉઝર પરીક્ષણોએ ઉત્તમ સુધારાની જાણ કરી.

બે ઉકેલો માટે પરીક્ષણ પરિણામોની તુલના કરો:

નિર્ણય
અપટાઇમ
મધ્યસ્થ
75 ટકા
95 ટકા

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

આ એવા સોલ્યુશનનો ડેટા છે જે IPSEC ટનલ મારફતે ઉપયોગ કરે છે એશિયા-પૂર્વ1. us-east4 દ્વારા પરિણામો વધુ ખરાબ હતા, અને ત્યાં વધુ ભૂલો હતી, તેથી હું પરિણામો આપીશ નહીં.

બે ટનલના આ પરીક્ષણના પરિણામોના આધારે, જેમાંથી એક ચીનના સૌથી નજીકના પ્રદેશમાં સમાપ્ત થાય છે, અને બીજી અંતિમ મુકામ પર, તે સ્પષ્ટ થઈ ગયું છે કે ચાઇનીઝ ફાયરવોલની નીચેથી ઝડપથી "ઉભરવું" મહત્વપૂર્ણ છે. શક્ય છે, અને પછી ઝડપી નેટવર્ક્સ (CDN પ્રદાતાઓ, ક્લાઉડ પ્રદાતાઓ, વગેરે) નો ઉપયોગ કરો. ફાયરવોલમાંથી પસાર થવાનો પ્રયાસ કરવાની જરૂર નથી અને તમારા ગંતવ્ય પર એક જ સમયે પહોંચવાની જરૂર નથી. આ સૌથી ઝડપી રસ્તો નથી.

સામાન્ય રીતે, પરિણામો ખરાબ નથી હોતા, જો કે, semrush.com પાસે 8.8s અને 75 પર્સેન્ટાઈલ 9.4s (સમાન કસોટી પર) છે.
અને આગળ વધતા પહેલા, હું એક ટૂંકું ગીતાત્મક વિષયાંતર કરવા માંગુ છું.

લિરિકલ ડિગ્રેશન

વપરાશકર્તા સાઇટમાં પ્રવેશ કરે તે પછી www.semrushchina.cn, જે "ઝડપી" ચાઇનીઝ DNS સર્વર્સ દ્વારા ઉકેલે છે, HTTP વિનંતી અમારા ઝડપી ઉકેલમાંથી પસાર થાય છે. પ્રતિસાદ એ જ પાથ સાથે પરત કરવામાં આવે છે, પરંતુ ડોમેન તમામ JS સ્ક્રિપ્ટો, HTML પૃષ્ઠો અને વેબ પૃષ્ઠના અન્ય ઘટકોમાં ઉલ્લેખિત છે. semrush.com વધારાના સંસાધનો માટે કે જે જ્યારે પેજ રેન્ડર કરવામાં આવે ત્યારે લોડ થવું જોઈએ. એટલે કે, ક્લાયંટ "મુખ્ય" એ-રેકોર્ડને ઉકેલે છે www.semrushchina.cn અને ઝડપી ટનલમાં જાય છે, ઝડપથી પ્રતિસાદ મેળવે છે - એક HTML પૃષ્ઠ જે જણાવે છે:

• sso.semrush.com પરથી આવા અને આવા js ડાઉનલોડ કરો,
• cdn.semrush.com પરથી CSS ફાઇલો મેળવો,
• અને dab.semrush.com પરથી કેટલીક તસવીરો પણ લો
• અને તેથી પર.

બ્રાઉઝર આ સંસાધનો માટે "બાહ્ય" ઇન્ટરનેટ પર જવાનું શરૂ કરે છે, દરેક વખતે ફાયરવોલમાંથી પસાર થાય છે જે પ્રતિસાદ સમયને ઉઠાવી લે છે.

પરંતુ પાછલા પરીક્ષણ પરિણામો બતાવે છે જ્યારે પૃષ્ઠ પર કોઈ સંસાધનો ન હોય semrush.comમાત્ર semrushchina.cn, અને *.semrushchina.cn પછી ટનલમાં જવા માટે શેનઝેનમાં વર્ચ્યુઅલ મશીનનું સરનામું નક્કી કરે છે.

ફક્ત આ રીતે, ચાઈનીઝ ફાયરવોલને ઝડપથી પસાર કરવા માટે તમારા સોલ્યુશન દ્વારા તમામ સંભવિત ટ્રાફિકને મહત્તમ કરવા માટે, તમે સ્વીકાર્ય ગતિ અને વેબસાઇટ ઉપલબ્ધતા સૂચકાંકો તેમજ સોલ્યુશન પરીક્ષણોના પ્રમાણિક પરિણામો મેળવી શકો છો.
અમે ટીમના ઉત્પાદન બાજુ પર એક પણ કોડ સંપાદન વિના આ કર્યું.

સબફિલ્ટર

આ સમસ્યા સપાટી પર આવ્યા પછી લગભગ તરત જ ઉકેલનો જન્મ થયો. અમને જરૂર હતી પી.ઓ.સી. (પ્રૂફ ઓફ કોન્સેપ્ટ) કે અમારા ફાયરવોલ પેનિટ્રેશન સોલ્યુશન્સ ખરેખર સારી રીતે કામ કરે છે. આ કરવા માટે, તમારે શક્ય તેટલું આ સોલ્યુશનમાં તમામ સાઇટ ટ્રાફિકને લપેટી લેવાની જરૂર છે. અને અમે અરજી કરી સબફિલ્ટર nginx માં.

સબફિલ્ટર nginx માં એકદમ સરળ મોડ્યુલ છે જે તમને રિસ્પોન્સ બોડીમાં એક લીટીને બીજી લીટીમાં બદલવાની પરવાનગી આપે છે. તેથી અમે બધી ઘટનાઓ બદલી semrush.com પર semrushchina.cn બધા જવાબોમાં.

અને... તે કામ કરતું ન હતું કારણ કે અમને બેકએન્ડ્સમાંથી સંકુચિત સામગ્રી પ્રાપ્ત થઈ હતી, તેથી સબફિલ્ટરને જરૂરી રેખા મળી નથી. મારે nginx માં બીજું સ્થાનિક સર્વર ઉમેરવું પડ્યું, જેણે પ્રતિસાદને ડિકમ્પ્રેસ કર્યો અને તેને આગલા સ્થાનિક સર્વર પર પસાર કર્યો, જે પહેલેથી જ સ્ટ્રિંગને બદલવામાં, તેને સંકુચિત કરવામાં અને તેને સાંકળમાંના આગલા પ્રોક્સી સર્વર પર મોકલવામાં વ્યસ્ત હતું.

પરિણામે, ગ્રાહક ક્યાંથી પ્રાપ્ત કરશે .semrush.com, તેણે પ્રાપ્ત કર્યું .semrushchina.cn અને આજ્ઞાકારીપણે અમારા નિર્ણય દ્વારા ચાલ્યો.

જો કે, ફક્ત ડોમેનને એક રીતે બદલવું પૂરતું નથી, કારણ કે બેકએન્ડ્સ હજુ પણ ક્લાયન્ટની અનુગામી વિનંતીઓમાં semrush.comની અપેક્ષા રાખે છે. તદનુસાર, તે જ સર્વર પર જ્યાં વન-વે રિપ્લેસમેન્ટ કરવામાં આવે છે, એક સરળ રેગ્યુલર એક્સપ્રેશનનો ઉપયોગ કરીને અમને વિનંતીમાંથી સબડોમેઇન મળે છે, અને પછી અમે કરીએ છીએ proxy_pass ચલ સાથે $હોસ્ટ, માં પ્રદર્શિત $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-શેનઝેન и us-east-1 (અમારા માટે સૌથી નજીકનું બિંદુ-પૂર્વ4). અલી માં us-east-1 બીજું વર્ચ્યુઅલ મશીન ઊભું કર્યું જેથી એક વધુ હોય હોપ.

તે આના જેવું બહાર આવ્યું:

બ્રાઉઝર પરીક્ષણ પરિણામો નીચે છે:

નિર્ણય
અપટાઇમ
મધ્યસ્થ
75 ટકા
95 ટકા

CloudFlare
86.6
18s
30s
60s

IPsec
99.79
18s
21s
30s

CEN
99.75
16s
21s
27s

IPSEC કરતાં પ્રદર્શન થોડું સારું છે. પરંતુ IPSEC દ્વારા તમે સંભવિતપણે 100 Mbit/s ની ઝડપે ડાઉનલોડ કરી શકો છો, અને CEN દ્વારા માત્ર 5 Mbit/s અને વધુની ઝડપે ડાઉનલોડ કરી શકો છો.

સંકર જેવું લાગે છે, બરાબર ને? IPSEC ઝડપ અને CEN સ્થિરતાને જોડો.

IPSEC ટનલ નિષ્ફળ જવાની સ્થિતિમાં IPSEC અને CEN બંને મારફતે ટ્રાફિકને મંજૂરી આપીને અમે આ કર્યું છે. અપટાઇમ ઘણો ઊંચો થઈ ગયો છે, પરંતુ સાઇટ લોડિંગ સ્પીડ હજુ પણ ઇચ્છિત થવા માટે ઘણું છોડી દે છે. પછી મેં તે તમામ સર્કિટ દોર્યા જેનો અમે પહેલેથી ઉપયોગ કર્યો હતો અને પરીક્ષણ કર્યું હતું, અને આ સર્કિટમાં થોડી વધુ GCP ઉમેરવાનો પ્રયાસ કરવાનું નક્કી કર્યું, એટલે કે. જી.એલ.બી..

જી.એલ.બી.

જી.એલ.બી. છે વૈશ્વિક લોડ બેલેન્સર (અથવા Google ક્લાઉડ લોડ બેલેન્સર). તે આપણા માટે એક મહત્વપૂર્ણ ફાયદો ધરાવે છે: સીડીએનના સંદર્ભમાં તે ધરાવે છે anycast IP, જે તમને ક્લાયંટની સૌથી નજીકના ડેટા સેન્ટર પર ટ્રાફિકને રૂટ કરવાની મંજૂરી આપે છે, જેથી ટ્રાફિક ઝડપથી Google ના ઝડપી નેટવર્કમાં પ્રવેશ કરે અને "નિયમિત" ઇન્ટરનેટ દ્વારા ઓછું જાય.

બે વાર વિચાર કર્યા વિના, અમે ઊભા કર્યા HTTP/HTTPS LB અમે GCP માં સબફિલ્ટર સાથે અને બેકએન્ડ તરીકે અમારા વર્ચ્યુઅલ મશીનો ઇન્સ્ટોલ કર્યા છે.

ત્યાં ઘણી યોજનાઓ હતી:

• વાપરવુ Cloudflare ચાઇના નેટવર્ક, પરંતુ આ વખતે Origin એ વૈશ્વિક સ્પષ્ટ કરવું જોઈએ IP GLB.
• ખાતે ગ્રાહકોને સમાપ્ત કરો cn-શેનઝેન, અને ત્યાંથી સીધા જ ટ્રાફિકને પ્રોક્સી કરો જી.એલ.બી..
• ચીનથી સીધા જ જાઓ જી.એલ.બી..
• ખાતે ગ્રાહકોને સમાપ્ત કરો cn-શેનઝેન, ત્યાંથી પ્રોક્સી સુધી એશિયા-પૂર્વ1 IPSEC દ્વારા (માં us-east4 CEN દ્વારા), ત્યાંથી GLB પર જાઓ (શાંતિપૂર્વક, નીચે એક ચિત્ર અને સમજૂતી હશે)

અમે આ બધા વિકલ્પો અને ઘણા વધુ હાઇબ્રિડનું પરીક્ષણ કર્યું છે:

• Cloudflare + GLB

અપટાઇમ અને DNS ભૂલોને કારણે આ સ્કીમ અમને અનુકૂળ ન હતી. પરંતુ CF બાજુ પર બગને ઠીક કરવામાં આવે તે પહેલાં પરીક્ષણ હાથ ધરવામાં આવ્યું હતું, કદાચ તે હવે વધુ સારું છે (જોકે, આ HTTP સમયસમાપ્તિને બાકાત કરતું નથી).

• અલી + GLB

આ સ્કીમ અમને અપટાઇમના સંદર્ભમાં પણ અનુકૂળ ન હતી, કારણ કે સ્વીકાર્ય સમય અથવા સમયસમાપ્તિમાં કનેક્ટ થવાની અશક્યતાને કારણે GLB ઘણીવાર અપસ્ટ્રીમમાંથી બહાર નીકળી જાય છે, કારણ કે ચીનની અંદરના સર્વર માટે, GLB સરનામું બહાર રહે છે, અને તેથી પાછળ ચાઇનીઝ ફાયરવોલ. જાદુ થયો નથી.

• માત્ર GLB

અગાઉના વિકલ્પ જેવો જ એક વિકલ્પ, ફક્ત તે ચીનમાં જ સર્વર્સનો ઉપયોગ કરતું ન હતું: ટ્રાફિક સીધો જ GLB પર ગયો (DNS રેકોર્ડ્સ બદલવામાં આવ્યા હતા). તદનુસાર, પરિણામો સંતોષકારક ન હતા, કારણ કે સામાન્ય ઈન્ટરનેટ પ્રદાતાઓની સેવાઓનો ઉપયોગ કરતા સામાન્ય ચાઈનીઝ ક્લાયન્ટ્સ અલી ક્લાઉડ કરતાં ફાયરવોલ પસાર કરવા સાથે વધુ ખરાબ પરિસ્થિતિ ધરાવે છે.

• શેનઝેન -> (CEN/IPSEC) -> પ્રોક્સી -> GLB

અહીં અમે તમામ શ્રેષ્ઠ ઉકેલોનો ઉપયોગ કરવાનું નક્કી કર્યું છે:

• CEN તરફથી સ્થિરતા અને બાંયધરીકૃત SLA
• IPSEC તરફથી ઉચ્ચ ઝડપ
• Google નું "ઝડપી" નેટવર્ક અને તેની કોઈપણ કાસ્ટ.

આ યોજના કંઈક આના જેવી લાગે છે: વપરાશકર્તા ટ્રાફિકને વર્ચ્યુઅલ મશીન પર સમાપ્ત કરવામાં આવે છે ch-શેનઝેન. Nginx અપસ્ટ્રીમ્સ ત્યાં ગોઠવેલ છે, જેમાંથી કેટલાક IPSEC ટનલના બીજા છેડે સ્થિત ખાનગી IP સર્વર્સ તરફ નિર્દેશ કરે છે, અને કેટલાક અપસ્ટ્રીમ્સ CEN ની બીજી બાજુના સર્વરના ખાનગી સરનામાં તરફ નિર્દેશ કરે છે. IPSEC પ્રદેશ માટે ગોઠવેલ એશિયા-પૂર્વ1 GCP માં (સોલ્યુશન બનાવવામાં આવ્યું તે સમયે ચીનનો સૌથી નજીકનો પ્રદેશ હતો. GCP હવે હોંગકોંગમાં પણ હાજરી ધરાવે છે). CEN - પ્રદેશ માટે us-east1 અલી ક્લાઉડમાં.

ત્યારબાદ બંને છેડેથી ટ્રાફિકને નિર્દેશિત કરવામાં આવ્યો હતો anycast IP GLB, એટલે કે, Google ની હાજરીના સૌથી નજીકના બિંદુ સુધી, અને તેના નેટવર્ક દ્વારા પ્રદેશમાં ગયા us-east4 GCP માં, જેમાં રિપ્લેસમેન્ટ વર્ચ્યુઅલ મશીનો હતા (nginx માં સબફિલ્ટર સાથે).

આ હાઇબ્રિડ સોલ્યુશન, જેમ આપણે અપેક્ષા રાખી હતી, દરેક ટેક્નોલોજીના ફાયદાઓનો લાભ લીધો. સામાન્ય રીતે, ટ્રાફિક ઝડપી IPSECમાંથી પસાર થાય છે, પરંતુ જો સમસ્યાઓ શરૂ થાય છે, તો અમે ઝડપથી અને થોડીવાર માટે આ સર્વર્સને અપસ્ટ્રીમમાંથી બહાર કાઢી નાખીએ છીએ અને જ્યાં સુધી ટનલ સ્થિર ન થાય ત્યાં સુધી માત્ર CEN મારફતે જ ટ્રાફિક મોકલીએ છીએ.

ઉપરોક્ત સૂચિમાંથી 4થા ઉકેલને અમલમાં મૂકીને, અમે તે સમયે હાંસલ કર્યું જે અમને જોઈતું હતું અને તે સમયે વ્યવસાય માટે અમને શું જરૂરી હતું.

અગાઉના સોલ્યુશનની તુલનામાં નવા સોલ્યુશન માટે બ્રાઉઝર પરીક્ષણ પરિણામો:

નિર્ણય
અપટાઇમ
મધ્યસ્થ
75 ટકા
95 ટકા

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

સીડીએન

અમે અમલમાં મૂકેલા સોલ્યુશનમાં બધું સારું છે, પરંતુ પ્રાદેશિક અને શહેર સ્તરે પણ ટ્રાફિકને વેગ આપી શકે તેવું કોઈ CDN નથી. સિદ્ધાંતમાં, આનાથી CDN પ્રદાતાની ઝડપી સંચાર ચેનલોનો ઉપયોગ કરીને અંતિમ વપરાશકર્તાઓ માટે સાઇટને ઝડપી બનાવવી જોઈએ. અને અમે બધા સમય તેના વિશે વિચાર્યું. અને હવે, પ્રોજેક્ટના આગામી પુનરાવર્તનનો સમય આવી ગયો છે: ચીનમાં CDN પ્રદાતાઓની શોધ અને પરીક્ષણ.

અને હું તમને આ વિશે આગામી, અંતિમ ભાગમાં કહીશ :)

સોર્સ: www.habr.com