일반적으로 네트워크 서비스를 받기 위해 클라이언트가 통신을 시작한다. 클라이언트는 서버에 접속을 시도하고 그 연결 결과를 기다리든지 어떤 서비스를 요구하고 응답을 기다린다. 클라이언트의 이와 같은 요구에 대해 서버가 응답을 보내는 방식으로 동작이 이루어진다.
일반적으로 서버 프로세스는 클라이언트보다 먼저 실행되어 대기 상태에 있으므로 클라이언트의 연결 요청에 항상 응답할 준비가 되어 있다. 서버 프로세스는 일단 시작하면 영원히 종료되지 않고 실행되며, 다수의 클라이언트 요청을 반복적으로 수행한다. 클라이언트와 서버 사이의 네트워크 연결은 전송 계층의 포트 연결로 구현된다.
클라이언트/서버 통신 방식
Polling 방식
클라이언트가 서버에 주기적으로 요청 후 응답을 받는 방식이다. 가장 기본적인 기법으로 구현이 간단하지만 쓸모없는 요청과 응답 때문에 많은 트래픽이 낭비되며 다음 폴링이 이루어지기 전까지 어떤 이벤트가 왔는지 모르기 때문에 실시간성이 보장되지 않는다. 요청 주기를 짧게 줄일 수도 있지만 서버에 부하를 줄 수 있으므로 주의해야 한다. 실시간 메시지 전달이 크게 중요하지 않은 서비스에 적합한 방식이다.
Long Poll 방식
폴링방식의 단점인 반복적인 요청으로 응답을 받는 형태에서 Client가 서버에 대한 요청을 유지해 반복적인 요청을 없애고 유효한 이벤트가 발생하면 응답을 해주는 방식이다. Long이라는 이름과 같이 오래 접속을 유지하는 것인데 응답을 기다리다가 응답이 오면 데이터를 처리함과 동시에 새로운 접속을 생성하는 것이다. 무한정 기다리는 것이 아니라 일정 시간이 지나면 접속을 완료하고 새로 요청한다.
WebSocket 방식
위의 방식의 불편점을 개선하기 위해 만들어진 기술로 Client와 서버가 연결된 후부터 HTTP요청/응답 과는 상관없이 서버와 양방향 통신이 가능하다.
Web Socket이란?
웹소켓은 사용자의 브라우저와 서버 사이의 동적인 양방향 연결 채널을 구성한다. 웹소켓은 API를 통해 서버로 메세지를 보내고 요청없이 응답을 받아오는 것이 가능하다. 별도의 포트를 사용하지 않고 HTTP와 같은 80번 포트를 사용하고 있는데 이 때문에 클라이언트인 웹 브라우저뿐만 아니라 웹 서버도 기능을 지원하고 있어야 한다.
웹을 통해 사용자들이 정보를 교환하고 교류하고자 하는 수요가 늘어나면서 서버와 클라이언트 간의 상호작용을 하는 부분들이 생기기 시작했다. 전형적인 브라우저 렌더링 방식은 HTTP 요청에 대한 HTTP 응답을 받아서 브라우저의 화면을 모두 지우고 받은 내용을 새로 표시하는 방식이었지만 Ajax와 같은 기술이 등장하면서 사용자와 긴밀히 상호작용하는 웹 서비스가 등장했고 이러한 Rich Internet Application 기술의 발달이 웹 소켓의 등장배경이라고 할 수 있다.
사용 방법은 Ajax와 비슷하지만 개념 면에서 차이가 있다. Ajax의 경우는 웹 브라우저에서 데이터를 호출하면 웹 서버에서 호출된 값을 검색, 작성해서 웹 브라우저로 메세지를 보내는 형식의 구조라면 웹소켓의 경우는 웹 브라우저에서 호출해서 데이터를 가져가는 기능을 포함하여 반대로 서버에서 클라이언트를 호출할 수 있는 기능까지 있다.
상태를 유지하는 프로토콜이기 때문에 데이터의 빠른 업데이트가 필요한 곳에서 유용하다. 예를 들어, 채팅이나 멀티플레이어 게임, 증권 거래, 주식 차트와 같은 실시간성이 요구되는 애플리케이션의 개발을 한층 효과적으로 구현할 수 있다.
Web Socket 접속 과정
- TCP/IP 접속 요청
- TCP/IP 접속 수락
- 웹소켓 열기 핸드쉐이크 요청
- 웹소켓 열기 핸드쉐이크 수락
- 웹소켓 데이터 송, 수신
클라이언트에서 요청을 할 때 HTTP 1.1로 요청을 하고 웹 소켓 프로토콜로 업그레이드 해줄 것을 요청한다. 서버에서는 프로토콜 업그레이드가 성공하면 HTTP status 101 응답을 전송한다. 연결이 정상적으로 이루어지면 서버와 클라이언트 간의 웹소켓 연결이 이루어지고 일정 시간이 지나면 HTTP 연결은 자동으로 끊어진다.
핸드쉐이크는 한번의 HTTP 요청과 HTTP응답으로 이루어지며 핸드쉐이크가 끝나면 HTTP 프로토콜을 웹소켓 프로토콜로 변환하여 통신하는 구조이다.
API Gateway의 WebSocket API
API Gateway에서 AWS Lambda 또는 HTTP 엔드포인트에 대한 상태 저장 프론트엔드로 웹소켓 API를 만들 수 있다. 웹소켓 API는 클라이언트 애플리케이션에서 수신한 메세지의 내용을 기반으로 백엔드를 호출한다.
| Operation | Action |
|---|---|
| POST | 서버에서 연결된 웹소켓 클라이언트로 메세지 보내기 |
| GET | 연결된 웹소켓 클라이언트의 최신 연결 상태 가져오기 |
| DELETE | 연결된 웹소켓 클라이언트 연결 끊기 |
Route
API Gateway가 특정 타입의 클라이언트 요청을 어떻게 처리해야 하는 지 나타내며 라우팅키를 포함한다. 라우팅키는 라우트를 확인하기 위해 제공되는 값이라고 볼 수 있다. WebSocket API는 다수의 라우트로 구성되어 있다. 특정 inbound 요청이 어떤 라우트를 사용해야 하는지 정하려면 라우팅 선택 표현식이라는 것을 제공해야 한다.
- API Gateway는 클라이언트와 WebSocket API간 지속적인 연결이 시작될 때
$connect라우팅을 호출한다. - API Gateway는 클라이언트 또는 서버가 API와의 연결을 끊을 때
$disconnect라우팅을 호출한다. - 일치하는 라우팅이 발견되면 메세지를 기준으로 라우팅 선택 표현식이 평가된 후 API Gateway가 사용자 지정 라우팅을 호출한다. 일치 여부에 따라 어떤 통합이 호출될 지 결정된다.
- 일치하는 라우팅이 없거나 메세지를 기준으로 라우팅 선택 표현식을 평가할 수 없는 경우 API Gateway 가
$default라우팅을 호출한다.