Blog

[개인프로젝트] 코멧, 웹소켓

요즘 업무 외적으로 회사분들과 프로젝트를 진행중이다. 현재까지 진행하면서(진행된건 없음) 느낀점과 배운점을 정리하고 앞으로도 업데이트할 생각이다.

우선 만들려고하는 것은 어떠한 파일을 관리하는 웹서비스이다. GUI환경에서 해당파일을 편집할 수 있도록 하자는 건데 로그인구현, 카테고리 추가/삭제, 그룹 추가/삭제, 접속자 목록, 시각 피드백등 여러 feature list가 정리되었다. 접속자들에게 시각적 피드백을 실시간으로 주기위해서 그리고 편집대상 파일의 최신본을 유지하기위해서 기존의 폴링방식이 아닌 서버 푸쉬가 필요하게 되었다. 폴링이 뭔지 푸쉬가먼지 개념이 없었어 프로젝트를 위해 약간의 학습을 하였다.

우선 푸쉬 서버 기능을 구현하기위해서 많이쓰이는 방법중 하나로 코멧이 있는데 코멧을 구현하기위해서는 롱폴링과 HTTP스트리밍 두가지 방법이있다. 그전에 폴링에 대해 정리하자면 (숏)폴링은 클라이언트 요청 -> 서버 즉시 응답(내려줄 데이터의 유무에 상관없이 응답 후 커넥션 종료)하는 일반적인 방식을 말하는 것 같다. 롱폴링과 HTTP스트리밍은 아래와 같은 개념으로 정리할 수 있을 것 같다.

  • 롱폴링 – 클라이언트 요청 -> 서버 응답(내려줄 데이터가 있을 때 까지 서버측에서 응답대기, 응답 후 커넥션 종료 -> 즉시 클라이언트 요청으로 커넥션 연결)
  • HTTP 스트리밍 – 하나의 HTTP 커넥션을 열어놓고 계속해서 해당자원 사용

HTTP스트리밍은 아직 잘 모르겠고 롱폴링 구현을 위해서는 ajax call을 구현 응답 후 즉시 새로운 요청을 보내면 될 것같다. 일정 시간동안 서버측 응답이 없고 클라이언트에서도 요청이 없으면 커넥션을 종료하면 될듯 싶다.  그리고 내려받은 데이터로 UI를 조작하도록 작업하면 될 것같다. 서버측에서 어떠한 기준?으로 응답시간을 딜레이할지 정하고 구현을 어떻게할지 정의해봐야할 것 같다.

그리고 코멧이 아닌 푸쉬 구현의 다른 예를 찾다가 웹소켓이라는 것을 찾아보게 되었는데 아직 잘은 모르겠지만 계속해서 네트워크를 주고받아야하는 (롱)폴링보다는 서버에 덜 부담이 되지 않을까 싶다. 굳이 따지면 HTTP스트리밍과 유사한 개념같은데 차이점은 브라우저당 제한된 HTTP자원을 사용하지 않는다는점( ws: wss: 프로토콜을 사용한다. ) 정도일 것 같다. 차이점에 대해 잘 아시는분이 계시면 아래 댓글로 정리해주시면 좋을 것 같네요.

웹소켓은 HTML5 API로 사용은 매우 간단하다.

  • 해당 브라우저가 웹소켓을 지원하는지 확인후 웹소켓 인스턴스를 생성
  • API 제공되는 4가지 이벤트( onopen, onmessage, onclose, onerror)로 적절히 클라이언트측 스크립트 구현
  • 적당한 서버측 웹소켓언어(php, ruby, python, java, c/++, javascript(nodejs)) 선택하여 구현( 이부분은 정확히 어떤건지 모르겠다. )

웹소켓은 양방향 통신으로 문자열(json), 바이너리데이터, 원시데이터를 모두 받을 수 있다. 각 데이터 타입에 따라 클라이언트 측에서 처리해줘야하는 부분이 존재하긴 하지만 꽤 좋은 듯 싶다. 사실 서버측 구현만 된다면 웹소켓을 사용해 보고싶기도 한데 이부분은 구현된 푸쉬서버 예제를 찾아보고 상의해서 정해야할 듯 싶다.

 

동기/비동기 문의

  • 서버푸쉬를 구현하려고하는데 서버푸쉬같은게 비동기인건가요? 말씀하신대로 동기면 (숏/롱)폴링, HTTP스트리밍, 비동기면 웹소켓 같은게 맞는걸까요?
  • 네 맞습니다. 서버푸쉬 같은 경우에는 비동기/동기 두 방식 모두로 구현할수 있을것 같아요. 그런데 요즘 서버푸쉬 같은 경우에는 구현을 하려고 할때 보통 동기방식으로 구현을 하는것 같더라구요. 요즘 같이 통신속도가 빠른세상에 동기/비동기에 차이가 그리 크게 나지 않고 웹서버 같은 경우에는 동기 방식으로 서버를 구현해야 더 편리한 이점이 있기 때문인것 같아요. 폴링/푸시 방식에서도 따지자면 폴링이 동기 방식인데 요즘 iot 관련해서 홈네트워크를 구현할때는 그냥 푸쉬로 여러번 때려버리는게 양쪽 모두 시스템 구현할 필요없는 구현의 편리함이 좋고 경제적단점이라던가의 차이가 폴링방식에 비해 떨어지지 않기 때문에 푸쉬방식으로 구현하는것 같더라구요. 뭐 제 생각에는 결국 속도는 어느정도 평준화 되었으니 적당히 무시하고 유지보수와 구현의 편리성 여부를 따져 푸쉬방식으로 갈거냐 폴링으로 갈거냐 하는것 같습니다.
  • 작과 끝의 순서가 순차적으로 발생하는 것을 동기라고 부르고 순서가 바뀔 수도 있는 경우를 비동기라고 합니다. 데이터 통신/네트워크 시간에 배웁니다. 서버푸시의 경우는 데이터 통신의 동기/비동기와는 관련이 없습니다. (부연: 위에도 언급되었듯이 푸시는 데이터의 전달방식이지 통신방식은 아닙니다. 푸시자체는 데이터의 시작과 끝이 일방적이므로 동기/비동기를 나눌 수 있지 않습니다.)