랜덤 채팅방이나, 실시간 주식차트등과 같이
현재 내용이 갱신되게되면, 사용자는 실시간으로 갱신된 내용을 볼 수 있게 서비스를 만들고 싶었다.
이러한 서비스를 만들기 위해서는 WebSocket을 활용해야 됐기 때문에, WebSocket 에 대해 알아보고자한다.
알아보고자하는 순서
- 1️⃣ WebSocket이 어떻게 동작하는지?
- RestAPI 와 뭐가 다를까?
- 2️⃣ STOMP 프로토콜, Publish/Subscribe 모델을 알아야 구현이 된다.
- 프로토콜?
- STOMP의 구조가 뭔지 알아보자
- 3️⃣ SpringBoot에서 구현해보기
spring-boot-starter-websocket라이브러리 추가
-WebSocketConfig설정(발행자, 구독자, endPoint)@Controller생성 및 테스트
1. WebSocket이 어떻게 동작하는지?
평소 RestAPI에 익숙했던 사람이라면, 먼저 WebSocket에 대해 이해해야된다.
왜냐면, RestAPI가 HTTP 기반 통신인데, WebSocket역시 HTTP 기반 통신이기 떄문에 이둘의 차이를 알아야하고 어떻게 동작하는지 차이를 분명하게 알고 있어야한다.
게다가, 이사실을 알게되면, API != RestAPI 임을 깨닫고, RestAPI는 API 종류중 하나라는 것을 알게된다.
기존 (Rest)API의 한계
RestAPI 와 뭐가 다를까?
- 초기 Web은 주로 정적인 콘텐츠를 제공하는데 초점이 맞춰졌었다. 하지만, 자연스레 웹 기술은 점점 발전하고 사용자들도 보다 좋은 것에 대한 요구사항이 증가하면서, 더욱 동적이고 "실시간" 기능이 필요해 졌다.
- 사실 동적인 콘텐츠를 위해 AJAX의 기술이 나왔지만, 이것 역시 통신이
HTTP 요청/응답 모델이 기반이였기때문에,실시간 양방향 통신에는 한계가 있었다. - 나름 구현할 수는 있지만, 네트워크 트래픽과 서버 부하만 증가시키는 문제가 있다.
- 클라이언트가 주기적으로 서버에 데이터를 요청하는 방식으로 실시간 기능을 만들 수는 있다.(Polling)
좀 더 구체적으로 알아보자
Rest API
- HTTP 프로토콜 기반으로 요청-응답 모델을 사용한다.
- 아래는 기본적으로 클라이언트와 서버과 TCP/IP 통신하는 과정을 나타낸다.
- 여기서 중요한 것은 연결을 위한 3way HandShake 해제를 위한 4way HandShake가 아닌, 클라이언트가 요청을 보내면 서버가 응답을 해주는 것이 요점이다!
- 보통 이걸 요청-응답 패턴 혹은 요청-응답 모델이라고 한다.
- 이 모델은 정적인 콘텐츠에는 유용하나
실시간 양방향 통신에는 한계가 있다.
RestAPI도 이 모델을 사용하고 있을 뿐이다. 다만, 클라이언트와 서버가 특정 상황을 보다 체계적으로 구분하기위해, GET, POST, PUT, DELETE등의 메소드를 만들었다.
WebSocket
- HTTP 프로토콜 기반이지만,
양방향 데이터 통신을 한다.- 항상 클라이언트가 서버로 요청을 보내야지만, 응답할 수 있는 단방향이였지만,
- 서버가 클라이언트에게 데이터를 푸시할 수 있게 되어 양방향이 된 것이다.
- 다만, RestAPI보다 이후에 나와
HTML5 이후부터표준화되어 이전 버전은 지원이 안될 수도 있다. 오버헤드가 낮은 특징이 있는데, 클라이언트와 서버가 통신할 때 초기와 마지막에 항상하는 것이 *way handshake임을 알 수 있다.- 이 과정이 websocket의 경우에는 처음 연결이 필요한 한번만 하기 때문에 통신 오버헤드가 낮다는 의미이다.
좋아!, 이제 연결은 됐어 그럼 이제 실시간 데이터교환은 어떻게 할까?
데이터를 어떻게 교환하는지 알려면 STOMP, Publish/Subscribe 프로토콜을 알아야한다.
2. STOMP 프로토콜, Publish/Subscribe 모델을 알아야 구현이 된다.
- STOMP 은 메시지를 안전하고 효율적으로 전달하는 방법의 대표적인 메시징 프로토콜이다.
- 메시징 프로토콜은 STOMP외에도 AMQP, MQTT, XMPP등 다른 여러종류가 있다.
- 이러한 프로토콜들은 각각의 목적과 환경에 맞게 설계되었는데, 실시간 웹 애플리케이션에는 STOMP가 적합할 수 있고, IoT 기기 간의 효율적인 메시징을 위해서는 MQTT나 CoAP가 더 적합할 수 있다.
프로토콜
컴퓨터 네트워크에 수많은 통신이 일어나고, 서로 구분하고 알기위해 서로 다른 기종의 컴퓨터끼리 통신하기 위해서 미리 정해놓은 통신 규약 및 통신 약속
종류
| 계층 | 프로토콜 |
|---|---|
| 응용(Application) | HTTP, SMTP, FTP, Telnet |
| 표현(Presentation) | ASCII, MPEG, JPEG, MIDI |
| 세션(Session) | NetBIOS, SAP, SDP, NWLink |
| 전송(Transport) | TCP, UDP, SPX |
| 네트워크(Network) | IP, IPX |
| 데이터 링크(Data Link) | Ethernet, Token Ring, FDDI, Apple Talk |
| 물리(Physical) | ISDN, wired(유선), wireles(Wi-Fi,5G) |
- 이렇게 계층별로 필요에따라 여러 프로토콜이 존재하고, 우리가 흔히 아는 TCP/IP 프로토콜도 서로 다른 계층에서 사용하기때문에 서로 독립적이며 보완적인 관계이다.
그렇기 때문에 HTTP 위에 WebSocket이 통신방식을 규약할 수 있고, WebSocket위에 STOMP으로 메시징 형식과 규칙을 추가할 수 있는 것이다.
STOMP의 구조
-
STOMP프로토콜은 기본적으로 Publish/Subscribe 모델을 가지고 있다.
Publish/Subscribe 모델
Publish/Subscribe(발행/구독) 모델은 메시지를 직접적으로 특정 수신자에게 보내는 대신,
메시지를 주제나 채널에 발행하여
관심 있는 구독자들이 해당 메시지를 받을 수 있게 하는 패턴(모델)
Publish/Subscribe 모델 주요 특징
- 분리(Decoupling)
- 발행자와 구독자는 서로를 몰라도 된다.
- 발행자 : 메시지를 주제에 발행하기만
- 구독자: 관심 있는 주제를 구독하기만
- 이로 인해 시스템의 다양한 부분들이 서로 독립적으로 운영될 수 있다.
- 발행자와 구독자는 서로를 몰라도 된다.
- 동적인 네트워크 구성
- 새로운 구독자나 발행자가 시스템에 손쉽게 추가될 수 있다.
- 구독자는 언제든지 구독을 시작하거나 중단할 수 있고, 발행자는 필요에 따라 새로운 주제를 만들어 메시지를 발행할 수 있다.
- 확장성(Scalability)
- 주제에 대한 관심이 많은 구독자가 있을 경우, 메시지 브로커가 메시지를 효율적으로 분배하여 각 구독자에게 전달할 수 있습니다. 이는 시스템의 확장성을 크게 향상시킬 수 있다.
느낀점
이로써, 본격적으로 WebSocket을 구현하기 전, 어떻게 구성되어 있는지 알아봤다.
websocket만 정리해서 올리려다보니, 뭔가 구체적으로 와닿지 않고 중간중간 정확히 모르는 개념이 발견될 때마다 그 것을 찾아 정리하다보니 점점 내용이 많아지는 것 같아 이번 포스팅은 여기서 마무리하고 다음에 다시 작성하고자한다.(STOMP 설명도 추가적으로 더 할 예정) 그리고 다음에는 코드내용도 같이 올려 보고자한다.
