HTTP/2 프로 토 콜 은 iOS 푸 시 알림 서비스(APNS)에 사 용 됩 니 다.

애플 은 최근 이들 의 푸 시 알림 서비스 프로 토 콜 인 APNS 를 업데이트 했다.이 새 버 전의 프로 토 콜 은 HTTP/2 와 JSON 을 기반 으로 기 존의 바 이 너 리 프로 토 콜 에 비해 새로운 프로 토 콜 이 크게 개선 되 었 다.
새로운 APNS 프로 토 콜 은 HTTP/2 를 기반 으로 합 니 다.

새로운 기능:
JSON 기반 요청 및 응답
모든 알림 에 성공 하면 200 표 지 를 되 돌려 줍 니 다.-알림 이 받 아들 여 졌 는 지 추측 할 필요 가 없습니다.
응답 오 류 는 JSON 문자 로 되 돌아 갑 니 다.
메시지 의 길 이 는 2048 바이트 에서 4096 바이트 로 증가 했다.
연결 상 태 는 HTTP/2 ping 프레임 워 크 를 통 해 확인 할 수 있 습 니 다.
지원 테마
일반적인 푸 시 인증서-같은 인증 서 를 개발 하고 생산 하면 됩 니 다.
오래된 APNS 바 이 너 리 프로 토 콜

오래된 바 이 너 리 APNS 프로 토 콜 은 좀 특이 합 니 다.일반적으로 푸 시 배포 서버 는 APNS 게 이 트 웨 이 서버 와 의 socket 연결 을 열 고 이 연결 을 유지 해 야 합 니 다.오래된 프로 토 콜 에서 서버 응답 이 성공 하면 아무런 응답 도 받 지 못 할 것 입 니 다.그러나 서버 응답 이 실패 하면(예 를 들 어 불법 Push token 을 사용 한 경우)서버 는 오류 인 코딩 을 되 돌려 주 고 이 socket 을 닫 습 니 다.가장 중요 한 것 은 이 무효 token 을 사용 한 후에 보 낸 모든 알림 을 다시 보 내야 합 니 다.따라서 서버 에 의 해 성공 적 으로 전송 되 었 는 지 확인 하지 못 할 수도 있 습 니 다.많은 시스템 이 이 구멍 을 사용 하여 고의로 잘못된 token 을 보 내 는데 이런 해 킹 행 위 는 시스템 성능 을 저하 시 킬 것 이다.애플 은'feedback'이라는 서비스 가 있 습 니 다.저 희 는 이 서 비 스 를 정기 적 으로 호출 하여 invalid tokens 의 목록 을 얻 을 수 있 습 니 다.이 서 비 스 는 한 번 만 호출 하면 모든 invalid tokens 목록 을 얻 을 수 있 습 니 다.따라서 만약 에 응용 프로그램 에 많은 푸 시 알림 공급 자가 있다 면 그들 은 자원 을 쟁탈 하여 invalid tokens 목록 을 찾 을 것 입 니 다.invalidtoken 이 많 을 수록 시스템 성능 이 낮 아 지기 때문에 APNS 는 오류 가 발생 하면 이 연결 을 닫 습 니 다.
하지만 여전히 제한 이 있다.TLS 인증 서 를 가 져 오 는 것 이 복잡 하고 저장-퍼 가기 능력 이 약 합 니 다.APNS 는 장치 가 오프라인 상태 일 때 하나의 알림 만 유지 하고 장치 가 출시 된 후에 도 서버 에 정 보 를 업로드 하지 않 습 니 다Google Cloud Messaging이러한 모든 기능 이 있 습 니 다.
GCM 도 이제 iOS 장 비 를 지원 한 다 는 점 을 고려 하면 APNS 와 GCM 은 이제 경쟁 관 계 를 형성 하 게 됐다.APNS 의 2016 년 새로운 기능 을 함께 기대 해 보 겠 습 니 다.