클라이언트와 서버간 실시간 통신을 하는 방법

우리가 인터넷을 사용할때는 주로 http 통신을 이용해 서버에 데이터를 요청 합니다. 그럼 서버는 클라이언트의 요청에 맞춰서 데이터를 다시 돌려주곤 하죠.
이게 일반적으로 서버와 클라이언트가 데이터를 주고받는 과정입니다. 하지만 여기서 중요한 포인트는 클라이언트의 요청이 있기 전까지는 서버는 어떠한 데이터도 줄 수 없다는 사실입니다.

하지만 채팅같은 서비스의 경우엔 다른사람이 입력한 내용을 클라이언트가 요청할때만 받아오는게 아니고 계속해서 실시간으로 받아 볼수 있어야 하는데요. 이러한 서비스를 구현하기 위해 다양한 방법들이 존재합니다.

일반적으로 실시간 통신을 구현하는 방법중에 하나는 단방향 통신을 이용해 실시간으로 데이터를 가져오게 구현하는 방법과, 다른 하나는 양방향 통신을 이용해 서버가 클라이언트로 데이터를 먼저 주는 방식을 사용하는 것입니다.

단방향 통신을 사용하는 방식에는 대표적으로 Polling, Long Polling, SSE가
(Server-Sent Events) 있습니다.

Polling과 Long Polling

출처 : https://hpbn.co/xmlhttprequest/#polling-longpolling

Polling

폴링 방식은 http 통신을 주기적으로 날려서 서버에서 클라이언트로 전달할 메시지를 빠르게 가져오는 형태입니다.
이미지 왼쪽에 표현된 방식이 폴링 인데요. GET /poll을 서버로 계속 날려서 업데이트된 내용이 있는지 주기적으로 체크합니다.

장점

• 구현이 쉽다.(ajax 통신을 주기적으로 요청하는것 만으로도 구현 가능)

단점

• 폴링 주기가 짧으면 서버에 부하가 발생할 수 있다.
• 타이밍에 따라 실시간성이 떨어진다.(이미지 처럼 서버의 응답 이후 서버에 업데이트 내용이 발생하면, 클라이언트의 요청이 있기 전까지 업데이트 내용을 전달하지 못하는 상황이 발생한다.)

Long Polling

롱 폴링은 폴링 방식의 단점을 개선하기 위한 방식인데 클라이언트에서 서버에 요청을 날리면 서버에서 바로 응답이 해주는게 아니고, 업데이트 내용이 생기면 응답을 해주는 방식입니다. 클라에서는 응답을 받으면 다시 서버로 업데이트된 사항을 요청합니다.(업데이트된 내용이 없어서 timeout이 발생했을때도 다시 요청합니다.)

하지만 업데이트가 빈번하게 발생하는 상황이라면 폴링 방식과 크게 다르지 않기 때문에 데이터 업데이트가 자주 발생하지 않는 상황에서 폴링에 비해 유리하다고 할수 있습니다.

지금은 어떻게 처리되는지는 모르겠지만 Facebook 채팅이 Long Polling을 이용해 구현되었다고 합니다. 링크

장점

• 폴링에 비해 좀더 실시간에 가까운 통신을 구현할 수 있다.

단점

• 서버에서 응답할 내용이 있을때 까지 커넥션을 유지해야해서 클라이언트의 수 가 많아질경우 서버의 부하가 발생한다.(polling과 유사)
• 동시에 많은 수의 연결이 요청되고, 반복되면 서버에 갑작스런 부하가 발생할 수 있다.(ex. 100명이 접속해 채팅을 하면 100개의 request가 동시에 서버로 요청 된다.)

SSE

출처 : https://hpbn.co/websocket/#transport-flow

SSE는 Server-Sent Events의 약어로 서버와 한번 커넥션을 맺어두면 서버에서 클라이언트로 지속적으로 데이터를 푸시하는 형태로 동작합니다.

HTML5의 등장과 함께 표준화된 기술입니다. 따라서 IE를 제외한 대부분의 브라우저에서 지원을 하고 있습니다. 지원 범위

주기적으로 클라이언트에게 어떤 알림을 처리해야할때 사용하면 좋을거 같습니다. (ex. 키워드 알림, 댓글 알림)

WebSocket

위에 소개했던 기술과 다르게 WebSocket은 양방향 통신을 가능하게 해주는 기술입니다. 클라에서도 언제든지 서버로 요청을 날릴 수 있고, 서버에서도 언제든지 클라이언트로 응답을 보낼 수 있습니다.

WebSocket은 IE를 포함한 거의 모든 브라우저에서 동작하기 때문에 호환성에 대한 걱정을 하지 않아도 됩니다. 지원 범위

장점

• 양방향 통신을 구현할 수 있다.

단점

• 다른 방식에 비해 커넥션 비용이 많이 든다.

정리

웹 환경에서의 실시간 통신을 구현하는 방식에 대해 간단하게 알아보았습니다. 위 글을 정리하면서 느낀건 ‘어떤 방식이 더 뛰어나다’가 아닌 내가 구현하려는 서비스의 특징과, 서버 상황에 맞는 올바른 기술을 선택하는것이 중요 하다고 생각이 됩니다.

참고

• https://d2.naver.com/helloworld/1052
• https://kuimoani.tistory.com/entry/%EC%9B%B9%EC%B1%84%ED%8C%85-%EA%B5%AC%ED%98%84%EC%8B%9C-Long-Polling-%EB%B0%A9%EC%8B%9D%EA%B3%BC-Polling%EB%B0%A9%EC%8B%9D-%EC%84%A0%ED%83%9D%ED%95%98%EA%B8%B0
• https://adrenal.tistory.com/20
• https://medium.com/@icehongssii/%EA%B9%9C%EC%B0%8D%ED%95%9C-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%A8%B8%EB%93%A4%EC%9D%84-%EC%9C%84%ED%95%9C-%EA%B0%84%EB%8B%A8%ED%95%9C-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%EC%83%81%EC%8B%9D-2-2-http%EB%A5%BC-%EB%84%98%EC%96%B4%EC%84%9C-%EC%8B%A4%EC%8B%9C%EA%B0%84-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%82%B9websocket-c49125e1b5a0
• https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
• https://spoqa.github.io/2014/01/20/sse.html
• https://boxfoxs.tistory.com/403
• https://hpbn.co/
• https://velog.io/@nomorebuild/SSEServer-Sent-Events-%ED%9B%91%EC%96%B4%EB%B3%B4%EA%B8%B0
• http://clearpal7.blogspot.com/2016/06/vs.html
• https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=youreme&logNo=110162110369
• https://velog.io/@hustle-dev/JavaScript-Long-Polling
• https://www.baeldung.com/spring-server-sent-events
• https://boxfoxs.tistory.com/403
• https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events
• https://javacan.tistory.com/entry/spring-webflux-server-sent-event-1