[Web]서버에서 클라이언트의 화면을 제어해보자 (1)

HW·2023년 5월 22일
0

서론

웹 기반 가족 레크레이션 게임을 개발하면서,
기기와 그래픽 인터페이스 동작이 서툰 어르신들을 위해 사회자가 게임의 진행상황을 제어하며 어르신의 인터페이스를 동작 해야하는 요구사항을 만족시키려고 합니다.

유즈 케이스를 살펴봅니다.

  1. 한 게임에는 단계가 있으며 이를 사회자가 제어합니다.
  2. 사회자가 게임의 다음 단계로 진행시킵니다.
  3. 사회자가 서버에 다음 단계 시작하도록 요청합니다.
  4. 각 단계가 시작할 때 마다 클라이언트에서는 새로운 뷰 컴포넌트를 보여야합니다.
  5. 클라이언트는 항상 인터페이스를 제어하지 않아도 자동으로 새로운 단계의 뷰를 보여줍니다.

사회자가 서버에게 "다음 단계로 이동해줘"라고 했을 뿐인데 서버가 다른 게임 참가자에게 이를 알려줄 수 있는 방법을 찾아 봅니다.

본론

HTTP 프로토콜

가장 흔한 HTTP 프로토콜의 형식은 비연결성입니다.
한번 연결을 맺은 후, 클라이언트 요청에 대한 서버가 응답을 마치면 맺었던 연결을 끊어버리며, 매번 새로운 연결을 시도 / 해제의 과정을 거쳐야 합니다.
연결 / 해제에 대한 오버헤드가 발생합니다.

폴링 (Polling)

클라이언트가 서버에게 일정한 주기를 가지고 지속적으로 요청후 응답을 받습니다.
클라이언트가 계속 요청을 보내서 서버의 부담이 늘어납니다.
그리고 연결을 맺고 끊는 것에 대한 비용 부담이 커지면서 실시간으로 동작한다고 보기 어렵습니다. 주기적으로 보내기 때문에 바로 응답을 받을 수 있다는 보장이 없기 때문입니다.

긴 폴링 (Long Polling)

클라이언트가 요청을 보냈을 때, 이벤트 발생할 때 까지 가지고 있다가 이벤트 발생 후 응답을 보냅니다.
주기적으로 요청을 하는 것이 아니라 유지 시간을 길게 가지는 겁니다.
연결을 계속 열어두고 요청이 올 때 해당 요청을 처리합니다.
서버에서 응답할 내용이 있을 때까지 연결을 유지해야해서 클라이언트의 수가 많아질 경우 서버에 부하가 발생합니다.
불필요한 헤더와 높은 트래픽을 초래합니다.

스트리밍 (Streaming)

클라이언트의 요청에 대한 응답하며 연결을 끊는 것이 아니라,
연결을 유지한채로 다음 요청을 계속 받아옵니다.
서버는 일정 시간동안 요청을 대기시키고, Chunked 메시지를 이용해 응답 시 연결을 계속 유지합니다.


웹 소켓 (WebSocket)

HTTP을 사용하면 요청 / 응답 헤더가 불필요하게 큽니다.
이러한 단점을 해소하기 위한 웹 소켓입니다.
TCP 연결을 위한 연결 지향형 통신 프로토콜이며 클라이언트에서 서버로의 영구 양방향 통신 입니다.
웹 소켓을 이용하면 최초 접속시에만 헤더 정보를 보내고 더 이상 보내지 않으므로 이를 처리해줄 수 있습니다.
서버와 클라이언트, 둘 중 하나가 세션을 닫을 때까지 언제든지 메시지를 보낼 수 있습니다.

대용량 트래픽에서는 서버가 클라이언트 수만큼의 연결을 유지해야 한다는 부담이 있습니다.

SSE (Server-Sent-Events)

HTTP 프로토콜만으로 가볍게 클라이언트가 서버로부터 데이터를 받도록 합니다.

SPirng Framework는 4.2부터 SseEmitter 클래스를 제공하여
서버 사이드에서의 SSE 통신 구현이 용이합니다.

Javascript에서는 EventSource를 이용하여 연결 생성 및 전송된 이벤트에 대한 제어가 가능합니다.

결론

현재 게임의 단계 정보인 int자료형을 처리하면 되므로, 웹소켓보다 가벼운 SSE을 사용하여 구현해보도록 합니다.

profile
예술융합형 개발자🎥

0개의 댓글