سائٹ کی رفتار کو بہتر بنانے کے لیے تقریباً ہر مضمون یا ٹول میں ایک معمولی شق ہوتی ہے "CDN استعمال کریں۔" عام طور پر، CDN مواد کی ترسیل کا نیٹ ورک یا مواد کی ترسیل کا نیٹ ورک ہے۔ میتھڈ لیب میں ہمیں اکثر اس موضوع پر کلائنٹس کے سوالات کا سامنا کرنا پڑتا ہے؛ ان میں سے کچھ اپنے CDN کو فعال کرتے ہیں۔ اس مضمون کا مقصد یہ سمجھنا ہے کہ CDN سائٹ لوڈنگ کی رفتار کے لحاظ سے کیا فراہم کر سکتا ہے، کیا مسائل پیدا ہو سکتے ہیں، اور کن صورتوں میں CDN کا استعمال جائز ہے۔
تصویر میں گردش کرنے والی تاخیر CDN کے استعمال کی وجہ سے ہوتی ہے۔
تاریخ کا ایک تھوڑا سا
بہت سی ٹیکنالوجیز کی طرح، CDNs ضرورت سے ابھرے ہیں۔ انٹرنیٹ صارفین کے درمیان انٹرنیٹ چینلز کی ترقی کے ساتھ، آن لائن ویڈیو خدمات ظاہر ہوئیں. قدرتی طور پر، ویڈیو مواد کو ویب سائٹ کے باقاعدہ مواد (تصاویر، متن، اور CSS یا JS کوڈ) کے مقابلے میں زیادہ بینڈوتھ کے آرڈرز کی ضرورت ہوتی ہے۔
جب ایک سرور سے متعدد کلائنٹس کے متوازی طور پر ایک ویڈیو سٹریم نشر کرنے کی کوشش کی جائے تو، سرور کا انٹرنیٹ چینل ممکنہ طور پر رکاوٹ بن جائے گا۔ ایک اصول کے طور پر، ایک عام سرور چینل کو روکنے کے لیے چند ہزار تھریڈز کافی ہیں۔ بلاشبہ، وسائل کی دیگر حدود بھی ہو سکتی ہیں، لیکن وہ ابھی اہم نہیں ہیں۔ یہ بھی ضروری ہے کہ سرور چینل کو پھیلانا بہت مہنگا ہے (اور بعض اوقات ناممکن) اور ناقابل عمل بھی۔ نشریات کے دوران چینل پر لوڈ سائیکلکل ہو گا۔
انفرادی سرور کے چینل کو محدود کرنے کا مسئلہ CDN کے ذریعہ بالکل حل کیا جاتا ہے۔ کلائنٹ براہ راست سرور سے نہیں، بلکہ CDN نیٹ ورک میں نوڈس سے جڑتے ہیں۔ ایک مثالی صورت حال میں، سرور ایک سلسلہ CDN نوڈ کو بھیجتا ہے، اور پھر نیٹ ورک اس سلسلے کو بہت سے صارفین تک پہنچانے کے لیے اپنے وسائل کا استعمال کرتا ہے۔ معاشی نقطہ نظر سے، ہم صرف اصل میں استعمال ہونے والے وسائل کے لیے ادائیگی کرتے ہیں (یہ بینڈوتھ یا ٹریفک ہو سکتا ہے) اور اپنی سروس کی بہترین اسکیل ایبلٹی حاصل کرتے ہیں۔ بھاری مواد کی فراہمی کے لیے CDN کا استعمال مکمل طور پر جائز اور منطقی ہے۔ اگرچہ یہ بات قابل غور ہے کہ اس جگہ کے سب سے بڑے کھلاڑی (مثلاً Netflix) بڑے تجارتی CDNs (Akamai، Cloudflare، Fastly، وغیرہ) استعمال کرنے کے بجائے اپنے CDNs بنا رہے ہیں۔
جیسے جیسے ویب تیار ہوا ہے، ویب ایپلیکیشنز خود زیادہ پیچیدہ اور پیچیدہ ہو گئی ہیں۔ لوڈنگ سپیڈ کا مسئلہ سامنے آگیا۔ ویب سائٹ کی رفتار کے شوقین افراد نے جلدی سے کئی بڑے مسائل کی نشاندہی کی جن کی وجہ سے ویب سائٹس آہستہ آہستہ لوڈ ہوتی ہیں۔ ان میں سے ایک نیٹ ورک میں تاخیر تھی (RTT - راؤنڈ ٹرپ ٹائم یا پنگ ٹائم)۔ تاخیر ویب سائٹ کی لوڈنگ میں بہت سے عمل کو متاثر کرتی ہے: ایک TCP کنکشن قائم کرنا، TLS سیشن شروع کرنا، ہر انفرادی وسائل کو لوڈ کرنا (تصویر، JS فائل، HTML دستاویز وغیرہ)
مسئلہ اس حقیقت سے بڑھ گیا کہ HTTP/1.1 پروٹوکول استعمال کرتے وقت (SPDY، QUIC اور HTTP/2 کی آمد سے پہلے یہ واحد آپشن تھا)، براؤزر ایک میزبان کے لیے 6 سے زیادہ TCP کنکشن نہیں کھولتے۔ یہ سب کنکشن ڈاؤن ٹائم اور چینل بینڈوڈتھ کے غیر موثر استعمال کا باعث بنے۔ مسئلہ کو جزوی طور پر ڈومین کی شارڈنگ سے حل کیا گیا تھا - کنکشن کی تعداد کی حد پر قابو پانے کے لیے اضافی میزبانوں کی تخلیق۔
یہ وہ جگہ ہے جہاں CDN کی دوسری قابلیت ظاہر ہوتی ہے - پوائنٹس کی بڑی تعداد اور صارف سے نوڈس کی قربت کی وجہ سے تاخیر (RTT) کو کم کرنا۔ فاصلہ یہاں فیصلہ کن کردار ادا کرتا ہے: روشنی کی رفتار محدود ہے (آپٹیکل فائبر میں تقریباً 200 کلومیٹر فی سیکنڈ)۔ اس کا مطلب ہے کہ ہر 000 کلومیٹر کا سفر RTT میں 1000 ms تاخیر یا 5 ms کا اضافہ کرتا ہے۔ ٹرانسمیشن کے لیے یہ کم از کم وقت درکار ہے، کیونکہ درمیانی آلات میں بھی تاخیر ہوتی ہے۔ چونکہ CDN عام طور پر اپنے سرورز پر اشیاء کو کیش کرنے کا طریقہ جانتا ہے، اس لیے ہم ایسی اشیاء کو CDN کے ذریعے لوڈ کرنے سے فائدہ اٹھا سکتے ہیں۔ اس کے لیے ضروری شرائط: کیشے میں آبجیکٹ کی موجودگی، CDN کی قربت ویب ایپلیکیشن سرور (اوریجن سرور) کے مقابلے میں صارف کی طرف اشارہ کرتی ہے۔ یہ سمجھنا ضروری ہے کہ CDN نوڈ کی جغرافیائی قربت کم تاخیر کی ضمانت نہیں دیتی۔ کلائنٹ اور CDN کے درمیان روٹنگ کو اس طرح بنایا جا سکتا ہے کہ کلائنٹ کسی دوسرے ملک، اور ممکنہ طور پر کسی دوسرے براعظم میں میزبان سے جڑ جائے گا۔ یہیں سے ٹیلی کام آپریٹرز اور CDN سروس کے درمیان تعلق (پیئرنگ، کنکشن، IX میں شرکت وغیرہ) اور خود CDN کی ٹریفک روٹنگ پالیسی عمل میں آتی ہے۔ مثال کے طور پر، Cloudflare، جب دو ابتدائی منصوبے (مفت اور سستے) استعمال کرتے ہیں، تو قریبی میزبان سے مواد کی ترسیل کی ضمانت نہیں دیتا - میزبان کو کم از کم لاگت حاصل کرنے کے لیے منتخب کیا جائے گا۔
بہت ساری سرکردہ انٹرنیٹ کمپنیاں عوام کی دلچسپی (ویب ڈویلپرز اور سروس مالکان) کو لوڈنگ کی رفتار اور ویب سائٹ کی کارکردگی کے موضوع کی طرف راغب کرتی ہیں۔ ان کمپنیوں میں Yahoo (Yslow Tool)، AOL (WebPageTest) اور Google (Page Speed Insights service) شامل ہیں، جو سائٹس کو تیز کرنے کے لیے اپنی سفارشات تیار کر رہی ہیں (بنیادی طور پر ان کا تعلق کلائنٹ آپٹیمائزیشن سے ہے)۔ بعد میں، ویب سائٹ کی رفتار کی جانچ کے نئے ٹولز ظاہر ہوتے ہیں، جو ویب سائٹ کی رفتار بڑھانے کے لیے تجاویز بھی فراہم کرتے ہیں۔ ان خدمات یا پلگ ان میں سے ہر ایک کی مستقل سفارش ہے: "سی ڈی این استعمال کریں۔" نیٹ ورک کی تاخیر میں کمی کو عام طور پر CDN کے اثر کی وضاحت کے طور پر پیش کیا جاتا ہے۔ بدقسمتی سے، ہر کوئی یہ سمجھنے کے لیے تیار نہیں ہے کہ CDN کا ایکسلریشن اثر کیسے حاصل ہوتا ہے اور اس کی پیمائش کیسے کی جا سکتی ہے، اس لیے سفارش کو عقیدے پر لیا جاتا ہے اور اسے ایک فرض کے طور پر استعمال کیا جاتا ہے۔ درحقیقت، تمام CDNs برابر نہیں بنائے گئے ہیں۔
CDN Today استعمال کرنا
CDNs کے استعمال کی افادیت کا اندازہ لگانے کے لیے، انہیں درجہ بندی کرنے کی ضرورت ہے۔ اب عملی طور پر کیا پایا جا سکتا ہے (بریکٹ میں مثالیں، یقیناً مکمل نہیں ہیں):
- JS لائبریریوں کی تقسیم کے لیے مفت CDN (MaxCDN، Google. Yandex)۔
- کلائنٹ کی اصلاح کے لیے خدمات کا CDN (مثال کے طور پر، فونٹس کے لیے Google فونٹس، Cloudinary، Cloudimage برائے تصاویر)۔
- CMS میں جامد اور وسائل کی اصلاح کے لیے CDN (Bitrix، WordPress اور دیگر میں دستیاب ہے)۔
- عمومی مقصد CDN (StackPath، CDNVideo، NGENIX، Megafon)۔
- ویب سائٹ ایکسلریشن کے لیے CDN (Cloudflare، Imperva، Airi)۔
ان اقسام کے درمیان اہم فرق یہ ہے کہ ٹریفک کا کتنا حصہ CDN سے گزرتا ہے۔ اقسام 1-3 مواد کے صرف ایک حصے کی ترسیل ہیں: ایک درخواست سے لے کر کئی درجن تک (عام طور پر تصاویر)۔ 4 اور 5 قسمیں CDN کے ذریعے ٹریفک کی مکمل پراکسینگ ہیں۔
عملی طور پر، اس کا مطلب ہے کنکشنز کی تعداد جو سائٹ کو لوڈ کرنے کے لیے استعمال ہوتے ہیں۔ HTTP/2 کے ساتھ، ہم کسی بھی درخواست پر کارروائی کرنے کے لیے میزبان سے ایک واحد TCP کنکشن استعمال کرتے ہیں۔ اگر ہم وسائل کو مرکزی میزبان (اصل) اور CDN میں تقسیم کرتے ہیں، تو کئی ڈومینز میں درخواستوں کو تقسیم کرنا اور متعدد TCP کنکشن بنانا ضروری ہے۔ بدترین صورت یہ ہے: DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT۔ یہ فارمولہ موبائل نیٹ ورکس میں ڈیوائس کے ریڈیو چینل کو چالو کرنے میں تاخیر (اگر یہ فعال نہیں تھا) اور سیل ٹاور پر تاخیر کو مدنظر نہیں رکھتا ہے۔
سائٹ کے لوڈنگ آبشار پر یہ کیسا لگتا ہے (CDN سے منسلک ہونے کی تاخیر RTT 150 ms پر نمایاں کی گئی ہے):
اگر CDN تمام سائٹ ٹریفک کا احاطہ کرتا ہے (سوائے فریق ثالث کی خدمات کے)، تو ہم ایک TCP کنکشن استعمال کر سکتے ہیں، اضافی میزبانوں سے منسلک ہونے میں تاخیر کو بچا کر۔ بلاشبہ، یہ HTTP/2 کنکشنز پر لاگو ہوتا ہے۔
مزید اختلافات کا تعین کسی خاص CDN کی فعالیت سے کیا جاتا ہے - پہلی قسم کے لیے یہ صرف ایک جامد فائل کی میزبانی کر رہا ہے، پانچویں کے لیے یہ اصلاح کے مقصد کے لیے سائٹ کے مواد کی کئی اقسام کو تبدیل کر رہا ہے۔
ویب سائٹ کو تیز کرنے کے لیے CDN کی صلاحیتیں۔
آئیے CDN کی انفرادی اقسام کی فعالیت کی پرواہ کیے بغیر، سائٹس کو تیز کرنے کے لیے CDN صلاحیتوں کی مکمل رینج بیان کرتے ہیں، اور پھر دیکھیں کہ ان میں سے ہر ایک میں کیا لاگو کیا گیا ہے۔
1. ٹیکسٹ وسائل کا کمپریشن
سب سے بنیادی اور قابل فہم خصوصیت، پھر بھی اکثر ناقص طور پر لاگو کیا جاتا ہے۔ تمام CDNs کمپریشن کی موجودگی کو اپنی سرعت کی خصوصیت قرار دیتے ہیں۔ لیکن اگر آپ مزید تفصیل سے دیکھیں تو کوتاہیاں واضح ہوجاتی ہیں:
- متحرک کمپریشن کے لیے کم ڈگری استعمال کی جا سکتی ہے - 5-6 (مثال کے طور پر، gzip کے لیے زیادہ سے زیادہ 9 ہے)؛
- جامد کمپریشن (کیشے میں فائلیں) اضافی خصوصیات کا استعمال نہیں کرتی ہیں (مثال کے طور پر، ڈگری 11 کے ساتھ زوفی یا بروٹلی)
- موثر بروٹلی کمپریشن کے لئے کوئی تعاون نہیں ہے (gzip کے مقابلے میں تقریبا 20٪ کی بچت)۔
اگر آپ CDN استعمال کرتے ہیں، تو یہ چند نکات کو چیک کرنے کے قابل ہے: CDN سے آنے والی فائل لیں، اس کا کمپریسڈ سائز ریکارڈ کریں اور موازنہ کے لیے اسے دستی طور پر کمپریس کریں (مثال کے طور پر آپ بروٹلی سپورٹ کے ساتھ کچھ آن لائن سروس استعمال کر سکتے ہیں۔ ).
2. کلائنٹ کیشنگ ہیڈر سیٹ کرنا
اس کے علاوہ ایک سادہ اسپیڈ اپ خصوصیت: کلائنٹ (براؤزر) کے ذریعہ مواد کیشنگ کے لیے ہیڈر شامل کریں۔ سب سے موجودہ ہیڈر کیشے کنٹرول ہے، پرانا ایک ختم ہو رہا ہے۔ مزید برآں، Etag استعمال کیا جا سکتا ہے۔ اہم بات یہ ہے کہ کیش کنٹرول کی زیادہ سے زیادہ عمر کافی ہے (ایک ماہ یا اس سے زیادہ سے)۔ اگر آپ وسائل کو زیادہ سے زیادہ مشکل سے کیش کرنے کے لیے تیار ہیں، تو آپ غیر تبدیل شدہ آپشن شامل کر سکتے ہیں۔
CDNs زیادہ سے زیادہ عمر کی قدر کو کم کر سکتے ہیں، جو صارف کو زیادہ کثرت سے جامد مواد کو دوبارہ لوڈ کرنے پر مجبور کر سکتا ہے۔ یہ واضح نہیں ہے کہ یہ کس چیز سے منسلک ہے: نیٹ ورک پر ٹریفک بڑھانے یا ان سائٹس کے ساتھ مطابقت بڑھانے کی خواہش جو کیشے کو دوبارہ ترتیب دینے کا طریقہ نہیں جانتی ہیں۔ مثال کے طور پر، ڈیفالٹ Cloudflare ہیڈر کیشے کا وقت 1 گھنٹہ ہے، جو کہ ناقابل تغیر جامد ڈیٹا کے لیے بہت کم ہے۔
3. تصویر کی اصلاح
چونکہ CDN امیجز کو کیش کرنے اور پیش کرنے کے افعال کو انجام دیتا ہے، لہذا یہ منطقی ہو گا کہ انہیں CDN کی طرف سے بہتر بنایا جائے اور اس فارم میں صارفین کو پیش کیا جائے۔ آئیے فوراً ایک ریزرویشن کرتے ہیں کہ یہ خصوصیت صرف CDN اقسام 2، 3 اور 5 کے لیے دستیاب ہے۔
آپ مختلف طریقوں سے امیجز کو بہتر بنا سکتے ہیں: ایڈوانس کمپریشن فارمیٹس (جیسے WebP)، زیادہ موثر انکوڈرز (MozJPEG) کا استعمال، یا محض غیر ضروری میٹا ڈیٹا کو صاف کرنا۔
عام طور پر، اس طرح کی اصلاح کی دو قسمیں ہیں: معیار کے نقصان کے ساتھ اور معیار کے نقصان کے بغیر۔ تصویر کے معیار میں تبدیلی کے بارے میں گاہک کی ممکنہ شکایات سے بچنے کے لیے CDNs عام طور پر بے مقصد اصلاح استعمال کرنے کی کوشش کرتے ہیں۔ ایسے حالات میں فائدہ کم سے کم ہوگا۔ حقیقت میں، اکثر JPEG معیار کی سطح ضرورت سے بہت زیادہ ہوتی ہے اور آپ صارف کے تجربے سے سمجھوتہ کیے بغیر محفوظ طریقے سے کم معیار کی سطح کے ساتھ دوبارہ کمپریس کر سکتے ہیں۔ دوسری طرف، تمام ممکنہ ویب ایپلیکیشنز کے لیے عالمی سطح پر معیار اور ترتیبات کی سطح کا تعین کرنا مشکل ہے، اس لیے CDNs ان کے مقابلے میں زیادہ قدامت پسند ترتیبات استعمال کرتے ہیں جو سیاق و سباق کو مدنظر رکھتے ہوئے لاگو کی جا سکتی ہیں (تصاویر کا مقصد، ویب ایپلیکیشن کی قسم وغیرہ)
4. TLS کنکشن کو بہتر بنانا
آج زیادہ تر ٹریفک TLS کنکشن پر سفر کرتی ہے، جس کا مطلب ہے کہ ہم TLS مذاکرات پر اضافی وقت صرف کرتے ہیں۔ حال ہی میں اس عمل کو تیز کرنے کے لیے نئی ٹیکنالوجیز تیار کی گئی ہیں۔ مثال کے طور پر، یہ EC کرپٹوگرافی، TLS 1.3، سیشن کیش اور ٹکٹس، ہارڈویئر انکرپشن ایکسلریشن (AES-NI) وغیرہ ہے۔ TLS کو درست طریقے سے ترتیب دینے سے کنکشن کا وقت 0-1 RTT تک کم ہو سکتا ہے (DNS اور TCP کو شمار نہیں کرنا)۔
جدید سافٹ ویئر کے ساتھ، خود سے اس طرح کے طریقوں کو لاگو کرنا مشکل نہیں ہے.
تمام CDNs TLS بہترین طریقوں پر عمل درآمد نہیں کرتے ہیں؛ آپ اسے TLS کنکشن کے وقت کی پیمائش کر کے چیک کر سکتے ہیں (مثال کے طور پر، Webpagetest میں)۔ نئے کنکشن کے لیے مثالی - 1RTT، 2RTT - اوسط لیول، 3RTT اور مزید - خراب۔
یہ بھی واضح رہے کہ CDN سطح پر TLS استعمال کرتے وقت بھی، ہماری ویب ایپلیکیشن کے ساتھ سرور کو بھی TLS پر کارروائی کرنی چاہیے، لیکن CDN کی طرف سے، کیونکہ سرور اور CDN کے درمیان ٹریفک پبلک نیٹ ورک پر گزرتی ہے۔ بدترین صورت میں، ہمیں TLS کنکشن میں دوہری تاخیر ملے گی (سب سے پہلے CDN میزبان کو، دوسرا اس کے اور ہمارے سرور کے درمیان)۔
کچھ ایپلی کیشنز کے لیے، سیکورٹی کے مسائل پر توجہ دینے کے قابل ہے: ٹریفک کو عام طور پر CDN نوڈس پر ڈکرپٹ کیا جاتا ہے، اور یہ ٹریفک کو روکنے کا ایک ممکنہ موقع ہے۔ ٹریفک کے انکشاف کے بغیر کام کرنے کا اختیار عام طور پر ایک اضافی فیس کے لیے اعلیٰ ٹیرف پلان میں پیش کیا جاتا ہے۔
5. کنکشن میں تاخیر کو کم کریں۔
CDN کا بنیادی فائدہ جس کے بارے میں ہر کوئی بات کرتا ہے: CDN میزبان اور صارف کے درمیان کم تاخیر (کم فاصلہ)۔ جغرافیائی طور پر تقسیم شدہ نیٹ ورک فن تعمیر کے ذریعے حاصل کیا گیا، جس میں میزبان صارفین کے ارتکاز کے مقامات (شہر، ٹریفک ایکسچینج پوائنٹس، وغیرہ) میں واقع ہیں۔
عملی طور پر، مختلف نیٹ ورکس کی ترجیحات مخصوص علاقوں میں ہوسکتی ہیں۔ مثال کے طور پر، روسی CDNs کی روس میں موجودگی کے مزید مقامات ہوں گے۔ امریکی سب سے پہلے امریکہ میں نیٹ ورک تیار کریں گے۔ مثال کے طور پر، سب سے بڑے CDN Cloudflare میں سے ایک کے پاس روس میں صرف 2 پوائنٹس ہیں - ماسکو اور سینٹ پیٹرزبرگ۔ یعنی، ہم ماسکو میں براہ راست جگہ کا تعین کرنے کے مقابلے میں زیادہ سے زیادہ 10 ایم ایس کی تاخیر بچا سکتے ہیں۔
زیادہ تر مغربی CDNs کے پاس روس میں بالکل بھی پوائنٹس نہیں ہیں۔ ان سے منسلک ہو کر، آپ صرف اپنے روسی سامعین کے لیے تاخیر میں اضافہ کر سکتے ہیں۔
6. مواد کی اصلاح (منفی، ساختی تبدیلیاں)
سب سے پیچیدہ اور تکنیکی طور پر جدید ترین نقطہ۔ ڈیلیوری کے دوران مواد کو تبدیل کرنا بہت خطرناک ہو سکتا ہے۔ یہاں تک کہ اگر ہم minification لیتے ہیں: سورس کوڈ کو کم کرنا (اضافی جگہوں، غیر اہم ڈھانچے وغیرہ کی وجہ سے) اس کی کارکردگی کو متاثر کر سکتا ہے۔ اگر ہم مزید سنگین تبدیلیوں کے بارے میں بات کرتے ہیں - جے ایس کوڈ کو ایچ ٹی ایم ایل کے آخر میں منتقل کرنا، فائلوں کو ضم کرنا وغیرہ - سائٹ کی فعالیت میں خلل ڈالنے کا خطرہ اور بھی زیادہ ہے۔
لہذا، صرف کچھ قسم 5 CDNs یہ کرتے ہیں. بلاشبہ، چیزوں کو تیز کرنے کے لیے درکار تمام تبدیلیوں کو خودکار بنانا ممکن نہیں ہوگا — دستی تجزیہ اور اصلاح درکار ہے۔ مثال کے طور پر، غیر استعمال شدہ یا ڈپلیکیٹ کوڈ کو ہٹانا ایک دستی کام ہے۔
ایک اصول کے طور پر، اس طرح کی تمام اصلاح کو ترتیبات کے ذریعے کنٹرول کیا جاتا ہے اور سب سے زیادہ خطرناک کو بطور ڈیفالٹ غیر فعال کر دیا جاتا ہے۔
CDN قسم کی طرف سے ایکسلریشن کی صلاحیتوں کے لیے سپورٹ
تو آئیے اس پر ایک نظر ڈالتے ہیں کہ مختلف قسم کے CDNs کس ممکنہ سرعت کے مواقع فراہم کرتے ہیں۔
سہولت کے لیے، ہم درجہ بندی کو دہراتے ہیں۔
- JS لائبریریوں کی تقسیم کے لیے مفت CDN (MaxCDN، Google. Yandex)۔
- کلائنٹ کی اصلاح کے لیے خدمات کا CDN (مثال کے طور پر، فونٹس کے لیے Google فونٹس، Cloudinary، Cloudimage برائے تصاویر)۔
- CMS میں جامد اور وسائل کی اصلاح کے لیے CDN (Bitrix، WordPress اور دیگر میں دستیاب ہے)۔
- عمومی مقصد CDN (StackPath، CDNVideo، NGENIX، Megafon)۔
- ویب سائٹ ایکسلریشن کے لیے CDN (Cloudflare، Imperva، Airi)۔
اب آئیے CDN کی خصوصیات اور اقسام کا موازنہ کریں۔
موقع
ٹائپ کریں 1
ٹائپ کریں 2
ٹائپ کریں 3
ٹائپ کریں 4
ٹائپ کریں 5
ٹیکسٹ کمپریشن
+ -
-
+ -
+ -
+
کیشے ہیڈرز
+
+
+
+
+
تصویریں
-
+ -
+ -
-
+
TLS
-
-
-
+ -
+
تاخیر
-
-
-
+
+
مواد
-
-
-
-
+
اس جدول میں، "+" کا استعمال مکمل حمایت کی نشاندہی کرنے کے لیے کیا جاتا ہے، "-" کوئی سپورٹ نہیں ہے، اور "+-" جزوی حمایت ہے۔ بلاشبہ، حقیقت میں اس جدول سے انحراف ہو سکتا ہے (مثال کے طور پر، کچھ عمومی مقصد CDN تصاویر کو بہتر بنانے کے لیے خصوصیات کو نافذ کرے گا)، لیکن عام خیال کے لیے یہ مفید ہے۔
کے نتائج
امید ہے کہ اس مضمون کو پڑھنے کے بعد آپ کو اپنی سائٹوں کو تیز کرنے کے لیے "CDN استعمال کریں" کی سفارش کے حوالے سے ایک واضح تصویر ملے گی۔
کسی بھی کاروبار کی طرح، آپ کسی بھی سروس کے مارکیٹنگ کے وعدوں پر یقین نہیں کر سکتے۔ اثر کو حقیقی حالات میں ماپا اور جانچنے کی ضرورت ہے۔ اگر آپ پہلے سے ہی CDN استعمال کر رہے ہیں، تو مضمون میں بیان کردہ معیار کو استعمال کرتے ہوئے اس کی تاثیر کو چیک کریں۔
یہ ممکن ہے کہ ابھی CDN استعمال کرنے سے آپ کی سائٹ کے لوڈ ہونے کا وقت کم ہو رہا ہے۔
ایک عمومی تجویز کے طور پر، ہم درج ذیل پر توجہ مرکوز کر سکتے ہیں: اپنے سامعین کا مطالعہ کریں، اس کے جغرافیائی دائرہ کار کا تعین کریں۔ اگر آپ کے مرکزی سامعین 1-2 ہزار کلومیٹر کے دائرے میں مرکوز ہیں، تو آپ کو اس کے بنیادی مقصد یعنی تاخیر کو کم کرنے کے لیے CDN کی ضرورت نہیں ہے۔ اس کے بجائے، آپ اپنے سرور کو اپنے صارفین کے قریب رکھ سکتے ہیں اور اسے مناسب طریقے سے ترتیب دے سکتے ہیں، مضمون میں بیان کردہ زیادہ تر اصلاحات حاصل کر کے (مفت اور مستقل)۔
اگر آپ کے سامعین کو واقعی جغرافیائی طور پر تقسیم کیا گیا ہے (3000 کلومیٹر سے زیادہ کا رداس) تو معیاری CDN استعمال کرنا واقعی مفید ہوگا۔ تاہم، آپ کو پہلے سے ہی یہ سمجھنا ہوگا کہ آپ کا CDN بالکل کیا تیز کر سکتا ہے (صلاحیتوں کا جدول اور ان کی تفصیل دیکھیں)۔ تاہم، ویب سائٹ کی سرعت اب بھی ایک پیچیدہ کام ہے جسے CDN کو جوڑنے سے حل نہیں کیا جا سکتا۔ مندرجہ بالا اصلاح کے علاوہ، سرعت کے سب سے مؤثر ذرائع CDN کے پیچھے رہتے ہیں: سرور کے حصے کی اصلاح، کلائنٹ کے حصے میں جدید تبدیلیاں (غیر استعمال شدہ کوڈ کو ہٹانا، رینڈرنگ کے عمل کو بہتر بنانا، مواد کے ساتھ کام کرنا، فونٹس، موافقت، وغیرہ۔ )
ماخذ: www.habr.com