우리는 웹소켓 프로토콜을 통해 실시간 양방향 통신을 구현할 예정
How about HTTP Polling?
polling = 하나의 프로그램이 다른 프로그램(혹은 장치)의 상태를 주기적으로 검사하여 일정 조건을 만족하면 자료를 처리하는 개념
메시지를 원하는 클라이언트는 서버에게 일정 주기로 계속 Request를 전송
서버 입장에서 클라이언트가 원하는 이벤트가 준비되었다면(도착했다면) HTTP Response 형태로 이를 반환해주고, 그렇지 않다면 요청은 실패
but,
네트워크 리소스 많이 잡아먹음
오버헤드를 줄이기 위해 전송 주기 T를 길게 하면 실시간성이 떨어짐
cf) long polling = 요청 횟수에 따라 서버 부담이 급증하는 Polling 방식을 개선하기 위해 등장
* 구체적으로는, 만약 전송할 데이터가 없다면 일단 커넥션을 열어 둔 채로 기다리다가 데이터가 준비되는 순간 응답을 되돌려 줄 수 있기에 일반 Polling 보다는 실시간성을 보장
How about Server-Sent Events?
서버로부터 일방적으로 데이터를 수신
HTTP 프로토콜의 특징 중에는 무상태성(Stateless) 존재 => SSE에서는 HTTP 헤더의 keep alive와 자체 error recovery 전략을 활용해 연결을 지속하기 때문
cf) HTTP/2부터는 Multiplexing(하나의 HTTP connection에서 여러 요청을 처리하는 것)이 가능하기에 별도의 추가 설정 없이 한 번의 Handshake만으로도 지속적인 데이터 수신이 가능
but,
클라이언트가 서버에게 데이터를 보낼 수 없는 단방향 통신이다
Then, what's websocket?
하나의 TCP 커넥션에서 실시간 전이중 통신을 지원하는 프로토콜
TCP/IP 기반 네트워크 통신 계층은 위와 같다
TCP connection = transport layer = 상대방과의 통신 위해 종단 간 연결 수립할 때
websocket은 이런 tcp connection을 쉽게 해준다 (wrapper)
웹소켓의 통신 방식은
- 최초 접속 시 일반 HTTP 요청을 통해 Handshaking 진행
- HTTP connection이 생성된 후 프로토콜 스위치 요청을 통해 WebSocket 요청을 처리하는 소켓 생성
- Stateful한 해당 connection 내에서 WebSocket 프로토콜(ws://)을 통해 데이터 송수신
새롭게 http 프로토콜 연결이 찍히지 않고, 하나의 websocket connection 안에서만 데이터 송수신 됨
therefore,
실시간성, 양방향성을 충분히 만족하기에 실시간 채팅 서비스 뿐만 아니라 라이브 스트리밍 등에도 널리 사용
but,
http가 아닌 별도의 프로토콜을 사용하기에 추가적인 웹 서버가 필요함
순수 데이터(binary data)를 주고받기 때문에 어플리케이션 차원에서 처리해야 할 게 많아짐 (json 포맷으로 통일되어있지 않음)
별도의 웹 서버가 필요하다 => Django + React 조합으로 테스팅해봅시다
'web > snulion' 카테고리의 다른 글
실시간 채팅 구현에 대해 araboza (0) | 2024.11.02 |
---|---|
WAS, WSGI, ASGI에 대해 araboza (0) | 2024.11.02 |
카카오페이를 이용한 간편결제에 대해 araboza (6) | 2024.10.05 |
상태관리에 대해 araboza (2) (1) | 2024.10.05 |
상태관리에 대해 araboza (1) | 2024.09.25 |