HTTP와 WebSocket

💡클라이언트 연결 방법 비교 - HTTP vs WebSocket

WebSocket은 HTTP의 단점을 보완하여 나온것이다.

 

WebSocket도 처음 연결은 HTTP의 기반이 되는 TCP로 통신하고

그 후엔 Socket 연결로 프로토콜을 변환하는 방식을 사용한다.

 

HTTP

HTTP는 Hyper Text Transfer 즉 하이퍼 텍스트를 웹이나 앱에 출력할 수 있도록 한 통신규약이다.

 

HTTP의 특징으로는 stateless(무상태성)과 connectionless(비연결성)이 존재한다.

 

HTTP는 요청(client) 과 응답(Server)의 구조적인 특징을 가지고 있다.

또한 TCP 기반으로 만들어졌기 때문에 매 연결시 3-way-handshake 과정이 일어나기에 약간의 딜레이가 발생할 수 있다.

이로 인해 HTTP는 실시간 통신과는 어울리지 않다고 볼 수 있다.

실시간 데이터의 업데이트 주기는 예측 불허하고, 매번 요청과 응답의 구조로 통신하고, 응답 결과를 반영한다면 서버에 많은 부하를 야기시킨다.

 

HTTP는 기본적으로 양방향 통신이 불가능하다.

예를 들어 한 유저가 채팅방에 메시지를 전달했을 때 다른 채팅방은 새로운 메세지가 발생했는지 기본적으로 알수 없다.

이러한 양방향 통신을 위해 Polling 방식이나 Socket 통신 방식이 필요하다.

 

HTTP의 실시간 통신 방식

1. Polling 방식

브라우저가 일정한 주기마다 서버에 HTTP 요청을 보내는 방식이다.

단점으로는 time interval을 어떻게 잡나야 따라 서버의 부하가 올라가거나 실시간성이 떨어지는 trade off 관계를 갖는다.

 

Polling 방식은 실시간성이 조금 떨어져도 시간을 늘려 여러 대의 클라이언트를 통신할 때 사용한다.

예시로는 페이스북의 친구리스트의 온라인 상태 확인(1분 주기)를 예를 들 수 있다.

 

 

2. Long Polling 방식

Polling의 서버 부하를 줄이면서 실시간성을 높이기 위한 방식이다.

1. HTTP 요청 시 서버는 해당 연결을 바로 해제하지 않고 일정시간 대기시킨다.
   대기 시간 중 데이터가 업데이트(변경)가 일어났다면 바로 클라이언트에게 응답을 보내고 전달받은 데이터를 처리한다. 응답받은 클라이언트는 바로 서버에 다시 요청을 보낸다.
2. 브라우저의 요청이 있어도 요청한 서버의 데이터 변경이 없으면 보내지 않는다.
3. 응답이 와서 연결이 끊기면 클라이언트가 서버에 다시 요청한다.

Long Polling 방식의 단점으로는

 

여러 클라이언트와 잦은 데이터 변경이 일어나면 서버의 부담이 크다는 것이다.

 

예를 들어 수천 개의 Client와 연결된 채팅 Server에서 한 명이 채팅을 쓰면 데이터가 변경되기 때문에

Server는 변경된 데이터를 연결된 모든 Client에게 동시에 Response를 보내고, 다시 모든 Client에게 Request를 받으므로 순간적으로 Queue가 쌓여서 Server에 부담을 줄 수 있다.

 

즉, 서버의 부하도 줄이고 실시간성을 높여주지만, 대규모 클라이언트가 연결되어있고, 데이터가 자주 변경되는 경우에서는 오히려 서버에 부담감을 줄 수 있다.

 

Long Polling 방식을 사용하려면 실시간성이 필요한 적은 수의 클라이언트와 연결되어 있는 경우 사용이 가능하다.

예를 들면 1:1 채팅이나 10명 이하의 상대와 채팅하는 경우를 들 수 있다.

 

 

