WebSocket과 SSE의 핵심 차이 정리(통신 방향·프로토콜·연결 방식·재연결·주 용도)

DevTools에서의 탐지 포인트(101 vs 200, Frames vs Response 누적)와

실무 선택 기준(채팅·게임은 WebSocket, 단방향 실시간 전달은 SSE) 요약


목차

  1. WebSocket vs SSE 핵심 차이 요약
  2. 온라인 통신 관점에서의 본질 비교 (개념 이해용)
  3. DevTools 기준으로 구분하는 실무 표(탐지용)
  4. DevTools 기준으로 구분하는 실무 표(탐지용)
  5. 언제 무엇을 쓰는지 (선택 기준)

SSE와 웹 소켓의 비교

  • WebSocket : 서버와 클라이언트가 계속 대화하는 온라인 통신
  • SSE : 서버가 클라이언트에게 계속 흘려보내는 온라인 통신

WebSocket vs SSE 핵심 차이 요약

구분  WebSocket SSE
통신 방향 양방향 단방향 (서버 → 클라이언트)
프로토콜 WebSocket 전용 HTTP
연결 방식 Protocol Upgrade HTTP 연결 유지
재연결 직접 구현 자동 재연결
주 용도 상호작용 실시간 전달

온라인 통신 관점에서의 본질 비교 (개념 이해용)

항목 WebSocket SSE
온라인 통신 유형 대화형 방송형
연결 유지 O O
상태 보유 O O
이벤트/스트림 O O
양방향 제어 가능 불가

DevTools 기준으로 구분하는 실무 표(탐지용)

구분 WebSocket  SSE
Status Code 101 200
Messages 탭 있음 없음
Network 표시 websocket 항목 Fetch/XHR + Pending
데이터 확인 Frames Response 누적

언제 무엇을 쓰는지 (선택 기준)

상황 선택
채팅 / 게임 WebSocket
양방향 제어 WebSocket
실시간 알림 SSE
실시간 시세/체결 SSE (대부분)
단방향 스트림 SSE

Server-Sent Events의 기본 개념과 연결 원리 정리

HTTP 기반 지속 연결과 자동 재연결 동작 요약

ext/event-stream 포맷과 event/data/id/retry 필드 규칙 설명

백엔드(res.write)·프론트(EventSource) 예제 코드 포함으로 실무 적용 가이드 제공


목차

  1. SSE의 개요
  2. SSE의 연결
  3. SSE의 구조
  4. SSE의 송수신 데이터
  5. SSE의 예시코드

SSE

개요

  • Server-Sent Events

정의

  • 온라인 통신을 위한 “서버 → 클라이언트 스트림”
  • 서버가 클라이언트에게 계속 소식을 보내는 통신
  • 의미 : 서버가 클라이언트에게 데이터를 계속 “밀어주는” 방식

연결

  • 기반 프로토콜 : HTTP ( 보통 HTTP/1.1 또는 HTTP/2)

연결 원리

  • HTTP 범위 내에서 연결 일어남
  • 통신 과정
    1. 클라이언트가 EventSourse로 HTTP 요청
    2. 서버가 연결을 끊지 않음
    3. 서버가 이벤트를 텍스트 스트림으로 지속 전송
    4. 클라이언트는 실시간으로 수신만 수행
    5. 연결 끊기면 자동 재연결
  • 방송형 온라인 통신

구조

전체 구조

[브라우저]
  EventSource
      ↓  (HTTP 연결 유지)
[백엔드 서버]
  res.write() 로 이벤트 스트림 전송

백엔드에서 연결

[실시간 체결 데이터]
   ↓
[백엔드]
   ↓ SSE
[프론트]
  • 위의 구조가 흔함
    • 이유 보안 | WS는 노출 위험 큼 단방향 충분 | 서버→클라이언트면 SSE로 충분 안정성 | SSE 자동 재연결 인프라 | HTTP 기반이 운영 편함

