زیرساخت فنی پوش نوتیفیکیشن: پروتکل‌ها، رمزنگاری و تحویل‌پذیری | پوشفا

پوش نوتیفیکیشن وب (Web Push) به یکی از مؤثرترین کانال‌های ارتباطی با کاربران تبدیل شده است، اما در پشت صحنه، این فناوری ساده به نظر می‌رسد. در حقیقت، ارسال یک اعلان از سرور تا مرورگر کاربر از زنجیره‌ای از پروتکل‌ها، استانداردها و اجزای فنی پیچیده تشکیل شده است که هر یک نقش حیاتی دارند. اگر توسعه‌دهنده هستید یا مسئولیت فنی یک وب‌سایت را بر عهده دارید، درک عمیق این زیرساخت برای اطمینان از تحویل‌پذیری بالا، امنیت و عملکرد بهینه ضروری است.

بسیاری از کسب‌وکارها با مشکل «اعلان ارسال می‌شود اما دریافت نمی‌شود» مواجه می‌شوند. ریشه این مشکل اغلب به خطاهای پیکربندی در پروتکل‌ها، عدم رعایت استانداردها یا نادیده گرفتن محدودیت‌های مرورگر برمی‌گردد. در این مقاله، به زبان فنی اما قابل فهم، تمام لایه‌های فنی پوش نوتیفیکیشن وب را بررسی می‌کنیم: از Web Push API و VAPID تا رمزنگاری سرتاسری، Service Worker، مدیریت رویدادها، و بهینه‌سازی تحویل‌پذیری.

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

مقدمه‌ای بر زیرساخت پوش

پوش نوتیفیکیشن وب یک فناوری سمت کلاینت است که به وب‌سایت‌ها اجازه می‌دهد حتی زمانی که کاربر در سایت نیست، پیام‌هایی را به مرورگر او ارسال کنند. این قابلیت بر پایه سه مؤلفه اصلی استوار است: مرورگر، سرویس‌دهنده ارسال (Push Service) و Service Worker. مرورگر به عنوان واسط کاربر، اشتراک را مدیریت می‌کند و سرویس‌دهنده ارسال، وظیفه انتقال اعلان از سرور شما به مرورگر را بر عهده دارد.

در گذشته، برای ارسال اعلان به کاربران، وب‌سایت‌ها باید از سرویس‌های اختصاصی و نه‌چندان استاندارد استفاده می‌کردند. اما با ظهور Web Push API و استانداردسازی آن توسط W3C و IETF، اکنون یک پروتکل واحد و باز برای ارسال اعلان‌ها به همه مرورگرهای اصلی وجود دارد. این پروتکل به توسعه‌دهندگان امکان می‌دهد تا با استفاده از کتابخانه‌های مختلف، به سادگی اعلان ارسال کنند، در حالی که امنیت و قابلیت اطمینان در سطح بالایی حفظ می‌شود.

برای درک کامل، ابتدا باید با اصطلاحات فنی آشنا شویم. Push Service سرویسی است که توسط مرورگر یا شخص ثالث ارائه می‌شود (مانند FCM برای کروم، و Push Service اپل برای سافاری). این سرویس‌ها پیام‌ها را از سرور شما دریافت کرده و به مرورگر کاربر تحویل می‌دهند، حتی اگر کاربر آفلاین باشد. ارتباط بین سرور شما و Push Service از طریق پروتکل HTTP/2 با استفاده از Web Push Protocol انجام می‌شود.

یکی از نکات مهم، تفاوت بین پوش نوتیفیکیشن وب و اعلان‌های بومی (Native) در برنامه‌های موبایل است. در وب، مرورگرها قوانین سخت‌گیرانه‌تری برای نمایش اعلان‌ها دارند و معمولاً نیاز به تعامل کاربر برای اشتراک است. همچنین، برخی مرورگرها مانند سافاری شیوه خاص خود را دارند. در ادامه، هر یک از این جنبه‌ها را به تفصیل بررسی می‌کنیم.

پروتکل Web Push: ستون فقرات ارتباط

