iOS "푸시"알림은 서버를 폴링 할 필요없이 특정 장치에 어떻게 전달됩니까?
예를 들어 Facebook에서 새 메시지를 받았다고 가정 해 보겠습니다. Facebook은 내 기기가 이와 같은 알림을 받아야한다고 Apple에 알립니다. 그러나 Apple은 메시지를 푸시 할 장치 / IP를 어떻게 알 수 있습니까?
iOS "푸시"알림은 서버를 폴링 할 필요없이 특정 장치에 어떻게 전달됩니까?
예를 들어 Facebook에서 새 메시지를 받았다고 가정 해 보겠습니다. Facebook은 내 기기가 이와 같은 알림을 받아야한다고 Apple에 알립니다. 그러나 Apple은 메시지를 푸시 할 장치 / IP를 어떻게 알 수 있습니까?
답변:
댓글을 달기 엔 너무 많았어요.
문서에서.
Apple 푸시 알림 서비스 (APN)는 해당 알림을 수신하도록 등록 된 애플리케이션이있는 기기에 푸시 알림을 전파합니다. 각 장치는 서비스와 공인되고 암호화 된 IP 연결을 설정하고이 영구 연결을 통해 알림을받습니다. 공급자는 클라이언트 애플리케이션 용으로 들어오는 데이터를 모니터링하면서 지속적이고 안전한 채널을 통해 APN에 연결합니다. 애플리케이션에 대한 새 데이터가 도착하면 공급자는 채널을 통해 알림을 준비하고 APN으로 전송하여 알림을 대상 장치로 푸시합니다.
자세한 정보와 사용 및 구성 방법에 대해서는 문서를 읽는 것이 좋습니다. 모두 거기에 있습니다.
각 장치는 고유 한 장치 토큰을 사용하여 데이터로 업데이트 할 수 있습니다. 이 그림은 모든 것을 설명합니다. .
APN (Apple 푸시 알림 서비스)은 원격 알림 기능의 핵심입니다. 앱 개발자가 iOS (및 간접적으로 watchOS), tvOS 및 macOS 장치에 정보를 전파 할 수있는 강력하고 안전하며 매우 효율적인 서비스입니다.
사용자 기기에서 앱을 처음 시작할 때 시스템은 앱과 APN간에 인증되고 암호화 된 영구 IP 연결을 자동으로 설정합니다. 이 연결을 통해 앱은 원격 알림 지원 구성에 설명 된대로 알림을 수신 할 수 있도록 설정을 수행 할 수 있습니다.
알림 전송을위한 나머지 절반 (제공자 서버와 APN 간의 지속적이고 안전한 채널)은 온라인 개발자 계정의 구성과 Apple에서 제공 한 암호화 인증서를 사용해야합니다. 공급자는 배포 및 관리하고 APN과 함께 작동하도록 구성하는 서버입니다. 그림 1-1은 원격 알림 전달 경로를 보여줍니다.
그림 1-1 공급자에서 앱으로 원격 알림 전달
제공 업체와 앱에서 푸시 알림 설정을 완료하면 제공 업체가 APN에 알림 요청을 보낼 수 있습니다. APN은 해당 알림 페이로드를 각 대상 장치에 전달합니다. 알림을 받으면 시스템은 기기의 적절한 앱에 페이로드를 전달하고 사용자와의 상호 작용을 관리합니다.
장치의 전원이 켜져 있지만 앱이 실행되지 않은 상태에서 앱에 대한 알림이 도착하는 경우 시스템은 여전히 알림을 표시 할 수 있습니다. APN이 알림을 보낼 때 장치의 전원이 꺼지면 APN은 알림을 보류하고 나중에 다시 시도합니다 (자세한 내용은 서비스 품질, 저장 후 전달 및 통합 알림 참조).
공급자 서버는 APN에 참여하기 위해 다음과 같은 책임이 있습니다.
공급자가 보내는 각 원격 알림 요청에 대해 다음을 수행해야합니다.
그림 1-2는 APN이 앱을 실행하는 장치에 대해 활성화하는 일종의 가상 네트워크를 보여줍니다. 알림로드를 처리하기 위해 일반적으로 각각 APN에 대한 자체 영구 및 보안 연결이있는 여러 공급자를 배포합니다. 그런 다음 각 공급자는 유효한 장치 토큰이있는 모든 장치를 대상으로 알림 요청을 보낼 수 있습니다.
그림 1-2 여러 공급자의 원격 알림을 여러 장치로 푸시
Apple 푸시 알림 서비스에는 저장 후 전달 기능을 수행하는 서비스 품질 (QoS) 구성 요소가 포함되어 있습니다. APN이 알림 전달을 시도하고 대상 장치가 오프라인 인 경우 APN은 제한된 기간 동안 알림을 저장하고 장치를 다시 사용할 수있을 때 전달합니다. 이 구성 요소는 기기 및 앱별로 가장 최근 알림 만 저장합니다. 장치가 오프라인 인 경우 해당 장치를 대상으로하는 알림 요청을 보내면 이전 요청이 삭제됩니다. 기기가 오랫동안 오프라인 상태로 유지되면 APN에 저장된 모든 알림이 삭제됩니다.
유사한 알림의 병합을 허용하려면 알림 요청에 축소 식별자를 포함 할 수 있습니다. 일반적으로 장치가 온라인 상태 일 때 APN에 보내는 각 알림 요청은 장치에 알림을 전달합니다. 그러나 apns-collapse-id 키가 HTTP / 2 요청 헤더에 있으면 APN은 해당 키의 값이 동일한 요청을 병합합니다. 예를 들어, 동일한 헤드 라인을 두 번 보내는 뉴스 서비스는 두 요청에 대해 동일한 축소 식별자 값을 사용할 수 있습니다. 그런 다음 APN은 두 요청을 하나의 알림으로 통합하여 장치에 전달합니다. apns-collapse-id 키에 대한 자세한 내용은
APN은 연결 신뢰와 장치 토큰 신뢰라는 두 가지 신뢰 수준을 사용하여 종단 간 암호화 유효성 검사 및 인증을 시행합니다.
연결 신뢰는 공급자와 APN간에, 그리고 APN과 장치간에 작동합니다.
장치 토큰 신뢰는 각 원격 알림에 대해 종단 간 작동합니다. 알림이 올바른 시작 (제공자) 및 종료 (장치) 지점 사이에서만 라우팅되도록합니다.
기기 토큰은 Apple이 특정 기기의 특정 앱에 할당 한 고유 식별자를 포함하는 불투명 한 NSData 인스턴스입니다. APN 만 장치 토큰의 내용을 디코딩하고 읽을 수 있습니다. 각 앱 인스턴스는 APN에 등록 할 때 고유 한 장치 토큰을 수신 한 다음 원격 알림 지원 구성에 설명 된대로 토큰을 공급자에게 전달해야합니다. 공급자는 연결된 장치를 대상으로하는 각 푸시 알림 요청에 장치 토큰을 포함해야합니다. APN은 기기 토큰을 사용하여 알림이 의도 된 고유 한 앱-기기 조합에만 전달되도록합니다.
APN은 다양한 이유로 새 장치 토큰을 발급 할 수 있습니다.
결과적으로 앱은 APN- 장치 연결 신뢰 및 장치 토큰에 설명 된대로 시작시 장치 토큰을 요청해야합니다. 코드 예제는 원격 알림 수신 등록을 참조하십시오.
APN을 사용하여 HTTP / 2 기반 TLS 세션을 설정하려면 각 공급자에 GeoTrust 글로벌 CA 루트 인증서가 설치되어 있는지 확인해야합니다. 공급자가 macOS를 실행하는 경우이 루트 인증서는 기본적으로 키 체인에 있습니다. 다른 시스템에서는이 인증서를 명시 적으로 설치해야 할 수 있습니다. GeoTrust 루트 인증서 웹 사이트에서이 인증서를 다운로드 할 수 있습니다. 다음은 인증서에 대한 직접 링크입니다.
그림 1-3은 HTTP / 2 기반 APN 공급자 API를 사용하여 신뢰를 설정하고 JWT 공급자 인증 토큰을 사용하여 알림을 보내는 방법을 보여줍니다.
그림 1-3 토큰 기반 공급자 연결 신뢰 설정 및 사용
그림 1-3에 표시된 것처럼 토큰 기반 공급자 신뢰는 다음과 같이 작동합니다.
공급자는 그림에서 "TLS 시작"이라는 화살표로 표시된 TLS (전송 계층 보안)를 사용하여 APN과의 보안 연결을 요청합니다.
그런 다음 APN은 공급자에게 그림에서 다음 화살표로 표시되는 APN 인증서 (“APN 인증서”로 표시됨)를 제공하고 공급자는이를 검증합니다.
이 시점에서 연결 신뢰가 설정되고 공급자 서버가 토큰 기반 원격 푸시 알림 요청을 APN에 보낼 수 있습니다. 공급자가 보내는 각 알림 요청에는 그림에서 "알림 푸시"라는 화살표로 표시된 JWT 인증 토큰이 함께 제공되어야합니다.
APN은 각 푸시에 응답하며 그림에서 "HTTP / 2 응답"이라고 표시된 화살표로 표시됩니다.
공급자가이 단계에서받을 수있는 응답에 대한 자세한 내용은 APN의 HTTP / 2 응답을 참조하세요.
그림 1-4는 Apple에서 발급 한 SSL 인증서를 사용하여 공급자와 APN 간의 신뢰를 설정하는 방법을 보여줍니다. 그림 1-3과 달리이 그림은 알림 푸시 자체를 보여주지 않지만 TLS (전송 계층 보안) 연결 설정시 중지됩니다. 인증서 기반 신뢰 체계에서 푸시 알림 요청은 인증되지 않지만 함께 제공되는 장치 토큰을 사용하여 유효성이 검사됩니다.
그림 1-4 인증서 기반 공급자 연결 신뢰 설정
그림 1-4에 표시된 것처럼 인증서 기반 공급자 -APN 신뢰는 다음과 같이 작동합니다.
공급자는 그림에서 "TLS 시작"이라는 화살표로 표시된 TLS (전송 계층 보안)를 사용하여 APN과의 보안 연결을 요청합니다.
그런 다음 APN은 공급자에게 그림에서 다음 화살표로 표시되는 APN 인증서 (“APN 인증서”로 표시됨)를 제공하고 공급자는이를 검증합니다.
그런 다음 공급자는 Apple에서 제공 한 공급자 인증서 (Xcode 도움말의 "범용 APN 클라이언트 SSL 인증서 생성"에 설명 된대로 이전에 온라인 개발자 계정에서 얻은)를 "공급자"라는 화살표로 표시된 APN으로 다시 보내야합니다. 증명서."
그런 다음 APN은 공급자 인증서의 유효성을 검사하여 연결 요청이 합법적 인 공급자로부터 시작되었는지 확인하고 TLS 연결을 설정합니다.
이 시점에서 연결 신뢰가 설정되고 공급자 서버가 인증서 기반 원격 푸시 알림 요청을 APN으로 보낼 수 있습니다.
이 섹션에 설명 된대로 APN과 각 장치 간의 신뢰는 앱의 참여없이 자동으로 설정됩니다.
각 장치에는 초기 장치 활성화시 운영 체제에서 제공하고 장치의 키 체인에 저장되는 암호화 인증서와 개인 암호화 키가 있습니다. 활성화하는 동안 APN은 그림 6-5와 같이 인증서와 키를 기반으로 장치에 대한 연결을 인증하고 유효성을 검사합니다.
그림 1-5 장치와 APN 간의 연결 신뢰 설정
그림 1-5에 표시된대로 APN- 장치 신뢰는 다음과 같이 작동합니다.
장치 토큰을받은 후 앱은 앱의 연결된 공급자에 연결하고 토큰을 전달해야합니다. 이 단계는 공급자가 나중에 장치를 대상으로하는 APN에 알림 요청을 보낼 때 장치 토큰을 포함해야하기 때문에 필요합니다. 토큰 전달을 위해 작성한 코드는 원격 알림 수신 등록에도 표시됩니다.
사용자가 처음으로 장치를 활성화하거나 APN이 새 장치 토큰을 발급했는지 여부에 관계없이 프로세스는 유사하며 그림 6-6에 나와 있습니다.
그림 1-6 장치 토큰 관리
앱은 위쪽 화살표에 표시된 것처럼 원격 알림을 위해 APN에 등록됩니다. 앱이 이미 등록되어 있고 앱별 장치 토큰이 변경되지 않은 경우 시스템은 기존 토큰을 앱에 신속하게 반환하고이 프로세스는 4 단계로 건너 뜁니다.
새 장치 토큰이 필요한 경우 APN은 장치 인증서에 포함 된 정보를 사용하여 토큰을 생성합니다. 토큰 키를 사용하여 토큰을 암호화하고 오른쪽을 가리키는 가운데 화살표에 표시된 것처럼 장치로 반환합니다.
시스템은 application : didRegisterForRemoteNotificationsWithDeviceToken : delegate 메소드를 호출하여 기기 토큰을 앱에 다시 전달합니다.
토큰을 받으면 앱 (대리자 메서드 내)에서이 토큰을 바이너리 또는 16 진수 형식으로 제공 업체에 전달해야합니다. 공급자는이 토큰없이 장치에 알림을 보낼 수 없습니다. 자세한 내용은 원격 알림 지원 구성의 원격 알림 수신 등록을 참조하십시오.
APN 장치 토큰은 가변 길이입니다. 크기를 하드 코딩하지 마십시오.
공급자가 APN에 푸시 알림 요청을 보낼 때 고유 한 앱-장치 조합을 식별하는 장치 토큰이 포함됩니다. 이 단계는 그림 6-7에서 공급자와 APN 사이의 "토큰, 페이로드"화살표로 표시됩니다. APN은 토큰을 해독하여 요청의 유효성을 확인하고 대상 장치를 결정합니다. APN이 발신자와 수신자가 합법적이라고 판단하면 식별 된 장치로 알림을 보냅니다.
그림 1-7 공급자에서 장치로의 원격 알림 경로
장치가 알림을 수신 한 후 (그림 1-7에 표시된 마지막 단계 이후) 시스템은 원격 알림을 앱에 전달합니다.
참고 : Apple 푸시 알림 서비스
이제 기술 흐름을 이해하려면 여기를 살펴보십시오 . iOS 애플리케이션에서 Apple 푸시 알림 서비스를 구현하는 방법은 무엇입니까?
장치는 푸시 알림을 위해 서버를 계속 폴링하지 않습니다.
간단하게 유지하려면 iPhone이 인터넷에 연결되어 있다고 생각해보십시오. 인터넷에 연결하면 iPhone이 Apple Push Notifications 서버에 대한 연결을 설정합니다.이 연결은 열린 연결입니다. 즉, 데이터가 서버에 도착하는 순간 서버에서 iPhone으로 데이터를 보낼 수 있습니다.
Apple은 푸시 알림에 HTTP 프로토콜을 사용하지 않지만 HTTP 프로토콜을 이해한다면 거의 비슷한 방법론입니다.
http://en.wikipedia.org/wiki/Push_technology#HTTP_server_push