APNS: nó là gì, cách Apple Push Notification Service hoạt động và kiến trúc của nó

APNS là gì?

Apple Push Notification Service (APNS) là dịch vụ độc quyền của Apple để định tuyến thông báo push từ máy chủ ứng dụng đến thiết bị của người dùng. Không giống FCM, APNS không hỗ trợ Android hoặc các nền tảng khác — nó hoàn toàn gắn với hệ sinh thái Apple.

Dịch vụ hoạt động thông qua kết nối TLS liên tục mà mỗi thiết bị Apple thiết lập với máy chủ APNS khi khởi động. Kết nối này được duy trì trong nền và được sử dụng để gửi thông báo với độ trễ tối thiểu.

APNS xử lý toàn bộ cơ sở hạ tầng gửi: mã hóa, xác thực, ưu tiên và gửi lại khi thiết bị không khả dụng. Nhà phát triển chỉ cần cung cấp tải trọng được định dạng đúng cách và token push hợp lệ.

Sự phát triển của APNS

Ban đầu, APNS hoạt động thông qua giao thức nhị phân trên các cổng 2195–2196. Từ năm 2015, Apple đã chuyển dịch vụ sang giao thức HTTP/2 hiện đại, hỗ trợ ghép kênh, nén tiêu đề và thông báo push từ máy chủ. HTTP/2 trở thành bắt buộc vào tháng 6 năm 2020.

Apple Push Notification Service hoạt động như thế nào?

Quá trình gửi thông báo push qua APNS bao gồm năm giai đoạn: đăng ký thiết bị, nhận token push, gửi yêu cầu từ máy chủ, định tuyến APNS và gửi đến thiết bị.

• Đăng ký — khi khởi động, ứng dụng gọi registerForRemoteNotifications, hệ thống liên hệ APNS
• Token — APNS trả về token push cho thiết bị — một chuỗi duy nhất nhận dạng ứng dụng trên thiết bị
• Gửi — máy chủ ứng dụng gửi yêu cầu POST đến https://api.push.apple.com kèm token và tải trọng
• Định tuyến — APNS tìm thiết bị theo token và gửi tin nhắn qua kết nối TLS
• Xử lý — iOS/macOS hiển thị thông báo hoặc chuyển nó đến ứng dụng tùy theo trạng thái

Nếu thiết bị không khả dụng (tắt hoặc không có mạng), APNS lưu trữ tin nhắn mới nhất cho mỗi ứng dụng và gửi nó khi kết nối được khôi phục. Thời gian lưu trữ tối đa là 4 tuần, sau đó tin nhắn bị xóa.

Xác thực trong APNS: Token và Chứng chỉ

Apple hỗ trợ hai phương pháp xác thực máy chủ ứng dụng khi gửi thông báo push. Mỗi phương pháp có những đặc điểm riêng về thời hạn hiệu lực, quản lý và dễ sử dụng.

Xác thực Dựa trên Token là phương pháp Apple khuyến nghị từ năm 2019. Bạn tạo một khóa p8 duy nhất trong Apple Developer Console, tải nó lên máy chủ của mình và ký mỗi yêu cầu APNS với nó. Khóa không bao giờ hết hạn và hoạt động cho tất cả ứng dụng trong tài khoản của bạn.

Nên chọn phương pháp xác thực nào

Đối với các dự án mới, xác thực Dựa trên Token rõ ràng được ưa tiên hơn: một khóa p8 cho toàn bộ tài khoản, vô hạn, không phụ thuộc môi trường. Phương pháp Dựa trên Chứng chỉ (.p12) vẫn được sử dụng trong các dự án cũ nhưng yêu cầu thay thế hàng năm và chứng chỉ riêng cho Sandbox và Production. Hãy xem xét thời hạn chứng chỉ khi lập kế hoạch CI/CD.

Các loại thông báo push APNS

APNS hỗ trợ ba loại thông báo push, khác nhau về hành vi trên thiết bị và yêu cầu thuộc tính yêu cầu. Việc chọn loại phụ thuộc vào kịch bản UX và mức độ khẩn cấp của tin nhắn.

• Alert — thông báo tiêu chuẩn với tiêu đề, văn bản và các nút hành động tùy chọn
• Background — gửi dữ liệu ẩn (push im lặng) mà không hiển thị cho người dùng, được xử lý trong application:didReceiveRemoteNotification
• VOIP — loại đặc biệt cho ứng dụng VoIP (PushKit), được gửi ngay lập tức ngay cả khi ứng dụng đóng

Đối với thông báo Background, bạn phải chỉ định khóa content-available: 1 và đặt ưu tiên là 5 (gửi tiết kiệm năng lượng). Hệ thống có thể giới hạn số lượng thông báo nền nếu ứng dụng không xử lý chúng kịp thời.