پروتکل Web Push که در RFC 8030 تعریف شده است، نحوه ارتباط بین سرور برنامه (Application Server) و Push Service را مشخص می‌کند. این پروتکل بر پایه HTTP/2 طراحی شده و از روش POST برای ارسال پیام استفاده می‌کند. آدرس endpoint که در زمان اشتراک توسط مرورگر تولید می‌شود، به عنوان مقصد ارسال پیام عمل می‌کند. این endpoint متعلق به Push Service است و شامل شناسه‌هایی است که به مرورگر خاص کاربر اشاره می‌کند.

در واقع، request ارسالی شما به سمت endpoint شامل بدنه پیام (Payload) و هدرهای مشخصی است. بدنه پیام می‌تواند حداکثر ۴۰۹۶ بایت داده (حدود ۳-۴ کیلوبایت متن) باشد، که برای متون اعلان معمولی کاملاً کافی است. این محدودیت بر اساس استاندارد است و برخی مرورگرها ممکن است حداکثر کمتر یا بیشتری داشته باشند. برای مثال، فایرفاکس از پیام‌های بزرگ‌تر پشتیبانی می‌کند.

یکی از ویژگی‌های کلیدی، امکان استفاده از هدر TTL برای کنترل مدت زمان نگهداری پیام در Push Service است. اگر کاربر آفلاین باشد، پیام به مدت TTL در سرویس نگهداری می‌شود و پس از آن منقضی می‌گردد. این موضوع برای مدیریت اعلان‌های زمانی‌دار اهمیت دارد. همچنین، هدر Topic یا CollapseKey به شما امکان می‌دهد اعلان‌های مرتبط را گروه‌بندی کنید تا فقط آخرین مورد نمایش داده شود. این قابلیت به ویژه برای جلوگیری از ازدحام اعلان‌ها مفید است.

RFC 8030 همچنین رفتار Push Service را در شرایط خطا مشخص می‌کند. کدهای وضعیت HTTP مانند 201 (Created) برای موفقیت، 404 (Not Found) برای endpoint نامعتبر، و 410 (Gone) برای endpoint منقضی شده استفاده می‌شوند. در صورت دریافت خطای 404 یا 410، باید اشتراک کاربر را حذف کنید و دیگر به آن اعلان ارسال نکنید. این خطاها معمولاً به دلیل لغو اشتراک یا غیرفعال شدن کاربر رخ می‌دهند.

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

VAPID: احراز هویت و امنیت

VAPID (Voluntary Application Server Identification) یک استاندارد است که در RFC 8292 تعریف شده و به سرور برنامه اجازه می‌دهد هویت خود را به Push Service اثبات کند. این مکانیزم امنیتی ضروری است تا هیچ کس نتواند به‌جای شما برای کاربران اعلان ارسال کند. VAPID از یک جفت کلید عمومی و خصوصی استفاده می‌کند که در زمان اشتراک تولید می‌شود.

هنگامی که کاربر اشتراک ایجاد می‌کند، کلید عمومی VAPID شما در هنگام ساخت اشتراک (در گزینه applicationServerKey در مرورگر) دخیل است. سپس، برای ارسال اعلان، باید یک توکن JWT (JSON Web Token) ایجاد کنید که با کلید خصوصی شما امضا شده است. این توکن شامل اطلاعاتی مانند issuer (معمولاً آدرس ایمیل یا URL شما) و تاریخ انقضا است. Push Service با بررسی امضای JWT، مطمئن می‌شود که درخواست از سمت شما است.

اهمیت VAPID در این است که بدون آن، هر کسی که بتواند اشتراک کاربر را بهدست آورد (مثلاً از طریق حملات XSS)، می‌تواند پیام‌های جعلی ارسال کند. با VAPID، شما مالکیت دامنه را اثبات می‌کنید و Push Service می‌تواند درخواست‌های نامعتبر را رد کند. همچنین، برخی مرورگرها مانند کروم، ارسال اعلان بدون VAPID را مجاز نمی‌دانند و درخواست را با خطای 403 رد می‌کنند.

برای پیاده‌سازی VAPID، می‌توانید از کتابخانه‌های آماده در زبان‌های برنامه‌نویسی مختلف استفاده کنید. به عنوان مثال، در Node.js از کتابخانه web-push استفاده می‌شود و در PHP می‌توانید از minishlink/web-push استفاده نمایید. این کتابخانه‌ها مدیریت تولید کلید، ساخت JWT و ارسال درخواست را ساده می‌کنند. یک نکته مهم: کلید خصوصی باید در سمت سرور به صورت امن نگهداری شود و هرگز در معرض دید عموم قرار نگیرد.

