WebSocket

WebSocket가 없을 때 어떤식으로 통신을 했을까?웹소켓이 등장하기 전, 우리는 실시간 통신을 흉내 내기 위해 Polling 방식을 사용했습니다.Polling은 클라이언트가 일정 주기로 서버에 데이터를 요청하고, 서버가 그때마다 응답하는 구조입니다.이때 요청을 보낼

websocket의 이전 양방향 통신은 한계가 뚜렷했습니다.HTTP 폴링 (Polling) : 클라이언트가 요청을 보냈지는 일정 주기마다 확인을 하는 작업으로 항상 불필요한 요청과 응답이 있었습니다.Long Polling : 클라이언트 측에서 요청이 올 때까지 서버는

@Configuration은 해당 클래스가 설정 클래스임을 의미합니다. 내부에 정의된 @Bean 메서드들을 스프링 컨테이너에 등록해줍니다. WebSocketConfig는 웹소켓 설정을 위한 설정 클래스로 사용됩니다.@EnableWebSocketMessageBroker는

Java Websocket을 통해 채팅방을 만들려하면 많이들 쓰는게 Redis의 Pub/Sub입니다.다른 SQL과 달리 NoSQL로 채팅같은 실시간 데이터 처리를 할때 매우 유용한 친구입니다.응답의 두 번째 요소로 제공된 채널을 성공적으로 구독했음을 의미합니다. 세 번

WebSocket을 이용한 채팅을 구현할 때 구글링을 하면 Redis를 이용한 WebSocket 채팅 구현이 보입니다.저 또한 Redis를 이용하여 WebSocket 채팅을 구현했습니다.그렇다면 Redis는 과연 이런쪽에서 장점만 있을까에 대해 정리해보겠습니다.Redi

서비스에 실시간 채팅 기능이 필요했습니다.사용자 간 메시지를 거의 즉시 반영할 수 있어야 했고, 빠르게 프로토타이핑이 가능한 기술이 필요했습니다.특히 초기 개발 단계였기 때문에, 인프라 구축에 많은 리소스를 들이기 어려운 상황이었습니다.Kafka, RabbitMQ 등