Cấu hình ưu tiên gửi

APNS hỗ trợ hai giá trị ưu tiên: 10 (gửi ngay lập tức) và 5 (tiết kiệm năng lượng). Đối với thông báo alert, sử dụng 10 — người dùng sẽ nhận được chúng ngay lập tức. Đối với thông báo nền, sử dụng 5 — hệ thống có thể trì hoãn gửi để tiết kiệm pin. Ưu tiên không chính xác cho nền có thể dẫn đến từ chối của APNS.

Định dạng tải trọng APNS

APNS chấp nhận tải trọng ở định dạng JSON với kích thước tối đa 4 KB cho thông báo thông thường và 5 KB cho VOIP. Tải trọng chứa từ điển aps bắt buộc với cài đặt hiển thị và các trường tùy chỉnh không bắt buộc.

{
    "aps": {
        "alert": {
            "title": "Tin nhắn mới",
            "body": "Bạn có 3 cuộc trò chuyện chưa đọc"
        },
        "badge": 3,
        "sound": "default",
        "category": "message_category",
        "thread-id": "chat_room_42"
    },
    "customData": {
        "chatId": "42"
    }
}

Khóa thread-id nhóm các thông báo trong Trung tâm thông báo iOS. Khóa category liên kết thông báo với UNNotificationCategory để hiển thị các nút hành động. Nếu không có các khóa này, tất cả thông báo sẽ hiển thị riêng lẻ.

Trường tùy chỉnh trong tải trọng APNS

Ngoài từ điển aps bắt buộc, tải trọng APNS có thể chứa bất kỳ trường tùy chỉnh nào ở cấp cao nhất. Các trường này có thể truy cập được từ ứng dụng thông qua từ điển userInfo khi xử lý thông báo. Dữ liệu tùy chỉnh thuận tiện cho việc truyền các định danh thực thể, màn hình hoặc liên kết. Kích thước tải trọng tối đa là 4 KB, vì vậy tránh truyền khối lượng dữ liệu lớn qua push; hãy tải chúng qua API sau khi mở thông báo.

Ví dụ gửi qua API HTTP/2

Để gửi thông báo push từ máy chủ, bạn cần thực hiện yêu cầu POST đến điểm cuối APNS với các tiêu đề xác thực chính xác. Dưới đây là ví dụ trong Node.js sử dụng xác thực Dựa trên 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: "Xin chào!", body: "Push thử nghiệm" } }
})

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 đã gửi thành công")
    }
})

Sau khi gửi, APNS trả về trạng thái HTTP 200 khi gửi thành công hoặc mã lỗi kèm mô tả trong phần thân phản hồi. Điều quan trọng là xử lý các lỗi token-unregistered (410) — những token đó nên bị xóa khỏi máy chủ, vì ứng dụng đã bị xóa khỏi thiết bị.

Lỗi APNS và cách xử lý

APNS trả về mã trạng thái HTTP cho mỗi yêu cầu gửi. Gửi thành công trả về trạng thái 200. Các lỗi yêu cầu các chiến lược xử lý khác nhau. BadDeviceToken (400) hoặc Unregistered (410) — token thiết bị đã lỗi thời và cần xóa khỏi máy chủ. PayloadTooLarge (413) — vượt quá giới hạn 4 KB, hãy giảm tải trọng.

TooManyRequests (429) — vượt quá giới hạn yêu cầu. APNS đặt hạn ngạch về số lượng gửi mỗi giây. Khi nhận được 429, hãy thực hiện backoff theo cấp số nhân (exponential backoff) và thử lại. Khuyến nghị không vượt quá 100 yêu cầu mỗi giây cho mỗi kết nối HTTP/2.

Lỗi phía APNS — 500 và 503 (Lỗi máy chủ nội bộ / Dịch vụ không khả dụng). Đây là những lỗi tạm thời của cơ sở hạ tầng Apple. Trong những trường hợp này, hãy thử lại với độ trễ 1–5 giây, không quá 3 lần. Lỗi 5xx liên tục với máy chủ hoạt động bình thường là hiếm và thường liên quan đến sự cố kết nối TLS.

Đối với môi trường Production, hãy đảm bảo thực hiện ghi log tất cả lỗi APNS kèm token, mã lỗi và thời gian. Điều này sẽ giúp nhanh chóng xác định các sự cố với chứng chỉ, hạn ngạch hoặc token thiết bị cụ thể. Kiểm tra thường xuyên ngày hết hạn chứng chỉ nếu bạn sử dụng xác thực Dựa trên Chứng chỉ.