http와 웹소켓 프로토콜의 정의, 차이, 왜 다르게 사용해야하는지, 어떻게 사용해야할지
🐳 http
Half-Duplex(반이중 방식): 양방향 통신을 하지만 송수신을 동시에 할 수 없고, 무전기 방식처럼 해야한다.
단방향 통신
클라이언트에서 서버로 request, 서버는 클라이언트로 response
기본적으로 무상태성임. 상태를 저장하지 않음 & 비연결성 (실시간 통신에 적합하지 않음)
---> 소켓을 사용하면 클라이언트가 요청하지 않아도 데이터가 저절로 서버로부터 온다. 즉, 별도의 요청 없이 데이터 수신이 가능하다.
ex) google docs 는 여러 사용자가 동시에 한 문서를 편집하고, 새로고침을 누르지 않아도 실시간으로 다른 사용자가 편집한 부분이 적용된다.
실시간 통신을 http로도 할 수 있을까? -> 3가지 방법으로 할 수 있기는 함
1. polling
-> 일정주기마다 서버에 계속 요청 (이벤트가 없어도 요청 , 서버와 클라이언트 부담)
그냥 지속적으로 request, response 를 받는 형식으로. 근데 업데이트 주기는 예측 불가함. 그래서 불필요한 요청에 따른 서버 부하가 늘어날 것임 (time interval을 너무 짧게 잡으면 부하가 올라가고, 너무 길게 잡으면 실시간성이 떨어진다) -> so, 실시간성이 조금 떨어져도 되는 경우에는 이렇게도 사용한다.
ex) 실시간 야구 중계같이 5~10초 주기로 계속 업데이트 / 페북 친구 리스트 온라인 상태 확인 (1분 주기)
2. long polling
-> 서버에 요청을 보내고 이벤트가 생겨 응답 받을 때까지 서버 측에서 연결을 종료하지 않는것 . 응답을 받으면 끊고 다시 재요청 (이벤트가 발생하면 연결된 모든 클라이언트에 동시에 응답보내고 연결 끊고 새로 요청을 받음-> 서버 부담)
클라이언트가 웹 서버에세 새로운 내용이 있는지 물어보았을 때 웹 서버에서 새로운 이벤트가 없다면 대답해 주지 않다가 새로운 내용이 생기면 이 때 대답해 주는 방식
불필요한 request를 없앨 수 있지만, 많은 양의 메세지가 쏟아질 경우에는 polling 과 같아진다.
대규모 클라이언트, 데이터가 자주 변경되는 경우에는 적합하지 않다
ex) 1:1 채팅, 10명 이하의 상대와의 채팅
3. streaming
-> 서버에 연결 요청을 보내놓고, 응답 데이터를 계속 다운받는다. 서버는 이벤트가 발생하면 응답을 보낸다. (클라이언트가 서버에 데이터를 보내기가 힘들다.)
서버에 요청 보내고 끊기지 않은 연결상태에서 끊임없이 데이터를 수신한다.
🐳 웹소켓
Full-Duplex(전이중 방식): 동시에 송수신을 하며 양방향 통신을 할 수 있다.
클라이언트와 서버를 연결하고 실시간으로 통신이 가능하도록 하는 통신 프로토콜.
socket connection을 유지한채로 실시간 양방향 통신 or 데이터 전송이 가능한 프로토콜이다.
ex) 채팅, 화상회의, 구글 docs ...
특징
- 최초 접속이 일반 http 요청을 이용한 handshaking으로 이루어진다.
- 유연성 : http 요청을 그대로 사용하므로 80,443 포트를 그대로 사용하기때문에 대부분의 방화벽 및 프록시 서버에서 차단되지 않음. http 규격인 cors 적용, 인증 등을 기존과 동일하게 이용할 수 있다.
- 상태 프로토콜이기때문에, 클라이언트와 서버가 한 번 연결되면 그 연결을 이용해서 통신하기 때문에 , http 사용시 필요없이 발생되는 http,tcp 연결 트래픽, 커넥션 비용을 아낄 수 있다.
- 지속적인 연결을 통해 데이터를 교환할때 발생하는 오버헤드가 줄어든다.
- 서버에서 클라이언트로 직접 푸시 : 클라이언트가 지속적으로 서버에 폴링을 하지 않아도 되므로, 리소스 사용을 최소화
작동원리
- 웹소켓 연결을 위한 http 통신
- handshake 과정이 성공적으로 이루어지면 http -> web socket 프로토콜로 변경 (프로토콜 스위칭)
