정의
클라이언트와 서버(== 브라우저[웹]와 서버)를 연결하고 실시간으로 통신이 가능하도록 하는 첨단 통신 프로토콜입니다. 하나의 TCP 접속에 전이중(duplex) 통신 채널을 제공합니다.
Duplex : 송수신이 양방향으로 가능하고, 동시에 송수신이 가능한 통신 방식
즉, 웹소켓은 소켓 연결을 유지한 채로 실시간으로 양방향 통신 or 데이터 전송이 가능한 프로토콜
Protocol : (통신 프토토콜) : 컴퓨터나 원거리 통신 장비 사이에서 메시지를 주고 받는 양식과 규칙의 체계
등장 배경
인터넷의 등장 후,
기존의 HTTP를 통한 통신은 단방향이었습니다.
단방향이라는 말은, 서버로부터 데이터를 가져오기 위해서는 오직 클라이언트가 서버로 요청을 보내는 경우에만 서버에서 클라이언트 측에 응답을 보내주어 데이터를 보내준다는 것을 의미합니다.
아주 예전에는 오로지 URL을 통해서만 요청을 하였습니다.
시간이 지남에 따라, 여기서 발전된 방식인 Ajax 통신으로 클라이언트가 XMLHttpRequest 객체를 이용해 서버에 요청을 보내고 응답을 받아오게 되었습니다. Ajax 통신을 통해서 페이지 전체를 요청하는게 아니라 데이터 요청을 이용해 부분적으로 정보를 업데이트 할 수 있게 되었습니다.
하지만 결국 Ajax 또한 HTTP를 이용하기 때문에 요청을 보내는 경우에만 응답이 온다는 단점이 존재했고
이러한 단점을 해소하고자 웹소켓이 등장하게 되었습니다.
어떤 경우에 HTTP 통신이 불편함을 초래할까요?
•
웹에서 노션이나 피그마에 여러 사용자가 동시 접속한 경우, 새로 고침을 하지 않더라도(== 클라이언트가 요청을 보내지 않아도) 실시간으로 본인 외의 다른 유저가 편집한 부분이 자동으로 적용되는 경우
◦
만약 HTTP 이라면, 한 유저가 편집을 하면, 다시 새로고침을 해야만 그 편집이 다른 편집자에게 보일 수 있습니다.
•
주가 정보를 실시간으로 확인 할 수 없습니다.
◦
우리가 주가 어플을 사용할 때, 새로고침을 하지 않더라도 실시간으로 오르내리는 주가를 확인 할 수 있습니다.
▪
만약 HTTP 이라면, 1초마다 순식간에 바뀌는 주가를 유저가 직접 새로고침 해야만 주가 변동을 확인 가능해집니다.
참고로,
HTTP는 Stateless Protocol입니다.
이와 달리, Web Socket은 Stateful Protocol입니다.
그리고 2014년, HTML5에 웹 소켓을 포함하게 되었다고 합니다.
그렇다는 건, HTML 문서에서 웹 소켓을 다룰 수 있다는 말이겠죠?
프로토콜 요청은 [ws://…..] 방식으로 한다고 합니다.
저는 socket.io를 이용하므로 저 방식을 사용하지는 않을 것 같습니다..
동작 원리
HTTP를 통해 서버와 클라이언트간의 웹 소켓 연결이 이뤄집니다.
?? HTTP 통신을 벗어나려고 웹 소켓 통신을 만든거 아닌가요??
잠시, 두 프로토콜의 통신 방식의 약간의 차이점을 알아보도록 합시다.
웹소켓의 통신 방식
웹 소켓은 핸드셰이크를 이용해 연결을 맺습니다.
이때, HTTP Upgrade Header를 이용해 HTTP에서 Web Socket Protocol로 변경하는 겁니다.
일정 시간 후엔 자동으로 HTTP 연결은 끊어집니다.
이후, 어느 한 쪽(Client or Server)이 연결을 끊지 않는 이상인 영구적으로 동일 채널이 맺어지게 됩니다.
웹소켓의 통신 방식
최초 접속 시에는 HTTP 프로토콜을 이용해 핸드셰이크가 이뤄진다는 점을 기억하시면 되겠네요.
좀 더 자세히 설명해보겠습니다.
웹소켓의 통신 방식
웹소켓 통신 과정
•
TCP/IP 접속
◦
결국 HTTP 방식 위에 존재하는게 웹 소켓 통신 방식이므로 서로 TCP/IP 위에서 동작하므로 서로 접속이 되어 있어야 웹소켓을 사용할 수 있습니다.
•
HandShake 요청/수락
◦
자세하게 설명하진 않겠지만, “악수”라는 뜻처럼, 데이터를 보내기 위한 연결이 이뤄지는 과정입니다.
◦
클라이언트가 먼저 HandShake Request를 보내고 서버가 HandShake Response를 보내는 구조
▪
HTTP 1.1 Protocol
단점
우선,
딱 봐도 프로그램 구현 복잡성이 높다는 것을 알 수 있습니다.
Stateful Protocol이므로 연결을 항상 유지시켜야하며, 비정상적으로 끊어진 경우 대응을 적절히 해야하므로, 기존 HTTP와 비교해봤을 때, 복잡성 상승 요인이 됩니다.
또한, 소켓 연결 유지 자체가 부담이 됩니다.
특히 트래픽 양이 많은 서버인 경우에는 CPU에 큰 부담이 됩니다.
실시간으로 빠르게 데이터들을 전송하고 처리해야할텐데, 당연히 CPU에 부담이 많이 된다는 것을 짐작해볼 수 있습니다.
오래된 버전의 브라우저는 지원을 하지 않을 수도 있습니다.
하지만 대부분의 브라우저는 지원하므로 웬만하면 걱정할 일이 없을 듯 합니다.