[소켓과 웹소켓] 한 번에 정리 (2) | 소켓과 웹소켓의 차이점, 웹소켓의 모든것, http-tcp-소켓의 상관관계

Konseo·2022년 2월 27일

TCP/IP socket websocket 네트워크 소켓 실시간통신 양방향통신 웹소켓 프로토콜

네트워크

목록 보기

2/7

지난 시간은 소켓 위주로 정리를 해보았다. 이번 편은 웹소켓에 대해 다루어보자! 이번 기회에 소켓과 웹소켓의 차이를 확실히 알게되길 바라며...😌

TCP/IP소켓과 웹소켓의 차이

(TCP/IP) 소켓에 대한 내용은 여기서 볼 수 있다. 이제 소켓은 대충 알겠고 .. 웹소켓은 뭘까?

일단 소켓과 웹소켓은 IP와 포트를 통한 통신을 한다는 점에서는 비슷하다. 또, 둘 다 양방향 통신을 한다는 비슷한 특징을 갖고 있기도 하다.

차이점은,
웹 소켓은 HTTP 레이어에서 작동하는 소켓으로 TCP/IP 소켓의 레이어가 다르다!
그러니 두 개념은 엄연히 다르다. 같다고 혼동하지 않아야한다.

WebSocket

웹소켓은 http에서 실시간 통신을 할 수 없다는 문제를 해결하기 위해 나온 기술이다! 웹소켓의 탄생 배경이 되는, http의 특징에 대해 간략히 살펴보자.

HTTP로는 실시간 통신을 할 수 없어요

웹소켓의 탄생배경을 알기 위해선 http의 특징에 대해 짚고 넘어가야한다.

비연결성 (단방향)
매번 연결 맺고 끊는 과정의 비용
request-response 의 구조
헤더의 비중이 너무 큼 → 실시간성으로 많은 데이터를 주고 받고자 하는 경우에는 매우 부담이 되는 요소 중 하나

http는 위와 같은 특징을 같고 있기 때문이다. 즉, 요청을 보내면 응답이 오는 단방향적 구조로 통신하기 때문에 TCP/IP 프로토콜을 사용하는 소켓처럼 계속 connection이 유지되는 실시간 통신을 할 수 없다. 이의 문제점을 해결하기 위해 나온것이 웹소켓 프로토콜이다.

웹소켓은 실시간 통신을 할 수 있어요

연결지향 (양방향)
한 번 연결 맺은 뒤 유지
핸드쉐이크 과정에서는 헤더의 비중이 크지만, 한번 연결이 되면 간단한 메시지들만 오고감 → 굉장히 경제적임

웹소켓은 위와 같은 특징으로 실시간 통신을 할 수 있다. 웹소켓은 http를 대체할 수 있는 개념까진 아니고, 그저 웹에서 실시간 통신을 해야하는 상황에서 잘 쓰이는 프로토콜 중 하나라고 생각하면 된다. 위에서 언급했지만 이름부터 웹소켓이기에 http 레이어 위에서 작동한다.

웹소켓 정확히 언제 쓰지?

당연한 얘기지만 실시간 통신을 해야하는 상황에 쓴다. 아래와 같이!

case1 | B유저와 게임을 할때 타유저가 게임 action을 줄 때마다 새로고침을 해야함 → 매우 불편하겠죠? 즉, 게임할 때
case 2 | 채팅을 해야할 때
case 3 | 실시간 주식 거래 사이트를 만들 때 .. 등등

웹 소켓 동작 방법

1. 일단 손을 맞잡는다 🤝 핸드쉐이킹!

채널에 대한 정상적인 통신이 시작되기 전에 두 개의 실체 간에 확립된 통신 채널의 변수를 동적으로 설정하는 자동화된 협상과정

2. 이제 데이터를 넣을 프레임을 구성하자! Frame 구성

최초 접속에서만 http 프로토콜 위에서 핸드쉐이킹을 하기 때문에 http 헤더를 사용한다.
웹소켓을 위한 별도의 포트는 없으며 기존 포트(http-80,https-443)를 사용(호환된다는 의미)
프레임으로 구성된 메시지라는 논리적 단위로 송수신
메시지에 포함될 수 있는 교환 가능한 메시지(frame)는 텍스트와 바이너리 뿐!

웹소켓 한계

웹소켓은 html5이후에 나왔다. html5이전 기술로 구현된 서비스에서는 어떻게 해야할까?

1. Socket.io, SockJS

Socker.io, SockerJS가 html5이전의 기술로 구현된 서비스에서 웹 소켓처럼 사용할 수 있도록 도와주는 기술임. 이걸로 실시간 통신을 도와준다.

