스프링(Spring): 소켓(Socket), 웹소켓(Web Socket) 이론

RFC 147: Definition of a socket

RFC 6455: The WebSocket Protocol

 

소켓

소켓(Socket)은 네트워크 통신을 가능하게 하는 인터페이스로, 통신의 엔드포인트(End point)이다. 네트워크에서 데이터를 송수신하기 위한 목적으로 사용되는 프로그래밍 인터페이스로, 일반적으로 인터넷 프로토콜(IP) 주소와 포트 번호의 조합으로 식별된다.

 

소켓 프로그래밍이란 소켓을 사용하여 네트워크 상에서 다른 프로그램과 데이터를 주고받는 코드를 작성하는 일련의 과정이다. 주로 서버와 클라이언트 모델을 기반으로 통신하며, 양측에서 소켓을 생성하여 데이터를 교환한다.

 

소켓의 종류

1. 스트림 소켓(Stream Sockets, TCP 소켓)
   - TCP(Transmission Control Protocol) 위에서 동작하며 신뢰성 있는 데이터 전송을 보장한다.
   - 데이터의 경계가 없이 연속적인 데이터 스트림을 전송한다.
2. 데이터그램 소켓(Datagram Sockets, UDP 소켓)
   - UDP(User Datagram Protocol)를 사용하여 비연결형 서비스를 제공한다.
   - 각각의 패킷이 독립적으로 전송된다.

 

소켓의 기본 작동 원리

소켓은 클라이언트/서버 아키텍처 기반이다.

 

예를 들어, HTTP 서버는 일반적으로 클라이언트의 요청을 처리하기 위해 TCP 소켓을 열고, 클라이언트는 서버와의 통신을 위해 소켓을 사용한다.

• HTTP(HyperText Transfer Protocol)는 월드 와이드 웹(WWW)에서 데이터를 주고받기 위한 프로토콜이다.
• HTTP는 기본적으로 TCP(Transmission Control Protocol) 위에서 동작한다.

HTTP 서버: 80번 포트를 열고 클라이언트의 요청을 대기한다. 80 포트에서 연결 요청을 수락하는 TCP 소켓을 생성한다.

클라이언트: 클라이언트는 서버의 IP 주소와 포트 번호를 사용하여 TCP 소켓을 통해 서버에 연결 요청을 전송한다. 연결이 성립되면 HTTP 요청을 전송하고, 서버는 클라이언트의 요청에 대한 응답을 반환한다.

 

바인딩 (Binding)

• 바인딩은 소켓을 특정 IP 주소와 포트 번호에 연결하는 과정이다.
• 서버 소켓은 바인딩을 통해 특정 포트에서 클라이언트의 연결 요청을 대기할 수 있게 된다.
• 클라이언트 소켓도 바인딩을 통해 특정 IP 주소와 포트를 사용할 수 있지만, 일반적으로 시스템이 자동으로 할당한다.

 

 

이 통신 과정은 아래와 같은 단계로 이루어진다.

Client Socket, Server Socket

1. 소켓 생성: 서버와 클라이언트는 각각 소켓을 생성합니다.
2. 소켓 바인딩: 서버는 생성된 소켓을 특정 IP 주소와 포트에 바인딩합니다.
3. 리스닝: 서버 소켓은 클라이언트의 연결 요청을 기다립니다.
4. 연결 수락: 서버는 클라이언트의 연결 요청을 수락하고 새로운 소켓을 성립합니다.
5. 데이터 전송: 연결된 소켓을 통해 서버와 클라이언트는 데이터를 주고받습니다.
6. 소켓 종료: 데이터 전송이 완료되면 연결된 소켓을 종료합니다.

// 자바에서 서버 소켓을 생성하는 코드 예시
ServerSocket serverSocket = new ServerSocket(portNumber);

// 클라이언트 소켓을 생성하고 서버에 연결하는 코드 예시
Socket clientSocket = new Socket("hostname", portNumber);

 

 

소켓과 포트 번호의 차이점

• 소켓은 네트워크 통신을 가능하게 하는 인터페이스로, 통신의 엔드포인트(End point)이다.
• 포트 번호는 네트워크 서비스와 프로토콜을 식별하고, 데이터가 올바른 애플리케이션에 도달하도록 한다.

 

