[치지직] 웹 사이트 구조 분석(채팅)

 

 

요즘 웹소켓에 대해서 지식을 얻는 와중 다른 실시간 통신을 요구하는 기술을 가진 웹사이트의 구조가 궁금해서 살펴 보았다. 그 중에서는 신규  스트리밍 사이트 치지직을 확인해 보기로 했다.

 

최초 스트리머의 방을 입장하면 우직에 보이는 채팅창이 있다. 접속 시 최초 채팅 50개가 표시 된다.

 

최초 접속시 웹소켓 서버와 세션 연결을 수행하며 서비스는 NGINX 하단에 서버가 위치한 것으로 보인다.

 

세션이 연결되면 https 프로토콜로 주고 받는 것이 아닌 wss로 업그레이드 되어 서버와 양방향 통신을 하게 된다. 최초 접속시 50개의 데이터를 가져오는 응답 값(길이확인) 그리고 채팅 하나 씩 데이터를 받는 모습이다.

 

실제 데이터는 class live_chatting_list_wrapper 부분에서 갱신된다. 치지직의 웹프레임워크는 vue.js로 각 class간 중첩을 통하여 관리하는 컴포넌트 구조를 가지고 있기에 class명이 충돌되지 않도록 빌드 및 실행 과정에서 랜덤 접미사가 붙어 있는 모습이다.

 

웹소켓을 수행하는 스크립트는 소스 쪽에 있을 것이며 그 중 흥미로운 것을 발견 했다. NGINX 아래 도메인 별로 리버스 프록싱으로 로드벨런싱 대상 서버가 라이브에서는 최소 4개이상 있으며 개발서버 스테이지서버 라이브서버 체제로 서비스를 테스트 하는 것으로 추정된다.

kr-ss1 요청 시 NGINX가  kr-ss2, kr-ss3, kr-ss4 등으로 로드벨런싱 예상

 

보안 관점으로는 클라이언트에서 접근 시 웹소켓 서버에서 CORS로 허용된 도메인의 요청만을 받아 처리해야할 것이다.

> 영향도 : 사설 서버에서 개설된 웹서비스가 치지직 서버자원을 사용하는 것을 방지할 수 있다.(ex. 각종 스트리밍 사이트 모음 서비스 / 채팅 모아보기 서비스)

> 한계점 : 직접 웹사이트 요청을 모방하여 직접 웹소켓 서버에 접속하는 경우 채팅 데이터를 획득할 수 있다.

 

해당 데이터의 흐름이 서비스 운영시 유의적인지 판단하여 실무부서에서 판단하여 결정(유지/변경)이 필요하다고 생각한다. 보안은 위험을 줄이기 위하여 보수적으로 접근하기 때문이다.

개인적인 생각으로는 웹소켓 서버 세션이 하나 열리는 것으로 보아 실무상으로는 서버 등 영향력은 낮아보이나 부정접근자의 접근을 막기위한 대안을 제시할 것 같다. 보안장비 로그 모니터링 강화 등. 인프라는 서버 모니터링 시스템을 웹소켓 서버에서 설정하여 과도 트래픽을 식별하여 웹소켓 부정접근 확인 시 유관부서(정보보안팀 등) 요청을 보내서 처리하면 좋을 것 같다.

웹은 언제나 흥미 진진하다. 눈에 보이는 것은 직접 알아볼 수 있기 때문이다.

끝.