송수신 데이터

  • text Stream : event : / data : 형태
  • 이벤트 단위 : 줄 단위 텍스트
  • 단순 이벤트 스트림에 적합

SEE 데이터 포맷 규칙

필드 설명
event 이벤트 이름 (선택)
data 실제 데이터 (필수)
id 이벤트 ID (재연결 시 사용)
retry 재연결 간격(ms)
event: trade
data: {"price":71200,"volume":3}
id: 10291

예시 코드

백엔드 예시

  • 기존 SSE 서버
import express from 'express';

const app = express();

app.get('/sse', (req, res) => {
  // SSE 필수 헤더
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Connection', 'keep-alive');

  // 최초 연결 확인용 이벤트
  res.write(`event: connected\\n`);
  res.write(`data: connected\\n\\n`);

  let count = 0;

  const interval = setInterval(() => {
    count++;

    res.write(`event: tick\\n`);
    res.write(`data: ${JSON.stringify({ value: count, time: Date.now() })}\\n\\n`);
  }, 1000);

  // 클라이언트 연결 종료 처리
  req.on('close', () => {
    clearInterval(interval);
    console.log('SSE client disconnected');
  });
});

app.listen(3000, () => {
  console.log('SSE server running on port 3000');
});
​
포인트 의미
text/event-stream SSE 전용 MIME 타입
res.write 연결을 끊지 않고 데이터 전송
\n\n 이벤트 단위 종료 표시
req.on('close') 클라이언트 이탈 감지

 

프론트엔드 예시 (브라우저)

  • 기본 EventSource 사용
    const es = new EventSource('/sse');
    
    es.onopen = () => {
      console.log('SSE connected');
    };
    
    es.onmessage = (event) => {
      console.log('message', event.data);
    };
    
    es.onerror = (err) => {
      console.error('SSE error', err);
    };
    ​
    
  • 이벤트 타입 별로 받기
    const es = new EventSource('/sse');
    
    es.onopen = () => {
      console.log('SSE connected');
    };
    
    es.onmessage = (event) => {
      console.log('message', event.data);
    };
    
    es.onerror = (err) => {
      console.error('SSE error', err);
    };
    ​

SSE 의 장점이 코드에서 드러나는 부분

  • 자동 재연결 : 네트워크 끊기면 브라우저가 자동 재 시도
  • 단순성 : WebSocket 보다 코드 단순
  • HTTP 기반 : 프록시/보안 설정 유

실무에서 자주 쓰이는 패턴

  • 실시간 체결 스트
event: execution
data: { price, volume, time }
  • 알림
event: notification
data: { title, body }

 

devTool

항목 모습
Network Fetch/XHR
Status 200
상태 Pending 유지
Response 텍스트가 계속 누적
Messages 탭 없음

웹 통신(HTTP)과 온라인 통신(실시간)의 차이점 요약

연결·세션·채널 개념 정리, WebSocket·SSE·Long Polling 방식별 특징과 데이터 포맷(JSON·Binary·Protobuf) 활용 가이드

연결 유지에 따른 비용·스케일링·보안 고려사항 정리


목차

  1. 웹소켓의 개요
  2. 웹소켓의 연결
  3. 웹소켓의 송수신 데이터
  4. 웹소켓 예시 코드

웹 소켓

개요

항목 내용

정의 웹 브라우저와 서버 간의 실시간 양방향 통신 기술
표준 RFC 6455
기반 최초 연결은 HTTP → 이후 전용 프로토콜 전환
  • 웹 소켓은 HTTP로 시작하지만 연결이 수립되면 HTTP가 아닌 WebSocket 전용 프로토콜로 전환

정의

  • 온라인 통신을 위한 “양방향 채널”
  • 서버와 클라이언트가 대등하게 계속 대화하는 통신

연결

통신 원리

  • HTTP를 벗어나 “전용 통신 상태”로 들어감
  • 통신 과정
    1. HTTP로 HandShake 요청
    2. Protocol Upgrade → WebSocket 전환
    3. 연결 유지
    4. 양쪽에서 자유롭게 메시지 송 수신
    5. 명시적 Close 까지 지속
  • 대화형 온라인 통신

