Web Push? (3) (feat. RFC 8030)

이번 기술 세미나를 준비하면서, 웹푸시 기술에 대해 한문장으로 다음과 같이 정의 해보았습니다.

웹푸시 기술은 웹서버가 실시간으로 실행가능한 알림과 메세지를 사용자 장치의 브라우저 내 웹페이지에서 안전하게 확인할 수 있게하는 기술.

RFC 8030 제목을 보면 알 수 있듯이 'Generic Event Delivery using HTTP Push' 제목 내에도 HTTP 통신을 한다고 이야기하고 있습니다. HTTP통신은 TCP 기반의 통신 프로토콜 중 하나이다. 그래서 HTTP는 L7 과 L4 계층에서 주로 작동한다는 것이기에 웹 푸시 기술은 주로 응용과 전송계층과 관련있다는 것을 알 수 있었습니다.

웹푸시 작동구조
RFC 8030 문서에서는 작동구조를 다음과 같이 정리하고 있었다.
웹푸시를 이해하는 입장에서는 조금 부족한 구조도와 설명이라고 생각하였습니다.
유저와 푸시서비스는 서로 어떻게 모니터링을 하는건지 웹 서버에서 특정 그룹에게만 메세지를 보내려하는데 그 특정그룹을 어떻게 확인할 수 있는 건지와 같은 내용이 미흡 하여,
제가 공부하면서 이해한 바탕으로 구조도를 좀 더 보충하자면 다음 과같은 구조도가 나옵니다.

서비스 워커를 등록할 때는 따로 클라이언트쪽에서 UI적으로 바뀌는게 없기때문에 눈치채기가 어렵다.
등록 후, 구독 여부를 체크하여 구독 허용을 하게되면 푸시서비스로부터 자신의 구독정보를 받아 (이후 이 구독정보를 통해 구독상태를 변경할 수 있는 권한을 얻는다.) 웹 서버에서도 각 사용자의 구독여부를 알 수 있도록 구독정보를 전달 받고나게 되면, 푸시메세지를 보낼 수 있는 권한이 생겨 푸시메세지와 보내려는 유저의 구독정보를 푸시서비스에 전송하고 푸시서비스는 서비스워커에게 전달하면 서비스워커는 사용자의 활성 유무나 사용자가 받을 수 있는 상황인지 판단하여 브라우저에 메세지를 일시저장할지 푸시서비스에 저장할지 정하고 사용자가 받을 수 있는 상황에 메세지를 보내게됩니다.

OSI 7계층에 대입
다음과 같은 플로우에서 RFC문서를 기반으로 크게 나누면 2가지 형식의 HTTP 통신으로 나뉘어지게 됩니다.

HTTP/1.1 과 HTTP/2로 나뉘게되는데 RFC 문서 맨처음에 Abstract을 보게되면 This scheme uses HTTP/2 server push. 다음과같은 한줄을 보게됩니다. 이 스키마는 HTTP/2 서버푸시를 사용하였다.
서버 푸시는 클라이언트에서 먼저 request없이 서버에서 먼저 판단하여 마땅히 받아야할 파일들 (여기에선 메세지가 해당)을 미리 서버에서 먼저 클라이언트로 보내, 더빨리 데이터를 랜더링하여 로딩속도를 줄이는 등의 효율을 나타내는 기능입니다.

HTTP/2는 필수적으로 TLS 인증을 받야만하는것은 아니지만 여러 브라우저에서 HTTP/2를 사용하기위해선 HTTPS 프로토콜을 받아야만한다 라고 정해둬서 받아야만합니다.
TLS/SSL 인증은 표현 계층에 해당할 수 있습니다.

서비스 워커는 브라우저 백그라운드에서 작동하는 자바스크립트 파일인데 프록시 서버와 같은 역할을 할 수 있습니다. 서비스워커의 백그라운드에서 작동하는 것, 푸시알림과 캐싱기능은 응용계층이라 할 수 있고 웹서버와 브라우저 간에 네트워크 관리측면에서는 세션계층이라 할 수 있습니다.

그래서 웹푸시 기능은 4,5,6,7계층에서 작동한다고 이야기할 수 있습니다.

글을 다시 정리해봤는데요, 이 외에도 수정이나 추가할 내용이 있는지 확인해보시고, 궁금한 점이 있다면 언제든지 질문해주세요!