Websocket

🍄 Websocket

• Websocket은 컴퓨터 네트워크용 통신 규약의 하나이다.
  (인터넷의 표준화 단체인 W3C(World Wide Web Consortium)가 API 책정을 맡고, IETF가 Websocket 프로토콜 책정을 맡음으로써, 웹서버와 클라이언트간의 통신을 위한 규정을 정의한 양방향 통신용 기술 규약)

• WebSocket 서버에 연결한 다음 연결에서 데이터를 보내고 받기 위한 기본 인터페이스이다.
  (즉, Websocket(웹 소켓) API는 사용자의 브라우저(클라이언트)와 서버 간의 양방향(실시간) 통신 세션을 열 수있게하는 기술)

• 이 API를 사용하면 응답을 위해 서버를 폴링(polling, 클라이언트가 서버에게 요청하는 방식 <-> 푸시(push))하지 않고도 서버에 메시지를 보내고 이벤트 기반 응답을 받을 수 있다.

🌸 Websocket 등장배경

초기 웹(WEB)의 목적은 문서전달과 하이퍼링크를 통한 문서연결이다. 웹을 위한 HTTP프로토콜은 이러한 목적에 부합하는 모델이다.
하지만 웹(WEB)이 발전할수록 더욱 동적이고 상호작용적인 기능이 요구됨에 따라 웹환경이 개발되었다.
그 중 웹환경에서 실시간 양방향 통신을 위한 스펙이 Websocket이다.
Websocket은 서버와 클라이언트가 지속적으로 연결된 TCP라인을 통해 실시간으로 데이터를 주고 받을 수 있도록 하는 HTML5의 새로운 사양이다.
따라서 Websocket을 이용하면 일반적인 TCP소켓과 같이 연결지향 양방향 전이 중 통신이 가능하다.
👉 이를 활용한 분야로는 채팅, 게임, 실시간 주식 차트와 같은 실시간이 요구되는 응용프로그램의 개발을 효과적으로 구현할 수 있다.

🦋 REST API가 가진 한계점으로 인해 Websocket API가 등장하게 되었다.

REST API로 데이터가 전송되는 것은 항상 누군가가 그 데이터를 요청한 것의 결과이다.

ex) 브라우저 방문 사례 (웹사이트 주소 입력 > 엔터 > 웹페이지 뜸)
즉, 엔터를 치는 행위가 서버로부터 웹페이지의 콘텐츠를 달라고 요청하는 행위이다. 엔터를 치지 않으면 웹페이지를 구성하는 데이터를 제공받지 못한다.

ex) 웹페이지 새로고침 사례 (웹사이트 방문 후 새로고침을 하기 전까지는 화면에 변화가 없다)
즉, 이벤트 동작 등이 없으면 자동으로 서버에서 데이터를 계속 받아올 수 없다.

ex) 실시간으로 정보가 업데이트 되어야하는 분야(주식 등) -> 요청 행위 없이 실시간 데이터가 업데이트 되기 위해서는 무한 새로고침을 반복해야 할것이다.

👉 REST API의 한계는
1) 정보가 변할 때, 그때마다 실시간으로 받아보기 힘들다는 점
2) 한 번의 요청이 한 번의 응답으로 끝난다.
(즉, 한 번 요청하면 그 뒤로 계속해서 알아서 업데이트 해주는 방식의 API가 필요하다)

그래서 등장한 API가 Websocket API(= 구독형 API)이다.

• 데이터 요청자(클라이언트)와 데이터 제공자(서버) 간의 채널이 열리게 된다.
• 채널이 열리기 전, 요청자는 제공자로부터 어떤 데이터를 받고 싶은지 미리 알려줘야 한다.
• 채널이 열린 후, 제공자는 요청자가 요구했던 데이터들을 전달하기 시작한다.
• 이 채널이 닫히지 않는 한 데이터는 무한 들어올 수 있다.
  (채널형성 = 데이터 무한 제공)

🌸 Websocket이 필요한 경우

• 실시간 양방향 데이터 통신이 필요한 경우
• 많은 수의 동시 접속자를 수용해야 하는 경우
• 브라우저에서 TCP 기반의 통신으로 확장해야 하는 경우
• 개발자에게 사용하기 쉬운 API가 필요할 경우
• 클라우드 환경이나 웹을 넘어 SOA로 확장해야 하는 경우

🌸 Websocket 서버의 종류

• phpwebsockets
• jWebSocket(java)
• web-socket-ruby(ruby)
• Socket-IO-node(node.js)

🌸 기존 통신방법과 Websocket의 결정적 차이는?