연결 주체에 따른 비교

구분 프론트엔드 백엔드

연결 시작 ⭕ (브라우저에서 new WebSocket) ⭕ (서버↔서버, 클라이언트 역할)
연결 대상 서버 다른 서버 / 외부 소켓 서버
주 용도 사용자 실시간 데이터 수신 중계, 집계, 브로드캐스트
UI 직접 반영

일반적인 구조

[브라우저(프론트)]
    ↓ WebSocket
[웹 서버 / 실시간 서버]

역할 설명

프론트엔드 WebSocket 클라이언트 역할
백엔드 WebSocket 서버 역할

백엔드에서 WebSocket을 연결하는 경우

  • 백엔드는 WebSocket “클라이언트”가 됨
[외부 실시간 소스] ← WebSocket → [백엔드] → (가공) → 프론트

상황 설명

외부 시세 수신 거래소/증권소켓에서 실시간 수신
중앙 집계 여러 소스를 하나로 통합
보안 프론트에 직접 노출 금지

프론트 엔드에서 직접 연결하지 않는 이유

  • 백엔드에서 웹소켓 연결해서 프론트에 웹소켓을 하는 방식이 금융권에서는 흔함
[외부 실시간 소켓]
        ↓
     [백엔드]
        ↓ (SSE / WS / API)
     [프론트]

이유 설명

보안 인증 토큰 노출 위험
프로토콜 복잡 바이너리/암호화/서명
트래픽 제어 수천 클라이언트 직접 연결 부담
제어 구독/권한 관리 중앙화

송수신 데이터

  • text : JSON, 문자열
  • Binary : protobuf, 압축 데이터
  • Control : ping/pong/close
  • 고빈도 대용량 양방향에 적합

WebSocket 메시지 구조

{
  "type": "subscribe",
  "channel": "trade",
  "symbol": "AAPL"
}
{
  "type": "trade",
  "symbol": "AAPL",
  "price": 182.31,
  "volume": 100,
  "time": 1710000000000
}

필드 의미

type 메시지 종류
channel 구독 대상
payload 데이터 본문

예시 코드

백엔드 예시

  • 기본 WebSocket 서버포인트 의미
    connection 클라이언트 접속
    message 메시지 수신 이벤트
    send 서버 → 클라이언트 전송
    close 연결 종료
    import WebSocket, { WebSocketServer } from 'ws';
    
    const wss = new WebSocketServer({ port: 8080 });
    
    wss.on('connection', (ws, req) => {
      console.log('Client connected');
    
      // 클라이언트 → 서버
      ws.on('message', (message) => {
        console.log('Received:', message.toString());
    
        // 서버 → 클라이언트 (응답)
        ws.send(
          JSON.stringify({
            type: 'echo',
            data: message.toString(),
            time: Date.now(),
          })
        );
      });
    
      // 연결 종료
      ws.on('close', () => {
        console.log('Client disconnected');
      });
    
      // 에러
      ws.on('error', (err) => {
        console.error('WebSocket error', err);
      });
    });
    
    console.log('WebSocket server running on ws://localhost:8080');
    ​

프론트 엔드 예시 (브라우저)

본 webSocket 연결

const ws = new WebSocket('ws://localhost:8080');

ws.onopen = () => {
  console.log('WebSocket OPEN');

  // 서버로 메시지 전송
  ws.send(
    JSON.stringify({
      type: 'hello',
      payload: 'frontend connected',
    })
  );
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('MESSAGE', data);
};

ws.onerror = (error) => {
  console.error('WebSocket ERROR', error);
};

ws.onclose = (event) => {
  console.log('WebSocket CLOSE', event.code, event.reason);
};
​

 

WebSocket 의 특징이 코드에서 드러나는 부분

  • 양방향 : send / onmessage
  • 연결 유지 : onopen ~ onclose
  • 이벤트 기반 : message / close / error

