هيلو!
نيڪيتا توهان سان گڏ آهي، ڪمپني مان هڪ سسٽم انجنيئر SEMrush. ۽ هن آرٽيڪل سان گڏ آئون ڪهاڻي جاري رکان ٿو ته اسان ڪئين حل سان گڏ آيا آهيون چيني فائر وال اسان جي خدمت لاءِ semrush.com.
В مون چيو:
- فيصلو ٿيڻ کان پوءِ ڪهڙا مسئلا پيدا ٿين ٿا ”اسان کي چين ۾ اسان جي سروس ڪم ڪرڻ جي ضرورت آهي“
- چيني انٽرنيٽ جا ڪهڙا مسئلا آهن؟
- توهان کي ICP لائسنس جي ضرورت ڇو آهي؟
- اسان ڪيئن ۽ ڇو اسان جي ٽيسٽ بيڊ کي ڪيچ پوائنٽ سان جانچڻ جو فيصلو ڪيو
- Cloudflare چائنا نيٽورڪ تي ٻڌل اسان جي پهرين حل جو نتيجو ڇا هو
- اسان کي Cloudflare DNS ۾ هڪ بگ ڪيئن مليو
هي حصو سڀ کان وڌيڪ دلچسپ آهي، منهنجي خيال ۾، ڇاڪاڻ ته اهو اسٽيجنگ جي مخصوص ٽيڪنالاجي عملن تي ڌيان ڏئي ٿو. ۽ اسان شروع ڪنداسين، يا بلڪه جاري رکو، سان علي بابا ڪڪر.
علي بابا ڪڪر
علي بابا ڪڪر هڪ تمام وڏو ڪلائوڊ فراهم ڪندڙ آهي، جنهن ۾ اهي سڀئي خدمتون آهن جيڪي ان کي ايمانداري سان پاڻ کي ڪلائوڊ فراهم ڪندڙ سڏڻ جي اجازت ڏين ٿيون. اهو سٺو آهي ته انهن وٽ غير ملڪي استعمال ڪندڙن لاءِ رجسٽر ٿيڻ جو موقعو آهي، ۽ اها سائيٽ گهڻو ڪري انگريزيءَ ۾ ترجمو ٿيل آهي (چين لاءِ هي هڪ عيش آهي). ھن بادل ۾، توھان ڪم ڪري سگھوٿا دنيا جي ڪيترن ئي علائقن، سرزمين چين، گڏوگڏ سامونڊي ايشيا (هانگ ڪانگ، تائيوان، وغيره).
IPSEC
اسان جغرافيائي سان شروع ڪيو. جيئن ته اسان جي ٽيسٽ سائيٽ گوگل ڪلائوڊ تي واقع هئي، اسان کي علي بابا ڪلائوڊ کي GCP سان ”لنڪ“ ڪرڻ جي ضرورت هئي، تنهن ڪري اسان انهن هنڌن جي هڪ فهرست کولي جنهن ۾ گوگل موجود آهي. انهي وقت انهن وٽ اڃا تائين هانگ ڪانگ ۾ پنهنجو ڊيٽا سينٽر نه هو.
ويجھو علائقو نڪتو ايشيا-اوڀر 1 (تائيوان). علي، سرزمين چين جو سڀ کان ويجھو علائقو تائيوان مان نڪتو سي اين-شينزين (شينزين).
جي مدد سان ٽريفڪ بيان ڪيو ۽ GCP ۽ علي ۾ سڄي زيربنا کي وڌايو. ڪڪرن جي وچ ۾ هڪ 100 Mbit/s سرنگ لڳ ڀڳ فوري طور تي مٿي ٿي وئي. شينزين ۽ تائيوان جي پاسي، پراکسينگ ورچوئل مشينون بلند ڪيون ويون. شينزين ۾، صارف جي ٽرئفڪ کي ختم ڪيو ويو آهي، هڪ سرنگ ذريعي تائيوان ڏانهن پراڪس ڪيو ويو آهي، ۽ اتان اهو سڌو اسان جي خدمت جي ٻاهرين IP ڏانهن وڃي ٿو. آمريڪا- اوڀر (آمريڪا ايسٽ ڪوسٽ). سرنگ ذريعي مجازي مشينن جي وچ ۾ پنگ 24MS، جيڪو ايترو خراب ناهي.
ساڳئي وقت، اسان هڪ امتحان واري علائقي ۾ رکيا علي بابا Cloud DNS. اين ايس علي کي زون جي حوالي ڪرڻ کان پوء، قرارداد جو وقت 470 ايم ايس کان گهٽجي ويو 50 MS. ان کان اڳ، زون پڻ Cloudlfare تي هو.
سرنگهه ڏانهن متوازي ايشيا-اوڀر 1 شينزين کان سڌو سنئون ٻي سرنگ کي وڌايو us-east4. اتي انهن وڌيڪ پراکسي ورچوئل مشينون ٺاهيون ۽ ٻنهي حلن کي جانچڻ شروع ڪيو، ڪوڪيز يا ڊي اين ايس استعمال ڪندي ٽيسٽ ٽريفڪ جي روٽنگ. ٽيسٽ بينچ کي هيٺ ڏنل شڪل ۾ اسڪيم طور بيان ڪيو ويو آهي:
سرنگن لاءِ ليٽيسي هن ريت نڪرندي آهي:
علي سي اين-شينزين <-> GCP ايشيا-ايسٽ 1 - 24ms
علي cn-shenzhen <-> GCP us-east4 - 200ms
ڪيچ پوائنٽ برائوزر ٽيسٽ بهترين سڌارو ٻڌايو.
ٻن حلن لاءِ ٽيسٽ جا نتيجا موازنہ ڪريو:
فيصلو
سمجھو
ميڊيڪل
75 سيڪڙو
95 سيڪڙو
پنهنجي
86.6
18s
30s
60s
IPsec
99.79
18s
21s
30s
اهو هڪ حل مان ڊيٽا آهي جيڪو استعمال ڪري ٿو IPSEC سرنگ ذريعي ايشيا-اوڀر 1. اسان جي ذريعي اوڀر 4 نتيجا خراب هئا، ۽ وڌيڪ غلطيون هيون، تنهنڪري مان نتيجا نه ڏيندس.
ٻن سرنگن جي هن ٽيسٽ جي نتيجن جي بنياد تي، جن مان هڪ کي چين جي ويجھي علائقي ۾ ختم ڪيو ويو آهي، ۽ ٻيو آخري منزل تي، اهو واضح ٿي ويو آهي ته اهو ضروري آهي ته "اڀرڻ" چيني فائر وال جي هيٺان جلدي جلدي. ممڪن آهي، ۽ پوءِ تيز نيٽ ورڪ استعمال ڪريو (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 ڊائون لوڊ ڪريو،
- CSS فائلون حاصل ڪريو cdn.semrush.com تان،
- ۽ dab.semrush.com تان ڪجھ تصويرون پڻ وٺو
- ۽ پوء تي.
برائوزر انهن وسيلن لاءِ ”خارجي“ انٽرنيٽ ڏانهن وڃڻ شروع ڪري ٿو، هر ڀيري فائر وال مان گذرندو آهي جيڪو جوابي وقت کي کائي ٿو.
پر پوئين امتحان ڏيکاري ٿو نتيجن کي جڏهن صفحي تي ڪو وسيلا نه آهن semrush.comصرف semrushchina.cn، ۽ *.semrushchina.cn شينزين ۾ ورچوئل مشين جي ايڊريس کي حل ڪري ٿو ته پوءِ سرنگ ۾ داخل ٿيڻ لاءِ.
صرف هن طريقي سان، توهان جي حل ذريعي تمام ممڪن ٽرئفڪ کي وڌ ۾ وڌ تيز ڪرڻ سان چيني فائر وال کي جلدي پاس ڪرڻ لاء، توهان حاصل ڪري سگهو ٿا قابل قبول رفتار ۽ ويب سائيٽ جي دستيابي جا اشارا، انهي سان گڏ حل ٽيسٽ جا ايماندار نتيجا.
اسان ٽيم جي پراڊڪٽ واري پاسي تي هڪ ڪوڊ ايڊٽ ڪرڻ کان سواءِ ڪيو.
ذيلي فلٽر
هن مسئلي جي ظاهر ٿيڻ کان پوء، حل تقريبا فوري طور تي پيدا ٿيو. اسان کي ضرورت هئي پو (تصور جو ثبوت) ته اسان جي فائر وال جي دخول جا حل واقعي سٺو ڪم ڪن ٿا. هن کي ڪرڻ لاء، توهان کي تمام ممڪن حد تائين هن حل ۾ سڀني سائيٽ ٽرئفڪ کي لپائڻ جي ضرورت آهي. ۽ اسان لاڳو ڪيو 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;
}
}هي config proxies ڏانهن مقامي هلو پورٽ 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 سرنگن جي گرڻ بابت افسانه جي تصديق نه ڪئي وئي هئي. پر پوءِ سرنگون ڪرڻ لڳيون. ڏينهن ۾ ڪيترائي ڀيرا چند منٽن لاء. ٿورڙو، پر اهو اسان کي مناسب نه هو. جيئن ته ٻنهي سرنگن کي ساڳئي روٽر تي علي پاسي ختم ڪيو ويو، اسان فيصلو ڪيو ته شايد اهو هڪ علائقائي مسئلو هو ۽ اسان کي بيڪ اپ واري علائقي کي وڌائڻ جي ضرورت آهي.
هنن ان کي کنيو. سرنگون مختلف وقتن تي ناڪام ٿيڻ شروع ڪيون، پر اسان جي لاءِ ناڪاري ڪم ڪيو نينڪس ۾ اپ اسٽريم جي سطح تي. پر پوءِ لڳ ڀڳ ساڳئي وقت سرنگون گرڻ شروع ٿيون 🙂 ۽ 502 ۽ 504 ٻيهر شروع ٿيا، اپٽائم خراب ٿيڻ لڳو، تنهنڪري اسان ان سان گڏ آپشن تي ڪم ڪرڻ شروع ڪيو. علي بابا CEN (Cloud Enterprise Network).
CEN
CEN - هي علي بابا ڪلائوڊ اندر مختلف علائقن مان ٻن VPCs جو ڪنيڪشن آهي، يعني توهان ڪلائوڊ اندر ڪنهن به علائقي جي نجي نيٽ ورڪن کي هڪ ٻئي سان ڳنڍي سگهو ٿا. ۽ سڀ کان اهم: هن چينل ۾ ڪافي سخت آهي SLA. اهو رفتار ۽ اپ ٽائيم ٻنهي ۾ تمام مستحڪم آهي. پر اهو ڪڏهن به سادو ناهي:
- اهو حاصل ڪرڻ تمام ڏکيو آهي جيڪڏهن توهان چيني شهري يا قانوني ادارو نه آهيو،
- توهان کي هر ميگا بائيٽ چينل جي گنجائش لاءِ ادا ڪرڻو پوندو.
ڳنڍڻ جو موقعو مليو مينينڊلينڊ چين и اوورسيز، اسان ٻن علي علائقن جي وچ ۾ هڪ CEN ٺاهيو: سي اين-شينزين и us-east-1 (اسان جي ويجھي پوائنٽ- اوڀر 4). عليءَ ۾ us-east-1 هڪ ٻي مجازي مشين کي وڌايو ته جيئن هڪ وڌيڪ آهي ها.
اهو هن طرح ظاهر ٿيو:
برائوزر ٽيسٽ جا نتيجا ھيٺ ڏنل آھن:
فيصلو
سمجھو
ميڊيڪل
75 سيڪڙو
95 سيڪڙو
پنهنجي
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 شامل ڪرڻ جي ڪوشش ڪرڻ جو فيصلو ڪيو، يعني ايل ايل بي.
ايل ايل بي
ايل ايل بي - هي آهي (يا گوگل ڪلائوڊ لوڊ بيلنسر). اهو اسان لاءِ هڪ اهم فائدو آهي: سي ڊي اين جي حوالي سان اهو آهي anycast IP، جيڪو توهان کي اجازت ڏئي ٿو ٽريفڪ کي ڪلائنٽ جي ويجھو ڊيٽا سينٽر ڏانهن رستو ، انهي ڪري ته ٽرئفڪ جلدي گوگل جي تيز نيٽ ورڪ ۾ وڃي ٿي ۽ گهٽ ”باقاعده“ انٽرنيٽ ذريعي وڃي ٿي.
ٻه ڀيرا سوچڻ کان سواء، اسان اٿي HTTP/HTTPS LB اسان پنھنجي ورچوئل مشينن کي GCP ۾ ذيلي فلٽر سان ۽ ھڪڙي پس منظر جي طور تي نصب ڪيو.
اتي ڪيترائي منصوبا هئا:
- استعمال ڪريو Cloudflare چائنا نيٽورڪ، پر هن ڀيري Origin کي گلوبل بيان ڪرڻ گهرجي IP GLB.
- تي گراهڪن کي ختم ڪريو سي اين-شينزين، ۽ اتان کان سڌو ٽريفڪ کي پراکسي ايل ايل بي.
- چين کان سڌو وڃو ايل ايل بي.
- تي گراهڪن کي ختم ڪريو سي اين-شينزين، اتان کان proxy ڏانهن ايشيا-اوڀر 1 IPSEC ذريعي (۾ us-east4 CEN ذريعي)، اتان وڃو GLB (آرام سان، هيٺ ڏنل تصوير ۽ وضاحت هوندي)
اسان انهن سڀني اختيارن کي آزمايو ۽ ڪيترائي وڌيڪ هائبرڊ وارا:
- Cloudflare + GLB
هي اسڪيم اسان جي مطابق نه هئي اپ ٽائم ۽ DNS غلطين جي ڪري. پر ٽيسٽ ڪيو ويو ان کان اڳ جو بگ مقرر ڪيو ويو CF پاسي، شايد اهو هاڻي بهتر آهي (جڏهن ته، هي HTTP ٽائيم آئوٽ کي خارج نٿو ڪري).
- علي + جي ايل بي
اها اسڪيم اسان کي اپٽائم جي لحاظ کان به مناسب نه هئي، ڇاڪاڻ ته GLB اڪثر ڪري اپ اسٽريم کان ٻاهر ٿي ويندو آهي ڇاڪاڻ ته قابل قبول وقت يا ٽائم آئوٽ ۾ ڳنڍڻ جي ناممڪن ٿيڻ جي ڪري، ڇاڪاڻ ته چين جي اندر سرور لاءِ، GLB ايڊريس ٻاهر رهي ٿي، ۽ تنهن ڪري. چيني فائر وال. جادو نه ٿيو.
- صرف GLB
ھڪڙو اختيار اڳئين ھڪڙي وانگر، صرف اھو چين ۾ سرور استعمال نه ڪيو: ٽرئفڪ سڌو سنئون GLB ڏانھن ويو (ڊي اين ايس ريڪارڊ تبديل ڪيا ويا). ان جي مطابق، نتيجا اطمينان بخش نه هئا، ڇاڪاڻ ته عام چيني گراهڪ عام انٽرنيٽ فراهم ڪندڙن جي خدمتن کي استعمال ڪندي علي ڪلائوڊ جي ڀيٽ ۾ فائر وال کي پاس ڪرڻ سان تمام خراب صورتحال آهي.
- شينزين -> (CEN/IPSEC) -> پراکسي -> GLB
هتي اسان سڀني حلن مان بهترين استعمال ڪرڻ جو فيصلو ڪيو:
- استحڪام ۽ ضمانت ٿيل SLA CEN کان
- IPSEC کان تيز رفتار
- گوگل جو ”تيز“ نيٽ ورڪ ۽ ان جو ڪاسٽ.
اسڪيم ڪجهه هن طرح ڏسڻ ۾ اچي ٿو: صارف ٽرئفڪ کي ختم ڪيو ويو آهي مجازي مشين تي ch-شينزين. نينگڪس اپ اسٽريم اتي ترتيب ڏنل آهن، جن مان ڪجهه پوائنٽ IPSEC سرنگ جي ٻئي پڇاڙي تي واقع نجي IP سرورز ڏانهن، ۽ ڪجهه اپ اسٽريم سي اين جي ٻئي پاسي سرورز جي نجي پتي ڏانهن اشارو ڪن ٿا. IPSEC علائقي ڏانهن ترتيب ڏني وئي ايشيا-اوڀر 1 GCP ۾ (جڏهن حل پيدا ڪيو ويو ته چين جي ويجهو ترين علائقو هو. GCP هاڻي هانگ ڪانگ ۾ پڻ موجود آهي). CEN - علائقي ڏانهن us-east1 علي بادل ۾.
پوءِ ٻنهي پاسن کان ٽريفڪ کي هدايت ڪئي وئي anycast IP GLB، اهو آهي، گوگل جي موجودگي جي ويجهي نقطي تائين، ۽ ان جي نيٽ ورڪ ذريعي علائقي ڏانهن ويو us-east4 GCP ۾، جنهن ۾ متبادل مجازي مشينون هيون (نگينڪس ۾ ذيلي فلٽر سان).
هي هائبرڊ حل، جيئن اسان توقع ڪئي، هر ٽيڪنالاجي جي فائدن جو فائدو ورتو. عام طور تي، ٽريفڪ تيزيءَ سان IPSEC ذريعي ٿئي ٿي، پر جيڪڏهن مسئلا شروع ٿين ٿا، اسان جلدي ۽ چند منٽن لاءِ انهن سرورز کي اپ اسٽريم مان ٻاهر ڪڍون ٿا ۽ ٽريفڪ صرف CEN ذريعي موڪلين ٿا جيستائين سرنگ مستحڪم نه ٿئي.
مٿي ڏنل فهرست مان چوٿين حل کي لاڳو ڪرڻ سان، اسان حاصل ڪيو جيڪو اسان چاهيون ٿا ۽ ڇا ڪاروبار اسان کي ان وقت جي ضرورت آهي.
اڳوڻين جي مقابلي ۾ نئين حل لاءِ برائوزر ٽيسٽ جا نتيجا:
فيصلو
سمجھو
ميڊيڪل
75 سيڪڙو
95 سيڪڙو
پنهنجي
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 فراهم ڪندڙ جي فاسٽ ڪميونيڪيشن چينلز کي استعمال ڪندي آخري صارفين لاءِ سائيٽ کي تيز ڪرڻ گهرجي. ۽ اسان ان بابت هر وقت سوچيو. ۽ هاڻي، وقت اچي ويو آهي منصوبي جي ايندڙ ورهاڱي لاء: چين ۾ سي ڊي اين فراهم ڪندڙن جي ڳولا ۽ جانچ.
۽ مان توهان کي ان بابت ايندڙ، آخري حصي ۾ ٻڌائيندس :)
جو ذريعو: www.habr.com