[iOS] Push Notification의 원리/동작 구조

Push Notification

푸시 알림이란?

어떤 전송 요청이 중앙 서버에서 시작되는 정보 전달 방식이다.

 

예를 들어서, 뉴스/메일링/광고 서비스 등을 생각할 수 있는데 뉴스를 구독하거나 메인 및 광고 수신에 동의하는 절차를 통해서 자동으로 서버에서 클라이언트로 주기적으로 정보를 제공한다. 

 

(*반대되는 개념으로 pull이 있는데, 이것은 클라이언트가 먼저 데이터를 얻기 위해 서버에 요청하여 데이터를 받는 것이다.

즉, 정보 취득을 통제하는 주체가 서버인지, 클라이언트인지에 따라서 푸시, 풀이 나뉘게 된다.)

 

Push를 보내는 원리

앱에서 일반적으로 푸시 알림을 보내는 원리는 아래와 같다.

(앱의 자체 서버+FCM으로 푸시 알림을 보낸다고 가정하자.)

 

먼저 사용자들은 푸시 알림을 수신할 것인지 여부를 체크한다.
푸시 알림에 동의한 사용자들은 서비스 내에서 발생한 다양한 이벤트에 대한 정보를 푸시로 제공받을 수 있게 된다.
(*이벤트 : 앱에서 사용자가 게시한 글에 댓글 또는 '좋아요'등의 표현이 등록되었을 때 혹은 '친구'로 등록된 사용자가 새로운 콘텐츠를 등록했을 때 등이 있다.)
사용자들이 이러한 이벤트를 발생시키면 이러한 이벤트를 감지해서 APNs에 푸시 알림을 요청하게 되고 이 푸시 서버가 푸시 알림을 받을 클라이언트에게 푸시 알림을 전송한다. 

 

예를 들어서 당근마켓과 같은 서비스에서 푸시를 어떻게 보내는지 살펴보자.

 

'프라이탁'이라는 키워드로 판매자_후리 가 글을 올렸다고 가정했을 때, 평소 '프라이탁' 제품에 관심이 있던 구매자_소깡이가 이에 대해 키워드 알림을 신청한 상황이라고 하자. 구매자_태끼는 아무런 키워드 알림을 신청한 상태가 아니다. 그리고 후리와 소깡, 태끼는 같은 동네라고 가정하자.

 