devTool

항목  모습
Network websocket 항목
Status 101 Switching Protocols
Messages Frames 송·수신 기록
Opcode text / binary

웹 통신(HTTP)과 온라인 통신(실시간)의 기본 원리와 연결 모델 비교, 

연결·세션·채널의 의미 정리

WebSocket·SSE·Long Polling 등 방식별 특징과 데이터 포맷(JSON·Binary·Protobuf) 사용 가이드

연결 유지에 따른 비용·스케일·보안 이슈 및 설계 시 고려사항 요약


목차

  1. 웹 통신과 온라인 통신의 비교
    1. 웹 콩신과 온라인 통신의 차이
  2. 온라인 통신
    1. 정의
    2. 특징
    3. 기본원리
    4. 온라인 통신에서의 "연결"
    5. 주고 받는 데이터 형태
    6. 온라인 통신에서의 메시지
    7. 온라인 통신의 단점과 비용

웹 통신(HTTP 기반)과 온라인 통신(실시간 통신)의 비교

  

구분 웹 통신 (HTTP 기반) 온라인 통신 (실시간 통신)
통신 방식 요청(Request) → 응답(Response) 양방향(Bidirectional) 지속 연결
연결 상태 요청마다 연결 생성/종료 한 번 연결 후 지속 유지
데이터 흐름 클라이언트 주도 서버·클라이언트 모두 가능
실시간성 낮음 높음
지연 시간 상대적으로 큼 매우 낮음
주요 프로토콜 HTTP, HTTPS WebSocket, TCP, UDP
서버 부담 요청 빈도 증가 시 큼 연결 수 관리 부담
사용 예시 게시판, 로그인, 조회 API 채팅, 게임, 주식 시세, 알림

웹 통신(오프라인 통신) 과 온라인 통신의 차이

항목  설명
웹 통신 "필요할 때 요청하고 응답을 받는 구조"
온라인 통신 "항상 연결된 상태에서 즉시 주고받는 구조"
항목  오프라인 통신(HTTP) 온라인 통신
연결 요청마다 생성/종료 연결 유지
주도권 클라이언트 서버·클라이언트
데이터 흐름 단방향 요청 양방향 또는 서버 주도
실시간성 낮음 높음
대표 기술 REST API WebSocket, SSE, TCP
  • 웹 통신 - 정적인 정보 요청에 적합
  • 온라인 통신 - 즉각적인 상태 변화 공유에 적합

온라인 통신

  • “연결을 유지하면서 상태와 이벤트를 실시간으로 공유하는 통신”

정의

  • 연결을 유지한 상태에서 데이터를 지속적으로 주고 받는 통신
  • “항상 연결됨(Connected)”
  • 오프라인/요청형 통신(HTTP 요청-응답)과 대조적

특징

  • 연결 유지 - 한 번 연결되면 끊기 전까지 유지
  • 실시간성 - 데이터 지연이 매우 낮음
  • 상태 기반 - 연결 자체가 상태(state)를 가짐
  • 이벤트 중심 - 데이터 변경이 즉시 전달됨
요소  의미
연결 끊기지 않고 유지되는 통로
상태 연결에 귀속된 정보
이벤트 상태 변화 알림
스트림 이벤트의 연속

기본 원리

  • 계속 유지되는 일련의 과정
    1. 연결 요청 (Handshake)
    2. 연결 수립 (Session 생성)
    3. 데이터 송 · 수신 반복
    4. 연결 종료 (Close)

온라인 통신에서의 “연결”

  • 연결 자체가 리소스
  • 연결 (Connection) : 서로가 살아있음을 인지하는 논리적 통로
  • 세션 (Session) : 연결에 부여된 상태 정보
  • 채널 (Channel) : 실제 데이터가 흐르는 경로

온라인 통신 방식 (웹 기준)

방식  설명  방향
WebSocket 전용 프로토콜 양방향
SSE HTTP 스트림 서버 → 클라이언트
Long Polling 요청 유지 서버 → 클라이언트
TCP Socket 저수준 양방향

