Android,iOS,Windows Phone 의 푸 시 기술 에 대한 상세 한 설명

푸 시 는 신기 술 이 아니 라 인터넷 시대 에 이미 유행 했다.다만 모 바 일 인터넷 시대 로 접어 들 면서 푸 시 기술 이 더욱 중요 해 졌 다.스마트 폰 에서 푸 시 는 어느 정도 수년간 사용 해 온 문자 메 시 지 를 대체 할 수 있 고 문자 메시지 에 비해 사용자 에 게 더 많은 정보(예 를 들 어 이미지,표,소리 등)를 보 여줄 수 있 기 때문이다.
푸 시 기술 의 실현 은 보통 서버 에서 클 라 이언 트 에 게 메 시 지 를 푸 시 하 는 방식 을 사용한다.즉,클 라 이언 트 가 사용자 이름,Key 등 ID 를 통 해 서버 에 등록 하면 서버 에서 모든 활동 하 는 클 라 이언 트 에 메 시 지 를 보 낼 수 있다.
실제로 많은 모 바 일 운영 체제 에서 공식 적 으로 푸 시 방안 을 제공 했다.예 를 들 어 구 글 의 클 라 우 드 푸 시,IOS,윈도 폰 7/8 도 비슷 한 푸 시 방안 을 제공 했다.그러나 이러한 푸 시 방안 의 서버 는 모두 외국 에 있 고 일부 푸 시 서비스(예 를 들 어 구 글 의 클 라 우 드 푸 시)는 국내 에서 어떤 이유 로 불안정 하기 때문에 국내 에서 최근 몇 년 동안 국민 을 위 한 푸 시 서비스 가 많이 생 겨 났 다.
본 고 는 각종 유행 모 바 일 운영 체제 에 착안 하여 푸 시 기술 의 각종 실현 방식 을 소개 할 것 이다.물론 우리 의 주요 목적 은 안 드 로 이 드 의 푸 시 기술 을 토론 하 는 것 이다.
1.iOS 의 푸 시 기술
애플 은 IOS 에 완벽 한 푸 시 방안 을 제공 했다.기본 원 리 는 애플 이 APNS(Apple Push Notification Service,애플 푸 시 알림 서버)라 는 자신의 푸 시 서버 를 제공 하 는 것 이다.반면 클 라 이언 트 장치(IPhone,IPad 등)는 APNS 와 직접 긴 연결 을 맺 는 다.그러나 클 라 이언 트 장치 에 보 내 는 메 시 지 는 APNS 에서 발생 하 는 것 이 아니 라 메 시 지 를 보 내야 하 는 사용자 가 직접 제공 하 는 서버(Provider 라 고 함)에서 발생 한 것 이다.그리고 Provider 는 메 시 지 를 APNS 에 전송 하고 마지막 으로 APNS 에서 클 라 이언 트 장치 에 메 시 지 를 전송 한다.즉,메 시 지 는 처음에 Provider 에서 생 성 된 다음 Provider 가 메 시 지 를 APNS 에 전송 하고 마지막 에 APNS 에서 클 라 이언 트 장치 에 전송 하 는 것 이다.소식 전달 과정 은 그림 1 과 같다.

클 라 이언 트 장치 에 메 시 지 를 보 내 고 메 시 지 를 받 는 과정 에서 이 토 큰 의 전송(device token)을 수반 합 니 다.APNS 를 사용 하여 메시지 서 비 스 를 제공 하려 면 응용 프로그램 이 먼저 IOS 에 등록 하고 제공 해 야 할 필요 한 정 보 는 현재 장치 와 관련 된 device token 입 니 다.IOS 는 devicetoken 을 받 은 후에 APNS 에 이 device token 이 APNS 에 등록 되 었 는 지 확인 합 니 다(모든 IOS 장 치 는 처음 사용 할 때 애플 서버 에 계 정 을 등록 해 야 합 니 다.그렇지 않 으 면 애플 스토어 에서 애플 리 케 이 션 을 다운로드 할 수 없습니다.물론 푸 시 서 비 스 를 사용 할 수 없습니다.)이미 등록 되 어 있 으 면 APNS 는 애플 리 케 이 션 에 이 devicetoken 을 직접 되 돌려 줍 니 다.응용 프로그램 이 이 devicetoken 을 받 은 후에 APNS 가 자신 에 게 메 시 지 를 보 낼 수 있 도록 허용 되 었 음 을 나타 내 고 이 device token 을 푸 시 서버(Provider)에 보 내야 합 니 다.이 프로그램 은 APNS 에 자신 을 등록 하 는 데 성공 했다.이제 Provider 를 통 해 푸 시 할 메 시 지 를 만 들 수 있 습 니 다.그리고 Provider 는 APNS 서버 에 메 시 지 를 보 내 고 마지막 으로 APNS 서버 는 응용 프로그램 에 메 시 지 를 직접 보 냅 니 다.이 과정 은 비교적 복잡 하지만 그림 2 의 묘 사 를 보면 이 과정 에 대해 더욱 잘 알 수 있 을 것 이다.모든 프로 세 스 는 앞의 숫자 가 보 내 는 시간의 선후 순 서 를 나타 낸다.

