R Socket이란 무엇일까?

리액티브 스트림의 근간을 다루는 개념은 바로 배압(backpressure)이다. 하지만 HTTP는 리액티브하지 않다. HTTP는 요청-응답 패러다임에 뿌리를 두고 있다. 과거의 개발자들은 HTTP를 사용하는 단순 요청-응답을 넘어서 터널로 서로 연결하는 방법을 고민해왔다.

 

> 첫 번째, 롱 폴링

클라이언트가 서버에 요청을 보낸 후 즉각적인 대답을 기대하지 않고, 오래 기다리더라도 서버의 응답을 기다린다. 응답을 받으면 처리하고 바로 새로운 요청을 서버에 보내 기다리는 식으로 연결 지속성을 확보한다. 하지만 자원을 점유한다는 한계가 있다.

 

> 두 번째, 웹소켓

웹소켓은 HTTP와는 다르게 양방향이다. 가볍고 양방향 비동기 통신을 지원하지만 배압 개념이 없으므로 리액티브하지 않다.

 

---

 

RSocket 리액티브 프로토콜 탄생

 R소켓은 HTTP와 웹소켓과 마찬가지로 OSI 7계층 프로토콜이다. R소켓은 웹소켓, TCP, 애런 등 여러 가지 프로토콜 위에서 동작하도록 설계됐다. HTTP는 TCP의 연결 관리를 사용해서 TCP 위에서 동작한다. R소켓도 TCP를 사용해서 장애내성과 확장성을 가진 리액티브 연결을 만들 수 있다. 애런은 UDP 위에서 동작하는 메시징 프로토콜이다. 

 

 

R소켓 패러다임

R소켓은 당연하게 소켓을 전재로 한다. 소켓은 연결을 맺고, 데이터를 송수신하는 데 신뢰성이 입증된 방식이다. R소켓의 패러다임에는 4가지 종류가 있다.

 

• 요청-응답 request-response (1개의 스트림)
  HTTP의 패러다임을 사용하는 것을 첫 번째로 언급하는 것이 역설적이다. 하지만 실제 통신에서 필요한 요구사항의 80%는 요청-응답 방식으로 해결할 수 있다. 원격 서비스에 데이터를 요청하고 새 데이터를 전송하고 확정을 기다리는 등 여러 작업이 요청-응답을 통해 수행된다.
  
  
• 요청-스트림 request-stream (다수의 유한한 스트림)
  한 번의 요청을 보내고 스트림 형태로 응답을 계속 받을 수 있으므로 좀 더 효율적이다. 롱 폴링 방식은 응답을 받을 때마다 처리를 하고 다시 요청을 보내는 일을 반복해야 해서 오버헤드를 유발한다. 또 응답을 기다리면서 스레드가 점유되므로 트래픽이 많은 상황에서 지연을 발생시키는 원인이 되기도 한다.
  R소켓은 채널을 열고 요청을 보낸 후에 스레드를 점유하지 않고 스트림 형태로 응답을 받을 수 있다. 주식 종목의 가격 변화를 스트림 형태로 계속 응답받는 상황이 대표적인 사례라고 할 수 있다.
  
  
• 실행 후 망각 fire-and-forget (무응답)
  요청을 보내고 응답을 신경 쓰지 않는 방식이다. R소켓은 모든 요청이 응답 결과를 항상 필요로 하는 것이 아니라는 점을 활용하면 연관성 유지에 의해 발생하는 오버헤드를 제거할 수 있다.
  
  
• 채널 channel (양방향)
  앞서 살펴본 3가지 패러다임은 요청을 보내는 클라이언트와 요청을 처리하는 서버가 등장한다. 채널 패러다임은 이런 틀을 깨고 진정한 '메시지 지향 양방향 통신 채널'을 실현한다. 채널의 어느 쪽이든 상대방에게 메시지를 전송할 수 있고, 양쪽 모두 리액티브 메시지 리스너를 반드시 등록해야 한다.