3. Streaming 방식

Long Polling 방식의 연결 구축에 대한 부하를 해결하는 방식이다.

서버에 연결 요청을 보내놓고 계속 응답 데이터를 다운 받는다.

이 때 서버는 이벤트가 발생하면 응답을 보낸다 (클라이언트가 서버에 데이터를 보내기 힘들다)

 

요청에 대한 응답을 완료하지 않은 상태에서 데이터를 계속 내려받는 방식이다.

따라서 응답을 받더라도 연결을 끊고 다시 request 요청을 보내는 과정이 없고 계속 응답을 받아 처리한다.

 

이로 인해, 클라이언트에서 서버로 데이터를 보내는 것이 힘들다.

따라서 실시간 양방향 통신이 아닌 실시간 단방향 통신이 주로 이루어진다.

 

WebSocket

HTTP 통신의 특징인 (연결 -> 연결 해제) 때문에 효율이 많이 떨어지게 되고, 웹 브라우저가 아닌 외부 플러그인이 항상 필요하게 되었다. 이를 해결하기 위해 2014년 HTML5에 웹 소켓을 포함하게 되었다.

 

WebSocket은 클라이언트가 접속요청을 하고 웹 서버가 응답한 후에 연결을 끊는 것이 아닌, Connection을 그대로 유지하고 클라이언트의 요청 없이도 데이터를 전송할 수 있는 프로토콜이다. 프로토콜의 요청은 ws://~ 로 시작한다.

 

HTTP 반이중(Half-Duplex) 방식이 아닌 양방향 통신인 전이중(Full-Duplex) 방식이다.

반이중 방식은 양방향 통신을 하지만 동시에 송-수신이 불가능 하고, 무전기 처럼 한쪽에서만 통신할 수 있는 방식이다.

반면, 전이중 방식의 경우에는 동시에 송-수신을 하며 양방향 통신이 가능하다.

 

이로 인해, WebSocket은 웹에서 하나의 TCP 연결을 통해 양방향 통신을 제공하는 컴퓨터 통신 프로토콜이라고 볼 수 있다.

 

 

WebSocket 특징

• 최초 접속이 일반 HTTP 요청을 이용한 HandShaking으로 이루어진다.
• TCP Socket은 바이트 스트림을 사용하지만, WebSocket은 UTF-8의 텍스트와 바이너리 둘 다 보낼 수 있다.
• 텍스트의 경우 시작과 끝에 0x00, 0xFF 를 붙여서 구분한다.
• statefull
  • 서버와 클라이언트가 한 번 연결되면 계속 같은 라인을 사용하여 통신하므로, HTTP 사용 시 불필요하게 발생되는 연결 트래픽을 방지한다.
  • WebSocket은 최초 접속을 제외하면 헤더 정보를 보내지 않지만, HTTP 프로토콜을 요청할 때마다 헤더 정보를 보내게 되므로 네트워크 비용적인 측면에서 우수하다.
• HTTP 연결을 그대로 사용하기 때문에 HTTP는 80, HTTPS는 443 포트를 그대로 사용하면서 CORS 적용, 인증-인가 등을 기존과 동일하게 이용할 수 있다.)

 

정리

HTTP를 사용하여 실시간성을 보장하기에는 서버에 많은 부하가 갈 수 있고, 실시간성을 보장하여 구현하기에는 신경써야할 부분이 많다. 이와 달리 WebSocket을 사용하면 비교적 쉽게 실시간성을 보장한 통신이 가능하다. 하지만, 큰 용량의 데이터를 많이 통신할 때에는 서버에 큰 부하를 야기할 수 있다.

 

 

본 포스트는 작성자가 공부한 내용을 바탕으로 작성한 글입니다.
잘못된 내용이 있을 시 언제든 댓글로 피드백 부탁드리겠습니다.
항상 정확한 내용을 포스팅하도록 노력하겠습니다.