주고 받는 데이터 형태

논리적 데이터 형태

형태  설명 예시
이벤트 상태 변화 알림 체결 발생
스트림 연속 데이터 가격 흐름
명령 요청/제어 구독/해제
상태 현재 값 잔고, 포지션

물리적 데이터 포맷

포맷  특징 사용 사례
JSON 가독성 좋음 채팅, 알림
Binary 빠름/압축 금융, 게임
Protobuf 구조화/고속 대규모 실시간
Text Stream 단순 SSE
  • 실시간, 대량 일수록 Binary 비중이 높아짐

온라인 통신에서의 메시지

  • 구성
    • Header : 타입, 길이, 메타정보
    • Body : 실제 데이터
    • Qpcode : 메시지 종류 (text/binary/ping)
  • 예시 (개념)
  • { type: "trade", symbol: "AAPL", price: 182.3, volume: 100 }

온라인 통신의 단점과 비용

  • 서버 부하 : 연결 수만큼 리소스 사용
  • 복잡성 : 상태/에러 처리 필요
  • 보안 : 장시간 연결 관리
  • 스케일링 : 수평 확장 어려움

서로 다른 실행 컨텍스트 간 데이터 전달 개념과 구조적 복사 동작 원리 요약

Web Worker와 Service Worker 메시지 비교(통신 대상·응답 방식·용도) 및 Transferable(ArrayBuffer) 활용 예시 포함

메시지 기반 설계 패턴(type 기반 프로토콜·상태 분리)과 실무 코드 샘플

워커 통신 아키텍처 설계 팁 제공


목차

  1. 메시지의 개념
  2. Web Worker과 Service Worker 메시지 비교
  3. 메시지를 쓰는 이유
  4. 메시지에 담을 수 있는 것
  5. 구조적 복사(Structured Clone) 개념
  6. Web Worker에서의 메시지 흐름
  7. Service Worker에서의 메시지 특징
  8. 메시지 vs API 호출 비교
  9. 핵심
  10. 메시지의 패턴 - 설계

메시지

개념

  • 서로 다른 실행 컨텍스트(스레드/워커/페이지) 사이에서 데이터를 주고 받기 위한 통신 단위
  • 이벤트 기반 데이터 전달
  • 브라우저 내부에서
    • 데이터 직렬화
    • 워커 쪽으로 전달
    • 이벤트로 수신

Web Worker / Service Worker 메시지 비교

구분 Web Worker 메시지 Service Worker 메시지

통신 대상 메인 스레드 ↔ 워커 페이지 ↔ 서비스 워커
기본 메커니즘 postMessage + message 이벤트 postMessage + message 이벤트
호출 방식 함수 호출 ❌ 함수 호출 ❌
전달 형태 데이터 객체 데이터 객체
동작 모델 이벤트 기반 비동기 이벤트 기반 비동기
응답 방식 이벤트로 응답 이벤트로 응답
네트워크 대체 가능 일부 가능(fetch 대체)
주요 용도 계산 결과 전달 상태 알림, 명령 전달

메시지를 쓰는 이유

이유 설명

실행 컨텍스트 분리 워커는 메인 스레드와 메모리 공간이 다름
동기 호출 불가 서로 직접 함수 호출 불가
안전성 스레드 간 데이터 충돌 방지
구조 단순화 명확한 요청/응답 패턴

메시지에 담을 수 있는 것

  • 가능 : 문자열, 숫자, 객체(JSON), 배열, ArrayBuffer
  • 불가능 : 함수, DOM 노드, 클래스 인스턴스(일반적으로)

구조적 복사(Structured Clone) 개념

  • 메시지는 구조적 복사 알고리즘으로 전달 됨
  • 특징
    • 기본 동작 : 데이터 복사해서 전달
    • 참조 공유 : X
    • 원본 수정 영향 : X
    • 비용 : 데이터 크기가 클 수록 증가
  • 예외
    • ArrayBuffer 등은 Transferable 로 전달 가능
      • 복사 X, 소유권 이동 가능 (빠름)