소켓 프로그래밍에서의 TCP와 UDP의 차이점

• TCP 소켓은 연결 지향적 소켓으로, 데이터 전송 순서 및 신뢰성을 보장한다.
• UDP소켓은 비연결 지향적 소켓으로, 더 빠르지만 전송 순서나 신뢰성은 보장하지 않는다.

블로킹 소켓과 논블로킹 소켓의 차이

• 블로킹 소켓은 데이터 수신을 기다리는 동안 호출한 스레드가 블록(대기)된다.
• 논블로킹 소켓은 데이터가 도착하길 기다리지 않고 즉시 반환하여 다른 작업을 계속할 수 있다.

소켓 프로그래밍에서의 listen() 함수의 역할

• listen() 함수는 서버가 클라이언트의 연결 요청을 받을 준비가 되었음을 시스템에 알리고, 동시에 처리할 수 있는 최대 연결 요청 수를 설정한다.

 

소켓을 사용한 네트워크 통신에서 발생할 수 있는 문제점

• 네트워크 지연, 패킷 손실, 타임아웃, 부적절한 데이터 전송 순서 등의 문제가 발생할 수 있다.

 

---

 

웹 소켓

웹소켓(WebSocket)은 HTML5에서 소개된 프로토콜로, 웹 클라이언트와 서버 간의 전이중(Full-Duplex Communication) 통신 방식이다. 웹소켓을 사용하면 웹 애플리케이션이 실시간으로 데이터를 송수신할 수 있어서 기존의 HTTP 기반 통신 방식보다 훨씬 효율적이고 빠른 실시간 통신이 가능하다. 

 

전이중 통신은 네트워크 통신에서 양방향으로 데이터를 동시에 주고받을 수 있는 통신 방식이다. 즉, 두 개의 엔드포인트가 서로 동시에 데이터를 송신하고 수신할 수 있다. 따라서 전이중 통신을 통해서 효율적이고 빠른 데이터 교환이 가능하다.

 

웹 소켓 특징

• 비교적 최신 버전의 인앱 채팅, 알림, 음성 또는 화상 통화와 같은 실시간 애플리케이션에 적합하다.
• 웹소켓 연결은 처음에 한 번만 핸드셰이크(Handshake)를 통해 설정되며, 이후에는 연결을 유지한 채 데이터를 주고받는다. 연결을 유지하면서 데이터를 주고받기 때문에, 매번 새로운 연결을 설정해야 하는 HTTP 방식보다 효율적이다.
• HTTP 요청/응답 헤더에 비해 웹소켓 프레임 헤더는 매우 작아, 데이터 전송 시 오버헤드가 줄어든다. 데이터 전송 시 불필요한 헤더 정보가 적어서 대역폭 사용이 최적화된다.
• 웹소켓 프로토콜은 2011년 IETF에 의해 RFC 6455로 표준화되어 대부분의 브라우저에서 지원한다.

 

웹 소켓과 HTTP 비교

HTTP 연결 방식

 

Web Socket 연결 방식

 

HTTP 연결 방식은 반이중(Half-Duplex Communication)  통신으로 서버로부터 데이터를 받기 위해서는 반드시 클라이언트로부터 요청이 있어야 한다.

 

반이중(Half-Duplex) 통신이란 양방향 전송이 가능하지만 동시에 양쪽 방향에서 전송할 수 없는 방식이다. 한 번에 한 방향으로만 데이터가 전송된다. 클라이언트가 요청을 보내는 동안 서버는 기다리고, 서버가 응답을 보내는 동안 클라이언트는 기다린다. 예를 들어, 무전기, 모뎀을 이용한 데이터 통신이 있다. 

1. HTTP/1.0:
   • HTTP/1.0 버전에서는 기본적으로 각 요청마다 새로운 TCP 연결이 필요했습니다.
   • 따라서 요청을 보낼 때마다 새로운 TCP 연결을 설정하고, 요청을 처리한 후에는 연결을 끊어야 했습니다.
   • 이러한 방식은 매번 연결 설정과 해제 과정에서 오버헤드가 발생했습니다.
