APNS: چیست، ساختار Apple Push Notification Service و چگونگی کار آن

APNS چیست؟

Apple Push Notification Service (APNS) — سرویس خود Apple برای مسیریابی اعلام‌های push از سرور برنامه به دستگاه‌های کاربران است. بر خلاف FCM، APNS از Android یا سایر پلتفرم‌ها پشتیبانی نمی‌کند — آن کاملاً به اکوسیستم Apple وابسته است.

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

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

تکامل APNS

در ابتدا APNS از طریق پروتکل دودویی در پورت‌های 2195–2196 کار می‌کرد. از سال 2015، Apple به پروتکل مدرن HTTP/2 منتقل شد که از چندگانه‌سازی، فشرده سازی هدر و اعلام‌های push سرور پشتیبانی می‌کند. HTTP/2 از جوان 2020 الزامی شد.

Apple Push Notification Service چگونه کار می‌کند؟

فرآیند تحویل اعلام push از طریق APNS شامل پنج مرحله است: ثبت دستگاه، دریافت push token، ارسال درخواست توسط سرور، مسیریابی APNS و تحویل به دستگاه.

• ثبت نام — برنامه در طول راه‌اندازی registerForRemoteNotifications را فراخوان می‌کند، سیستم با APNS ارتباط برقرار می‌کند
• توکن — APNS یک push token به دستگاه برمی‌گرداند — یک رشته منحصربه‌فرد که برنامه را روی دستگاه شناسایی می‌کند
• ارسال — سرور برنامه یک درخواست POST به https://api.push.apple.com با توکن و بار مفید ارسال می‌کند
• مسیریابی — APNS دستگاه را توسط توکن پیدا می‌کند و پیام را از طریق اتصال TLS تحویل می‌دهد
• پردازش — iOS/macOS بسته به وضعیت، اعلام را نمایش می‌دهد یا آن را به برنامه منتقل می‌کند

اگر دستگاه غیرقابل دسترس باشد (خاموش یا بدون شبکه)، APNS آخرین پیام را برای هر برنامه ذخیره می‌کند و پس از بازگشتن اتصال آن را تحویل می‌دهد. حداکثر زمان ذخیره — 4 هفته، پس از آن پیام حذف می‌شود.

احراز هویت در APNS: Token و گواهینامه

Apple دو روش احراز هویت سرور برنامه را برای ارسال اعلام‌های push پشتیبانی می‌کند. هر روش ویژگی‌های خود را از نظر مدت اعتبار، مدیریت و راحتی استفاده دارد.

Token-based احراز هویت — روش توصیه‌شده توسط Apple از سال 2019. شما یک کلید p8 در Apple Developer Console ایجاد می‌کنید، آن را روی سرور بارگذاری می‌کنید و هر درخواست APNS را با آن امضا می‌کنید. کلید منقضی نمی‌شود و برای همه برنامه‌های حساب شما کار می‌کند.

کدام روش احراز هویت را انتخاب کنیم

برای پروDAژه‌های جدید، Token-based احراز هویت به صورت قطع ترجیح دارد: یک کلید p8 برای کل حساب، بی‌مدت، بدون وابستگی به محیط. Certificate-based (.p12) هنوز در پروDAژه‌های legacy استفاده می‌شود، اما نیازمند تعویض سالانه و گواهینامه‌های جداگانه برای Sandbox و Production است. هنگام برنامه‌ریزی CI/CD زمان انقضای گواهینامه را در نظر بگیرید.

انواع اعلام‌های push APNS

APNS از سه نوع اعلام push پشتیبانی می‌کند که از نظر رفتار روی دستگاه و نیازمندی‌های مشخصات درخواست متفاوت هستند. انتخاب نوع بستگی به سناریو UX و فوریت پیام دارد.

• Alert — اعلام استاندارد با عنوان، متن و دکمه‌های اقدام اختیاری
• Background — تحویل خاموش داده‌ها (silent push) بدون نمایش به کاربر، پردازش در application:didReceiveRemoteNotification
• VOIP — نوع ویژه برای برنامه‌های VoIP (PushKit)، حتی در صورت بسته بودن برنامه فوراً تحویل می‌شود

برای اعلام‌های Background باید کلید content-available: 1 را قرار داده و اولویت را 5 (تحویل با بهینه‌سازی مصرف انرژی) تعیین کنید. سیستم می‌تواند تعداد اعلام‌های پس‌زمینه را محدود کند اگر برنامه آن‌ها را به موقع پردازش نکند.

تنظیم اولویت تحویل

APNS از دو مقدار اولویت پشتیبانی می‌کند: 10 (تحویل فوری) و 5 (بهینه‌سازی مصرف انرژی). برای اعلام‌های alert از 10 استفاده کنید — کاربر باید آن‌ها را فوراً دریافت کند. برای background از 5 استفاده کنید — سیستم می‌تواند برای صرفه‌جویی در باتری تحویل را به تاخیر بیندازد. اولویت نامناسب برای background می‌تواند منجر به رد اعلام توسط APNS شود.

