Client - Sever 통신

• 일반적으로 소프트웨어에서 사용하는 데이터들은 보통 서버에서 관리된다.
• 그럼 클라이언트에서 이 서버에서 접속하여 테이터를 주고받게 되는데, 여기서 통신 방식이 크게 Http 통신과 Socket 통신 2가지 방식이 있다.

HTTP 통신

클라이언트의 요청이 있을 때만** 서버가 응답하여 해당 정보를 전송하고 곧바로 연결하는 종료하는 방식

• 단방향적 통신
  - 서버가 클라이언트로 요청을 보낼 수 없다.
  - 그래서 요청을 보낼 때, 내용을 기다리는 시간과 함께 연결하는 시간이 들어가게 된다.

HTTP 통신 언제 쓸까?

• 실시간 연결이 아닌, 필요한 경우에만 서버로 접근하는 컨텐츠 위주의 데이터를 사용할 때 용이하다.
  - 만약 게시물에 대한 내용을 요청하기 위해 실시간으로 연결을 유지하는 소켓통신을 사용하게 되면, 게시물을 받은 후에도 계속 통신을 위한 연결이 성립되어 부하가 걸리게 된다.

소켓 통신

서버와 클라이언트가 특정 포트를 통해 실시간으로 양방향 통신을 하는 방식

• 소켓 통신은 HTTP 통신과 달리 서버와 클라이언트가 특정 포트를 통해 연결을 성립하고 있어 실시간으로 양방향 통신을 하는 방식이다.
• 소켓 통신은 서버 역시 클라이언트로 요청을 보낼 수 있다.
• 계속 연결을 유지하는 연결지향형 통신이기 때문에 실시간 통신이 필요한 경우 자주 사용된다.
  - 스트리밍 중계나 실시간 채팅과 같이 즉각적으로 정보를 주고받는 경우에 사용
  - 만약 스트리밍 서비스를 HTTP 통신으로 구현한다면?
  - 사용자가 서버로 동영상을 요청하기 위해서는 동영상이 종료되는 순간까지 계속해서 HTTP 통신을 보내야 한다. -> 부하가 걸리게 된다.

웹소캣

전이중 통신 채널 제공 -> 실시간성 보장

• 웹소캣 언제 쓸까?
• HTTP 와 웹소캣
• 웹소캣 in Spring
• STOMP 그리고 Spring-Messaging

웹소캣 언제 쓸까?

• 실시간성을 보장하는 서비스
• 게임, 채팅, 실시간 주식 거래 사이트 등

웹소켓 접속 과정

• 웹소켓을 이용하여 서버와 클라이언트가 통신을 하려면 먼저 웹소켓 접속 과정을 거쳐야 한다. 웹소켓 접속 과정은 TCP/IP 접속 그리고 웹소켓 열기 HandShake 과정으로 나눌 수 있다. 웹소켓도 TCP/IP위에서 동작하므로, 서버와 클라이언트는 웹소켓을 사용하기 전에 서로 TCP/IP 접속이 되어있어야 한다. TCP/IP 접속이 완료된 후 서버와 클라이언트는 웹소켓 열기 HandShake 과정을 시작한다.
• 웹소켓 열기 HandShake
  - 웹소켓 열기 HandShake 는 클라이언트가 먼저 HandShake 요청을 보내고 이에 대한 응답을 서버가 클라이언트에게 보내는 구조다.

HTTP 통신과 웹소캣 통신 비교

수립된 커넥션을 어떻게 처리하냐? 의 차이가 있다. 그리고 HTTP 통신의 경우, 요청, 응답마다 웹소켓에 비해 더 많은 양의 응답 헤더와 요청 헤더가 필요하다.

HTTP

• HTTP에서도 실시간성을 보장하는 기법이 존재
  - Poling, Long Poling, Streaming

Poling, Long Poling, Streaming

Polling

• 클라이언트가 평범한 HTTP Request를 서버로 계속 요청해 이벤트 내용을 전달받는 방식
• 쉬운 방법이지만 지속적으로 Request를 요청하기 때문에 클라이언트의 수가 많아지면 서버의 부담이 급증한다.
• HTTP Request Connection 을 맺고 끊는 것 자체가 부담이 많은 방식
• 클라이언트에서 실시간 정도의 빠른 응답을 기대하기 어렵다.

Long Polling

• 클라이언트에서 서버로 일단 HTTP Request 를 요청한다. 이 상태로 계속 기다리다가 서버에서 해당 클라이언트로 전달할 이벤트가 있다면 그 순간 Response 메시지를 전달하며 연결이 종료된다. 곧이어 클라이언트가 다시 HTTP Request 를 요청해 서버의 다음 이벤트를 기다리는 방식
• polling과 비교해 polling 보다 서버의 부담을 줄지만 클라이언트로 보내는 이벤트들의 시간 간격이 좁다면 polling과 별로 차이가 없다.
• 다수의 클라이언트에게 동시에 이벤트가 발생될 경우 서버의 부담이 급증한다.

Streaming

• Long Poliing 과 마찬가지로 클라이언트 -> 서버로 HTTP Request 를 요청한다. 서버 -> 클라이언트로 이벤트를 전달할 때 해당 요청을 해제하지 않고 필요한 메시지만 보내기를 반복하는 방식
• 비연결성
• 매번 연결 맺고 끊는 과정의 비용
• (요청 - 응답) 구조

웹소캣

• 연결 지향
• 한번 연결 맺은 뒤 유지
• 양방향 통신
• WebSocket이 기존의 TCP Socket과 다른 점은 최초 접속이 일반 HTTP Request를 통해 HandShaking 과정을 통해 이뤄진다는 점이다. 
• HTTP Request를 그대로 사용하기 때문에 기존의 80, 443 포트로 접속을 하므로 추가 방화벽을 열지 않고도 양방향 통신이 가능하고, HTTP 규격인 CORS 적용이나 인증 등 과정을 기존과 동일하게 가져갈 수 있는 것이 장점이다.

STOMP

• Simple Text Oriented Messaging Protocol
• 메시지 브로커를 활용하여 쉽게 메시지를 주고 받을 수 있는 프로토콜
  - Pub-Sub(발행-구독): 발신자가 메시지를 발행하면 수신자가 그것을 수신하는 메시징 패러다임
  - 메시지 브로커: 발신자의 메시지를 받아와서 수신자들에게 메시지를 전달하는 어떤 것
• 웹소켓 위에 얹어 함께 사용할 수 있는 하위(서브) 프로토콜
• STOMP는 웹소켓만을 위해 만들어진 프로토콜이 아니지만 웹소켓과 같은 양방향 프로토콜과 함께 사용할 수 있다는 점과 스프링이 웹소켓위에 STOMP를 얹었다는 점을 알아두면 좋다.
• 프레임 단위의 프로토콜
  - 커맨드
  - 헤더
  - 바디

STOMP를 사용하는 장점

• 하위 프로토콜 혹은 컨벤션을 따로 정의할 필요가 없다.
• 연결 주소마다 새로 핸들러를 구현하고 설정해줄 필요가 없다.
• 외부 Messaging Queue를 사용할 수 있다
  - RabbitMQ, 카프카
• Spring Security를 사용할 수 있다.