2.윈도 폰 의 푸 시 기술
마이크로소프트 가 윈도 폰 에 제공 하 는 푸 시 방안 은 IOS 와 유사 하 며,스스로 푸 시 서버(Cloud Service 라 고 할 수 있 음)를 준비 해 야 한다.장치 ID 가 우리 로 바 뀌 었 다 는 뜻 일 뿐이다.Window Phone 에 Push Client Service(PCS)가 있 습 니 다.푸 시 서비스 가 필요 한 모든 프로그램 은 Push Client Service 와 통신 해 야 합 니 다.다음은 윈도 폰 푸 시 기본 절차 로 독자 들 은 그림 3 과 대조 해 이 과정 을 볼 수 있다.
1 단계:응용 프로그램 이 Push Client Service 에 Push Notification URI(①)를 요청 합 니 다.
2 단계:현재 Window Phone 장치 가 마이크로소프트 서버 에 등록 되 어 있 으 면 Push Client Service 는 MPNS(Microsoft Push Notification Service,마이크로소프트 푸 시 알림 서비스)에서 Push Notification URI 를 가 져 와 응용 프로그램 에 되 돌려 주 며 푸 시 서비스 가 사용 가능 하 다 는 뜻(② 와 ③)을 표시 합 니 다.
3 단계:응용 프로그램 은 Push Notification URI 를 자신의 푸 시 서버(Cloud Service)(④)에 보 내야 합 니 다.
4 단계:메 시 지 를 전송 할 필요 가 있 으 면 클 라 우 드 서 비 스 는 메 시 지 를 MPNS 에 보 내 고 MPNS 는 Push Client Service 에 메 시 지 를 보 내 며 마지막 으로 Push Client Service 에서 응용 프로그램(⑤,⑥,③)에 메 시 지 를 전송 합 니 다.