Web Worker에서의 메시지 흐름

  1. 메인 스레드가 “이 데이터 계산해 줘” 메시지 전송
  2. 워커가 message 이벤트 수신
  3. 워커가 계산 수행
  4. 결과를 메시지로 다시 전송
  5. 메인 스레드가 결과 수신 후 UI 반영

Service Worker에서의 메시지 특징

항목 설명

대상 다수 여러 탭/페이지와 통신 가능
식별 필요 어떤 클라이언트인지 구분 필요
용도 상태 전달, 명령 전달
주력 역할 메시지보다 fetch 이벤트가 핵심

메시지 vs API 호출 비교

구분 메시지 API 호출

범위 브라우저 내부 네트워크
지연 매우 낮음 네트워크 지연
실패 원인 코드/라이프사이클 네트워크/서버
사용 목적 내부 작업 분리 서버 통신
  • 메시지 라이프 사이클 연구 필요

핵심

  • 메시지는 스레드/컨텍스트 간 유일한 통신 수단
  • 함수 호출, 공유 메모리 X
  • 이벤트 기반 비동기 통신
  • 데이터 전달이지 “로직 실행”이 아님
  • 공유 메모리에 대한 연구 필요

메시지의 패턴 - 설계

메시지 설계란

  • 워커와 메인 스레드 사이의 프로토콜(API계약)을 정의하는 일
  • 어떤 타입의 메시지를, 어떤 데이터 구조로, 어떤 순서로 주고받을지 결정

