WebSocket과 Socket, 모두 통신 프로토콜이고 비슷해 보이지만 엄연히 다른 개념이다.
socket 자체는 two-way 네트워크 연결의 엔드포인트, 연결부의 의미를 지닌다. 소켓은 클라이언트-서버 통신, P2P, 실시간 데이터 전송에 일반적으로 사용되고 TCP, UDP를 사용한다. 계층적으로는 전송 계층 위에 존재한다.
WebSocket는 HTTP에 기반한 브라우저와 서버 사이에 양방향 인터렉티브한 통신을 위한 프로토콜이다. 지속적인 TCP 연결을 통해 빈번한 폴링 없이 클라이언트, 서버간 양방향 실시간 통신을 가능하게 한다. 온라인게임, 채팅 어플리케이션, 금융 거래 플랫폼과 같이 낮은 지연 시간, 고 처리량 통신이 필요한 어플리케이션에 사용될 수 있다.
웹소켓과 HTTP 연결과의 차이점
딥하게 들어가면 HTTP통신 또한 소켓 통신의 일종이다.
소켓 자체가 의미하는 것이 포트넘버와 IP주소를 통한 엔드포인트를 의미하는데 HTTP에서 또한 이것들을 이용하기 때문이다.
그럼에도 이 둘을 구분하는 이유는 다르기 때문이다. (당연한..?)
1) 지속성
웹 소켓은 클라이언트와 서버와의 연결이 지속되는 'stateful protocol' 상태 프로토콜로 동작한다.
각각의 요청이 독립적이지 않다.
연결을 시작하게 되면 클라이언트와 서버는 handshake 이후 새로운 연결을 만들어 내고 이것이 끊어 지지 않는 이상 계속 이 연결을 통해 양방향으로 지속적으로 메시지, 데이터를 주고 받을 수 있게 된다. 클라이언트 쪽이나 서버쪽에서 연결을 끊지 않는 이상 연결이 지속된다. 한 쪽에서 끊으면 양쪽 다 끊어지게 된다.
그렇기 때문에 채팅, 트레이딩과 같은 리얼 타임 어플리케이션에 잘 어울린다.
HTTP의 경우 'stateless protocol' 무상태 프로토콜로 동작한다.
각각의 요청이 독립적이다.
요청을 하고 응답을 받으면, 새롭게 연결을 시작해야 한다. 기존의 연결상태를 유지하지 않는 것.
그런데 여기서 궁금했던 점이 HTTP의 경우 1.1이 되면서 Connection: Keep-alive 속성을 이용하여 연결을 지속할 수 있다고 알고 있었다. HTTP에서도 연결을 지속하고 그 연결 안에서 데이터를 주고 받을 수 있다면 socket이 딱히 실시간 어플리케이션에 더 좋을 이유가 있나? 라고 생각했다. 그 답은 아래 duplex에 있었다.
2) full-duplex / half-duplex
웹 소켓의 경우 full-duplex, HTTP의 경우 Half-duplex 방식이었다.
두개의 디바이스 모두에서 데이터 송신과, 동시에 수신도 가능한 방식이 full-deplex이고,
한 쪽에서만 송신과, 송신에 따른 응답을 수신하는 half-duplex방식이었던 것 !
참고사이트
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API
https://medium.com/kifi-engineering/websockets-vs-regular-sockets-b3b8e7ea0708
https://www.comms-express.com/infozone/article/half-full-duplex/
https://ipwithease.com/web-socket-vs-http/
'Frontend Study - 1 > Socket' 카테고리의 다른 글
| Socket에 대하여! Socket의 정의와 생성과정 (0) | 2023.02.17 |
|---|
