[카카오프로젝트] 실시간 통신의 역사

paduck·2023년 3월 19일
0

프로젝트

목록 보기
3/11

프로젝트의 핵심 기능 중 하나로 WebRTC 가 결정되었다.
일전에 학교 다니면서 실시간 서비스에 관심이 있어 node 기반의 Socket.io를 활용해 진행했었는데, 프로젝트에서 요구되는 스택이 Spring boot이다 보니 해당 언어를 사용해 어떤 방식으로 구현할 수 있을지 걱정이 많았다.

웃프게도 결론은 WebRTC 라이브러리를 사용하기로 했지만, 그 과정까지 학습했던 내용을 공유해보고자 포스팅을 작성한다.

WebSocket, RTC 의 역사

웹 기술 역사에서 실시간 소통의 중요성이 증가하게 되면서, 이를 뒷받침해줄 수 있는 기술이 계속해서 발전해 왔습니다.

위의 사진에서 알 수 있듯이 초기에는 클라이언트와 서버가 연결되어 있지 않은 형태였습니다. 클라이언트는 최신의 데이터를 위해 주기적으로 서버에 데이터를 요청했는데, 이는 서버에 많은 트래픽을 발생시키고 지연시간도 늘어나는 단점이 있었습니다.

여기에서 발전한 방식이 Long Polling 방식으로 단순하게 요청 시간의 대기시간을 길게 늘여트려 놓은 형태입니다. 그 안에 업데이트가 이루어져 응답이 발생하면, 서버는 즉시 클라이언트로 데이터를 전송하고 클라이언트는 이걸 처리한 이후에 다시 요청을 보냅니다. 간단하게나마 생각할 수 있듯이 그렇게 큰 이점이 있지는 않았습니다.

이후에 등장한 방식이 SSE인데, 여기에서 조금 색다른 개념이 등장합니다. 우리가 신문이나 유튜브 채널을 구독하는 것처럼 클라이언트는 특정 이벤트 스트림에 연결합니다. 해당 이벤트가 발생할 경우 서버에서 클라이언트로의 전송만이 이루어집니다. 실시간 소통과 같은 양방향 시스템이 아닌, 서버에서 클라이언트로만 전송이 이루어지는 단방향 방식입니다. 그럼에도 불구하고, 이전에 방식들보다 서버의 부하를 많이 줄일 수 있었습니다.


이제 이후에 등장한 방식이 WebSocket입니다. 여기서부터 우리가 익히 알고 있는 실시간 통신이 이루어지게 됩니다.

WebSocket 과 이후에 발전한 WebRTC 모두 HandShake 라는 과정을 거치고 통신이 시작됩니다.
WebSocket은 연결이 이루어지기 전에 http 프로토콜로 먼저 연결이 되고, 이후에 ws 프로토콜로 업그레이드가 됩니다. 이 응답에 관한 내용을 서버로부터 전달받아 최종적으로 양방향 통신이 연결되는데 이게 websocket 의 handshake 과정입니다.
WebRTC의 최종 목표는 Peer-to-Peer 연결을 수립하는 것입니다. 이를 위해 SDP 라는 메타 데이터와 ICE 라는 네트워크 정보를 교환하게 되는데 이 과정이 WebRTC 의 핸드쉐이크 입니다.

(화질이 깨져서 죄송합니다...)

참고

If카카오에서 에디 님의 발표를 보고 많은 도움이 되었습니다.
Velog 도 운영하고 계시니 많이 방문하셔서 얻어가셨으면 좋겠습니다.

profile
끈질기게 들러붙기

0개의 댓글