[실시간 통신 / 채팅 기능] Web Socket 과 Socket.io
저희 채팅 기능이 필요해요!
회사에서 미션이 주어졌다.
평소에는 서비스와 관련하여 기능 개발을 하고, 외부 api를 붙이는 작업을 진행했지만, 이번에는 큰 기능이 들어왔다.
채....팅...
언젠가 하게될 거라고 생각했다.
스타트업 특성상 속도가 중요하기 때문에, 처음에는 서비스를 제공하는 외부 업체를 찾아봤다.
그런데 제공하는 기능과 조건들이 우리의 니즈에 부합하지 않았다.
일단 채팅을 구현하기 위해 강의를 지르고 클론코딩으로 형태를 만들어보기로 했다.
그런데 하다보니 왠지 할 수 있을것 같은 느낌이 들었다.
아래는 내가 채팅 관련 강의를 들으면서 공부하고 이해한 내용을 바탕으로 작성한다.
(정리 목적이기 때문에 참고만 하길 바란다.)
목차
1. 네트워크 통신
2. 웹 소켓과 socket.io
1. 네트워크 통신
클라이언트와 서버의 통신은 꾸준히 이루어져 왔다. 하지만 실시간 통신을 위한 노력도 이어졌다.
1-1) Polling
- 클라이언트가 평범한 http req를 서버로 요청하는 방식
- 가장 단순하지만, 필요할 때마다 계속 요청을 보내기 때문에 요청량이 많아진다면 서버의 부담 증가
- 또한 요청을 해야 응답을 주기 때문에 실시간성이 떨어짐
1-2) Long Polling
- 폴링과 동작 방식은 유사
- 요청을 미리 받고 응답에 대해서 클라이언트 쪽에서 사용가능한 데이터가 없으면 기다리다가 서버에서 해당 클라이언트로 전달할 이벤트가 있다면 그때 응답을 보내고 연결 종료
- 클라이언트에서 다시 http req를 요청하고 서버의 다음 이벤트를 기다리는 방식
- 폴링보다 서버의 부담은 상대적으로 줄어들지만, 이 방법 역시 요청량이 증가하면, 서버의 부담 증가
1-3) SSE (Server Sent Event)
- (클라이언트 - 서버)가 한 번 연결한 이후에는 서버에서 클라이언트로 데이터를 내려주는 단방향 통신
- 따라서 서버의 이벤트/ 메시지를 클라이언트로 일정 주기마다 내려주는 작업에 유용
1-4) Web Socket (웹 소켓)
- 실시간 양방향 데이터 전송을 위한 프로토콜
- HTML5의 일부로 정의된 프로토콜이기 때문에 최신 브라우저에서 지원함
- 기존의 http req-res방식은 요청한 해당 클라이언트에게만 응답이 가능하지만, ws 프로토콜을 통해서 포트 공유가 가능
- 이를 통해서 웹 소켓 포트에 접속한 모든 클라이언트에게 이벤트에 대한 응답 가능
- 최초 연결은 http req를 통해서 handShake라는 과정을 통해 이루어지기 때문에 기존의 80(http)/443(https) 포트로 접속
- 이로 인해서 추가적인 방화벽 설정없이 통신이 가능하고 CORS/ 인증등의 과정을 기존과 동일하게 처리 가능
2. 웹 소켓과 socket.io
- 실시간 양방향 통신을 가능하게 하는 라이브러리
[웹 소켓과의 차이점]
| 웹 소켓 | socket.io | |
| 프로토콜 | HTML5의 일부로 정의된 프로토콜 | 웹소켓을 기반으로 한 라이브러리 |
| 지원 범위 | 대부분의 최신 브라우저에서 웹소켓을 지원 | - 웹 소켓을 지원하지 않는 구형 브라우저에서도 폴링과 같은 대안적인 방법을 사용하여 통신 가능 |
| 지원 기능 | - 실시간 양방향 통신을 위한 기본 메커니즘을 제공 | - 웹 소켓을 기반으로 하면서도 추가적인 기능을 제공 - 방(Room) 개념, 클라이언트 식별 및 인증, 이벤트 기반 메시지 전송 외에도, 재연결 및 에러 처리와 같은 신뢰성과 안정성을 강화하는 기능 제공 |
[웹 소켓과의 장단점 비교]
| 웹 소켓 | socket.io | |
| 장점 | - 기본적으로 TCP를 사용하여 경량함 - 네이티브 웹 브라우저 지원이 강력하고, 최신 브라우저에서 추가 설정 없이 사용 가능 |
- 브라우저 지원의 폭이 더 넒음 - 웹 소켓 외에도 폴링/롱폴링과 같은 다른 통신 메커니즘을 지원하여 호환성 강화 - 추가적인 기능을 제공하여 개발자가 실시간 통신을 더 쉽게 구현 가능 |
| 단점 | - 오래된 브라우저에서 지원되지 않을 수 있음 - 연결을 유지하기 위해 서버 및 클라이언트 모두에서 추가적인 리소스 필요 |
- 웹소켓에 비해 약간의 오버헤드가 발생할 수있음 - 설정 및 구성이 웹 소켓보다 복잡할 수 있음 |
- 소켓의 계층 구조
- IO 객체 - NameSpace - Room - Socket.id
[Room과 NameSpace의 차이점]
| Room | NameSpace |
| 클라이언트들을 그룹으로 묶는 개념 | 클라이언트-서버 간의 논리적인 연결을 나누는 개념 |
| 비슷한 관심사를 가진 클라이언트를 하나의 그룹으로 묶어서 메시지 전달 및 이벤트 발송 가능 | 서버의 일부 기능이나 도메인을 분리하기 위해 사용 가능 |
| 동적으로 생성되고, 클라이언트는 동시에 여러 개의 방에 참여 가능 | 클라이언트는 네임스페이스에 연결하고 해당 네임스페이스를 통해 메시지 통신 가능 |
| join()/leave() 메서드를 통해 room에 참여/퇴장 가능 | URL 경로를 기반으로 식별되고, 클라이언트는 io()함수를 통해 특정 네임스페이스에 연결 가능 |
| 채팅 서비스에서 각 채팅방을 room으로 나타낼 수 있음 | 주로 서버의 기능을 논리적으로 구분하기 위해 사용되며, 실시간 알림기능 / 채팅기능을 분리할 수 있음 |
제공하는 기능
1. 이벤트 이름 전송
웹소켓은 단순히 메시지만을 문자열로 보냈다면,
socket.io에서는 발송/수신 시에 이벤트 이름을 통해서 특정 이벤트에 대해서 메시지를 전달 가능
2. timeout()
timeout 기능을 통해 일정 시간동안 이벤트가 없는 경우 분기처리를 추가할 수 있음
3. bradcasting
특정 room을 대상으로 메시지 전송 가능
4. multiplexing
특정 nameSpace를 대상으로 메시지 전송 가능
일단 socket.io에 대한 대략적인 개념은 알것 같다.
이제 클론코딩을 했던 코드를 만지작하면서 조금씩 바꿔보면서 익숙해져야겠다.
그 이후에는 채팅 서비스 개발...을....
가능하겠지...?
이제 기능 개발을 하러 가봐야겠다.
긴글 읽어주셔서 감사합니다.
혹시 잘못된 내용이나 수정사항있으면 댓글로 피드백주세요!
다들 화이팅입니다!!! 💪🏼