3.안 드 로 이 드 의 푸 시 방안
안 드 로 이 드 의 푸 시 방안 은 비교적 많 고 복잡 하 다.예 를 들 어 Google 이 공식 적 으로 제공 하 는 C2DM(Android Cloud to Device Messaging)이 있 습 니 다.제3자 의 푸 시 서비스(예 를 들 어 극광 푸 시);그리고 각종 프로 토 콜 을 통 해 이 루어 진 푸 시 서버 프로그램(예 를 들 어 AndroidPN)도 있 습 니 다.사용 자 는 이 서버 프로그램 을 통 해 자신의 푸 시 서버 를 구축 할 수 있 습 니 다.이러한 푸 시 기술 은 이 절 뒤의 부분 에서 상세 하 게 소개 할 것 이 며,이 절 은 먼저 안 드 로 이 드 에서 자주 사용 하 는 각종 푸 시 기술 을 소개 한다.물론 이런 푸 시 기술 은 다른 모 바 일 기기 에 도 사용 할 수 있 지만 안 드 로 이 드 의 공식 푸 시 서비스(C2DM)가 국내 에서 사용 하 는 데 문제 가 있 기 때문에 안 드 로 이 드 를 바탕 으로 하 는 제3자 푸 시 서 비 스 는 다른 시스템 보다 많 기 때문에 주로 안 드 로 이 드 를 대상 으로 소개 한다.
일반적으로 푸 시 기술 은 다음 과 같은 두 가지 방식 으로 이 루어 진다.
1.폴 링(Pull)방식
2.지속 적 인 연결 방식(서버 Push 방식)
폴 링 방식 은 클 라 이언 트 가 일정한 시간 간격 으로 서버 에 새로운 소식 이 있 는 지 계속 조회 하 는 것 이다.이런 방식 은 반드시 서버 와 의 통신 메커니즘,예 를 들 어 메시지 대기 열 등 을 스스로 실현 해 야 한다.또한 폴 링 의 빈 도 를 고려 해 야 한다.너무 느 리 면 일부 메시지 의 지연 을 초래 할 수 있 고 너무 빠 르 면 네트워크 대역 폭 과 배 터 리 를 대량으로 소모 할 수 있다.그래서 대부분의 푸 시 서 비 스 는 폴 링 방식 을 사용 하지 않 는 다.
지속 적 인 연결 방식 은 바로 Push 방식 입 니 다.클 라 이언 트 에 게 수 동적 인 방식 입 니 다.주동 권 은 서버 에 있 습 니 다.메시지 가 있 을 때 서버 는 푸 시 서버 에 등 록 된 모든 클 라 이언 트 에 게 메 시 지 를 보 냅 니 다.이런 푸 시 방식 의 장점 은 실시 성 을 확보 할 수 있 고 클 라 이언 트 가 간단 하 다 는 것 이다.물론 부족 할 수도 있다.예 를 들 어 대량의 클 라 이언 트 가 서버 와 긴 연결 을 유지 하면 서버 의 자원 을 소모 할 수 있다.그러나 메 시 지 를 푸 시 하지 않 았 을 때 이 긴 연결 은 빈 연결 이 되 었 고 보통 이런 연결 은 메모리 자원 을 소모 합 니 다.예 를 들 어 200 만 명의 사용자 가 수 십 GB 의 메모 리 를 소모 할 수 있다.따라서 이런 푸 시 메커니즘 을 구축 할 때 성능 이 좋 은 서버 를 사용 해 야 한다.
지속 적 인 연결 의 실현 에는 여러 가지 방식 이 있 는데,예 를 들 어 XMPP 를 통신 프로 토 콜 로 사용 할 수 있다.XMPP 의 주요 장점 은 협의 가 성숙 하고 강력 하 며 확장 성 이 강하 다 는 것 이다.XMPP 는 IM 시스템 에 더 많이 사용 되 고,뒤에 소개 할 Android PN 도 XMPP 프로 토 콜 을 사용 했다.
XMPP 도 뚜렷 한 단점 이 있다.예 를 들 어 협의 가 복잡 하 다.만약 에 XMPP 협 의 를 철저히 이해 하 는 데 시간 이 오래 걸 릴 수 있다.그리고 XMPP 는 XML 을 바탕 으로 하기 때문에 데이터 가 불필요 하고 모 바 일 기기 의 유량,전기 소모 등 단점 을 초래 할 수 있다.
XMPP 를 제외 하고 MQTT 프로 토 콜 도 사용 할 수 있 습 니 다.이런 프로 토 콜 의 주요 장점 은 간결 하고 작고 확장 성 이 강해 서 데이터 절약,전기 절약 등 장점 을 가 져 왔 고 C++버 전의 서버 구성 요소 rsmb 도 있 습 니 다.단점 은 협의 가 성숙 하지 않 고 실현 이 복잡 하 며 rsmb 가 오픈 되 지 않 아 하드웨어 를 배치 하 는 비용 이 비교적 높다 는 것 이다.
C2DM 서 비 스 는 국내 에서 불안정 하거나 일부 지역 에서 사용 할 수 없 을 수 있 지만 C2DM 의 원 리 를 소개 할 필요 가 있다.그러나 국내 에서 사용 하 는 응용 에 대해 서 는 제3자 의 푸 시 서 비 스 를 사용 하거나 스스로 푸 시 서버 를 가설 하 는 것 이 좋다.
C2DM 과 IOS 의 APNS,Window Phone 의 MPNS 는 대동소이 하 다.푸 시 서버 를 스스로 준비 하고 다음 절 차 를 통 해 메시지 푸 시 를 실현 해 야 한다.
첫 번 째 단계:모 바 일 기기 의 C2DM 서 비 스 는 Google 공식 C2DM 서버 와 상호작용 을 하여 현재 기기 가 C2DM 서버 에 등록 되 어 있 는 지 확인 해 야 합 니 다.이미 등록 되 어 있 으 면 C2DM 서버 는 클 라 이언 트 에 등 록 된 ID 의 C2DM 서 비 스 를 되 돌려 줍 니 다.(① 과 ②)
STEP 2:클 라 이언 트 의 C2DM 서 비 스 는 자신의 푸 시 서버 와 상호작용 을 하여 계 정과 C2DM 서버 가 돌아 온 등록 ID 를 푸 시 서버 에 전송 합 니 다.(③）
STEP 3:메 시 지 를 푸 시 하려 면 푸 시 서버 는 등 록 된 ID 와 푸 시 할 메 시 지 를 C2DM 서버 에 먼저 보 낸 다음 C2DM 서버 는 클 라 이언 트(핸드폰,태 블 릿 PC 장치)(④ 와 ⑤)에 직접 메 시 지 를 보 냅 니 다.
독 자 는 그림 4 를 대조 하여 이 세 단 계 를 이해 할 수 있다.

공식 푸 시 방안 을 사용 하 는 것 외 에 현재 국내 에는 극광 푸 시(JPush),바 이 두 푸 시 등 여러 제3자 푸 시 방안 이 쏟 아 져 나 오고 있다.독자 들 도 사용 할 수 있다.이런 것들 은 보통 무료 이다.