HTTP/3 و IPv6 در شبکه ایران؛ سایت شما باید چه تغییری بدهد

در فاصله زمستان ۱۴۰۴ تا میانه سال جاری، زیرساخت شبکه در ایران تغییرات فنی مهمی را تجربه کرد که بخشی از آن‌ها هنوز برجاست. دو مورد از این تغییرات برای هر کسی که سایت دارد اهمیت مستقیم دارد: غیرفعال شدن IPv6 در سطح سرویس‌دهنده‌ها و از کار افتادن پروتکل QUIC که پایه HTTP/3 است.

این مطلب یک بررسی فنی است، نه تحلیل سیاسی. هدف آن پاسخ به یک پرسش عملی است: وقتی دو پروتکل مدرن وب در بخش بزرگی از شبکه داخلی کار نمی‌کنند، صاحب سایت باید چه چیزی را در پیکربندی خود تغییر دهد تا سرعت و دسترس‌پذیری سایتش برای کاربر ایرانی حفظ شود. اگر روی طراحی سایت و سئو سرمایه‌گذاری کرده‌اید، این تنظیمات مستقیما روی بازده آن اثر می‌گذارد.

چه چیزی در سطح شبکه تغییر کرد

بر پایه گزارش سازمان‌های اندازه‌گیری شبکه، مجموعه‌ای از تغییرات فنی در این دوره اعمال شده است. جدول زیر خلاصه آن‌ها را نشان می‌دهد.

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

HTTP/3 و QUIC، از ۴۰ درصد به زیر ۵ درصد

عددی که بیشترین اهمیت فنی را دارد از داده‌های Cloudflare می‌آید. سهم HTTP/3 و QUIC در شبکه‌های اصلی ایران در روزهای پیش از اختلال دی‌ماه از حدود ۴۰ درصد به زیر ۵ درصد سقوط کرد.

در جزئیات، سهم HTTP/3 روی شبکه ایرانسل تا اواخر دسامبر ۲۰۲۵ از ۴۰ درصد به ۵ درصد رسید و روی شبکه مخابرات تا اوایل ژانویه به زیر ۵ درصد رسید. این ارقام یک نکته مهم را نشان می‌دهند: پیش از این تغییرات، بخش قابل توجهی از ترافیک وب در ایران از HTTP/3 استفاده می‌کرد و این پروتکل صرفا یک فناوری آزمایشی نبود.

برای درک اهمیت موضوع باید بدانیم HTTP/3 چه می‌کند. این نسخه به‌جای TCP روی UDP کار می‌کند و مزیت اصلی آن کاهش تعداد رفت‌وبرگشت‌های لازم برای برقراری اتصال و مقاومت بهتر در برابر افت بسته است. در شبکه‌هایی که کیفیت اتصال پایین یا تاخیر بالا دارند، همین ویژگی می‌تواند تفاوت محسوسی در زمان بارگذاری ایجاد کند. حالا این لایه بهینه‌سازی برای بخش بزرگی از کاربران داخلی در دسترس نیست.

IPv6 و افت فضای آدرس

تغییر دوم به IPv6 مربوط است. سهم ترافیک IPv6 در دوره اختلال دی‌ماه از ۱۲ درصد به ۱.۸ درصد رسید و فضای آدرس IPv6 اعلام‌شده حدود ۹۸.۵ درصد کاهش یافت.

برای صاحب سایت این موضوع در نگاه اول بی‌اهمیت به نظر می‌رسد، چون بیشتر سایت‌ها همچنان روی IPv4 کار می‌کنند. اما یک نکته فنی وجود دارد که نادیده گرفتن آن می‌تواند به کندی محسوس منجر شود و در بخش بعدی به آن می‌پردازیم.

UDP و اختلال در سطح پروتکل

گزارش‌ها نشان می‌دهد ترافیک UDP ناشناس در بیشتر سرویس‌دهنده‌ها مسدود شده است. UDP پروتکل پایه بسیاری از سرویس‌های امروزی است، از QUIC و HTTP/3 تا ارتباط صوتی و تصویری زمان واقعی و بخشی از سرویس‌های نام دامنه.