2. HTTP/1.1:
   • HTTP/1.1에서는 Keep-Alive라는 기능이 도입되어, 하나의 TCP 연결을 여러 번의 요청과 응답에 재사용할 수 있게 되었습니다.
   • 클라이언트가 서버에 요청을 보내면, 서버는 응답을 보낸 후에도 연결을 유지하고 다음 요청을 기다릴 수 있습니다.
   • 이로 인해 매번의 요청마다 핸드셰이크가 발생하지 않고, TCP 연결의 재사용으로 오버헤드가 줄어들게 됩니다.
3. HTTP/2:
   • HTTP/2에서는 여러 개의 요청과 응답을 병렬로 처리할 수 있도록 다중화(Multiplexing) 기능을 도입하였습니다.
   • 하나의 TCP 연결을 통해 동시에 여러 요청을 보내고, 응답을 받을 수 있습니다.
   • 이로 인해 더욱 효율적인 데이터 전송이 가능해졌습니다.

 

핸드셰이크와 오버헤드

• HTTP에서 핸드셰이크는 TCP 연결을 설정하고 해제하는 과정에서 발생하는 작업입니다.
• HTTP/1.0에서는 매 요청마다 핸드셰이크가 발생하여 연결 설정과 해제의 오버헤드가 크게 나타날 수 있었습니다.
• 하지만 HTTP/1.1의 Keep-Alive 기능이나 HTTP/2의 다중화 기능을 사용하면, 하나의 TCP 연결을 효율적으로 재사용하여 이러한 오버헤드를 줄일 수 있습니다.

따라서, HTTP 연결 방식에서 10번의 데이터를 주고 받는 경우, HTTP/1.1 이상의 버전에서는 하나의 TCP 연결을 통해 여러 번의 요청과 응답을 처리할 수 있으며, 이로 인해 핸드셰이크의 빈도와 오버헤드가 감소하게 됩니다.

 

Web Socket 연결 방식은 웹 클라이언트와 서버 간의 전이중(Full-Duplex Communication) 통신 방식으로 서버와 클라이언트는 원하는 시점에 데이터를 주고 받을 수 있다.

 

 

Web Socket 이전의 실시간 통신 방식

Polling, Long Polling, Streaming은 모두 Web Socket 이전의 실시간 데이터 전송을 위한 방법들이지만, 각각의 방식은 데이터를 전송하는 시점과 방법에서 차이가 있다. 

1. Polling (폴링)

Polling(폴링)은 클라이언트가 일정한 간격으로 서버에 데이터를 요청하는 방식이다. 클라이언트는 정기적으로 서버에 HTTP 요청을 보내고, 서버는 요청을 받아 새로운 데이터가 있으면 응답을 보내는 방식이다.

• Polling 작동 방식
  • 클라이언트는 일정한 주기로 서버에 요청을 보낸다. (예: 1초마다)
  • 서버는 클라이언트의 요청을 받으면, 데이터가 업데이트되었는지 확인하고, 업데이트가 있으면 즉시 데이터를 응답한다.
  • 클라이언트는 다시 주기적으로 서버에 새로운 요청을 보낸다.
• Polling 장점:
  • 구현이 비교적 간단하고, 대부분의 웹 브라우저에서 지원하는 기본적인 방법이다.
  • 모든 브라우저와 서버에서 사용할 수 있으며, 호환성이 좋다.
• Polling 단점:
  • 주기적으로 요청을 보내기 때문에, 불필요한 트래픽과 서버 자원 소모가 발생할 수 있다.
  • 데이터가 업데이트되지 않아도 주기적으로 요청을 보내야 하므로 효율성이 낮을 수 있다.

 

2. Long Polling (롱 폴링)

Long Polling(롱 폴링)은 클라이언트가 서버에 요청을 보내고, 서버는 즉시 응답하지 않고 데이터가 업데이트될 때까지 연결을 유지하는 방식이다. 따라서, Long Polling은 Polling에 비해 더 빠르게 데이터 업데이트를 받을 수 있는 방법이다.