فرمت بار مفید APNS

APNS بار مفید را در فرمت JSON با حداکثر اندازه 4 کیلوبایت برای اعلام‌های عادی و 5 کیلوبایت برای VOIP قبول می‌کند. بار مفید شامل فرهنگ الزامی aps با تنظیمات نمایش و فلدهای دلخواه است.

{
    "aps": {
        "alert": {
            "title": "نوین پیغام",
            "body": "شما 3 چت خوانده نشده دارید"
        },
        "badge": 3,
        "sound": "default",
        "category": "message_category",
        "thread-id": "chat_room_42"
    },
    "customData": {
        "chatId": "42"
    }
}

کلید thread-id اعلام‌ها را در مرکز اعلامات iOS به گروه‌ها تبدیل می‌کند. کلید category اعلام را برای نمایش دکمه‌های اقدام به UNNotificationCategory متصل می‌کند. بدون این کلیدها، همه اعلام‌ها به صورت جداگانه نمایش داده می‌شوند.

فلدهای سفارشی در APNS-پیامبار

علاوه بر فرهنگ الزامی aps، APNS-پیامبار می‌تواند هر فلد دلخواهی را در سطح بالا داشته باشد. این فلدها از طریق فرهنگ userInfo در زمان پردازش اعلام در دسترس برنامه قرار می‌گیرند. داده‌های سفارشی برای انتقال شناسه‌های نهادها، صفحات یا لینک‌ها مفید هستند. حداکثر اندازه پیامبار 4 کیلوبایت است، بنابراین از انتقال حجم بالای داده از طریق push خودداری کنید؛ آن‌ها را پس از باز شدن اعلام از طریق API بارگذاری کنید.

نمونه ارسال از طریق HTTP/2 API

برای ارسال اعلام push در سرور، باید یک درخواست POST به endpoint APNS با هدرهای احراز هویت مناسب ارسال کنید. در زیر یک نمونه با استفاده از احراز هویت Token-based در Node.js آورده شده است.

const http2 = require("http2")
const fs = require("fs")
const jwt = require("jsonwebtoken")

const token = jwt.sign(
    { iss: "TEAM_ID", iat: Math.floor(Date.now() / 1000) },
    fs.readFileSync("AuthKey.p8"),
    { algorithm: "ES256", keyid: "KEY_ID" }
)

const payload = JSON.stringify({
    aps: { alert: { title: "سلام!", body: "پیش تستی push" } }
})

const client = http2.connect(
    "https://api.push.apple.com"
)

const req = client.request({
    ":method": "POST",
    ":path": "/3/device/DEVICE_PUSH_TOKEN",
    "authorization": "bearer " + token,
    "apns-push-type": "alert",
    "apns-topic": "com.example.app",
    "apns-priority": "10"
})
req.end(payload)

req.on("response", (headers) => {
    if (headers[":status"] === 200) {
        console.log("Push با موفقیت ارسال شد")
    }
})

پس از ارسال، APNS ستون HTTP 200 را در صورت تحویل موفق یا کد خطا را با توضیح در بدنه پاسخ برمی‌گرداند. پردازش خطای token-unregistered (410) مهم است — چنین توکنی باید از سرور حذف شود، زیرا برنامه از دستگاه حذف شده است.

خطاهای APNS و پردازش آنها

APNS برای هر درخواست ارسال، ستون‌های HTTP را برمی‌گرداند. ارسال موفق — ستون 200. خطاها نیازمند راهبردهای مختلف پردازش هستند. BadDeviceToken (400) یا Unregistered (410) — توکن دستگاه منقضی شده، باید از سرور حذف شود. PayloadTooLarge (413) — حد مجاز 4 کیلوبایت تجاوز شده، پیامبار را کوتاه کنید.

خطای TooManyRequests (429) — حد درخواستها تجاوز شده است. APNS برای تعداد ارسال‌ها در ثانیه سهمیه تعیین می‌کند. در صورت دریافت 429، تأخیر نمایی (exponential backoff) پیاده سازی شود و ارسال تکرار شود. توصیه می‌شود از 100 درخواست در ثانیه برای یک اتصال HTTP/2 تجاوز نکنید.

خطاهای طرف APNS — 500 و 503 (Internal Server Error / Service Unavailable). اینها اختلالات موقت زیرساخت Apple هستند. در چنین مواردی، ارسال را با تأخیر 1–5 ثانیه، حداکثر 3 بار تکرار کنید. خطاهای 5xx مداوم در سرور کاملاً عامل پادیدار نادر است و معمولاً مربوط به مشکلات اتصال TLS است.

برای محیط Production، باید ثبت همه خطاهای APNS را با قید توکن، کد خطا و زمان اجرا کنید. این کار به شناسایی سریع مشکلات گواهینامه‌ها، لیمیت‌ها یا توکن‌های خاص کمک می‌کند. اگر از احراز هویت Certificate-based استفاده می‌کنید، مدت اعتبار گواهینامه‌ها را منظم بررسی کنید.