پیاده‌سازی کدهای فشرده‌سازی در Program.cs

برای فعال‌سازی این قابلیت، فایل تنظیمات هسته برنامه (Endpoint.Website/Program.cs) را مطابق ساختار زیر به‌روزرسانی کنید:

// اضافه کردن سرویس فشرده‌سازی پاسخ‌ها پس از خط AddControllersWithViews
builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
    options.Providers.Add();
    options.Providers.Add();
});

var app = builder.Build();

// فعال‌سازی میدل‌ور فشرده‌سازی در خطوط اولیه پایپ‌لاین درخواست‌ها (بلافاصله پس از ساخت اپلیکیشن)
app.UseResponseCompression();

// مابقی میدل‌ورها و تنظیمات مسیریابی...

دو Provider رایج:

options.Providers.Add();
options.Providers.Add();

• BrotliCompressionProvider : الگوریتم فشرده‌سازی مدرن و بهینه‌تر (توصیه‌شده برای مرورگرهای جدید).
• GzipCompressionProvider : الگوریتم استاندارد و سازگار با طیف وسیع‌تری از کلاینت‌ها.

استفاده همزمان از هر دو Provider نه تنها اشتباه نیست، بلکه روش استاندارد و توصیه‌شده برای پیاده‌سازی Response Compression در ASP.NET Core است. این کار باعث می‌شود میدل‌ور فشرده‌سازی بتواند بر اساس توانایی‌های کلاینت (مرورگر) تصمیم بگیرد که کدام الگوریتم را اعمال کند.

نکته: ترتیب Middleware ها

// 1. میدل‌ورهای مربوط به امنیت و مسیریابی ابتدا
app.UseHttpsRedirection();

// ******************************************
// 2. میدل‌ور فشرده‌سازی پس از مسیریابی و پیش از اجرای Endpoint قرار می‌گیرد
app.UseResponseCompression();
// ******************************************

app.UseStaticFiles();
 // فایل‌های استاتیک معمولاً در این نقطه سرو می‌شوند
app.UseRouting();

// 3. میدل‌ورهای مربوط به احراز هویت، دسترسی و در نهایت Endpointها
app.UseAuthentication();
app.UseAuthorization();
app.MapControllers(); // یا MapRazorPages / MapControllerRoute

تحلیل فنی و تاثیر سئویی این بهینه‌سازی

۱. استفاده ترکیبی از Brotli و Gzip

• الگوریتم Brotli (توسعه‌یافته توسط گوگل) نرخ فشرده‌سازی بسیار بالاتری نسبت به Gzip قدیمی دارد و امروزه توسط تقریباً تمامی مرورگرهای مدرن پشتیبانی می‌شود. با تعریف هر دو ارائه‌دهنده در ASP.NET Core، سیستم به‌صورت هوشمند بررسی می‌کند که اگر مرورگر کاربر از Brotli پشتیبانی کند، محتوا با آن فشرده شود و در غیر این صورت به سراغ Gzip می‌رود تا سازگاری کامل حفظ شود.

۲. فعال‌سازی روی بستر امن HTTPS (EnableForHttps = true)

• به طور پیش‌فرض، فشرده‌سازی در برخی نسخه‌ها ممکن است روی HTTPS غیرفعال باشد تا از آسیب‌پذیری‌های امنیتی احتمالی (مانند حملات CRIME/BREACH) جلوگیری شود. با فعال کردن صریح این گزینه، ترافیک امن سایت شما نیز فشرده شده و حجم صفحات به شدت کاهش می‌یابد.

فعال کردن EnableForHttps = true به این معنا نیست که "ممکن است جواب ندهد" یا کار نکند. بلکه به این معناست که یک ریسک امنیتی شناخته‌شده (حملات CRIME و BREACH) را آگاهانه می‌پذیرید. سؤال اصلی این نیست که "آیا کار می‌کند؟" (که تقریباً همیشه کار می‌کند)، بلکه این است که "آیا ارزشش را دارد که امنیت سایت را به خطر بیندازیم؟" در ادامه به طور کامل توضیح می‌دهم.

در ASP.NET Core، وقتی پاسخ‌ها (Response) را فشرده می‌کنید، به طور پیش‌فرض این فشرده‌سازی فقط روی اتصالات HTTP (غیرامن) اعمال می‌شود. گزینه EnableForHttps به طور پیش‌فرض false است تا از آسیب‌پذیری‌های امنیتی جلوگیری شود . با قرار دادن آن روی true ، به برنامه می‌گویید: "حتی وقتی کاربر از طریق HTTPS (اتصال امن) به سایت وصل شده، پاسخ‌ها را فشرده کن." این کار حجم ترافیک را به شدت کاهش می‌دهد و سرعت بارگذاری را بهتر می‌کند، اما یک حمله سایبری خاص را ممکن می‌سازد.

فشرده‌سازی روی HTTPS، دروازه‌ای برای حمله‌ای به نام BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) باز می‌کند. BREACH نسخه‌ای از حمله CRIME است و از نحوه فشرده‌سازی داده‌ها سوءاستفاده می‌کند.

پس راهکار چیست؟

با استفاده از توکن‌های ضد جعل (Antiforgery Tokens) این حمله قابل کاهش هست. این توکن‌ها که معمولاً به عنوان توکن CSRF نیز شناخته می‌شوند، در فرم‌ها قرار می‌گیرند و برای هر درخواست اعتبارسنجی می‌شوند. وجود و چرخش مداوم این توکن‌ها، کار مهاجم را برای حدس زدن و استخراج داده‌های حساس بسیار دشوار می‌کند.

اگر برنامه‌تان به شدت به امنیت حساس است (مثلاً یک پنل مدیریت یا سیستم پرداخت)، بهتر است فشرده‌سازی HTTPS را در سطح برنامه غیرفعال نگه دارید و به سرور وب (IIS/Nginx) بسپارید تا با تنظیمات امن خودش این کار را انجام دهد.

۳. بررسی صحت عملکرد (Verification)

• پس از اجرای پروژه و راه‌اندازی سرور، می‌توانید برای اطمینان از صحت عملکرد فشرده‌سازی، درخواست هدر را با استفاده از ابزار خط فرمان بررسی کنید:

curl.exe -k -i -H "Accept-Encoding: br, gzip" https://localhost:7101/

در پاسخ دریافتی، وجود هدر زیر نشان‌دهنده موفقیت‌آمیز بودن تنظیمات و فشرده‌سازی صحیح پاسخ توسط سرور خواهد بود:

Content-Encoding: br

(یا Content-Encoding: gzip بسته به نوع پشتیبانی کلاینت). این بهینه‌سازی نقش بسزایی در کاهش زمان بارگذاری اولیه و ارتقای امتیاز سایت در ارزیابی‌های سئو ایفا می‌کند.

پاسخ صحیح بصورت زیر می باشد:

اگر غیر از پاسخ بالا پاسخی نظیر پاسخ زیر دریافت شد، بمعنای عدم رعایت middleware خواهد بود.