2021-09-22 실시간 네트워킹 (HTTP vs Websocket)

1. HTTP의 한계

HTTP는 connectionless : 클라이언트가 요청을 하고 서버가 응답을 하면 연결이 끊긴다. 이는 서버가 다수 클라이언트와 연결을 유지하면서 발생하는 리소스 낭비를 막기 위해서이다.

→ 하지만 다음과 같은 문제 발생

  (1) 요청 보낼 때마다 페이지 리로딩됨

  (2) 동일한 요청에 중복된 헤더 파일을 전송한다.

  (3) 실시간 상호작용성이 떨어진다. (오늘의 주제!)

 

 

2. Polling 방식

- 클라이언트가 HTTP request를 서버에 계속 날리는 방법

- 가장 간단하지만 서버의 부담이 크다.

- 실시간 정도의 빠른 응답을 기대하기도 힘들다.

 

 

3. Long Polling 방식

- 클라이언트가 서버로 HTTP request를 전송한 후 서버가 해당 클라이언트에 응답할 내용이 생기면 response를 보내면서 연결이 종료된다.

- 연결이 종료되자마자 클라이언트는 다시 request를 보낸다.

- 이벤트가 자주 발생하거나 여러 클라이언트의 이벤트가 동시에 발생하는 경우 서버의 부담이 급증한다.

 

 

4. Streaming 방식

- 클라이언트가 서버로 HTTP request를 전송하면 연결 상태를 유지한 채 서버가 끊임없이 response를 제공한다. (trickle out)

- 하나의 TCP 포트로 읽기와 쓰기를 동시에 할 수 없기 때문에 클라이언트 측에서 서버로 메시지를 전송할 수 없다.

 

 

※ Long polling 방식과 Streaming 방식을 HTTP Comet 방식이라고도 부른다. 이러한 꼼수들은 TCP 연결 과정에서 오버헤드가 크게 발생한다.

 

 

5. 웹소켓 (Websocket)

- HTTP를 기반으로 하면서 HTTP의 실시간 처리능력 문제를 해결하기 위해 등장한 프로토콜

- 서버와 클라이언트 사이의 소켓 연결을 통해 양방향 통신이 가능하다.

- Statefull : HTTP의 stateless 성질과 다르게 웹소켓에서 서버는 클라이언트의 상태를 알 수 있다. 

- 웹소켓을 통해 전송되는 텍스트들은 UTF-8 포멧을 가진다.

- HTTP request를 그대로 사용하기 때문에 CORS적용, 인증 등의 과정을 동일하게 적용한다.

- 작동원리

  (1) 일반 HTTP request를 통해 hand shaking 과정을 거친다.

  (2) HTTP를 웹소켓 프로토콜로 변경하는 protocol switching 과정이 일어난다.

  (3) 웹소켓을 위해 만들어진 새로운 소켓을 활용하여 양방향 통신을 진행한다.

- 서버-클라이언트의 웹소켓 연결을 유지하기 위해 비용이 많이 발생한다. (트래픽이 많은 서버의 경우 CPU에 무리가 갈 수 있다.)