پیامد عملی این وضعیت برای طراحی سایت روشن است: هر قابلیتی که برای کارکرد خود به یک اتصال UDP پایدار وابسته باشد، در شبکه داخلی قابل اتکا نیست. این شامل تماس صوتی و تصویری درون‌مرورگری، برخی سرویس‌های پخش زنده و هر ابزاری است که مسیر ارتباطی خود را روی این پروتکل بنا کرده باشد. اگر چنین قابلیتی برای کسب‌وکار شما حیاتی است، لازم است مسیر جایگزین بر پایه TCP هم پیش‌بینی شود.

اگر سایت شما روی HTTP/3 حساب کرده باشد

خبر خوب این است که وب به‌گونه‌ای طراحی شده که در نبود HTTP/3 به نسخه پایین‌تر برمی‌گردد. مرورگر تلاش می‌کند اتصال QUIC برقرار کند و در صورت ناکامی به TCP و HTTP/2 بازمی‌گردد. یعنی سایت شما از کار نمی‌افتد.

اما این بازگشت هزینه دارد. در برخی پیکربندی‌ها مرورگر پیش از بازگشت، مدتی منتظر پاسخ می‌ماند و همین انتظار به تاخیر اولیه بارگذاری اضافه می‌شود. اگر سرویس CDN شما HTTP/3 را تبلیغ می‌کند و شما بر پایه آن بهینه‌سازی‌های دیگر را کنار گذاشته‌اید، عملا بخشی از سرعتی که فرض کرده‌اید در دسترس کاربر داخلی نیست.

توصیه عملی این است که عملکرد سایت را در حالت بدون HTTP/3 بسنجید و مطمئن شوید مسیر TCP و HTTP/2 به‌طور کامل بهینه شده است. HTTP/2 هم قابلیت‌های مهمی مانند چندگانه‌سازی درخواست‌ها و فشرده‌سازی سرآیندها دارد و اگر درست پیکربندی شود، فاصله محسوسی با HTTP/3 نخواهد داشت.

HTTP/2 در برابر HTTP/3، تفاوت در عمل

حالا که مسیر HTTP/3 برای بخش بزرگی از کاربران داخلی بسته است، دانستن اینکه دقیقا چه چیزی از دست می‌رود به اولویت‌بندی بهینه‌سازی کمک می‌کند.

نکته مهم این جدول در دو سطر میانی است. مزیت اصلی HTTP/3 در شبکه‌های با افت بسته و در جابه‌جایی میان شبکه‌ها نمایان می‌شود، یعنی دقیقا همان شرایطی که کاربر موبایل ایرانی تجربه می‌کند. اما دو قابلیت مهم دیگر، یعنی چندگانه‌سازی درخواست‌ها و فشرده‌سازی سرآیندها، در HTTP/2 هم وجود دارند.

نتیجه عملی این است که با پیکربندی درست HTTP/2 می‌توان بخش بزرگی از فاصله را پوشش داد. شرط آن، فعال بودن واقعی این نسخه روی سرور و CDN و کنار گذاشتن ترفندهای قدیمی دوره HTTP/1 است؛ تکنیک‌هایی مانند تقسیم منابع میان چند زیردامنه که در HTTP/2 نه فقط بی‌فایده‌اند، بلکه با اضافه کردن دست‌دادن‌های تازه به ضرر سرعت تمام می‌شوند.

رکورد AAAA و تله اتصال دوپشته‌ای

این بخش دقیق‌ترین نکته فنی این مطلب است. اگر دامنه شما هم رکورد A برای IPv4 و هم رکورد AAAA برای IPv6 داشته باشد، مرورگرها طبق رفتار استاندارد ابتدا مسیر IPv6 را امتحان می‌کنند.

در شبکه‌ای که IPv6 غیرفعال است، این تلاش با پاسخ سریع «غیرقابل دسترس» مواجه می‌شود و مرورگر بلافاصله به IPv4 برمی‌گردد. مشکل جایی پیش می‌آید که بسته‌ها بی‌پاسخ رها شوند؛ در آن حالت مرورگر باید منتظر پایان زمان انتظار بماند و سپس مسیر دوم را امتحان کند. مرورگرهای مدرن سازوکارهایی برای کوتاه کردن این انتظار دارند، اما تجربه کاربر در همین چند صد میلی‌ثانیه شکل می‌گیرد.

بنابراین اگر رکورد AAAA برای دامنه خود تعریف کرده‌اید، ارزش دارد بررسی کنید که مسیر IPv6 واقعا از شبکه‌های داخلی پاسخ می‌دهد یا نه. اگر پاسخ نمی‌دهد، نگه داشتن آن رکورد هیچ مزیتی ایجاد نمی‌کند و تنها یک تلاش اضافه به هر بارگذاری اضافه می‌کند.

