APNS: คืออะไร, Apple Push Notification Service ทำงานอย่างไรและสถาปัตยกรรมของมัน

APNS คืออะไร?

Apple Push Notification Service (APNS) คือบริการเฉพาะของ Apple สำหรับกำหนดเส้นทางการแจ้งเตือนแบบ push จากเซิร์ฟเวอร์แอปพลิเคชันไปยังอุปกรณ์ของผู้ใช้ แตกต่างจาก FCM ตรงที่ APNS ไม่รองรับ Android หรือแพลตฟอร์มอื่น ๆ — มันผูกติดกับระบบนิเวศของ Apple อย่างสมบูรณ์

บริการทำงานผ่าน การเชื่อมต่อ TLS ถาวร ที่อุปกรณ์ Apple แต่ละเครื่องสร้างขึ้นกับเซิร์ฟเวอร์ APNS เมื่อเริ่มต้นระบบ การเชื่อมต่อนี้จะถูกเก็บไว้ในพื้นหลังและใช้เพื่อส่งการแจ้งเตือนด้วยความหน่วงต่ำที่สุด

APNS จัดการโครงสร้างพื้นฐานการส่งทั้งหมด: การเข้ารหัส, การตรวจสอบสิทธิ์, การจัดลำดับความสำคัญ และการส่งซ้ำเมื่ออุปกรณ์ไม่พร้อมใช้งาน นักพัฒนาเพียงแค่ต้องให้เพย์โหลดที่มีรูปแบบถูกต้องและโทเค็น push ที่ถูกต้อง

วิวัฒนาการของ APNS

เดิมที APNS ทำงานผ่าน โปรโตคอลไบนารี บนพอร์ต 2195–2196 ตั้งแต่ปี 2015 Apple ได้ย้ายบริการไปยังโปรโตคอล HTTP/2 ที่ทันสมัย ซึ่งรองรับการมัลติเพล็กซ์ การบีบอัดส่วนหัว และการแจ้งเตือนแบบ push จากเซิร์ฟเวอร์ HTTP/2 กลายเป็นข้อบังคับตั้งแต่เดือนมิถุนายน 2020

Apple Push Notification Service ทำงานอย่างไร?

กระบวนการส่งการแจ้งเตือนแบบ push ผ่าน APNS ประกอบด้วยห้าขั้นตอน: การลงทะเบียนอุปกรณ์, การรับโทเค็น push, การส่งคำขอจากเซิร์ฟเวอร์, การกำหนดเส้นทาง APNS และการส่งไปยังอุปกรณ์

• การลงทะเบียน — เมื่อเริ่มต้น แอปเรียก registerForRemoteNotifications ระบบจะติดต่อ APNS
• โทเค็น — APNS ส่งคืนโทเค็น push ให้กับอุปกรณ์ — สตริงที่ไม่ซ้ำกันซึ่งระบุแอปบนอุปกรณ์
• การส่ง — เซิร์ฟเวอร์แอปพลิเคชันส่งคำขอ POST ไปยัง https://api.push.apple.com พร้อมโทเค็นและเพย์โหลด
• การกำหนดเส้นทาง — APNS ค้นหาอุปกรณ์ด้วยโทเค็นและส่งข้อความผ่านการเชื่อมต่อ TLS
• การประมวลผล — iOS/macOS แสดงการแจ้งเตือนหรือส่งต่อไปยังแอปตามสถานะ

หากอุปกรณ์ ไม่พร้อมใช้งาน (ปิดเครื่องหรือไม่มีเครือข่าย) APNS จะเก็บข้อความล่าสุดสำหรับแต่ละแอปและส่งเมื่อการเชื่อมต่อได้รับการกู้คืน ระยะเวลาการเก็บสูงสุดคือ 4 สัปดาห์ หลังจากนั้นข้อความจะถูกลบ

การตรวจสอบสิทธิ์ใน APNS: โทเค็นและใบรับรอง

Apple รองรับสองวิธีในการตรวจสอบสิทธิ์เซิร์ฟเวอร์แอปพลิเคชันเมื่อส่งการแจ้งเตือนแบบ push แต่ละวิธีมีลักษณะเฉพาะของตัวเองในด้านระยะเวลาที่มีผล การจัดการ และความสะดวกในการใช้งาน