رمزنگاری سرتاسری اعلان‌ها

یکی از مهم‌ترین جنبه‌های امنیتی پوش نوتیفیکیشن، رمزنگاری سرتاسری (End-to-End Encryption) است. طبق استاندارد RFC 8291، تمام payloadهای ارسالی باید با یک کلید عمومی که در زمان اشتراک تولید می‌شود، رمزنگاری شوند. این کار تضمین می‌کند که Push Service (مانند FCM) نتواند محتوای پیام را بخواند، و تنها مرورگر و سرور شما از محتوا مطلع هستند.

فرآیند رمزنگاری به این صورت است: در زمان اشتراک، مرورگر یک جفت کلید (کلید عمومی و خصوصی) برای payload ایجاد می‌کند. کلید عمومی و یک مقدار salt (که در حین ارسال تولید می‌شود) در هدرهای درخواست ارسال قرار می‌گیرند. سپس، با استفاده از الگوریتم ECDH (Elliptic Curve Diffie-Hellman) و HKDF (HMAC-based Key Derivation Function)، یک کلید واحد برای رمزنگاری مشتق می‌شود. پیام قبل از ارسال به Push Service با این کلید رمزنگاری می‌شود.

در سمت مرورگر، Service Worker کلید خصوصی را ذخیره می‌کند و با استفاده از آن، پیام را رمزگشایی می‌کند. این فرآیند برای توسعه‌دهنده شفاف است؛ کتابخانه‌های سمت سرور مانند web-push به طور خودکار رمزنگاری را انجام می‌دهند. با این حال، اگر خودتان قصد دارید پروتکل را پیاده‌سازی کنید، باید با این الگوریتم‌ها آشنا باشید.

یکی از چالش‌های رمزنگاری، محدودیت حجم پیام است. به دلیل حذف حجم اضافی رمزنگاری، حداکثر اندازه پیام ممکن است از ۴۰۹۶ بایت به حدود ۳۰۰۰ بایت کاهش یابد. برای اعلان‌های متنی ساده این مشکل ایجاد نمی‌کند، اما اگر بخواهید داده‌های بیشتری ارسال کنید، باید از راه‌حل‌های جایگزین مانند ذخیره داده در سرور و ارسال شناسه استفاده کنید.

Service Worker: مغز متفکر اعلان‌ها

Service Worker یک فایل جاوااسکریپتی است که به عنوان پروکسی بین مرورگر و شبکه عمل می‌کند. برای دریافت اعلان‌های پوش، Service Worker نقش حیاتی دارد: رویداد پوش (push event) را مدیریت می‌کند، پیام را رمزگشایی می‌کند و اعلان را نمایش می‌دهد. Service Worker باید در دامنه‌تان نصب شود و برای کارکرد، نیاز به HTTPS دارد (به جز در لوکال‌هاست).

هنگامی که پیام پوش به مرورگر می‌رسد، مرورگر Service Worker را در حالت فعال (در صورت خواب بودن) بیدار می‌کند. سپس رویداد push فراخوانی می‌شود. در این رویداد، شما می‌توانید داده‌ها را دریافت و یک اعلان (Notification) بسازید. کد معمول به این صورت است: self.addEventListener('push', function(event) { ... }) و سپس از event.data.json() برای پردازش داده استفاده می‌شود.

یکی از نکات مهم، مدیریت رویداد notificationclick است که وقتی کاربر روی اعلان کلیک می‌کند، فراخوانی می‌شود. در این رویداد باید پنجره یا تب مناسب را باز کنید. همچنین، باید رویداد notificationclose را مدیریت کنید. برای دریافت اعلان‌ها در پس‌زمینه، Service Worker باید شامل کد نمایش اعلان و مدیریت کلیک باشد.

برای آشنایی بیشتر با Service Worker و مسائل مربوط به آن، مقاله‌ای با عنوان وب پوش نوتیفیکیشن: وقتی کاربر آفلاین باشه چی؟ مفید است.