هزینه دست‌دادن TLS بدون کمک QUIC

یکی از مزیت‌های QUIC، کم کردن تعداد رفت‌وبرگشت‌های لازم برای برقراری اتصال امن است. با حذف این لایه، تعداد رفت‌وبرگشت‌ها به حالت متعارف TCP و TLS برمی‌گردد و در شبکه‌ای با تاخیر بالا، هر رفت‌وبرگشت هزینه محسوسی دارد.

در این شرایط چند تنظیم اهمیت بیشتری پیدا می‌کند. فعال بودن اتصال پایدار، کم کردن تعداد دامنه‌های مبدا که مرورگر باید با آن‌ها دست بدهد، کوتاه نگه داشتن زنجیره گواهی و استفاده از نسخه‌های تازه‌تر TLS، همه در جهت کم کردن همین رفت‌وبرگشت‌ها عمل می‌کنند.

نکته‌ای که کمتر به آن توجه می‌شود این است که هر دامنه خارجی اضافه در صفحه، یک دست‌دادن مستقل و یک جست‌وجوی نام دامنه جداگانه می‌طلبد. در شبکه‌ای با شرایط فعلی، این هزینه چند برابر حالت عادی است.

منابع خارجی، رایج‌ترین اشتباه در سایت‌های ایرانی

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

هر منبع خارجی سه ریسک ایجاد می‌کند: احتمال دسترسی‌نداشتن کامل، تاخیر بالا در صورت دسترسی، و وابستگی رندر صفحه به پاسخی که از کنترل شما بیرون است. اگر فایل سبک یا فونت در ابتدای صفحه از یک مبدا خارجی بارگذاری شود، مرورگر تا رسیدن پاسخ، نمایش محتوا را به تعویق می‌اندازد و کاربر صفحه سفید می‌بیند.

راه‌حل مشخص است: میزبانی محلی همه منابع حیاتی روی همان دامنه یا CDN داخلی. فونت‌ها، کتابخانه‌ها و آیکون‌ها را داخل هاست خودتان قرار دهید. حجم فایل‌های تصویری را هم می‌توانید پیش از بارگذاری با ابزار تبدیل و فشرده‌سازی تصاویر کم کنید تا تعداد بایت‌های ارسالی کاهش پیدا کند.

سرور ایران یا CDN، تصمیمی که باید بازبینی شود

تغییرات شبکه، معادله انتخاب میزبانی را عوض کرده است. پیش از این، قرار دادن مبدا در خارج و استفاده از یک CDN برای کاربران داخلی انتخاب رایجی بود. امروز باید چند عامل تازه را در این تصمیم وارد کرد.

عامل اول، وضعیت ظرفیت مراکز داده داخلی است که به‌طور کامل بازنگشته و می‌تواند بر پایداری اثر بگذارد. عامل دوم، رفتار مسیرهای بین‌المللی است که تاخیر و افت بسته آن‌ها قابل پیش‌بینی نیست. عامل سوم، این واقعیت است که بهینه‌سازی‌های مبتنی بر QUIC که بخشی از ارزش سرویس‌های CDN جهانی بود، برای کاربر داخلی اثر خود را از دست داده است.

مقایسه کامل این دو گزینه و معیارهای انتخاب را در مطلب سرور ایران بهتر است یا CDN ایرانی بررسی کرده‌ایم. توصیه کلی این است که تصمیم را بر پایه اندازه‌گیری واقعی از داخل ایران بگیرید، نه بر پایه پیکربندی‌ای که یک سال پیش بهترین گزینه بود.

تایم‌اوت، خطای ۵۰۴ و ظرفیت مبدا

وقتی مسیر شبکه ناپایدار است و بخشی از ظرفیت مراکز داده در دسترس نیست، خطاهای مربوط به پایان زمان انتظار بیشتر دیده می‌شوند. خطای ۵۰۴ رایج‌ترین نمود این وضعیت است و در سایت‌های وردپرسی سنگین بیشتر رخ می‌دهد.