• Long Polling 작동 방식
  • 클라이언트는 서버에 HTTP 요청을 보낸다.
  • 서버는 클라이언트의 요청을 받으면, 데이터가 업데이트되었는지 확인한다.
  • 데이터가 업데이트되지 않았다면, 서버는 클라이언트의 연결을 계속 유지하며 데이터가 업데이트될 때까지 기다린다.
  • 데이터가 업데이트되면 서버는 즉시 응답을 보내고, 클라이언트는 새로운 요청을 보내 다시 Long Polling을 시작한다.
• Long Polling 장점:
  • 데이터 업데이트가 발생하면 즉시 클라이언트에게 전달할 수 있다.
  • Polling 방식보다는 효율적이며, 실시간 데이터 전송에 적합하다.
• Long Polling 단점:
  • 서버가 많은 연결을 유지해야 하므로 서버 자원을 많이 소모할 수 있다.
  • 클라이언트와 서버 간의 연결이 지속적으로 유지되어야 하므로, HTTP 연결 관리가 복잡할 수 있다.

 

3. Streaming (스트리밍)

Streaming(스트리밍)은 클라이언트와 서버 간의 연결을 유지한 채로 실시간으로 데이터를 전송하는 방식이다. 이 방식은 데이터가 일정한 주기로 혹은 언제든지 클라이언트에게 전송될 수 있다.

• Streaming 작동 방식
  • 클라이언트는 서버에 HTTP 요청을 보낸다.
  • 서버는 요청을 받으면, 데이터가 업데이트되면서 서버에서 클라이언트로 데이터를 실시간으로 전송한다.
  • 이 과정에서 HTTP 연결은 계속 유지되며, 클라이언트는 데이터를 수신하는 동시에 추가 요청 없이 서버로부터 계속적으로 데이터를 받을 수 있다.
• Streaming 장점:
  • 실시간으로 데이터를 스트리밍하므로, 실시간 애플리케이션에 적합하다.
  • 클라이언트는 데이터를 즉시 수신하며, 추가적인 요청이 없어도 된다.
• Streaming 단점:
  • 일부 프록시 서버나 방화벽에서 지원하지 않을 수 있어 호환성 문제가 있을 수 있다.
  • 서버와 클라이언트 간의 연결을 오랫동안 유지해야 하므로, 자원 소모가 크게 될 수 있다.

 

선택 기준

• Polling: 단순한 구현과 호환성이 필요한 경우에 적합하다.
• Long Polling: 데이터의 실시간 업데이트를 필요로 하지만, 연결 수를 통제할 수 있는 경우에 적합하다.
• Streaming: 실시간으로 데이터를 처리해야 하며, 클라이언트와 서버 간의 지속적인 연결을 필요로 하는 경우에 적합하다.

Web Socket은 Polling, Long Polling, Streaming 방식이 해결하려는 단점들을 효과적으로 해결할 수 있는 방법이다.

 

Web Socket 의 작동 방식

 

Web Socket 핸드쉐이크(Hand-Shake) 과정

Web Socket 핸드쉐이크(Hand-Shake) 과정

 

Web Socket을 이용한 최초 연결은 핸드셰이크(Handshake) 과정을 거친다. Web Socket은 HTTP 기반 프로토콜이 아니라 별도의 프로토콜인 WebSocket 프로토콜을 사용하며, 이 프로토콜은 다음과 같은 과정으로 연결을 설정한다.

 

Web Socket 연결 과정

 

1. Handshake 요청 (Client)

• 클라이언트는 HTTP/HTTPS를 통해 웹 서버에 WebSocket 연결을 요청하는 HTTP 요청을 보낸다.
• 일반적으로 HTTP 메서드 중 GET 메서드를 사용하며, 웹 소켓의 특정 엔드포인트를 지정한다.

GET /websocket-endpoint HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

 

 

• Upgrade: websocket과 Connection: Upgrade 헤더는 웹 소켓 연결을 요청한다는 것을 나타내며, Sec-WebSocket-Key와 Sec-WebSocket-Version은 보안과 버전 정보를 제공한다.

 

2. Handshake 응답 (Server)

• 서버는 클라이언트의 WebSocket 연결 요청을 받으면, HTTP 응답을 사용하여 승인한다.
• 응답 코드는 보통 101 Switching Protocols 이다.

 

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

 

 