1. 먼저 앱을 설치 > 실행하면 해당 app은 푸시 알림을 보내기 위한 device token을 포함한 user의 정보를 서버로 전달한다.
2. 서버에서는 전달 받은 데이터와 + FCM에 해당 기기에 대한 토큰을 저장한다.
3. 당근마켓에서 판매자가 어떤 상품을 판매하기 위해서 글을 작성하는 것과 같이 사용자의 이벤트가 발생되면 이러한 정보가 (판매자에 대한 정보, 작성된 글, 사진 .. ) 서버로 보내진다.
4. 당근마켓 서버는 그 이벤트를 바탕으로 어떤 디바이스에게 푸시 알림을 보낼지 필터링을 해서 (예를 들어서 후리가 #프라이탁 을 태그로 추가해서 글을 작성하게 되면, 소깡, 태끼 두 유저에 대해 소깡 디바이스에 알림을 보내야한다.) FCM에 넘긴다.
5. FCM은 미리 저장해놓은 토큰 중 요청 받은 토큰이 무엇인지 판단하고 APNs를 통해 각각의 기기에 푸시 알림을 보낸다.

 

이 과정 속에서 필요한 것은 

✅ APNs와 FCM에 계정이 등록되어 있어야 하며,

✅ 푸시 알림을 보낼 서버가 있어야 하고,

✅ 앱에서는 device token을 서버로 전달해야 한다는 것이다.

 

 

APNs

Apple Push Notification Service의 약자로 애플의 푸시 알림 서비스를 의미한다.

 

앱의 새로운 데이터가 도착하면 데이터를 모니터링 하면서 해당 앱이 푸시 서비스에 등록된 앱인지 등을 판단하여 대상 장치에 알림을 보내는 서비스이다.

Provider(server)에서 APNs로 알림을 요청하게 되면 APNs에 등록된 토큰을 통해 해당 애플 기기에 푸시 알림 메시지를 전달하는 방식으로 동작한다. 

 

 

Provider 그리고 APNs의 동작 구조 

위에서 설명한 Push Notification의 원리와 비슷하다.

 

 

니카내카 라는 앱이 있고, 니카내카 서버가 있다고 가정해보자. 

여기서 니카내카 서버를 Provider(= Push Server) 라고 할 수 있다.

 

보통 Push Server가 앱에 푸시 알림을 보낸다고 하면, 니카내카 서버에서 바로 니카내카 앱에 푸시 알림을 보내면 되는 것 아닌가? 라고 생각할 수 있지만, 애플에서는 Provider에서 앱으로 직접 알림을 보내는 것을 허용하지 않는다.

여기서 반드시 거쳐야 하는 것이 바로 APNs이다. APNs라는 플랫폼을 통해서만 푸시 알림을 전달할 수 있다.

 

그래서 아래와 같은 구조가 만들어진다.

위의 이미지에서 확인할 수 있는 것처럼 APNs가 가운데에서 중간다리 역할을 하는 것이다.

 

어떻게 Push Server에서 많은 유저 중 내 앱을 찾아서 푸시 알림을 보낼까? 에 대한 답이 곧 원리이다. 

 

#App이 APNs에게 Device Token을 요청한다.

Device Token이란, 푸시가 전송되는 앱의 주소라고 생각하면 된다.

(위의 질문에서 어떻게 내 앱을 찾는가?라고 했는데, 이 Device Token이 내 앱에 대한 주소라고 볼 수 있다.)

 

이 Device Token을 APNs에서 얻을 수 있기 때문에 아래와 같이 (앱에서 사용자가 알림을 허용했다면) APNs에 토큰을 요청한다.

 

#APNs가 App에 Device Token을 알려준다.

 

#App이 Push Server(Provider)에게 Device Token을 보낸다.

 

위 과정을 거쳐야 Push Server로부터 푸시 알림을 받을 수 있다.

(푸시 알림을 받기 위한 필수 동작 방식이다.)

 

 

그리고 아래 과정부터는 실제로 푸시 알림이 울리는 작동 방식이라고 볼 수 있다. 

#Push Server는 푸시를 보내고 싶을 때, APNs에게 Device Token과 데이터를 보낸다.

사용자의 이벤트로 인해, 또는 앱에서 광고를 보내기 위해서 등 ..

Push Server가 앱에 푸시 알림을 보내고 싶다면, 위의 과정에서 받은 앱의 Device Token(앱에서 받은) 정보와 전달하고 싶은 메시지가 담긴 데이터를 APNs에 보내면 된다.

 

 

이 때, APNs와 Provider는 TLS 통신을 하기 때문에 Push Server에 인증서가 준비되어 있어야 한다.

(그래서 이전 글에서 Firebase에 인증키를 업로드한 것을 의미한다.)

 

#APNs는 해당 Device Token으로 데이터를 보낸다.

 

#Device에 푸시 알림이 도착한다.

Background 상태라면 OS에서 처리해서 알림 센터 등에 올라오고,

Foreground 상태라면 AppDelegate에서 정의한 방식대로 App 위에 보여지게 된다.

 

 

Device Token

Device Token이란? 푸시가 전송되는 App의 주소라고 볼 수 있다.

이 토큰은 애플에서 정한 고유한 식별자를 포함한 NSData 형태로 해독을 APNs에서만 할 수 있다.

 

각 앱 인스턴스는 APNs를 등록할 때마다 고유한 Device Token을 수신한다.

 

푸시 알림의 데이터 형식

푸시 서버가 푸시 알림을 보내기 위해서는 APNs에게 토큰과 데이터를 보내야 한다고 했는데, 이 데이터에도 형식이 있다. 

 

✅ JSON 형태여야 하고

✅ payload가 256 byte를 초과하지 않는 작은 크기 

여야 한다.