نکته مهم این است که این خطا همیشه نشانه خرابی سایت نیست. در بسیاری از موارد، یک درخواست سنگین سمت سرور طول می‌کشد و لایه میانی پیش از دریافت پاسخ، اتصال را می‌بندد. راه‌حل ترکیبی است: کاهش زمان پاسخ سمت سرور، تنظیم درست مقادیر زمان انتظار و استفاده از حافظه نهان برای صفحاتی که نیازی به تولید مجدد ندارند. تحلیل کامل این خطا و روش رفع آن را در مطلب رفع خطای ۵۰۴ در وردپرس آورده‌ایم.

اندازه‌گیری از داخل، نه از بیرون

بخش زیادی از ابزارهای سنجش سرعت سایت، آزمون را از سرورهای خارج از ایران اجرا می‌کنند. نتیجه چنین آزمونی برای سایتی که مخاطب اصلی آن کاربر داخلی است، تصویر گمراه‌کننده‌ای می‌دهد.

سه معیار را باید از داخل شبکه‌های داخلی اندازه گرفت: زمان رسیدن اولین بایت، زمان نمایش بزرگ‌ترین عنصر محتوایی و نرخ خطای درخواست‌ها. اختلاف این اعداد میان یک آزمون خارجی و یک آزمون داخلی می‌تواند چند برابر باشد و تصمیم‌گیری بر پایه عدد اشتباه، بهینه‌سازی را به سمت غلط می‌برد.

برای بررسی وضعیت فنی و سئوی سایت هم می‌توانید از اسکنر سئوی کافه لایسنس استفاده کنید و مواردی مانند حجم منابع، ساختار عنوان‌ها و مشکلات فنی صفحه را ببینید.

تفاوت شبکه موبایل و ثابت

یک نکته مهم که در بهینه‌سازی نادیده گرفته می‌شود، تفاوت رفتار شبکه‌های موبایل و ثابت است. داده‌های منتشرشده نشان می‌دهد افت سهم HTTP/3 روی شبکه موبایل و شبکه ثابت با فاصله زمانی و شدت متفاوتی رخ داده است.

در عمل یعنی تجربه کاربری که با داده موبایل به سایت شما می‌آید می‌تواند با کاربر اتصال ثابت تفاوت محسوس داشته باشد. اگر بخش عمده مخاطب شما موبایلی است، بهینه‌سازی باید بر پایه سنجش روی همان شبکه انجام شود. کم کردن حجم صفحه و تعداد درخواست‌ها در شبکه موبایل بازده بیشتری از هر تنظیم دیگری دارد.

چک‌لیست فنی

• عملکرد سایت را در حالت بدون HTTP/3 بسنجید و مسیر TCP و HTTP/2 را کامل بهینه کنید.

• وجود و پاسخ‌دهی واقعی رکورد AAAA را بررسی کنید و اگر مسیر IPv6 پاسخ نمی‌دهد، آن را حذف کنید.

• فونت‌ها، کتابخانه‌ها و آیکون‌ها را به میزبانی داخلی منتقل کنید.

• تعداد دامنه‌های مبدا در هر صفحه را به کمترین حد برسانید.

• حافظه نهان را در لایه‌های سرور و CDN فعال و آزمایش کنید.

• مقادیر زمان انتظار را با واقعیت زمان پاسخ سرور هماهنگ کنید.

• هر قابلیت وابسته به UDP را با مسیر جایگزین بر پایه TCP پیش‌بینی کنید.

• سنجش سرعت را از داخل شبکه‌های داخلی و به‌طور جداگانه برای موبایل و ثابت انجام دهید.

سه پیکربندی اشتباه که زیاد دیده می‌شود

در بازبینی فنی سایت‌های ایرانی، سه الگوی اشتباه بیش از بقیه تکرار می‌شود و هر سه در شرایط شبکه فعلی هزینه بیشتری از گذشته دارند.

اشتباه اول، فعال بودن حافظه نهان روی کاغذ و بی‌اثر بودن آن در عمل است. سرآیندهایی که به مرورگر می‌گویند محتوا را ذخیره نکن، همه بهینه‌سازی‌های دیگر را بی‌اثر می‌کنند و این وضعیت در سایت‌هایی که چند لایه حافظه نهان دارند، بیشتر پیش می‌آید. بررسی سرآیندهای پاسخ، اولین کاری است که در تحلیل سرعت باید انجام شود.

