Web Socket vs HTTP Long Polling

 

웹소켓 방식

웹소켓이지!!

 

실시간 통신하면 웹소켓이 가장 먼저 떠오른다.

 

그렇지만 한정된 자원, 특정 상황에서는 대안으로 http long polling기법을 사용할 수 있다.

 

 

회사에서 새로 시작한 프로젝트에서 동시성 이슈가 발생했다. 그래서 그에 대한 해결로 웹소켓에 관한 이야기가 나왔고 적용예정이다. 하지만 이번 동시성 이슈가 발생한 페이지는 일반적인 페이지가 아니고 특정 사용자만 접근이 가능한 페이지이다.

특정 사용자들끼리 동시에 접속하는 경우도 특별한데 데이터 요청도 빈번한 편은 아니다. 그래서 대안으로 생각해 놓은 게 http long polling이다.

 

 

웹소켓을 구축해 놓으면 물론 동시성이슈에 대해 거의 모든 부분을 커버할 수 있지만 초기 개발에 대한 개발자의 리소스가 너무 많이 들어가고 일정이 더 늘어난다.

 

 

따라서 이러한 경우에는 http long polling이 훌륭한 대안이 될 수 있다.

 

HTTP Long Polling이란?

HTTP Long Polling

 

클라이언트가 서버에게 request를 보내고 server는 응답을 보내지 않고 변경사항이 있을 때까지 혹은 타임아웃이 될 때까지 응답을 잠시 멈추는 것이다.

 

변경사항이 생기면 즉시 클라이언트에게 응답을 보내고 클라이언트는 응답을 받자마자 요청을 다시 보낸다 (반복)

 

위 그림에서 보면 request가 발생하고 서버에 도달 후 response를 다시 보내기 전까지는 실시간이 보장된다.

 

하지만 response가 클라이언트에게 도달하기 전, 도달 후, request가 서버에게 도달하기 전.

이 짧은 시간에는 실시간이 보장되지 못해 예기치 못한 버그가 발생할 수도 있다.

 

 

 

사실 이 부분이 가장 문제인데 소켓도 이 문제를 피해 갈 수 없다.

 

Web Socket은 무적 아니었어?

 

만약에 notion과 같은 에디터는 한 사용자가 편집하면 공유하고 있는 다른 사용자에게 보인다.

이 서비스는 물론 소켓으로 실시간을 구현해 놨을 것이다. 하지만 클라이언트의 네트워크는 끊길 수 있다. 소켓 연결이 끊어졌을 때의 상황에 실시간을 보장받지 못할 수 있다.

 

어떤 상황에서 실시간을 보장받지 못할까?

 

 

위에서 말했다시피 네트워크는 끊길 수 있으므로 클라이언트의 네트워크를 신뢰할 수 없다, 즉, DB중심으로 값을 불러와야 한다. 

 

그렇다면 DB가 모든 경우에 실시간성을 반영할 수 있을까?

 

한 글자 한 글자 바뀌는 걸 모두 네트워크 통신을 해서 DB에 저장한다면 서버의 부하가 너무 심해지고 부하를 줄이기 위해 디바운스 적용이 불가피하다.

 

근데 디바운스가 트리거 되기 전 네트워크 연결이 끊기고 클라이언트가 다시 접속하게 된다면 가장 최근의 DB의 값을 불러오는데 디바운스가 트리거 되기 전 값을 불러오게 되므로 실시간을 보장받지 못하게 된다.

 

소켓도 http long polling처럼 실시간을 보장 못 받을 수 도있다. 다만 그럴 확률은 매우 매우 적지만 말이다.

 

하지만 특정상황에서는 http long polling으로 자원을 아끼고 일정을 맞춰 서비스를 출시 후에 소켓으로 마이그레이션 하는 것이 훌륭한 대안이 될 수 있다.

 

 

 

 

 

사이드 프로젝트와 다르게 회사에는 인력이 있고, 일정이 있다.
이러한 고민을 추가로 하면서 개발을 한다는 건 또 다른 재미인 거 같다.
앞으로는 제한된 자원 속에서도 더 현명한 선택을 하기 위해 깊이 있는 고민을 계속해야겠다.