WebSocket, HTTP

WebSocket

WebSocket 프로토콜은 클라이언트와 서버가 전이중 채널에서 통신하는 방법을 설명한다. 즉, 클라이언트와 서버 모두 오랫동안 지속되는 연결을 통해 동시에 데이터를 보내고 받을 수 있다. 이러한 유형의 통신은 HTTP 폴링보다 오버헤드가 적기 때문에 애플리케이션에 실시간 기능에 대한 여러 이점을 제공한다.

 

• 전이중 채널은 양방향 통신이 동시에 가능한 통신 방식으로, 송신과 수신을 동시에 할 수 있는 채널을 의미한다.

 

 

WebSocket 장점

양방향 통신

 

연결된 양쪽에서 언제든지 메시지를 보낼 수 있다.

WebSocket 서버가 대화를 조정하는 경우, 클라이언트는 서버에 메시지를 보낸 다음 연결된 다른 모든 클라이언트에 즉시 이를 전달한다. 사용자는 실시간으로 서로에게 메시지를 보낼 수 있다.

 

 

짧은 대기 시간

 

HTTP 통신의 일반적인 패턴은 polling으로 클라이언트는 주기적으로 새 서버 데이터를 요청한다.

이 통신 방법의 가장 큰 단점은 대기 시간이다. 빈번하거나 장기간 실행되는 요청과 높은 대기 시간 사이에서 절충해야 한다. WebSocket 통신을 사용하면 데이터가 즉시 전송된다. 클라이언트는 계속 요청할 필요가 없고 오버헤드와 네트워크 트래픽이 최소화되어 대기 시간이 단축된다.

 

 

지속적인 연결

전통적인 HTTP 연결에서는 클라이언트가 요청을 하고 서버가 응답을 보낸 후 연결이 닫힌다. 클라이언트에 더 많은 데이터가 필요한 경우 새 연결을 열어야 한다.

 

WebSocket 연결을 사용하면 클라이언트는 서버와의 모든 WebSocket 통신에 대해 단일 연결을 열고 사용할 수 있다. 이 지속적인 연결을 통해 지연 시간이 짧은 양방향 메시지가 가능하다.

 

WebSocket 연결은 상태 저장일 수도 있다. WebSocket은 지속적인 연결 덕분에 상태를 유지한다.

HTTP 연결은 상태 비저장이다. 즉, 각 요청은 이전 요청에 대한 정보를 유지하지 않고 개별적으로 처리된다.

---

HTTP

HTTP 프로토콜은 요청-응답 프로토콜로 설계되었다. 브라우저와 같은 클라이언트는 웹 서버에 요청을 보내고 웹 서버는 HTML 및 CSS 파일과 같이 요청에 해당하는 리소스가 포함되어 있다. HTTP 연결이 열려 있는 동안에는 반이중만 가능하다. 즉, 통신은 단방향으로만 진행되고 응답을 받으면 연결이 종료된다.

 

HTTP/1.1에는 TCP/IP 연결을 재사용하는 영구 연결이 도입되어 일부 성능이 향상되었다. 그러나 이러한 영구 연결의 세부 사항은 서버마다 다르며 대부분의 경우 비활성 시간 초과에 따라 결국 닫힌다. 그러나 WebSocket 연결과 직접 비교할 수 있을 정도의 기능은 아니다.

 

 

 

HTTP 장점

단순성과 편재성

HTTP 연결의 지속력은 광범위한 채택과 간단한 접근성에서 비롯된다. HTTP의 세 가지 주요 버전(HTTP/1.1. HTTP/2.  HTTP/3.) 사이에서 거의 모든 웹 서버와 웹 브라우저는 어떤 형태로든 프로토콜을 활용할 수 있다.

 

 

상태 비저장 특성 및 캐싱 지원

HTTP 요청은 상태가 없고 독립적이기 때문에 특히 정적 콘텐츠와 자산을 처리할 때 응답을 캐싱하면 성능이 향상될 수 있다.

 

WebSocket 메시지는 상태가 저장되어 있고 일반적으로 상황에 민감하기 때문에 HTTP 응답만큼 쉽게 캐시 할 수 없다. 이러한 메시지는 대부분의 경우 캐싱이 도움이 되기에는 너무 자주 변경된다.

 

 

HTTP에서 실시간 통신을 하는 방법

Polling

 

Polling은 웹 브라우저가 주기적으로 서버에게 이벤트가 발생했는지 확인하는 방식이다. 만일 이벤트가 발생하지 않았다면 응답에는 이벤트 정보가 포함되지 않고, 반대로 이벤트가 발생했다면 포함되는 방식이다.

 

다만 주기적으로 서버에게 이벤트 발생 여부를 확인하는 방식이므로 실시간성이 떨어지는 단점이 있으며, 주기적인 요청/응답이 오가기 때문에 계속 트래픽이 발생한다는 문제가 있다​.

 

 

Long Polling

 

Long Polling은 기존 Polling의 실시간성을 보완한 기법이다. 웹 브라우저가 요청을 전송할 때 이벤트가 발생하기 전까지 응답을 보내지 않고, 이벤트가 발생할 때만 응답을 이벤트 정보와 함께 보내는 방식이다.

 

이 방법은 실시간성을 보완한 좋은 방식이지만, 서버의 이벤트가 자주 발생하지 않는 환경에서 이용하는 것이 좋다. 서버의 이벤트가 자주 발생하면 비효율적인 트래픽이 발생할 수 있다​.

 

 

Server-Sent Events (SSE)

 

 

Server-Sent Events (SSE)는 클라이언트가 서버와 지속적인 연결을 설정하고 서버가 클라이언트로 이벤트를 전송하는 방식이다. 클라이언트는 하나의 HTTP 연결을 통해 지속적으로 데이터를 받을 수 있다.

---

출처

WebSocket 대 HTTP 통신 프로토콜: 개발자에게 있어 차이점은 무엇인가? | Sendbird

WebSocket 대 HTTP 통신 프로토콜: 개발자에게 있어 차이점은 무엇인가?

실시간 웹 통신의 핵심: WebSocket과 HTTP의 차이점 (tistory.com)

실시간 웹 통신의 핵심: WebSocket과 HTTP의 차이점

[http vs WebSocket] http 통신과 WebSocket의 장단점 (velog.io)

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

웹소켓과 HTTP Polling에 대해 알아보자! (haon.blog)

웹소켓과 HTTP Polling 에 대해 알아보자!

Understanding Short Polling, Long Polling, Server Sent Events and Web Sockets - DEV Community

Understanding Short Polling, Long Polling, Server Sent Events and Web Sockets