HTTP와 WebSocket
이 기사는 HTTP와 WebSocket 프로토콜을 비교하여 주요 차이점, 기능 및 이상적인 사용 사례를 설명합니다. HTTP의 요청-응답 모델과 WebSocket의 실시간, 양방향 통신 기능을 대조하여 웹 애플리케이션에 적합한 프로토콜을 선택하는 데 필요한 중요한 개발자 통찰력을 제공합니다.
Developer
디지털 세계 전체의 기초는 기계 간의 통신입니다. 권한이 부여된 클라이언트가 요청을 생성하면 서버가 이를 수신하고 해석하여 적절한 응답을 제공합니다. 이는 일반인이 이해하는 디지털 통신의 공통적인 이해입니다. 그러나 이면의 작업은 복잡하고 지루합니다.
애플리케이션 개발자는 이 클라이언트-서버 통신이 제대로 작동하도록 보장하기 위해 많은 작업을 수행해야 합니다. 적절한 통신 프로토콜을 선택하는 것이 이러한 작업 중 하나입니다. 개발자가 실행 가능한 통신 프로토콜을 선택하려고 할 때, HTTP와 WebSocket은 흔히 접하게 되는 두 가지 개념입니다.
이 둘을 명확히 하여, 그 유사점, 기능 및 기타 측면을 이해하여 실제 필요에 따라 올바른 옵션을 선택하는 것이 중요합니다.
HTTP 소개
먼저 HTTP를 이해해봅시다. 아마 디지털 통신 분야에서 가장 많이 사용되는 프로토콜일 것입니다. HTTP의 초기 버전은 1989년에 출시되었으며 기능과 적용 범위가 제한적이었습니다. 그러나 브라우저와 서버 간의 대규모 통신을 지원하도록 빠르게 개선되고 업그레이드되었습니다.
HTTP는 단방향 프로토콜로, 주어진 시간에 통신 중 한 쪽만 정보를 보내거나 받을 수 있습니다. 클라이언트가 서버에 요청을 전송할 때, 이 요청은 HTTP 또는 HTTPS 형태로 전송되며 서버는 요청을 수신한 후 클라이언트에 고유한 응답을 전송합니다. 각 HTTP 또는 HTTPS 요청은 서버와 새 연결을 설정하고 응답을 수신한 후 자동으로 연결을 종료합니다.
HTTP의 주요 특징으로는 다음과 같은 것들이 있습니다:
- 무상태
- 연결 지향 프로토콜(SCTP 및 TCP 등)을 기반으로 작동할 수 있음
- 정보는 ASCII로 인코딩됨
- HTTP 요청의 주요 구성 요소에는 HTTP 버전(HTTP/1.1, HTTP/2, HTTP/3), 메서드, HTTP 헤더, 호스트 정보 및 메시지가 포함됨
WebSocket이란?
WebSocket은 클라이언트와 서버 간의 실시간 양방향 통신을 구현할 수 있는 통신 프로토콜입니다.
WebSocket은 웹 애플리케이션에서 실시간 양방향 통신 채널을 생성하기 위한 프로토콜입니다. 전통적인 HTTP 요청(일반적으로 하나의 요청은 하나의 응답에 해당함)과 달리, WebSocket은 지속적인 연결을 설정할 수 있으며 서버가 데이터를 클라이언트에 실시간으로 푸시하고 클라이언트로부터 데이터를 수신할 수 있습니다. 전통적인 폴링과 비교하여 WebSocket은 네트워크 트래픽과 대기 시간을 크게 줄여 데이터 전송의 효율성과 속도를 향상시킵니다. 이는 특히 실시간 웹 애플리케이션 및 온라인 게임 개발에 적합합니다.
WebSocket의 주요 특징으로는 다음과 같은 것들이 있습니다:
- 클라이언트 또는 서버가 종료 요청을 시작할 때까지 열려 있는 지속적인 TCP 연결 기반
- HTTP 프로토콜을 기반으로 구축되며, 모든 WebSocket 요청은 표준 HTTP 프로토콜을 통해 전송된 후 서버 측에서 특정 헤더 정보 업그레이드로 식별됨
- WebSocket 프로토콜은 프레임(데이터 패킷)을 기반으로 하며, 완전한 데이터 패킷은 여러 프레임으로 분할될 수 있으며 각 프레임에는 데이터의 일부와 헤더 정보가 포함됨
HTTP와 WebSocket의 관 계
위의 소개에서 볼 수 있듯이, HTTP와 WebSocket 프로토콜 모두:
- 데이터 전송을 위해 TCP 프로토콜을 사용
- 클라이언트와 서버 간의 통신에 사용됨
다음 표를 통해 HTTP와 WebSocket 간의 차이점을 보다 직관적으로 보여줄 수 있습니다.
| HTTP | WebSocket |
|---|---|
| 각 요청에 대해 새로운 연결을 설정하며(HTTP 연장 연결을 사용하지 않는 한, 예: HTTP/1.1 Keep-Alive), 통신이 끝나면 연결을 닫음 | 첫 번째 핸드셰이크가 성공하면, 연결은 적극적으로 닫히거나 오류가 발생하지 않는 한 계속 열려 있음 |
| 단방향 통신 모드로, 클라이언트가 요청을 보내고 서버가 응답을 반환하며, 각 새로운 통신은 연결을 다시 설정해야 함 | 양방향 통신 모드로, 연결을 설정한 후 클라이언트와 서버는 다시 연결을 설정하지 않고 언제든지 데이터를 보낼 수 있음 |
| 각 통신은 완전한 요청 및 응답 헤더를 보내야 하므로, 작은 메시지 통신이 빈번할 경우 오버헤드가 큼 | 연결이 설정되면, 데이터 전송이 가벼워져서 매번 헤더 정보를 전송할 필요가 없어, 고빈도, 저지연 통신 요구에 적합함 |
| 비교적 안정적인 데이터 전송에 주로 사용됨 | 실시간 데이터 전송에 주로 사용됨 |
| 각 요청마다 연결을 다시 설정하고 헤더 등을 통해 필요한 정보를 휴대해야 하므로 대역폭 사용 효율과 응답 속도가 영향받음 | 연속된 연결은 각 요청마다 연결 및 필요한 정보의 단계를 제거하여 지연 시간이 줄고 대역폭 사용 효율이 향상됨 |
| 빈번한 요청은 성능에 영향을 줌 | 빈번한 요청은 성능에 영향을 미치지 않음 |
어떤 프로토콜을 사용할지 선택하는 방법?
이전 섹션에서 HTTP와 WebSocket의 장단점을 비교한 것을 바탕으로, 두 가지 다른 차원에서 사용 시나리오를 평가할 수 있습니다:
- 데이터가 빠르게 변경되는지 여부와 비즈니스가 실시간 데이터에 의존하는지 여부
- 빈번한 양방향 통신이 포함되는지 여부
예를 들어, Jack이 각 사용자가 채팅 파트너로부터 실시간 비디오 데이터를 받고 자신의 비디오 스트림 데이터를 상대방에게 전송해야 하는 비디오 채팅 애플리케이션을 만들고 싶다면, WebSocket이 최선의 선택입니다.
Logto의 관리 콘솔은 현재 로그인한 사용자의 리소스 사용량을 자주 획득할 필요가 없습니다. 리소스는 사용자가 구성을 수정할 때만 상태가 변경됩니다. 사용자가 리소스를 조작할 때 적시에 리소스 상태를 다시 획득하면 됩니다. 이 관점에서 HTTP는 Logto 관리 콘솔의 사용 시나리오에 매우 적합합니다. 비슷하게, 대부분의 클라우드 서비스 대시보드에 대해서도, HTTP를 대시보드와 서버 간의 통신 프로토콜로 선택할 수 있습니다.