socket과 web socket

[Archive] 이 글은 2024년에 다른 플랫폼에서 작성한 글을 이전한 것입니다.
내용 중 일부는 현재 기준과 맞지 않을 수 있습니다.

연구본부 본부장님이 즐겨 던지시던 면접 질문이라는 이야기를 들은 후, 한번 찾아봤던 내용이다.
TIL로 간략히 정리해두었던 것을 추가 정보를 더해 별도 글로 재작성한다.

둘 다 IP와 포트를 기반으로 통신한다는 점에서는 유사해 보이지만, 자세히 살펴보면 다른 개념이다.

Socket

Socket은 프로그램이 네트워크에서 데이터를 주고받을 수 있도록 네트워크 환경에 연결할 수 있게 만들어진 연결부다.
일반적으로 TCP/IP 프로토콜을 사용하여 클라이언트와 서버 간의 연결을 설정하고, 데이터를 전송하는 데 사용한다.

동작 위치

Socket은 TCP/IP 4계층 모델에서 전송 계층(Transport Layer)과 응용 계층(Application Layer) 사이에 위치한다.
OS가 제공하는 API로서 전송 계층의 프로토콜(TCP/UDP)을 제어하기 위한 인터페이스 역할을 한다.

동작 방식

프로세스 간 통신에 Socket을 이용하는 Socket Programming에서, Socket은 통신 연결 요청 역할에 따라 Client Socket과 Server Socket으로 나뉜다.

Client Socket

소켓 생성 → 연결 요청(connect) → 데이터 송수신 → 소켓 닫기

Server Socket

소켓 생성 → 주소 결합(bind) → 연결 대기(listen) → 연결 수락(accept) → 데이터 송수신 → 소켓 닫기

WebSocket

등장 배경

HTTP는 기본적으로 connectionless(비연결성)와 stateless(무상태성) 특성을 가진다.
클라이언트가 요청을 보내면 서버가 응답하고 연결이 끊어지는 구조라, 실시간 데이터 통신에는 적합하지 않다.

WebSocket 이전에는 다음과 같은 방법으로 실시간성을 구현했다.

방식	설명	한계
Polling	클라이언트가 일정 주기로 서버에 반복 요청	불필요한 요청 낭비, 서버 부하
Long Polling	서버가 이벤트 발생 시까지 응답을 지연, 이후 즉시 응답	응답 후 새 연결 필요, 연결 유지 비용
SSE (Server-Sent Events)	서버→클라이언트 단방향 실시간 스트리밍	클라이언트→서버 방향 불가

WebSocket은 이러한 한계를 해결하기 위해 등장한 프로토콜로, 한 번 연결을 맺으면 양방향으로 자유롭게 데이터를 주고받을 수 있다. 채팅, 실시간 주가/코인 시세, 협업 도구, 온라인 게임 등에서 널리 활용된다.

동작 방식

1) Opening Handshake

최초 연결은 HTTP 프로토콜 위에서 이루어진다.
클라이언트가 HTTP Upgrade 요청을 전송하면, 서버는 응답 코드 101 Switching Protocols로 프로토콜 전환을 승인한다.

WebSocket 전용 포트는 별도로 없으며, 기존 HTTP(80) / HTTPS(443) 포트를 그대로 사용한다.
핸드셰이크 이후에는 HTTP 헤더 없이 경량 프레임 단위로만 데이터가 오간다.

2) 데이터 송수신

연결이 수립되면 양측은 frame으로 구성된 message 단위로 데이터를 주고받는다.
frame에 포함될 수 있는 데이터 유형은 다음과 같다.

• 텍스트 (UTF-8)
• 바이너리
• 컨트롤 프레임 (ping/pong, 연결 종료 신호 등 프로토콜 레벨의 신호)

연결은 당사자 중 하나가 종료하거나 타임아웃이 발생할 때까지 유지되며, 그 동안 동일한 채널을 통해 양방향 통신이 이루어진다. 보안이 필요한 경우 WSS(WebSocket Secure) 프로토콜을 통해 데이터를 암호화할 수 있다.

3) 연결 종료

연결 종료 이후 수신되는 모든 추가 데이터는 버려진다.

한계

WebSocket은 HTML5 이후에 등장한 기술이다.
HTML5 이전 환경에서 구현된 서비스에서는 WebSocket을 직접 사용할 수 없으며, 이 경우 Socket.io, SockJS 등의 라이브러리를 사용해야 한다.

이 라이브러리들은 WebSocket을 지원하지 않는 환경에서 Long Polling 등의 방식으로 자동 폴백(fallback)하여 실시간 통신을 구현해준다.

HTTP와 TCP

HTTP 프로토콜은 TCP/IP 위에서 동작한다.
그렇다면 TCP 서버를 구성할 때 Socket을 이용해 실시간 통신을 하는데, 왜 HTTP 프로토콜을 얹으면 단방향적 구조로 통신하게 되는 것일까.

이는 HTTP가 단방향 통신을 강제하는 것이 아니라, connectionless와 stateless 특성으로 인해 기본 동작이 요청-응답 사이클로 설계되어 있기 때문이다.
TCP 자체는 양방향 통신이 가능한 프로토콜이고, 그 위에 어떤 애플리케이션 계층 프로토콜을 얹느냐에 따라 통신 방식이 달라진다.

HTTP는 요청마다 새로운 TCP 연결을 설정하고, 응답을 받은 후 연결을 종료한다.
이 방식이 connectionless 특성과 일치하며, 각 요청과 응답이 독립적이라는 stateless 특성으로 이어진다.

TCP는 신뢰성 있는 전송을 보장하는 전송 계층 프로토콜로, HTTP는 이를 통해 데이터의 순서 보장과 오류 복구를 위임한다.

결론적으로 HTTP는 TCP를 사용해 데이터를 전송하는 프로토콜이므로, HTTP를 “Socket 통신을 활용한 통신 방식”으로 보는 것은 맞다.
다만 HTTP의 설계 방식(connectionless, stateless)으로 인해 실시간 양방향 통신이 필요한 경우에는 WebSocket과 같은 별도 프로토콜이 필요하다.