웹 소켓이 등장하기 까지 - Polling Long Polling, Streaming, Web Socket

1. WebSocket 이전의 양방향 통신 방법

(1) Polling 방식

클라이언트가 서버에서 HTTP Request를 주기적으로 요청하고, 서버가 응답하는 방식이다. 클라이언트가 주기적으로 요청을 하기 때문에 클라이언트의 수가 

증가하면 요청의 수도 함께 증가하기 때문에 서버의 부담이 커진다. 또한, 요청과 응답후에는 연결이 끊어지기 때문에 요청할 때마다 항상 연결을 맺는 과정이

필요하다. 이 부분에서 많은 비용이 소모된다.

(2) Long Polling 방식

클라이언트가 서버에 HTTP Request를 요청하면, 서버는 대가하고 있다가 이벤트가 발생했을 때, 클라이언트에게 응답을 하는 방식이다. Polling 처럼 불필요한

요청에 계속 응답하는 것이 아니기 때문에 요청에 따른 커넥션 맺는 과정에서 발생하는 비용이 줄어든다. 하지만, 클라이언트의 수가 증가하면, 

그에 따른 응답을 해야하는 수도 증가하기 때문에 Polling과 큰 차이는 없게 된다. 또한. 다수의 클라이언트가 동시에 이벤트가 발생할 경우, 

서버는 각 클라이언트에게 응답을 하게 되고, 그 다수의 클라이언트는 서버에게 곧바로 요청을 하기 때문에 이 순간 서버의 부담이 커진다.

(3) Streaming 방식

Polling, Long Polling은 항상 커넥션을 연결하고, 끊는 과정을 반복했다. 그러나 Streaming 방식은 클라이언트와 서버 사이의 연결을 끊지 않고 필요한 

메세지를 계속 전달한다. 그렇기 때문에 커넥션을 맺는 과정에서 발생하는 부담이 줄어든다.

2. WebSocket 통신 방법

웹 소켓은 클라이언트와 서버간의 전이중 통신을 지원하기 위한 통신 프로토콜이다. 웹 소켓은 다음과 방식으로 동작한다.

 (1) 클라이언트와 서버간에 전이중 통신을 수행하려면 클라이언트가 서버로 HTTP UPGRADE 요청을 보내야 한다. 이를 웹 소켓 프로토콜 핸드 쉐이크라고한다.

 (2) 서버가 커넥션을 UPGRADE 할 수 있는 경우,  HTTP 101 응답을 클라이언트에게 보낸다. 서버는 핸드 쉐이크가 성공적으로 수행되었다고 판단하고,

     서버와 클라이언트 사이의 커넥션을 웹 소켓 프로토콜로 UPGRADE 한다. 클라이언트와 서버 사이의 HTTP 101 응답이 전달되는 순간, 서버와 클라이언트

     사이의 커넥션은 HTTP 프로토콜이라고 하지 않는다. 그리오 이순간 양방향 통신이 가능해진다.

 (3) 웹 소켓으로 연결된 모든 클라이언트는 다른 클라이언트에게 커넥션을 끊는 요청을 전송할 수 있다.

그림을 보면 위에서 나온 방식으로 클라이언트와 서버간의 전이중 통신을 지원한다는 것을 알 수 있다. 그러면 가운데 API GateWay는 무엇일까?!

API GateWay는 EndPoint 관리를 지원해주는 프록시 서버이다. 클라이언트로부터 수신한 메세지 내용을 바탕으로 적절한 서버를 호출한다.

그림을 보면 클라이언트는 서버와 직접적으로 연결을 맺는 것이 아닌, API GateWay를 경유해서 연결을 하고 있는 것을 볼 수 있다. 

그리고 API GateWay는 클라이언트의 종류에 따라 여러 프로토콜이 지원 가능하다.