• 기존 통신방법과 WebSocket의 결정적 차이는 프로토콜에 있다. WebSocket 프로토콜은 접속확립에 HTTP를 사용하지만, 그 후의 통신은 WebSocket 독자의 프로토콜로 이루어진다.
• header가 상당히 작아 overhead가 적은 특징이 있다.
• 장시간 접속을 전제로 하기 때문에 접속한 상태라면 클라이언트나 서버로부터 데이터 송신이 가능하다. 또한 데이터의 송수신에 각각 커넥션(connection)을 맺을 필요가 없어서 하나의 커넥션으로 송수신 할 수 있다.
• 통신시, 지정되는 URL은 http://www.sample.com/ 과 같은 형식이 아니라 ws://www.sample.com/ 과 같은 형식이 된다.

[붉은 박스] : Opening Hanadshake
[노란 박스] : Data transfer
[보라 박스] : Closing Handkshake

웹소켓은 HTTP로 Handshake를 한 후, ws로 프로토콜을 변환하여, 웹소켓 프레임을 통해 데이터를 전송한다.
웹소켓은 양방향 통신(full-duplex)을 지원하며, 그래서 요청과 응답을 구분하지 않는다.

(1) Opening Handshake

웹소켓 클라이언트에서 핸드쉐이크 요청(HTTP Upgrade)을 전송하고 이에 대한 응답으로 핸드 셰이크 응답을 받는데, 이때 응답 코드는 101이다.
101은 '프로토콜 전환'을 서버가 승인했음을 알리는 코드이다.

이 과정에서 요청과 응답의 헤더는 아래와 같다.
ws://localhost:8080/chat 으로 접속하려고 한다고 가정.

GET /chat HTTP/1.1
Host: localhost:8080
Upgrade: websocket
// 프로토콜을 전환하기 위해 사용하는 헤더. 
// 웹소켓 요청 시에는 반드시 websocket이라는 값을 가지며, 이 값이 없거나 다른 값이면 cross-protocol attack이라고 간주하여 웹소켓 접속을 중지시킨다.
Connection: Upgrade
// 현재의 전송이 완료된 후 네트워크 접속을 유지할 것인가에 대한 정보. 
// 웹소켓 요청 시에는 반드시 Upgrade라는 값을 가지며, Upgrade와 마찬가지로 이 값이 없거나 다른 값이면 웹소켓 접속을 중지시킵니다. 
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
// 유효한 요청인지 확인하기 위해 사용하는 키 값.  
Sec-WebSocket-Protocol: chat, superchat
// 사용하고자 하는 하나 이상의 웹 소켓 프로토콜 지정. 
// 필요한 경우에만 사용.
Sec-WebSocket-Version: 13
// 클라이언트가 사용하고자 하는 웹소켓 프로토콜 버전. 
// 현재 최신 버전 13
Origin: http://localhost:9000
// 모든 브라우저는 보안을 위해 이 헤더를 보낸다(Cross-Site WebSocket Hijacking와 같은 공격을 피하기 위해서). 
// 대부분 어플리케이션은 이 헤더가 없는 요청을 거부하며, 이러한 이유로 CORS정책이 만들어진 것이다. 
// 이 외에도 여러 메시지나 서브 프로토콜, Referer나 Cookie와 같은 공통 헤더, 인증 헤더 등을 추가해 보낼 수도 있다. 

(2) Data Transfer

핸드쉐이크를 통해 웹소켓 연결이 수립되면, 데이터 전송 파트가 시작된다. 여기에서는 클라이언트와 서버가 '메시지'라는 개념으로 데이터를 주고받는데, 여기서 메시지는 한 개 이상의 '프레임'으로 구성되어 있다.
(프레임은 텍스트(UTF-8) 데이터, 바이너리 데이터, 컨트롤 프레임(프로토콜 레벨의 신호) 등이 있다)

핸드 셰이크가 끝난 시점부터 서버와 클라이언트는 서로가 살아 있는지 확인하기 위해 heartbeat 패킷을 보내며, 주기적으로 ping을 보내 체크한다. 이는 서버와 클라이언트 양측에서 설정 가능합니다.

(3) Close Handshake

클라이언트와 서버 모두 커넥션을 종료하기 위한 컨트롤 프레임을 전송할 수 있다. 이 컨트롤 프레임은 Closing Handshake를 시작하라는 특정한 컨트롤 시퀀스를 포함한 데이터를 가지고 있다.
위 그림에서는 서버가 커넥션을 종료한다는 프레임을 보내고, 클라이언트가 이에 대한 응답으로 Close 프레임을 전송한다. 그러면 웹소켓 연결이 종료된다.
연결 종료 이후에 수신되는 모든 추가적인 데이터는 버려진다.

---

🍄 SSL & TLS

ref