[http vs WebSocket] http 통신과 WebSocket의 장단점

JeBread·2024년 2월 21일

HTTP 프로토콜 통신 도 결국 소켓 통신을 기반으로 한다. TCP 프로토콜 계층 위에 존재하는(응용 계층) HTTP 또한 소켓 통신을 기반으로 하고, IP와 Port 번호 등이 존재하는 TCP/IP 헤더들이 붙여져 메시지가 송수신된다.

다만 둘을 구분하는 이유는 HTTP 프로토콜 통신의 경우 한쪽에서만 요청에 대한 응답을 하는 웹 통신에 특화되어있기에, 또는 이러한 통신을 위해 일반적인 소켓 통신 매커니즘과 다르기 때문에 구분하는 것이다.

HTTP 프로토콜 통신과 WebSocket

HTTP 프로토콜 통신

기존에는 HTML 파일을 전송하는 프로토콜의 의미를 가졌다(Hyper Text Transfer Protocol). 웹 브라우저에서의 통신은 초기 대부분 HTML 파일을 전송하는 목적이였기 때문이다.
현재는 JSON, Image 등 다양한 형식의 파일들을 전송할 수 있다.

HTTP 통신은 클라이언트에서 서버로 요청을 보내고, 서버가 이에 응답하는 방식으로 통신이 이루어진다. 여기서 응답은 클라이언트의 요청에 따른 결과를 반환한 것이다.

"클라이언트의 요청이 있을 때 서버가 응답하는 방식, 단방향 통신"

서버의 응답에는 응답 코드(202, 404 ..)가 같이 전송되며, 사용자는 응답 코드와 메시지 응답으로부터 오는 메시지 바디를 통해 요청 값을 전달받는다.

초기, 서버는 응답한 후 클라이언트와 연결이 바로 끊어졌으나(HTTP 프로토콜의 '무연결성'), 최근에는 성능상 이유로 'Keep Alive' 옵션을 통해 일정 기간동안 클라이언트와 연결을 유지하는 방식이 도입되기도 한다.

WebSocket(웹소켓)이란 ?

웹소켓(Web Socket) 프로토콜은 HTTP와는 다른 통신 프로토콜로 웹 서버와 웹 브라우저가 서로 실시간 메시지를 교환하는 데에 사용된다. 웹소켓 연결을 맺기 위한 첫 번째 핸드셰이크를 주고받은 이후 지속적으로 연결이 유지되는 것이 특징이며, 매번 메시지 전송 시에 새롭게 연결을 맺을 필요가 없어 빠르고 효율적이다.

웹소켓은 TCP 소켓과 이름만 유사할 뿐 브라우저의 소켓이며, 웹소켓 프로토콜은 HTTP 와 동일하게 애플리케이션 계층에서 동작한다. 그리고 평문 메시지 전송 방식이므로, SSL/TLS 보안 계층으로 암호화되어야 데이터 탈취를 방지할 수 있다.

출처: https://yozm.wishket.com/magazine/detail/1911/ [웹소켓으로 개발하기 전 알아야 할 것들 | 요즘IT]

HTTP에서 실시간 통신을 하려면?

Polling
Long Polling
Streaming

1. Polling

브라우저가 일정한 주기마다 서버에 HTTP 요청을 보내는 방식이다. 서버 쪽 데이터 업데이트 주기는 클라이언트 쪽에선 예측 불가능하므로 불필요한 요청이 있을 수 있고 이는 서버 및 네트워크 부하를 늘리는 악영향이 될 수 있다.
ex) 실시간 야구 문자 중계는 10초 주기로 업데이트

주기(interval)가 짧을 수록 실시간성은 높아지지만 서버 및 네트워크 부하가 높아지는 trade-off가 발생한다.
실시간성이 조금 떨어지더래도 주기를 늘려 여러 대의 클라이언트와 통신할 때 사용하는 방식이다.
ex) 페북 친구 리스트의 온라인 상태 확인, 약 1분 주기

2. Long Polling

polling 방식의 단점인 서버 부하를 줄이면서 실시간성을 높이기 위한 방식이다. HTTP 요청이 서버로 들어올 때 Polling 방식과 달리 요청에 대한 응답을 보내고 연결을 바로 끊는 것(stateless 방식)이 아닌 일정시간 대기한다. 이 대기 시간 중 데이터 업데이트(변경)이 일어났으면 바로 클라이언트에 응답을 보낸다. 응답을 받은 클라이언트는 바로 서버에 다시 요청을 보낸다.

