CDN زمانی مفید است که مسیر تحویل محتوا را کوتاهتر و بار سرور اصلی را کمتر کند؛ نه صرفاً وقتی رکورد DNS را پشت یک سرویس ابری قرار میدهید. اگر نقاط حضور به کاربران شما نزدیک نباشند، قوانین Cache اشتباه باشند یا سرور مبدأ همچنان مستقیماً در دسترس بماند، ممکن است هزینه و پیچیدگی اضافه شود بدون آنکه سرعت یا امنیت واقعاً بهتر شود.
در این راهنما میخوانید CDN چیست، چه زمانی برای سایت ایرانی ارزش دارد، چگونه ارائهدهنده را با تست واقعی انتخاب کنید و استقرار را بدون اختلال انجام دهید. برای سایت چندزبانه یا کسبوکاری که کاربران چند کشور را هدف میگیرد، راهنمای تخصصی CDN برای سایت بینالمللی و SEO چندمنطقهای را ببینید.
CDN چیست و چگونه کار میکند؟
شبکه توزیع محتوا یا Content Delivery Network مجموعهای از سرورهای توزیعشده است که میان کاربر و سرور مبدأ (Origin) قرار میگیرند. درخواست کاربر بر اساس DNS و مسیریابی شبکه به یک نقطه حضور یا PoP هدایت میشود. لبه شبکه میتواند پاسخ را از کش تحویل دهد یا درخواست را از طریق شبکه CDN به مبدأ برساند.
طبق راهنمای بیطرف CDN در web.dev، مزیت فقط ذخیره فایل نیست: خاتمه اتصال نزدیکتر به کاربر، اتصالهای آماده بین Edge و Origin و مسیرهای بهینه شبکه نیز میتوانند تحویل محتوای غیرقابلکش را بهتر کنند. بااینحال نتیجه به جغرافیا، اپراتور، زمان و پیکربندی بستگی دارد؛ نقشه بزرگ PoP بهتنهایی تضمین عملکرد نیست.
در یک درخواست چه اتفاقی میافتد؟
- مرورگر نام دامنه را از DNS میپرسد و IP لبه CDN را دریافت میکند.
- اتصال HTTPS میان کاربر و Edge برقرار میشود.
- CDN کلید Cache و قواعد امنیتی را بررسی میکند.
- اگر پاسخ معتبر موجود باشد، Cache Hit رخ میدهد و همان پاسخ تحویل میشود.
- در Cache Miss یا Bypass، CDN به Origin وصل میشود و پاسخ را میگیرد.
- پاسخ بر اساس هدرها و Cache Rules ممکن است در Edge ذخیره شود.
برای درک TTL، Cache-Control، Hit/Miss و روش ابطال، راهنمای معماری کش سایت را بخوانید.
CDN چه بخشهایی از سرعت را بهتر میکند؟
کاهش Round-Trip Time
اتصال کاربر به Edge نزدیکتر میتواند رفتوبرگشت شبکه برای DNS، TCP/QUIC و TLS را کاهش دهد. میزان سود برای کاربر نزدیک به Origin کمتر و برای کاربر دورتر معمولاً بیشتر است، اما مسیر واقعی ISP تعیینکننده است.
تحویل پاسخ از کش
تصویر، فونت، CSS، JavaScript، فایل دانلودی و گاهی HTML عمومی میتوانند از Edge تحویل شوند. هر Hit یک سفر تا Origin و پردازش آن را حذف میکند. محتوای شخصی، سبد خرید و پاسخ وابسته به نشست باید با کلید و قواعد Bypass دقیق مدیریت شود.
کاهش بار Origin
وقتی درصد مناسبی از درخواستها در Edge پاسخ داده شوند، پهنای باند، اتصالهای PHP و Queryهای پایگاه داده در مبدأ کم میشوند. این کاهش ظرفیت آزاد برای درخواستهای واقعاً پویا ایجاد میکند و در موج ترافیک مفید است.
پروتکل و فشردهسازی
بسیاری از CDNها TLS ۱.۳، HTTP/۲، HTTP/۳ و فشردهسازی Brotli/Gzip را در Edge ارائه میکنند. فعالبودن یک گزینه کافی نیست؛ باید مذاکره پروتکل و اندازه واقعی پاسخ را بررسی کنید. درباره مزایا و ریسکهای QUIC، راهنمای HTTP/۳ و QUIC را ببینید.
بهینهسازی تصویر و Edge Compute
تغییر اندازه، تبدیل فرمت و پردازش در Edge میتواند حجم انتقال و زمان پاسخ را کم کند، اما هزینه، کیفیت خروجی، Cache Key و وابستگی به فروشنده را تغییر میدهد. بهینهسازی تصویر در CDN جای انتخاب ابعاد و فرمت درست در برنامه را نمیگیرد.
آیا سایت ایرانی به CDN نیاز دارد؟
CDN در این شرایط معمولاً ارزش بررسی دارد:
- کاربران از چند شهر، اپراتور یا کشور وارد میشوند؛
- حجم تصویر، ویدئو یا دانلود عمومی بالاست؛
- کمپینها موج ترافیک و درخواست همزمان میسازند؛
- Origin ظرفیت یا پهنای باند محدودی دارد؛
- به WAF، Rate Limiting یا کنترل Bot در Edge نیاز دارید؛
- دسترسپذیری و Failover بخشی از هدف کسبوکار است.
برای سایت کمترافیکی که تقریباً همه کاربران نزدیک دیتاسنتر مبدأ هستند، CDN ممکن است سود بزرگی نداشته باشد. ابتدا TTFB و مسیر شبکه را اندازه بگیرید. همچنین دسترسی پایدار به پنل، روش پرداخت، پشتیبانی، امکان خروج داده و محدودیتهای قراردادی هر ارائهدهنده را پیش از وابستگی عملیاتی بررسی کنید.
CDN داخلی یا خارجی؛ چگونه تصمیم بگیریم؟
برچسب «داخلی» یا «خارجی» بهتنهایی معیار فنی کافی نیست. با وزندهی به کاربران و ریسک خود تصمیم بگیرید:
| معیار | سؤال عملی |
|---|---|
| پوشش واقعی | از شبکه و شهر کاربران هدف، RTT و TTFB چقدر است؟ |
| پایداری مسیر | در ساعات شلوغ و اختلال مسیر، نرخ خطا و نوسان چگونه است؟ |
| Cache | HTML، Query String، Cookie، purge و Tiered Cache چقدر قابلکنترلاند؟ |
| امنیت | WAF، Rate Limit، Bot Control، TLS و لاگ رویداد چه پوششی دارند؟ |
| Origin | امکان اتصال احرازشده، Allowlist و سلامتسنجی مبدأ هست؟ |
| رصدپذیری | Hit/Miss، Edge/Origin time، 4xx/5xx و خروجی لاگ در دسترس است؟ |
| عملیات | SLA، پشتیبانی اضطراری، API، Terraform و مدیریت دسترسی چگونه است؟ |
| تجاری | هزینه درخواست، پهنای باند، purge، WAF و خروج داده چگونه محاسبه میشود؟ |
یک Proof of Concept با ترافیک واقعی یا بخشی از دامنه قابلاعتمادتر از بنچمارک عمومی است. میانگین کافی نیست؛ صدک ۷۵ و ۹۵، نرخ خطا و تجربه اپراتورهای اصلی کاربران را مقایسه کنید.
CDN و امنیت؛ چه چیزی واقعاً محافظت میشود؟
جذب و پالایش DDoS
یک شبکه بزرگ میتواند بخشی از ترافیک حجمی را در Edge جذب کند، اما ظرفیت، نوع حمله و سطح سرویس مهماند. پوشش DDoS را از روی قرارداد، سقفها، زمان واکنش و گزارش رخداد ارزیابی کنید؛ عبارت تبلیغاتی «محافظت نامحدود» کنترل امنیتی قابلآزمون نیست.
WAF و Rate Limiting
WAF میتواند الگوهای حمله وب را مسدود کند و Rate Limiting سوءاستفاده از Login، API یا جستوجو را محدود سازد. قواعد آماده نقطه شروعاند، اما بدون Log، حالت Count و تنظیم تدریجی ممکن است کاربر یا خزنده سالم مسدود شود. WAF جای اصلاح SQL Injection و XSS در کد نیست.
TLS در هر دو مسیر
دو اتصال جدا دارید: کاربر تا Edge و Edge تا Origin. هر دو باید رمزنگاری و اعتبارسنجی شوند. حالتهایی که Edge از HTTP یا گواهی نامعتبر برای Origin استفاده میکند، امنیت سرتاسری واقعی نمیدهند.
محافظت از Origin
اگر IP مبدأ از DNS قدیمی، ایمیل، زیردامنه یا اسکن شبکه پیدا شود و مستقیماً پاسخ دهد، مهاجم میتواند Edge و WAF را دور بزند. دسترسی Origin را به IPهای CDN محدود کنید یا از mTLS/Authenticated Origin Pull استفاده کنید، دسترسی مدیریتی را جدا نگه دارید و یک مسیر اضطراری کنترلشده داشته باشید. مستندات Authenticated Origin Pulls نمونهای از احراز اتصال Edge به Origin را نشان میدهد.
CDN مستقیماً رتبه گوگل را بالا میبرد؟
خیر؛ «استفاده از CDN» بهخودیخود تضمین یا امتیاز مستقل رتبهبندی نیست. CDN میتواند TTFB، پایداری و تحویل منابع را بهتر کند و از این مسیر به تجربه صفحه کمک کند. گوگل نیز صریح میگوید نتیجه خوب Core Web Vitals تضمین رتبه بالا نیست و کیفیت و ارتباط محتوا همچنان اساسی است.
CDN بدپیکربندیشده حتی میتواند سئو را آسیب بزند: پاسخ ۵xx، Cache کردن redirect اشتباه، canonical قدیمی، مسدودکردن Googlebot، تغییر robots.txt یا نمایش نسخه متفاوت بر اساس IP. پس تغییر زیرساخت باید با تست Crawl و Index همراه باشد، نه فقط Lighthouse.
طراحی Cache Rules برای CDN
فایلهای استاتیک نسخهدار
برای فایلهایی که نام آنها با هر انتشار تغییر میکند، TTL بلند و immutable منطقی است. اگر نام فایل ثابت بماند، کاربر ممکن است CSS یا JavaScript قدیمی بگیرد؛ پاکسازی دستی دائمی جای Versioning نیست.
HTML عمومی
کش HTML بیشترین فشار را از Origin کم میکند اما نیازمند purge دقیق است. صفحات مقاله و لندینگ عمومی نامزد خوبی هستند. حساب، سبد و صفحات وابسته به Cookie باید Bypass شوند. قبل از فعالسازی سراسری، یک مسیر کمریسک را آزمایش کنید.
Query String و Cookie
پارامترهای کمپین مانند UTM معمولاً نباید هزاران نسخه همارز بسازند، اما حذف همه Query Stringها از Cache Key نیز میتواند پاسخ API یا فیلتر محصول را اشتباه کند. پارامترها را Allowlist و Cookieهای شخصی را در قواعد Bypass تعریف کنید.
تازگی و پاکسازی
برای هر نوع محتوا TTL، رویداد purge و مالک عملیات مشخص باشد. تصحیح قیمت یا خبر فوری نباید تا انقضای بلند Edge منتظر بماند. purge یک URL یا Tag وابستگی معمولاً از پاکسازی کل شبکه بهتر است.
مراحل راهاندازی CDN بدون قطعی
۱. خط مبنا بگیرید
TTFB، LCP، حجم انتقال، نرخ خطا، درخواست Origin و جغرافیای کاربران را ثبت کنید. تست سرد و گرم را جدا و حداقل در چند اپراتور انجام دهید.
۲. دامنه آزمایشی بسازید
CDN را روی Hostname آزمایشی یا زیردامنه کمریسک فعال کنید. HTTPS، Host Header، IP واقعی کاربر، Redirectها، Cookie و آپلود فایل را بررسی کنید. محیط آزمایش نباید ناخواسته Index شود.
۳. TLS و Origin را ایمن کنید
گواهی Edge و Origin، تمدید خودکار، SNI و Full validation را تست کنید. بعد از اطمینان، دسترسی مستقیم Origin را محدود کنید و یک راه مدیریتی خارج از مسیر عمومی نگه دارید.
۴. Cache و WAF را تدریجی فعال کنید
ابتدا فایل استاتیک، سپس HTML عمومی. قواعد WAF و Bot را پیش از Block در حالت Log/Count مشاهده کنید. Login، فرم، API و پرداخت را در هر مرحله تست کنید.
۵. DNS را منتقل کنید
پیش از تغییر، TTL رکورد را در بازه مناسب پایین بیاورید، رکوردهای DNS و ایمیل را کامل منتقل کنید و برنامه Rollback داشته باشید. درباره ملاحظات جابهجایی CDN، راهنمای رسمی تغییر زیرساخت میزبانی در Google Search Central نیز بر دسترسی Googlebot و تنظیم Firewall تأکید میکند.
۶. بعد از Cutover را رصد کنید
وضعیت DNS، گواهی، 4xx/5xx، Hit Ratio، Origin time، Loop ریدایرکت، فرم و پرداخت را پیوسته ببینید. لاگ قبل و بعد را مقایسه کنید و تا پایان بازه بازگشت، تنظیم قبلی را قابلبازیابی نگه دارید.
چگونه عملکرد CDN را بسنجیم؟
| شاخص | چرا مهم است؟ |
|---|---|
| TTFB به تفکیک جغرافیا/ISP | اثر مسیر Edge و Origin را نشان میدهد |
| Cache Hit Ratio | میزان استفاده مجدد را مشخص میکند؛ باید بر اساس نوع محتوا دیده شود |
| Edge Time و Origin Time | کندی Edge را از کندی مبدأ جدا میکند |
| 4xx/5xx و Timeout | اختلال کاربر، WAF یا Origin را آشکار میکند |
| Origin Offload | درخواست و پهنای باند حذفشده از مبدأ را میسنجد |
| Purge latency | زمان انتشار تا دیدهشدن نسخه تازه را نشان میدهد |
| RUM و Core Web Vitals | تجربه کاربران واقعی را مکمل تست آزمایشگاهی میکند |
هدف Hit Ratio صددرصد نیست. پاسخ شخصی یا بسیار پویا عمداً باید Bypass شود. افزایش Hit با نشت داده یا موجودی قدیمی، شکست محسوب میشود.
اشتباهات رایج در استفاده از CDN
- انتخاب ارائهدهنده فقط بر اساس تعداد PoP تبلیغشده؛
- کشکردن HTML بدون شناخت Cookie، Session و purge؛
- استفاده از TLS ناقص میان Edge و Origin؛
- بازگذاشتن IP مبدأ و امکان دورزدن WAF؛
- فعالکردن Block سختگیرانه Bot بدون بررسی لاگ و False Positive؛
- تغییر همزمان DNS، Cache، WAF و فشردهسازی بدون نقطه مقایسه؛
- وابستگی به میانگین تست خارجی بهجای RUM کاربران ایرانی؛
- نداشتن Runbook برای خرابی CDN، DNS یا Origin؛
- تصور اینکه CDN جای ظرفیتسنجی مبدأ را میگیرد.
سناریوی کمپین فروش
برای کمپینی که صفحه فرود، تصاویر و API محصول دارد، فایلها و HTML عمومی را پیشگرم کنید، اما ظرفیت حالت Cache Cold را هم بسنجید. Rate Limit را برای Login و endpointهای پرهزینه جدا تنظیم کنید. سلامت Origin را خارج از CDN مانیتور و یک تست خرید کامل از چند شبکه اجرا کنید. چکلیست جامع در جلوگیری از قطع سایت در ترافیک بالا قرار دارد.
چکلیست انتخاب و استقرار CDN
- توزیع واقعی کاربران و اپراتورها را میدانیم.
- TTFB و نرخ خطای قبل از CDN ثبت شده است.
- ارائهدهندگان با PoC روی ترافیک واقعی مقایسه شدهاند.
- هزینه درخواست، پهنای باند، WAF و خروج داده روشن است.
- فایل، HTML، API و صفحات شخصی سیاست جدا دارند.
- TLS در مسیر Edge و Origin اعتبارسنجی میشود.
- Origin در برابر دسترسی مستقیم محافظت شده است.
- WAF و Rate Limit با Log و تست تدریجی تنظیم شدهاند.
- Googlebot، robots.txt، canonical، sitemap و redirect بررسی شدهاند.
- Monitoring، Alert، دسترسی اضطراری و Rollback آمادهاند.
سؤالات متداول CDN
CDN چیست؟
CDN شبکهای از سرورهای Edge است که پاسخها و فایلها را نزدیکتر به کاربر تحویل میدهد و میتواند درخواستهای تکراری و بخشی از بار شبکه را از Origin کم کند.
آیا CDN برای سایت با کاربران فقط داخل ایران مفید است؟
ممکن است مفید باشد، اما پاسخ قطعی به مسیر ISP، موقعیت Origin، نوع محتوا و کیفیت ارائهدهنده بستگی دارد. از چند شبکه واقعی تست کنید و TTFB، خطا و Hit Ratio را قبل و بعد بسنجید.
آیا CDN جلوی همه حملات را میگیرد؟
خیر. CDN میتواند DDoS، WAF و Rate Limiting ارائه کند، اما پیکربندی، سطح سرویس و محافظت Origin تعیینکننده است. آسیبپذیری برنامه و کنترل دسترسی باید جداگانه اصلاح شوند.
آیا CDN باعث بهبود سئو میشود؟
استفاده از CDN سیگنال مستقل رتبهبندی نیست. اگر سرعت، پایداری و تجربه صفحه بهتر شود میتواند کمک غیرمستقیم کند؛ پیکربندی غلط نیز ممکن است Crawl، canonical و تازگی محتوا را خراب کند.
چقدر طول میکشد CDN راهاندازی شود؟
فعالسازی اولیه DNS ممکن است سریع باشد، اما استقرار امن شامل خط مبنا، TLS، Cache Rules، WAF، محافظت Origin، تست پرداخت، مانیتورینگ و Rollback است. مدت واقعی به پیچیدگی سایت و تعداد دامنهها بستگی دارد.
جمعبندی
CDN را نه با وعده «سرعت و امنیت فوری»، بلکه با هدف، داده و Runbook انتخاب کنید. مکان کاربر و Origin، Hit Ratio، کیفیت مسیر، کنترل Cache، امنیت مبدأ و توان عملیات همگی در نتیجه نقش دارند. استقرار تدریجی با معیارهای قبل و بعد، سریعتر از آزمونوخطای کور به تصمیم درست میرسد.
اگر برای انتخاب CDN داخلی/خارجی، طراحی Cache Rules یا آمادگی کمپین به ارزیابی مستقل نیاز دارید، در فرم مشاوره مایندیو دامنه، موقعیت کاربران، فناوری و نمونه ترافیک را ثبت کنید.
