🤚What is WebSocket?
- WebSocket은 Transport protocol의 일종으로 쉽게 이야기하면 웹버전의 TCP 또는 Socket이라고 이해하자.
- 서버와 클라이언트간의 Socket Connection을 유지해서 언제든 양방향 통신(Full Duplex) 또는 데이터 전송이 가능하도록 하는 기술
- Real-time Web Application 구현을 위해 널리 사용되어지고 있는 기술
🤔 Why use it WebSocket?
- 웹어플리케이션에서 기존의 서버와 클라이언트간의 통신은 대부분 HTTP로 이루어진다.
- HTTP는 클라이언트와 서버와의 요청과 응답이 대부분인 Stateless Protocol이다. (단방향 통신, Simplex)
❗Stateless Protocol의 경우 서버쪽 데이터가 업데이트 되더라도 클라이언트쪽의 UI가 Refresh하지 않는 한 변경된 데이터가 반영되지 않는 문제가 발생한다.
→ 이러한 경우는 일반적으로 Long polling 혹은 Ajax를 사용하여 어느정도 문제를 해결하였지만 데이터의 빠른 업데이트가 매우 중요한 요소로 자리매김으로써 어플리케이션의 실시간 업데이트를 지원해주는 Web Socket이 중요한 기술로 떠올랐다.
🤔 Polling 방식 : 일정 주기로 통신하여 데이터를 가져오는 통신 방식
→ 즉, 일정한 주기로 서버에 요청을 보낸다. (setTimeout, setInterval 등을 이용하여)
→ 하지만, 불필요한 요청과 Connection을 생성하여 서버에 부담
→ 요청주기가 짧을수록 부하가 커지는 단점 발생
→ ‘일정 주기마다’ 요청을 보내는 것으로 실시간이라 보기 애매함
→ HTTP 통신을 기반으로 진행되기에 요청과 응답 헤더가 불필요하게 크다.
🤔 Long Polling 방식 : Polling과 비슷하기 일정 주기마다 요청을 보내지만, 서버가 바로 응답하지 않는 방식
→ 즉, 요청을 보냈을 때 서버가 응답을 바로 보내지 않고 특정 이벤트나 타임아웃이 발생했을 때 응답을 전달한다.
→ 응답을 받은 클라이언트는 다시 서버에 요청하는 방식이다.
→ 불필요한 요청과 Connection이 생기지는 않지만 동시다발적인 요청과 응답이 발생하면 부하가 발생할 수 있다.
→ 이 또한 HTTP 통신을 기반으로 진행되기에 요청과 응답 헤더가 불필요하게 크다.
🤔 Streaming 방식 : 이벤트가 발생했을 때 응답을 보내되, 응답을 완료시키지 않고 계속 연결을 유지하는 방식
→ 매 응답마다 다시 요청을 하지 않아 효율적
→ 연결시간이 길어질수록 연결 유효성 관리에 부담 발생
→ 이 또한 HTTP 통신을 기반으로 진행되기에 요청과 응답 헤더가 불필요하게 크다.
🤔 How it works WebSocket?
웹 소켓의 동작과정은 위 사진과 같이 세가지로 나누어진다.
- 빨간색 박스 : Opening Handshake
- 노란색 박스 : Data transfer
- 보라색 박스 : Closing Handshake
🤔 What is Handshake?
- Opening Handshake와 Closing Handshake는 일반적인 HTTP/ TCP 통신 과정 중 하나. 자세한 설명은 따로 정리할 예정
- 위 사진에서는 우선 HTTP로 요청한 뒤, 웹소켓 프로토콜(WS)으로 변경
- 웹소켓 프로토콜로 변경되기 위한 HTTP 요청 헤더는 아래처럼 구분된다.
해당 경로로 접속한다 가정.
ws://localhost:8080/chat
GET /chat HTTP/1.1
Host: localhost:8080
Upgrade: websocket -> 프로토콜 전환 헤더 / websocket이 아닌 다른값이면 cross-protocol attack이라고 간주하여 웹 소켓 접속 중지
Connection: Upgrade -> 웹 소켓 요청시 필수 / 현재의 전송이 완료된 후 네트워크 접속을 유지할 것인지
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== -> 유요한 요청인가
Sec-WebSocket-Protocol: chat, superchat -> 사용하고자 하는 웹 소켓 프로토콜 지정
Sec-WebSocket-Version: 13 -> 클라이언트가 사용하고자 하는 웹소켓 프로토콜 버전
Origin: http:localhost:9000 -> CORS 정책으로 만들어진 헤더- HTTP 응답 헤더는 아래처럼 구분된다.
HTTP/1.1 101 Switching Protocols -> 101은 HTTP에서 WS로 프로토콜 전환이 승인되었다는 응답
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
Sec-WebSocket-Accept는 요청 헤더의 Key에 유니크 아이디를 더해서
SHA-1로 해싱한 뒤 base64로 인코딩한 결과.
즉, 웹 소켓 연결이 개시되었음을 알린다.Opening Handshake에서 승인이 나고나면, 웹 소켓 프로토콜로 노란색 박스 부분인 Data transfer이 진행된다.
해당 계층에선 데이터는 메시지라는 단위로 전달된다.
-
메시지 : 여러 프레임(frame)이 모여서 구성되는 하나의 논리적인 메시지 단위
-
프레임 : 통신에서 가장 작은 단위
❓ 가장 작은 단위의 데이터는 패킷이 아닌가?
💡 패킷 : 모든 네트워크 통신 과정에서 가장 작은 단위의 데이터
💡 프레임 : 데이터 링크계층(L2, 이더넷)에서 주고받는 가장 작은 단위→ 작은 헤더 + Payload로 구성
⚡ WebSocket을 지원하기 위한 Socket.io
- WebSocket은 HTML5의 기술이기에 오래된 버전의 웹브라우저는 WebSocket을 지원하지 않는다.
- 이를 해결하기 위해 나온 라이브버리 Socket.io
- WebSocket, Polling, Streaming 등 다양한 방법을 하나의 API로 추상화시킴.