수 많은 클라이언트와 연결된 채팅방을 가정해보면, 한 명이 채팅을 쓰면 데이터가 변경되고, 서버는 변경된 데이터를 연결된 모든 클라이언트에 동시다발적으로 응답을 보내게 될 것이다. 그리고 수 많은 클라이언트들은 응답을 받은 후 다시 요청을 동시다발적으로 서버에 보낼 것이다.
이러한 과정에서는 트래픽이 일시적으로 몰리는 경우가 발생하고, 서버 쪽의 요청 Queue가 쌓여 부담이 될 수 있다.

Long Polling 방식은 서버의 부하를 줄이면서 실시간성을 높여주는 장점이 있지만 (1)비교적 많은 클라이언트와의 연결, (2)데이터 변경 빈번한 경우 오히려 서버에 부담을 줄 수 있다.

따라서 실시간성이 필요한 적은 수의 클라이언트와 연결되어있는 경우 사용하는 것이 좋다.
ex) 웹 1:1 채팅, 10명 이하의 단체 채팅

3. Streaming 방식

(Long)Polling 방식에서는 서버로부터 응답을 받으면 클라이언트가 곧바로 재차 요청을 보내는 방식을 사용함으로써 실시간성을 유지한다. 이 방식에서는 HTTP의 Stateless 특성에 의해 재연결 오버헤드가 커지게 된다.

스트리밍 방식에서는 서버는 요청을 받으면 요청에 대한 응답을 완료하지 않은 상태에서 데이터를 계속 보내도록 한다. 따라서 클라이언트는 응답을 받더라도 연결을 끊고 다시 요청을 보내는 과정없이 계속 응답을 받아 처리한다.
서버는 무한정 혹은 일정 시간동안 요청을 대기시키고, chuncked 메시지를 이용하여 연결을 계속 유지하는 방식이다.

이 문제의 단점은 클라이언트에서 서버로 데이터를 보내는 것이 힘들다는 점이다. 실시간 양방향 통신이 아닌 실시간 단방향 통신과 가깝다.

정리

Polling
- 일정주기마다 서버에 요청
- 이벤트가 없어도(데이터 변경이 없어도) 요청이 이루어지기에 서버, 클라이언트 둘다 부담
Long Polling
- 서버가 요청을 받으면 바로 응답을 보내는 것이 아니라 이벤트가 발생하면 응답을 보낸다.
- 전체적인 요청/응답량이 줄어들지만 수 많은 클라이언트와 연결되어 있고, 이벤트 발생(데이터 변경)이 빈번하다면 오히려 서버 쪽에서 부담이 될 수 있다.
Streaming
- 서버가 요청을 받으면, 요청에 대한 응답을 완료하지 않은 상태에서 계속해서 데이터를 클라이언트 쪽으로 보낸다.
- 클라이언트 쪽에서 서버에 데이터를 보내기 힘들다는 단점이 있다.

웹소켓 vs HTTP : 실시간성에서 어떤기법이 더 유리한가?

HTTP 방식과의 차이점을 다시 간단히 짚고 넘어갈 필요가 있습니다. 정리해보자자면 아래와 같습니다.

HTTP

비 연결성(Connection less)

매번 연결을 맺고 끊는 과정의 비용이 많이듭니다.

Request - Response 의 구조를 지닙니다.

Web Socket

연결지향적인 특징을 지닙니다.

한번 연결을 맺은 뒤 계속 유지되는 실시간성을 보장합니다.

양방향 통신이라는 특징을 지닙니다.

1) HTTP는 클라이언트가 원하는 어떤 결과를 얻고자한다면 항상 서버에 요청을 보내야하지만, 웹소켓은 연결이 계속 유지되고 있는 상태이므로 클라이언트가 보낸 메시지를 서버는 그냥 듣고있기만 하면 됩니다.
2) HTTP 에 비해 웹소켓이 보내야하는 메시지, 데이터 양이 훨씬 적습니다.
HTTP 요청을 보낼시 Request URL, 상태코드, Request&Response 헤더와 바디, .. 등의 데이터 양이 매번 요청으로 만들어져서 서버로 보내진다면 실시간성을 요구하는 서비스에서는 꽤 큰 부담이 생길것입니다.
3) 웹 소켓을 사용할때 처음 HandShake를 하는 과정은 HTTP 프로토콜을 통해 진행하겠지만, 한번 연결이 수립된 후로는 간단한 메시지만 오가는 방식입니다.