230302 TIL

이지섭·2023년 3월 2일

내일배움캠프 TIL

오늘의 공부

웹소켓 프로그래밍

단방향 프로토콜인 HTTP의 단점을 보완하기 위해 개발된 프로토콜
- 일반 소켓 통신과는 달리 HTTP 80포트를 사용하여 연결되기 때문에 방화벽의 제약이 없다.
웹소켓이 없었을 땐... 양방향 통신을 하기 위한 여러 방법들이 있었다
- polling
  - 새로운 정보가 있는지 계속해서 서버에 요청하여 확인하는 방식
  - 계속 새로고침
  - 클라이언트가 많아질 수록 서버 부담 급증
- long-polling
  - 클라이언트가 서버에 요청을 보낸 상태로 기다린 뒤, 서버가 응답을 하면 즉시 이벤트를 전달하며 연결이 종료
  - 다수의 이벤트가 한번에 발생할 경우 서버 부담 급증
- streaming
  - long-polling과 비슷하지만, 연결이 종료되지 않고 계속해서 새로운 이벤트를 받는다
  - long-polling의 단점은 해소되었지만, 데이터를 '주고 받는'것 보단 받기만 하는것이 더 중점
- web socket
  - 연결을 계속 유지
  - 클라이언트의 요청 없이도 서버가 먼저 데이터를 보낼 수 있다
  - TCP 소켓과 다른 점?
    - 최초 연결(Handshake)이 HTTP request를 통해 이루어지므로 추가 방화벽을 열지 않고도 통신이 가능하고, CORS나 인증 등 HTTP의 특성을 동일하게 가진다.
- 항상 web socket이 좋은 것은 아니다. 상황에 따라 적절한 방식을 사용
HTTP와 REST에서 Application은 여러 URL로 모델링 된다.
반면에 웹 소켓은 일반적으로 초기 연결을 위한 URL이 한 개만 존재한다.
- 이런데 어떻게 여러개의 방이 개설되는지 이해가 가지 않았지만,
  STOMP를 이용하면 가능한 것 같다.

문제와 시도

채팅내역 저장은 어떻게 하나?

모든 내역들을 한 줄 한 줄 RDB에 저장하는것이 맞나?
테이블 구조를 어떻게 짜야하나

다수의 채팅방은 어떻게 구현하나?

웹소켓은 URL이 하나뿐인데, 어떻게 다수의 채팅방을 구현하나?

해결과 학습

채팅내역 저장은 어떻게 하나?

대용량 데이터를 다루는 실무에서는 어떨지 모르겠지만, RDB에 저장하는 사례들이 많았다.
하지만 매 전송 시 마다 INSERT를 하면 DB의 부담이 커지므로
Redis를 활용하여 일정량을 임시 저장해둔 뒤
flush하듯 한번에 INSERT하는 방식을 적용해볼 생각
4개의 테이블로 나누어 구현예정
- 모임 채팅방
- 모임 채팅방 채팅내역
- 개인 채팅방
- 개인 채팅방 채팅내역