이 글을 쓰게 된 배경
웹 프로젝트만 하다보니 단방향인 HTTP 프로토콜에만 익숙해져서 이 기회에
1. http와 소켓의 차이
2. TCP위의 계층에 존재하는 http의 특징
3. http 프로토콜보다 웹 소켓이 적합한 경우
에 대해 공부해볼겸 작성하게 되었다.
소켓이란?
OSI 7 계층의 어플리케이션 계층(application layer)에 존재하는 네트워크 응용 프로그램들은 데이터를 송수신 하기 위해 소켓을 거쳐 전송 계층(trasport layer)의 통신 망으로 전달함으로써 데이터를 송수신 하게 된다.
따라서 소켓은 그 사이에 위치하고 있으며, 응용 프로그램에서 TCP/IP를 이용하는 인터페이스 역할을 한다.
소켓은 엔드포인트, 즉 IP와 포트 번호를 활용하여 만들어진 통신의 양끝단이다.(TCP/IP)
HTTP와 TCP의 관계
이 2가지의 프로토콜은 서로 다르다. 우선 둘의 계층은 전혀 달라서 둘을 비교하는 것은 올바르지 못하다.
HTTP와 TCP의 가장 큰 차이점은 TCP는 독립적으로 서버와 클라이언트를 연결해서 데이터를 보낼 수 있지만, HTTP는 직접 연결을 하지 못해 TCP를 사용한다는 것이다.
결국 HTTP는 TCP를 통한 연결을 사용해서 데이터를 보내고 검색한다.
TCP/IP 소켓과 그 위의 계층에 존재하는 HTTP
HTTP가 TCP를 통해서 연결을 한다면 HTTP가 Stateless일 이유가 없지 않나? 와 같은 고민을 하게 되었다.
HTTP의 특징
1. 비연결성(단방향)
2. 매번 연결 맺고 끊는 과정의 비용
3. request-response의 구조
4. 헤더의 비중이 너무 큼 -> 실시간성으로 많은 데이터를 주고 받고자 하는 경우에는 매우 부담이 되는 요소 중 하나이다.
즉, http는 위와 같은 특징을 갖고 있어서, 요청을 보내면 응답이 오는 단방향적인 구조로 통신을 하기 때문에 TCP/IP 프로토콜을 사용하는 소켓처럼 계속 connection이 유지되는 실시간 통신을 할 수 없다.
TCP/IP 소켓은 클라이언트와 서버 간의 지속적인 연결을 관리하며, 각 세션의 상태를 추적하기 때문에 stateful하다. 반면에 HTTP는 이 연결 위에서 작동하지만, 각 요청이 독립적이기 때문에 stateless한 것이였다.
TCP/IP 소켓과 웹소켓
소켓과 웹소켓은 IP와 포트를 통한 통신을 한다는 점에서는 비슷하다.
둘 다 양방향 통신을 한다는 비슷한 특징을 가지고 있다.
하지만, 웹 소켓은 HTTP 요청으로 시작한다. 일반적인 HTTP 요청과 같이 TCP 연결을 진행하는데, 연결이 성공하면 서버와 클라이언트를 이 웹소켓 연결로 사용하기로 합의한다.
그러면, 연결은 필요한 만큼 유지되며, 서버와 클라이언트가 자유롭게 데이터를 독립적으로 전송할 수 있게 한다.
웹 소켓의 특징
실시간 통신 가능
- 연결 지향(양방향)
- 한 번 연결 맺은 뒤 유지
- 핸드쉐이크 과정에서는 헤더의 비주이 크지만, 한번 연결이 되면 간단한 메시지들만 오고감-> 굉장히 경제적
웹소켓은 위와 같은 특징으로 실시간 통신을 할 수 있다. 웹 소켓은 http를 대체할 수 있는 개념까지는 아니고, 그저 웹에서 실시간 통신을 해야 하는 상황에서 더 적합한 프로토콜 중 하나라고 생각하면 된다.
이름이 웹소켓이기 때문에 http 레이어 위에서 작동한다.
웹 소켓을 사용하는 경우
웹 소켓은 http와 달리 실시간성 양방향 통신이 필요한 경우에 적합하다.
아래와 같은 예시가 있다.
1. 실시간 채팅 애플리케이션
예시: 카카오톡, 페이스북 메신저, 슬랙과 같은 실시간 채팅 서비스.
설명: 사용자가 메시지를 보내면, 웹 소켓을 통해 서버로 바로 전달되고, 서버는 다른 클라이언트들에게 실시간으로 메시지를 전달한다. 별도의 HTTP 요청 없이 지속적으로 연결이 유지되므로, 대화가 빠르고 지연이 적다.
2. 온라인 게임
예시: 배틀그라운드, 리그 오브 레전드, 월드 오브 워크래프트와 같은 실시간 온라인 멀티플레이어 게임.
설명: 게임에서 각 플레이어의 행동이나 위치 정보가 실시간으로 서버와 동기화된다. 웹 소켓을 통해 플레이어 간 상태 정보를 빠르게 주고받아야 하기 때문에 빠른 응답이 중요한 게임 환경에서 사용된다.
