HTTP와 Web Socket에 대해서 생각해보자

HTTP는 클라이언트의 request에 서버가 response하는 형태

• 네트워크 흐름이 고정되어 있다.

  • client ⇒ server ⇒ client

• 하나의 요청에 하나의 응답만 가능하다.

• 클라이언트의 요청이 있어야 서버가 응답이 가능하다.

• 클라이언트의 요청이 없다면 서버 입장에서 클라이언트가 뭘 하는지 알 수 없다.

  해당 페이지와 연결된 서버가 있다 해도 유저가 나갔다면 서버는 알 수 있을까?
  -> 브라우저 닫기 버튼을 눌러서 나간 경우 unload 이벤트로 추적
  -> 뒤로 가기 버튼을 눌러서 나간 경우 componentWillUnmount 이벤트로 추적
  
  정전이 나면? 물을 끼얹으면? 브라우저가 멈춰서 강제 종료한 경우에는?
  -> 주기적으로 api 콜을 보내 해당 페이지에 있다고 알려줘야할까?
  
  해당 페이지에서 유저가 요청을 보내지 않는 행위만 하고 있다면 유저가 해당 페이지에 있다는 사실을 서버는 알 수 있을까?
  -> 해당 페이지를 보고있는 모든 유저에게 push를 하고 싶은데, 어떻게 해당 페이지를 보고 있는 유저를 추적할 수 있을까? 
  

클라이언트와 서버 사이의 연결 상태를 Web Socket을 사용하면 쉽게 알 수 있다.

• 유저가 뒤로가기, 강제종료, 브라우저 종료를 하면 웹소켓 연결이 끊어져서 유저가 뭘 하는지 알 수 있다.
• 여기서 드는 의문은 네트워크가 끊긴다면 웹소켓은 어떻게 판단할까?

  • 개발자 도구의 네트워크 창에서 네트워크를 offline으로 설정 했다가 다시 연결하기 통신이 연결됨.

    화면 기록 2023-11-14 오후 11.59.43.mov

연결 상태까지 알 수 있는 Web Socket을 모든 통신에 사용하면 안 될까?

• 웹 소켓의 경우 서버와 handshake 이후에 서브 프로토콜을 사용해 계속 연결 상태를 유지하기 때문에 베터리 사용량이 크다.
• HTTP 요청보다 구현이 복잡하다.
• 보내는 데이터는 적지만, 주기가 잦아 보내는 데이터의 총량은 많을 수도 있다.

우리는 어떤 통신을 선택할 것인가?

• Algo With Me 프로젝트의 경우에 주기적으로 서버와 연결된 상태임을 확인해야 하는 페이지가 존재한다.
• HTTP healthcheck로 발생하는 네트워크 비용 증가와 웹 소켓을 이용했을 때의 네트워크 비용 증가에 대해서 비교해 보고 선택하고 싶지만, 측정하기 어렵다고 판단되어 리얼타임이 필요한 곳에서 주로 사용되는 웹 소켓을 사용하기로 결정했다.
  • 멘토링 과정에서도 Web Socket을 사용하는 것에 문제가 있다는 조언은 받지않음.
  • 추후에 검증이 필요하다.
  • 네이버 부스트캠프의 프로젝트(6주)가 끝나고 검증해보자!