WebSocket 완전 정복 4편 — 브라우저 API: readyState, bufferedAmount, onclose가 알려주는 것

브라우저 WebSocket 객체의 생성·전송·종료를 예제로 훑고, readyState 네 상태와 bufferedAmount·protocol 속성의 쓰임, 그리고 임의 헤더를 붙일 수 없다는 제약과 onerror 대신 onclose의 코드로 판단해야 하는 이유를 다룹니다.

WebSocket 완전 정복 · 1부. 기초 · 16편 중 4편

이전 편: 3편 — 핸드셰이크

3편까지가 선 위를 오가는 프로토콜이었다면, 이번 편은 브라우저가 그것을 어떻게 드러내는지입니다. WebSocket 객체 하나로 연결부터 종료까지 훑고, 알아 둘 속성 세 가지와 이 API가 못 하는 것을 봅니다.

연결부터 종료까지

const ws = new WebSocket("wss://example.com/chat", ["chat.v1"]);
ws.binaryType = "arraybuffer"; // 기본값은 "blob"
 
ws.onopen = () => ws.send(JSON.stringify({ type: "hello" }));
ws.onmessage = (e) => {
  // e.data: 텍스트면 string, 바이너리면 ArrayBuffer/Blob
  console.log(e.data);
};
ws.onerror = (e) => console.error("error", e); // 상세 정보는 거의 없음
ws.onclose = (e) => console.log("closed", e.code, e.reason, e.wasClean);
 
ws.close(1000, "bye");

알아 둘 속성 세 가지

readyState: 0 CONNECTING, 1 OPEN, 2 CLOSING, 3 CLOSED. OPEN이 아닐 때 send하면 예외 또는 무시.
bufferedAmount: 아직 나가지 못하고 쌓인 바이트 수. 백프레셔 판단에 사용합니다(13편 — 백프레셔와 흐름 제어).
protocol: 서버가 선택한 서브프로토콜.

브라우저 API의 제약

브라우저 API는 임의의 헤더를 설정할 수 없습니다. Authorization 헤더를 붙일 수 없으니 인증 설계를 따로 해야 합니다. onerror는 원인을 거의 알려주지 않으므로 판단은 onclose의 code로 합니다.

헤더를 붙일 수 없는 조건에서 인증을 어떻게 설계하는지는 10편 — 인증과 인가에서 다룹니다.

더 깊이

풀스택 개발자를 위한 네트워크 8장 — 브라우저 보안 모델: SOP, CORS, 쿠키: 브라우저가 CSP의 connect-src로 WebSocket 목적지를 제한하는 방법입니다. 이 편의 new WebSocket()이 어디로 연결할 수 있는지를 페이지 쪽에서 통제하는 장치입니다.