اشتباه دوم، بارگذاری اسکریپت‌های سنگین در ابتدای صفحه و به‌صورت مسدودکننده است. تا زمانی که این فایل‌ها دریافت و اجرا نشوند، کاربر محتوایی نمی‌بیند. انتقال این اسکریپت‌ها به انتهای صفحه یا استفاده از بارگذاری غیرمسدودکننده، در شبکه کند تفاوت چند ثانیه‌ای ایجاد می‌کند.

اشتباه سوم، تصاویر بهینه‌نشده با ابعاد بسیار بزرگ‌تر از نیاز نمایش است. تصویری که با ابعاد اصلی دوربین بارگذاری شده و در صفحه به اندازه کوچک نمایش داده می‌شود، چند برابر حجم لازم را منتقل می‌کند. این مورد ساده‌ترین و سریع‌ترین اصلاح ممکن است و بیشترین اثر را در شبکه موبایل دارد.

اثر این وضعیت بر سئو و ترافیک

سرعت بارگذاری یکی از عوامل ارزیابی تجربه صفحه در موتورهای جست‌وجو است و افزایش زمان پاسخ می‌تواند به‌طور غیرمستقیم بر جایگاه سایت اثر بگذارد. اما اثر مستقیم‌تر و سریع‌تر، رفتار کاربر است: صفحه‌ای که کند بارگذاری می‌شود نرخ ترک بالاتری دارد و این سیگنال زودتر از هر عامل فنی دیگری در نتایج دیده می‌شود.

در شرایطی که سهم ترافیک ارجاعی موتورهای جست‌وجو به دلیل رشد پاسخ‌های هوش مصنوعی هم تحت فشار است، از دست دادن کاربری که وارد سایت شده اما صفحه برایش بارگذاری نشده، هزینه بیشتری دارد. تحلیل این تغییر را در مطلب هوش مصنوعی گوگل و ترافیک سایت‌ها و بررسی تغییرات الگوریتم را در آپدیت الگوریتم گوگل و اثر آن بر سایت آورده‌ایم.

آنچه در کنترل شما نیست

لازم است روشن باشد که بخش بزرگی از این وضعیت خارج از کنترل صاحب سایت است. غیرفعال بودن یک پروتکل در سطح سرویس‌دهنده را نمی‌توان با تنظیمات سایت جبران کرد و انتظار نتیجه معجزه‌آسا از بهینه‌سازی، واقع‌بینانه نیست.

کاری که در اختیار شماست، حذف هزینه‌های اضافی است: منبع خارجی غیرضروری، رکورد DNS بی‌پاسخ، تصویر بهینه‌نشده، حافظه نهان غیرفعال و انتظارهای بی‌مورد. مجموع این موارد در بسیاری از سایت‌ها چند ثانیه از زمان بارگذاری را تشکیل می‌دهد و همین بخش کاملا قابل اصلاح است.

در سایت‌های وردپرسی یک عامل دیگر هم اضافه می‌شود: تعداد افزونه‌های فعال و کیفیت قالب. هر افزونه معمولا فایل‌های سبک و اسکریپت خود را به همه صفحات اضافه می‌کند، حتی صفحاتی که به آن قابلیت نیازی ندارند. بازبینی فهرست افزونه‌ها و حذف موارد بی‌استفاده، یکی از کم‌هزینه‌ترین راه‌های کاهش حجم صفحه است. اگر با المنتور پرو کار می‌کنید، غیرفعال کردن قابلیت‌های استفاده‌نشده و کم کردن تعداد ویجت‌های سنگین در صفحات اصلی هم اثر محسوسی دارد.

جمع‌بندی

خلاصه وضعیت این است: دو لایه بهینه‌سازی مدرن وب، یعنی HTTP/3 و IPv6، برای بخش بزرگی از کاربران داخلی در دسترس نیست و ترافیک UDP ناشناس هم در بیشتر شبکه‌ها مسدود است. این یعنی سایت شما باید روی مسیر متعارف TCP و IPv4 به بهترین شکل کار کند.

عملا این تغییر، اهمیت اصول قدیمی بهینه‌سازی را بیشتر کرده است: صفحه سبک، تعداد درخواست کم، منابع میزبانی‌شده روی دامنه خودتان، حافظه نهان فعال و سنجش از داخل ایران. اگر برای بازبینی فنی سایت به کمک نیاز دارید، خدمات طراحی سایت و سئو کافه لایسنس در دسترس است و شرح کامل آن را در مطلب طراحی سایت و سئو حرفه‌ای آورده‌ایم.

سوالات متداول