การตรวจสอบสิทธิ์ แบบใช้ Token เป็นวิธีที่ Apple แนะนำตั้งแต่ปี 2019 คุณสร้างคีย์ p8 หนึ่งอันใน Apple Developer Console อัปโหลดไปยังเซิร์ฟเวอร์ของคุณ และเซ็นคำขอ APNS แต่ละรายการด้วยคีย์นั้น คีย์ไม่หมดอายุและทำงานกับแอปทั้งหมดในบัญชีของคุณ

ควรเลือกวิธีตรวจสอบสิทธิ์แบบใด

สำหรับโปรเจกต์ใหม่ การตรวจสอบสิทธิ์ แบบใช้ Token เหมาะกว่าอย่างชัดเจน: คีย์ p8 เดียวสำหรับทั้งบัญชี ไม่มีกำหนด ไม่ผูกกับสภาพแวดล้อม วิธีใช้ใบรับรอง (.p12) ยังคงใช้ในโปรเจกต์เก่า แต่ต้องเปลี่ยนทุกปีและต้องใช้ใบรับรองแยกต่างหากสำหรับ 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 — ผู้ใช้ควรได้รับทันที สำหรับการแจ้งเตือนพื้นหลัง ใช้ 5 — ระบบอาจชะลอการส่งเพื่อประหยัดแบตเตอรี่ ลำดับความสำคัญที่ไม่ถูกต้องสำหรับพื้นหลังอาจทำให้ APNS ปฏิเสธ

รูปแบบเพย์โหลดของ APNS

APNS รับเพย์โหลดในรูปแบบ JSON ด้วยขนาดสูงสุด 4 KB สำหรับการแจ้งเตือนปกติและ 5 KB สำหรับ 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 KB ดังนั้นหลีกเลี่ยงการถ่ายโอนข้อมูลปริมาณมากผ่าน push; โหลดผ่าน API หลังจากเปิดการแจ้งเตือน

ตัวอย่างการส่งผ่าน API HTTP/2

ในการส่งการแจ้งเตือนแบบ push จากเซิร์ฟเวอร์ คุณต้องดำเนินการคำขอ POST ไปยังปลายทาง APNS ด้วยส่วนหัวการตรวจสอบสิทธิ์ที่ถูกต้อง ด้านล่างเป็นตัวอย่างใน Node.js ที่ใช้การตรวจสอบสิทธิ์แบบใช้ Token

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 KB ให้ลดเพย์โหลด

TooManyRequests (429) — เกินขีดจำกัดคำขอ APNS กำหนดโควตาสำหรับจำนวนการส่งต่อวินาที เมื่อได้รับ 429 ให้ใช้การหน่วงเวลาแบบเอกซ์โพเนนเชียล (exponential backoff) และลองใหม่ ขอแนะนำไม่เกิน 100 คำขอต่อวินาทีต่อการเชื่อมต่อ HTTP/2

ข้อผิดพลาดฝั่ง APNS — 500 และ 503 (ข้อผิดพลาดภายในเซิร์ฟเวอร์ / บริการไม่พร้อมใช้งาน) สิ่งเหล่านี้คือความล้มเหลวชั่วคราวของโครงสร้างพื้นฐานของ Apple ในกรณีดังกล่าว ให้ลองใหม่ด้วยความหน่วง 1–5 วินาที ไม่เกิน 3 ครั้ง ข้อผิดพลาด 5xx ถาวรกับเซิร์ฟเวอร์ที่ทำงานได้อย่างสมบูรณ์นั้นหายาก และมักเกี่ยวข้องกับปัญหาการเชื่อมต่อ TLS

สำหรับสภาพแวดล้อม Production ต้องแน่ใจว่าได้ implement การบันทึกข้อผิดพลาด APNS ทั้งหมด พร้อมโทเค็น รหัสข้อผิดพลาด และเวลา ซึ่งจะช่วยระบุปัญหากับใบรับรอง โควตา หรือโทเค็นอุปกรณ์เฉพาะได้อย่างรวดเร็ว ตรวจสอบวันหมดอายุของใบรับรองเป็นประจำหากคุณใช้การตรวจสอบสิทธิ์แบบใช้ใบรับรอง