결국 브라우저와 웹서버의 종류와 버전을 파악하여 가장 적합한 기술을 선택해 웹소켓처럼 보여지게 기능을 만든다!

2. STOMP

웹소켓은 문자열들을 주고받을 수 있게 해줄 뿐 그 이상의 일은 하지 않는다. 주고 받는 문자열의 해독은 온전히 어플리케이션에 맡긴다

HTTP는 형식을 정해두었기 때문에 모두가 약속을 따르기만 하면 해석할 수 있다. 하지만 WebSocker방식은 sub-protocols을 사용해서 주고 받는 메시지의 형태를 약속하는 경우가 많음

sub-protocol로 자주 쓰이는게 STOMP

- STOMP

웹 소켓 이전의 비슷한 기술

http로도 실시간 통신을 하기 위한 다양한 방법이 존재한다.

1. http polling

서버로 일정 주기 요청 송신

cf. polling
프로그램이 충돌 회피 또는 동기화 처리 등을 목적으로 다른 프로그램의 상태를 주기적으로 검사하여 일정한 조건을 만족할 때 송수신 등의 자료 처리를 하는 방식

real-time 통신에서는 언제 통신이 발생할지 예측이 불가능하다
불필요한 request와 connection을 생성
사진을 보면, 이벤트가 없는데도 요청을 하게됨. 그러면 이벤트 발생 ‘후' 응답을 받을 때까지의 대기 간극이 생김. (-) 불필요한 시간
real-time 통신이라고 하기 애매한할 정도의 실시간성

2. http long-polling

서버에 요청을 보내고 이벤트가 생겨 응답 받을 때까지 서버 측에서 연결을 종료하지 않는것 . 응답을 받으면 끊고 다시 재요청

cf. long-polling
클라이언트가 웹 서버에세 새로운 내용이 있는지 물어보았을 때 웹 서버에서 새로운 이벤트가 없다면 대답해 주지 않다가 새로운 내용이 생기면 이 때 대답해 주는 방식

불필요한 request를 없앰(polling의 단점 일부 보완)
결국 많은 양의 메세지가 쏟아질 경우 polling과 같아짐..

3. http streaming

서버에 요청 보내고 끊기지 않은 연결상태에서 끊임없이 데이터를 수신한다.

클라이언트에서 서버로의 데이터 송신이 어렵다

하지만...

결과적으로 이 모든 방법이 HTTP를 통해 통신하기 때문에 Request, Response 둘다 Header가 불필요하게 큼 (빠르게 데이터를 주고받아야할 때에는, 이게 걸림돌이 될 수 있다는 의미)

근데... http는 왜 단방향 통신일까?

사실 글을 정리하면서, 웹프로토콜인 http와 tcp의 차이를 명료하게 이해할 수 없었다. 왜냐면 http 프로토콜은 기본적으로 TCP/IP 위에서 동작한다고 배웠다. 그런데 TCP 서버 구성을 할때 소켓을 이용해 실시간 통신을 하는데 왜 http 프로토콜을 얹으면 단방향적 구조로 통신하게 되는거지..? 라는 의문이 들었다. http 특징 자체가 단방향 통신이란 건 알겠는데... 애초에 TCP기반으로 만든 프로토콜인 http가 왜 실시간 통신이 안되는 지 자체가 이해가 안갔다.

http는 connectionless하고 tcp는 connection oriented한데 어떻게 tcp위에 http가 있을 수 있지?

일단 구글링을 해본 결과 내가 내린 결론은 관점에 따라 다르다 이다.

http는 tcp 위에서 만들어진다. 즉 소켓을 양끝단으로 하는 tcp 레이어 위에 존재하는 프로토콜이다. 아무리 'http vs socket'에 관하여 설명하는 글이 많다 할지라도 http가 tcp 위에 만들어졌으니 HTTP 또한 소켓 통신을 활용한 방식이라고 볼 수 있지 않느냐에 대한 물음에 대한 답은 '그렇다'일것 이다.

하지만 통신에는 계층이 있다. http와 소켓은 다른 프로토콜을 가지고 있고, 엄연히 다른 계층에서 동작한다. 일반적으로 사용하는 소켓통신(tcp통신)은 4계층에서 시작하여 패킷이 생성되고, http 통신의 경우 7계층에서부터 시작하여 패킷이 생성된다.

따라서 4계층 관점으로 본다면 이 둘은 연결지향적 통신이 되는 것이고,
7계층 관점에서 본다면 http는 비연결, socket 통신은 연결지향적이 되는 것이다.