• Upgrade: websocket과 Connection: Upgrade 헤더는 서버가 웹 소켓 프로토콜을 사용할 준비가 되었음을 나타낸다.
• Sec-WebSocket-Accept는 클라이언트가 보낸 Sec-WebSocket-Key를 기반으로 한 해시 값으로, 보안을 위한 확인 수단이다.

 

3. WebSocket 연결 설정 (Client & Server):

• 클라이언트와 서버 간의 Handshake가 성공적으로 완료되면, TCP 연결이 설정되고 양방향으로 데이터를 주고받을 수 있는 WebSocket 연결이 활성화된다.
• 이후에는 WebSocket 프로토콜에 따라 클라이언트와 서버가 데이터를 전송하고 받을 수 있다.

 

 

 

Frame 구조

RFC 6455 Web Socket Frame 구조

 

RFC 6455 에서는 Web Socket에서 데이터 전송은 Frame 단위로 WebSocket의 가장 작은 데이터 단위로 규정되어 있다. WebSocket Frame은 다음과 같은 구조를 가지고 있다.

1. FIN (1 bit):
   • 최종 프래그먼트(Fragment) 여부를 나타낸다.
   • 1이면 마지막 프래그먼트, 0이면 계속된 프래그먼트가 있음을 나타낸다.
2. RSV1, RSV2, RSV3 (각각 1 bit):
   • 현재는 확장을 위해 예약된 비트이며, 보통은 0으로 설정된다.
3. Opcode (4 bits):
   • Frame의 종류를 나타내는 비트이다.
   • 예를 들어, 데이터 전송을 위한 opcode는 0x1 이다.
4. Mask (1 bit):
   • Payload 데이터가 마스킹 되었는지 여부를 나타낸다.
   • 클라이언트에서 서버로 전송되는 모든 데이터는 마스크 처리가 필요하다.
5. Payload length (7 bits, 7+16 bits, 또는 7+64 bits):
   • Payload의 길이를 나타낸다.
   • 7 bits로 표현된 짧은 길이, 7 bits와 16 bits로 구성된 중간 길이, 또는 7 bits와 64 bits로 구성된 긴 길이를 사용할 수 있다.
6. Masking key (32 bits):
   • Mask가 설정된 경우, 4바이트의 마스킹 키를 사용하여 Payload 데이터를 XOR 처리한다.
7. Payload data:
   • 실제 전송할 데이터이다.
   • 마스크가 설정된 경우, 마스킹 키를 사용하여 XOR 처리된 데이터가 된다.

데이터 전송 과정

WebSocket에서 데이터 전송은 위와 같은 Frame 구조를 사용하여 이루어진다. 클라이언트와 서버 간에 Frame을 교환하여 메시지를 전송하고, 최종 프래그먼트(FIN) 비트가 1로 설정된 마지막 Frame이 전송될 때 메시지의 전송이 완료된다.

프래그먼트(fragment)란 데이터 전송 시 전체 데이터가 분할되어 전송되는 것을 의미합니다. WebSocket에서 프래그먼트는 하나의 메시지가 여러 개의 Frame으로 나뉘어 전송되는 경우를 말합니다.

WebSocket에서 프래그먼트는 주로 다음과 같은 상황에서 발생할 수 있습니다:

1. 메시지가 큰 경우: 클라이언트나 서버가 큰 크기의 데이터를 보내야 할 때, WebSocket은 이를 여러 개의 Frame으로 나누어 전송할 수 있습니다. 이때, 하나의 메시지가 여러 프래그먼트로 나뉘어 전송됩니다.
2. 메시지가 중간에 중단되는 경우: 대용량의 데이터를 전송할 때 네트워크 문제나 다른 이유로 데이터가 중간에 끊기는 경우가 발생할 수 있습니다. 이 경우 WebSocket은 중단된 데이터를 재전송하거나, 데이터를 여러 프래그먼트로 나누어 전송할 수 있습니다.

프래그먼트가 사용되는 경우에는 각 Frame의 FIN (Final Fragment) 비트가 설정됩니다. 이 비트는 해당 Frame이 메시지의 마지막 프래그먼트인지를 나타냅니다. 처음 Frame에서는 FIN 비트가 0이고, 마지막 Frame에서는 FIN 비트가 1로 설정됩니다.