메시지 타입

  • 구조 - 권장 포맷
  • type WorkerMessage<T = any> = { type: string; payload?입
  • 타입과 역할 → 위의 구조 안에 type 을 말함
    • 메시지 타입이 곧 “API 엔드포인트” 역할
    타입 방향 역할
    INIT Main → Worker 워커 초기 설정
    TICKS Main → Worker 원시 데이터 배치 전달
    SNAPSHOT Worker → Main 렌더용 결과 반환
    RESET Main → Worker 상태 초기화
    STATS Worker → Main 성능/상태 모니터링
    ERROR Worker → Main 에러 보고
    TERMINATE Main → Worker 작업 중단

상태 분리

단계 설명

INIT 설정은 한 번만
TICKS 데이터만 반복 전달
Worker 내부 상태 유지 (ring buffer 등)

코드 예시

  • Worker 코드
  • self.onmessage = (event) => { const { type, payload } = event.data; switch (type) { case 'INIT': { // 초기 설정 self.config = payload; break; } case 'TICKS': { // 대용량 데이터 처리 const result = processTicks(payload); self.postMessage({ type: 'SNAPSHOT', payload: result, }); break; } case 'RESET': { resetState(); break; } } };
  • 메인 스레드 코드 - Nextjs 클라이언트 컴포넌드
  • const worker = new Worker( new URL('./chart.worker.ts', import.meta.url) ); worker.postMessage({ type: 'INIT', payload: { timeframe: 1000, maxPoints: 2000, }, }); worker.postMessage({ type: 'TICKS', payload: ticks, }); worker.onmessage = (event) => { const { type, payload } = event.data; if (type === 'SNAPSHOT') { updateChart(payload); } };

ArrayBuffer를 쓰는 메세지 예제

  • 전달 메시지 (Transable)
  • worker.postMessage( { type: 'TICKS', payload: buffer, }, [buffer] // 소유권 이동 );
  • Worker 수신

버퍼(Buffer), 스트림(Stream), 스로틀(Throttle)의 목적과 처리 방식을

실무 예시와 표로 정리, 단점·사용처를 비교

실전 코드와 아키텍처 적용 팁


목차

  1. 웹워커
    1. 개념
    2. 필요성
    3. 특징 요약
    4. 사용 예시
  2. 서비스워커
    1. 개념
    2. 핵심 역할
    3. 생명주기
    4. 특징
    5. 사용 예

웹 워커와 서비스 워커

 

구분 Web Worker Service Worker
목적 UI를 막지 않고 무거운 연산을 병렬 처리 네트워크 제어 + 오프라인 + 백그라운드 작업
실행 위치 브라우저 (페이지 내부) 브라우저 (페이지 외부, 백그라운드)
페이지와의 관계 특정 페이지에 종속 페이지와 독립적
생성 시점 JS 코드에서 명시적으로 생성 브라우저에 등록(register) 후 이벤트 기반 실행
종료 시점 페이지 종료 시 함께 종료 페이지 닫혀도 유지 가능 (필요 시 깨어남)
DOM 접근 ❌ 불가 ❌ 불가
window 객체 ❌ 없음 ❌ 없음
통신 방식 postMessage postMessage, Fetch 가로채기
주요 역할 계산, 파싱, 압축, 암호화 등 CPU 작업 캐싱, 오프라인, 푸시 알림, 백그라운드 동기화
네트워크 제어 ❌ 불가 ✅ 가능 (fetch 이벤트 가로채기)
캐시 제어 ❌ 불가 ✅ Cache API 사용
오프라인 지원 ❌ 불가 ✅ 핵심 기능
푸시 알림 ❌ 불가 ✅ 가능
HTTPS 필요 여부 ❌ 불필요 ✅ 필수 (localhost 예외)
사용 난이도 비교적 낮음 비교적 높음 (라이프사이클 복잡)

웹 워커

개념

  • 브라우저의 “메인 스레드(UI스레드)”와 분리된 작업 전용 스레드
    • 브라우저에서 메인(UI) 스레드와 분리된 실행 컨텍스트를 만들어 무거운 js 작업을 UI 렌더링/입력 처리와 분리하는 기능
  • UI 멈춤 없이 연산 처리

필요성

  • js는 기본적으로 싱글 스레드 → 무거운 연산 시
    • 클릭 안 됨
    • 스크롤 끊김
    • 렌더링 지연 발생
  • Web Worker는 이 작업을 백그라운드로 분리

특징 요약

  • DOM에 접근 X (window/document 없음)
  • 메인 스레드와는 메시지(postMessage)로만 통신
    • 메시지 : 서로 다른 실행 컨텍스트(스레드/워커/페이지) 사이에서 데이터를 주고받기 위한 통신 단위 (이벤트 기반 데이터 전달)
  • 계산 전용
  • 상태 오래 유지는 부적
  • 큰 데이터 자주 주고 받으면 직렬화/복사 비용이 생김
    • ArrayBuffer 같은 것은 transferable 로 소유권 이동하면 비용 줄일 수 있음

사용 예

  • 대용량 JSON 파싱
  • 이미지 처리
  • 암호화/해시 계산
  • 실시간 데이터 가공
  • 차트용 데이터 전처

서비스 워커

개념

  • 웹 페이지 네트워크 요청을 가로채는 브라우저 백그러운드 스크립트
  • 웹의 프록시 서버 + 백그라운드 데몬 → 같은 존재

핵심 역할

  • 요청 가로채기 (fetch)
  • 캐싱 전략 적용
  • 오프라인 동작 구현
  • 푸시 알림 수신
  • 백그라운드 동기화

생명주기

단계  설명
install 최초 설치, 캐시 초기화
activate 이전 SW 정리 및 활성화
idle 아무 일 없으면 종료 상태
event fetch/push/sync 발생 시 깨어남
  • 항상 실행 중이 아님 → 이벤트 기반

특징

  • 페이지 없어도 동작 가능
  • 네트워크 요청 제어 가능
  • HTTPS 필수
  • 상태를 오래 들고 있으면 안 됨

사용 예

  • PWA 오프라인 모드
  • API 응답 캐싱
  • 앱처럼 빠른 로딩
  • 푸시 알림
  • 네트워크 실패 대비

+ Recent posts