چرخه حیات اشتراک (Subscription)

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

مرحله درخواست مجوز با استفاده از Notification.requestPermission() انجام می‌شود. پس از موافقت کاربر، با استفاده از registration.pushManager.subscribe() اشتراک ایجاد می‌شود. به عنوان گزینه، باید applicationServerKey (کلید عمومی VAPID) را به این متد بدهید تا اشتراک به هویت شما گره بخورد. اشتراک باید در اولین فرصت به سرور ارسال و ذخیره شود.

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

برای کاهش خطاهای ناشی از اشتراک‌های باطل، می‌توانید یک زمان‌بندی (Cron Job) برای پاکسازی خودکار اشتراک‌های نامعتبر راه‌اندازی کنید. همچنین، می‌توانید رویداد pushsubscriptionchange را در Service Worker مدیریت کنید که در صورت تغییر اشتراک فراخوانی می‌شود و اطلاعات جدید را به سرور ارسال می‌کند. این کار باعث به‌روزرسانی خودکار می‌شود.

بهینه‌سازی تحویل‌پذیری

تحویل‌پذیری (Deliverability) به درصد اعلان‌هایی اشاره دارد که به کاربران نمایش داده می‌شوند. عوامل فنی متعددی بر این شاخص تأثیر می‌گذارند. مهم‌ترین آنها، اعتبار دامنه شما است. Push Service ها ممکن است پیام‌های شما را به دلیل استفاده از آدرس‌های آی‌پی مشکوک یا عدم تطابق با VAPID مسدود کنند. برای بهینه‌سازی تحویل‌پذیری، باید از یک زیرساخت پایدار استفاده کنید و نرخ خطا را به حداقل برسانید.

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

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

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

عیب‌یابی مشکلات رایج

یکی از رایج‌ترین مشکلات، ارسال اعلان اما عدم نمایش آن است. این مشکل می‌تواند دلایل متعددی داشته باشد. اول، بررسی کنید که Service Worker به درستی ثبت شده است و رویداد push را مدیریت می‌کند. اگر Service Worker خطایی در کد داشته باشد، اعلان نمایش داده نمی‌شود. دوم، مطمئن شوید که endpoint اشتراک معتبر است و پیام به Push Service ارسال شده است.

شما می‌توانید با استفاده از ابزارهای توسعه‌دهنده مرورگر، مانند بخش Network و Application در Chrome، اشتراک را بررسی و پیام‌هایی که ارسال شده‌اند را مشاهده کنید. همچنین، می‌توانید از ابزارهای آنلاین برای تست Web Push استفاده کنید. اگر کد وضعیت 201 دریافت می‌کنید، یعنی پیام به Push Service تحویل شده است، اما ممکن است مرورگر به دلایلی آن را نمایش ندهد.

یکی دیگر از مشکلات رایج، عدم دریافت اعلان در حالت ناشناس (Incognito) یا وقتی مرورگر بسته است. در حالت ناشناس، اشتراک پوش ممکن است با بستن مرورگر حذف شود. همچنین، برخی مرورگرها مانند سافاری در حالت ذخیره انرژی، ارسال اعلان را به تأخیر می‌اندازند. برای مدیریت این مسائل، مقاله وب پوش نوتیفیکیشن ها ارسال میشوند اما در مقصد دریافت نمی شوند! مفید است.

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

برای مدیریت اعلان‌های تکراری، از CollapseKey یا استفاده از هدر Topic بهره ببرید. مقاله بروزرسانی پوش نوتیفیکیشن با Collapse ID راهنمای عملی در این زمینه است.

ترندهای فنی آینده

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

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

علاوه بر این، بحث Web Push و سئو نیز مطرح است. اگرچه پوش نوتیفیکیشن به طور مستقیم بر رتبه گوگل تأثیر نمی‌گذارد، اما می‌تواند باعث افزایش تعامل و بازگشت کاربران شود که به طور غیرمستقیم بر سئو مؤثر است. مقاله پوش نوتیفیکیشن وب و سئو به این موضوع پرداخته است.

جمع‌بندی

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

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

زیرساخت فنی پوش نوتیفیکیشن: راهنمای جامع پروتکل‌ها، رمزنگاری و تحویل‌پذیری در ۲۰۲۶