WebSocket 프로토콜에서 프래그먼트의 사용은 메시지의 크기를 효율적으로 관리하고, 데이터의 전송 안정성을 유지하는 데 도움을 줍니다. 따라서 큰 데이터를 안전하게 전송하거나, 중간에 데이터 전송이 중단되었을 때 데이터 손실을 방지하기 위해 프래그먼트 기능이 사용될 수 있습니다.

마스킹(Masking)은 WebSocket 프로토콜에서 사용되는 보안 기법으로, 클라이언트에서 서버로 데이터를 전송할 때 데이터를 XOR 연산을 통해 변환하는 과정을 말합니다.

마스킹의 목적

마스킹의 주요 목적은 다음과 같습니다

1. 보안 강화: 클라이언트에서 서버로 전송되는 데이터를 마스킹하여 중간에 제3자가 데이터를 캡처하여도 데이터를 읽기 어렵게 만듭니다. 즉, 데이터를 마스킹하지 않으면 중간에서 데이터를 가로채기 쉽고, 데이터의 의미를 쉽게 해석할 수 있습니다.
2. 웹 보안 정책 준수: 웹 보안 정책에 따라 클라이언트에서 서버로 데이터를 마스킹하여 보호해야 할 수 있습니다.

 

마스킹 과정

마스킹은 다음과 같은 과정으로 이루어집니다

1. 마스킹 키 생성: 클라이언트는 임의의 32비트 마스킹 키를 생성합니다.
2. 데이터 마스킹: 클라이언트는 실제 데이터를 생성된 마스킹 키와 XOR 연산을 수행하여 마스킹된 데이터를 생성합니다.
3. 마스크 헤더 추가: 생성된 마스킹 키를 포함한 마스크 헤더를 WebSocket 프레임에 추가합니다.
4. 서버 전송: 마스크 헤더가 포함된 WebSocket 프레임을 서버로 전송합니다.

 

서버에서의 처리

서버는 마스크 헤더를 포함하는 프레임을 수신하면, 다음과 같은 과정을 통해 데이터를 복호화합니다:

1. 마스크 키 추출: 프레임의 마스크 헤더에서 마스킹 키를 추출합니다.
2. 데이터 복호화: 추출된 마스킹 키를 사용하여 XOR 연산을 수행하여 실제 데이터를 복원합니다.

 

마스킹의 중요성

마스킹은 WebSocket의 보안성을 강화하는 중요한 요소 중 하나입니다. 마스킹을 통해 데이터를 전송하는 동안 중간에 데이터가 노출될 위험을 줄이고, 데이터의 안정성과 기밀성을 보장할 수 있습니다. 따라서 WebSocket 프로토콜에서는 클라이언트에서 서버로 전송되는 모든 데이터에 대해 마스킹을 필수적으로 사용합니다.

 

 

STOMP

STOMP(Simple Text Oriented Messaging Protocol)는 메시지 전송을 효율적으로 하기 위해 설계된 프로토콜로, 주로 pub/sub (publish/subscribe) 구조를 기반으로 동작한다. 따라서 개발자는 명확하게 메시지를 발행하고 구독하는 방식을 이해하고 개발할 수 있다. 

 

간단하고 명확한 프로토콜

• STOMP는 텍스트 기반의 간단한 프로토콜로, 명령(command)과 헤더(header), 바디(body)로 구성된 프레임(Frame)을 사용하여 메시지를 전송한다. 이는 개발자가 메시징 시스템을 이해하고 구현하기 쉽도록 도움이 된다.

구조화된 메시징 패턴

• pub/sub 구조를 기본으로 하여, 메시지 발행자(publisher)는 특정 주제(topic)에 메시지를 발행하고, 해당 주제를 구독하는 구독자(subscriber)는 메시지를 수신할 수 있다. 이는 메시지 전송의 목적과 방식을 명확히 정의하여 개발자가 애플리케이션을 설계하고 구현하는 데 도움을 준다.

메시지 처리의 효율성

• pub/sub 구조는 메시지의 전송과 처리를 효율적으로 관리할 수 있다. 메시지 발행과 구독을 명확하게 분리하여, 여러 클라이언트가 동시에 메시지를 수신하거나 발행할 수 있도록 지원한다.

