목차
웹 소켓
WebSocket 프로토콜은 클라이언트와 서버가 전이중 채널에서 통신하는 방법이다. 즉, 클라이언트와 서버 모두 오랫동안 지속되는 연결을 통해 동시에 데이터를 보내고 받을 수 있다. 이러한 유형의 통신은 HTTP 폴링보다 오버헤드가 적기 때문에 애플리케이션에 실시간 기능에 대한 여러 이점을 제공한다. 때문에, 실시간으로 진행되는 통신에서 적극적으로 사용하고 있다. (ex. 실시간 채팅, 게임 등 지연 시간이 중요한 애플리케이션)
웹 소켓은 HTML5이 등장하며 실시간 웹 애플리케이션을 위해 설계된 통신 프로토콜이며, TCP를 기반으로 한다. TCP를 기반으로 한 웹 소켓은 신뢰성 있는 데이터 전송을 보장하며, 메시지 경계를 존중하고, 순서가 보장된 양방향 통신을 제공할 수 있다. 이때 데이터는 패킷(packet) 형태로 전달되며, 전송은 연결 중단과 추가 HTTP 요청 없이 지속적으로 이루어진다.
웹 소켓 이전에는?
Polling
서버로 일정 주기로 요청을 송신하는 방법이다. 그러나,
•
real-time 통신에서는 언제 통신이 발생할지 예측이 불가능
•
불필요한 request와 connection을 생성
과 같은 이유로, 실시간 통신이라 부르기 애매할 정도의 실시간성과 함께 크게 의미가 없어졌다.
Streaming
서버에 요청을 보내고 끊기지 않은 상태에서 끊임없이 데이터를 수신하는 방법이다. 그러나 이 경우, 클라이언트에서 바로 데이터 송신이 어렵다는 단점이 있다.
결과적으로 이 모든 방법들은 HTTP를 통해 통신하기 때문에, Request, Response 둘 다 Header가 불필요하게 크다.
웹 소켓 handshake
웹 소켓의 첫 번째 과정은 handshake이다. 이때 HTTP 요청을 통해 연결을 설정하고, 이후에는 웹 소켓 프로토콜로 전환하여 통신한다.
웹 소켓 요청
•
HTTP 버전은 1.1 이상
•
반드시 GET 메서드를 사용해야 한다.
•
클라이언트는 서버에 Upgrade와 Connection 헤더가 포함된 HTTP 요청을 보낸다.
◦
Upgrade는 서버, 전송, 프로토콜 연결에서 다른 프로토콜로 업그레이드 또는 변경하기 위한 규칙
•
Sec-Websocket-Key는 클라이언트가 요청하는 여러 서브 프로토콜을 의미한다.
웹 소켓 응답
•
서버가 요청을 승인하면, 101 Switching Protocols 상태 코드와 함께 연결을 유지한다.
•
Sec-Websocket-Accept는 요청에서의 Key 값을 계산한 값으로 신원 인증에 필요한 헤더이다.
이렇게 위와 같이 핸드쉐이크가 완료되면 이후 통신은 HTTP가 아닌, 웹 소켓 프레임을 통해 이루어진다. 또는 wss와 같이 데이터 보안을 위해 SSL을 적용한 프로토콜로 변경된다.
Message : 여러 frame이 모여서 구성하는 하나의 논리적 메시지 단위
Frame : communication에서 가장 작은 단위의 데이터, 작은 헤더 + payload로 구성
웹 소켓 통신에 사용되는 데이터 : UTF8 인코딩
0x00 - 보내고 싶은 데이터 - 0xff 의 구성으로 데이터가 오간다.
+ Frame의 헤더 구조
•
FIN 비트 : 메시지가 끝났음을 나타내는 플래그
•
Opcode : 프레임의 종류. (텍스트, 바이너리, 연결 종료 등)
•
Payload Length : 이 프레임에 포함된 데이터의 총 길이를 나타내는 단위 (메시지의 크기)
•
Payload : 실제 메시지 데이터
전체적으로 아래와 같은 모습이 나온다.
웹 소켓 프로토콜 특징
•
최초 접속시만 http 프로토콜 위에서 handshaking을 하기 때문에 http header를 사용한다.
•
웹 소켓을 위한 별도의 포트는 없고, 기존 포트를 사용한다.
•
프레임으로 구성된 메시지는 논리적 단위로 송수신 한다
•
메시지에 포함될 수 있는 교환 가능한 메시지는 텍스트와 바이너리 뿐이다.
웹 소켓 한계
1.
HTML5 이후에 나온 기술
웹소켓은 HTML5이후에 나왔다고 했다, 그러면 HTML5이전의 기술로 구현된 서비스에서는 Socket.io, SockJS 와 같이 HTML5 이전의 기술로 구현된 서비스 에서 웹 소켓처럼 사용할 수 있도록 도와주는 기술을 활용해야한다.
2.
Web Socket은 문자열들을 주고 받을 수 있게 해줄 뿐 그 이상의 일을 하지 않는다.
HTTP는 형식을 정해두어서 모두가 약속을 따르기만 하면 해석할 수 있지만, Web Socket은 형식이 정해져 있지 않아 애플리케이션에서 쉽게 해석하기 힘들다.
때문에 Web Socket방식은 sub-protocol을 사용해 주고 받는 메시지의 형태를 약속하는 경우가 많다.
서브프로토콜로 자주 쓰이는게 STOMP이다. STOMP(Simple Text Oriented Message Protocol)은 채팅 통신을 하기 위한 형식을 지정한다. HTTP와 유사하게 정의한다.