플랫폼 간 호환성

•  STOMP는 다양한 플랫폼과 언어에서 지원되며, 클라이언트와 서버 간의 상호운용성을 보장한다. 이는 웹 애플리케이션 개발에서 다양한 환경에서의 메시징 요구를 충족시키는 데 유리하다.

따라서 STOMP 프로토콜은 간단하고 명확한 메시징 패턴을 제공하여 개발자가 메시지 전송을 효율적으로 관리하고, 메시징 시스템을 쉽게 구축하고 유지보수할 수 있도록 돕는 프로토콜이다.

Publish/Subscribe (Pub/Sub) 구조는 메시지 기반 시스템에서 사용되는 패턴으로, 메시지 발행과 구독을 분리하여 데이터를 효율적으로 전달하는 방식입니다. 이 패턴은 다수의 클라이언트가 동적으로 메시지를 송수신할 수 있도록 설계되어 있습니다. 여기에서는 pub/sub 구조의 핵심 개념과 작동 방식에 대해 구체적으로 설명하겠습니다.

핵심 개념

1. Publisher (발행자):
   • 메시지를 발행하는 주체입니다.
   • 특정 주제(topic)에 메시지를 발행하여, 해당 주제에 관심 있는 구독자들에게 메시지를 전달합니다.
   • 주제는 일종의 카테고리나 채널을 나타내며, 메시지의 유형이나 목적에 따라 구분됩니다.
2. Subscriber (구독자):
   • 특정 주제(topic)를 구독하는 클라이언트입니다.
   • 구독자는 원하는 주제를 구독하여 해당 주제에 발행된 메시지를 수신할 수 있습니다.
   • 구독자는 구독을 해지할 수도 있으며, 이 경우 해당 주제의 메시지를 더 이상 수신하지 않습니다.
3. Topic (주제):
   • 메시지를 발행하거나 구독하는 데 사용되는 카테고리나 채널입니다.
   • 특정 주제는 메시지의 유형이나 주제를 식별하는데 사용됩니다.
   • 여러 개의 구독자가 동일한 주제를 구독할 수 있으며, 각 구독자는 해당 주제에 발행된 메시지를 독립적으로 수신할 수 있습니다.

작동 방식

1. 메시지 발행(Publish):
   • 발행자는 특정 주제를 선택하여 메시지를 발행합니다.
   • 발행된 메시지는 해당 주제를 구독하는 모든 구독자에게 전달됩니다.
   • 발행된 메시지는 일반적으로 메시지 큐나 브로커를 통해 중재됩니다.
2. 메시지 구독(Subscribe):
   • 구독자는 특정 주제를 구독하여 해당 주제에 발행된 메시지를 수신합니다.
   • 구독자는 구독을 통해 원하는 주제에 대한 메시지를 실시간으로 받을 수 있습니다.
   • 구독자는 여러 개의 주제를 동시에 구독할 수 있습니다.
3. 이벤트 기반 통신:
   • Pub/Sub 구조는 이벤트 기반 통신을 지원하여, 발행자와 구독자 간에 느슨한 결합(Loose Coupling)을 제공합니다.
   • 이는 시스템의 확장성을 높이고, 각 컴포넌트가 독립적으로 동작할 수 있도록 합니다.

예시

예를 들어, 뉴스 애플리케이션에서 특정 카테고리(주제)의 뉴스를 구독하는 경우를 생각해보겠습니다. 사용자는 스포츠, 경제, 문화 등의 주제를 선택하여 해당 주제에 관련된 뉴스를 구독할 수 있습니다. 발행자는 각 주제에 맞는 뉴스를 발행하고, 해당 주제를 구독한 모든 사용자는 실시간으로 그 주제에 대한 뉴스를 수신할 수 있습니다.

이렇듯 Pub/Sub 패턴은 다수의 클라이언트가 실시간으로 데이터를 주고받아야 하는 경우나, 분산 시스템에서 이벤트 기반 통신이 필요한 경우에 유용하게 사용됩니다.

 

 

Web Socket 지원 현황과 한계

Web Socket 지원 현황과 한계

Web Socket 지원하지 않더라도 사용 가능하게 도와주는 도구들

 

Web Socket 지원