앞선 글에서 NestJS로 대용량 파일을 OOM 없이 내려보내는 방법을 정리했다.이번 글에서는 그 흐름을 영상 스트리밍 관점으로 확장한다. 영상 스트리밍은 단순히 큰 파일을 다운로드하는 기능이 아니다. 사용자가 보고 있는 구간만 빠르게 전달하고, 네트워크 상태에 따라 품질을 조절하고, 필요한 순간에 필요한 byte만 요청하는 구조다.1. 영상은 왜 통째로 받지 않을까2시간짜리 영상 파일이 20GB라고 해보자. 이 파일을 재생하기 전에 전부 다운로드해야 한다면 사용자는 영상을 보기까지 오래 기다려야 한다.20GB 영상 전체 다운로드 ↓다운로드 완료 대기 ↓재생 시작스트리밍 서비스는 이렇게 동작하지 않는다. 처음 재생에 필요한 앞부분만 먼저 받고, 사용자가 보는 동안 뒤쪽 데이터를 계속 받아온다.처음..

기본 스트림/백프레셔 개념은 01편을 참고.1. 넷플릭스/유튜브가 끊김 없이 재생되는 원리유튜브는 2GB짜리 영상 파일을 통째로 보내지 않는다.파일 전체 (2GB):[-------------------------------------------]실제 전송:[초반 30초 분량] → 재생 시작[다음 30초] → 재생 중에 미리 받아놓음 (프리패치)[그 다음 30초] → 계속 흘러들어옴이걸 가능하게 하는 게 HTTP Range Request + 스트리밍이다.2. Range 요청 구현import http from 'http';import { createReadStream, statSync } from 'fs';import path from 'path';const server = http.create..

1. DNS란도메인 이름을 IP 주소로 변환하는 분산 데이터베이스 시스템이다.사람: "naver.com" → 외우기 쉬움컴퓨터: "xxx.xxx.xxx.xxx" → 실제 통신에 사용전 세계에 하나의 DNS 서버가 있었다면 단일 장애점이 된다. 그래서 계층적으로 분산되어 있다.2. DNS 계층 구조 [루트 DNS 서버] (13개 클러스터, .으로 끝나는 최상위) | ┌───────────────┼───────────────┐ [.com TLD] [.net TLD] [.kr TLD] ← Top-Level Domain 서버 | [naver.com 권..

1. TCP vs UDP 핵심 차이항목 TCP UDP연결3-way handshake 필요연결 없음신뢰성보장 (재전송, 순서 보장)없음 (유실, 순서 뒤바뀜 가능)흐름 제어있음 (백프레셔)없음헤더 크기20~60 바이트8 바이트속도느림 (핸드셰이크, ACK 대기)빠름연결 수립 지연~1 RTT (HTTP/2), ~1.5 RTT (HTTP/1)0 RTT적합한 용도파일 전송, HTTP, DB게임, 음성통화, DNS, 스트리밍UDP가 빠른 이유: 보내고 끝. ACK 기다리지 않는다. 연결 상태를 유지하지 않는다.UDP가 불안정한 이유: 그래서 패킷이 유실되거나 순서가 바뀌어도 재전송하지 않는다.2. UDP 헤더 구조0 8 16 24 32 (비트)┌────────────..

1. IPv4의 한계IPv4는 32비트 주소 체계다.32비트 → 2³² = 약 43억 개2011년에 이미 IANA(인터넷 주소 관리기관)의 IPv4 주소가 고갈됐다.지금까지 버텨온 건 NAT(사설 IP) 덕분이다.2. IPv6 기본 구조IPv6는 128비트 주소 체계다.128비트 → 2¹²⁸ = 약 340조 × 1조 × 1조 개표기: 16비트씩 콜론으로 구분, 16진수2001:0db8:85a3:0000:0000:8a2e:0370:7334축약 규칙:1. 연속된 0000은 :: 으로 생략 (한 번만)2. 각 그룹의 앞 0 생략2001:db8:85a3::8a2e:370:7334IPv4 vs IPv6 비교항목 IPv4 IPv6주소 길이32비트128비트표기10진수 점 구분16진수 콜론 구분주소 수약 43억사실상 ..

1. HTTP가 항상 정답은 아니다HTTP는 범용적이고 편하지만, 모든 상황에 최적은 아니다.상황 HTTP의 한계실시간 양방향 통신요청-응답 구조라 서버 → 클라이언트 능동 전송 불가 (WebSocket으로 우회)초저지연 게임 서버헤더 오버헤드 (수백 바이트), TCP 재전송 지연내부 서비스 간 통신HTTP 헤더가 불필요한 오버헤드IoT / 임베디드메모리가 적어서 HTTP 파서 올리기 부담대용량 바이너리Base64 인코딩 오버헤드이런 상황에서 커스텀 프로토콜을 설계한다.2. 프로토콜 설계의 핵심: 패킷 구조패킷 = 헤더(메타데이터) + 바디(실제 데이터)헤더에 어떤 정보를 넣느냐가 프로토콜의 핵심이다.[고정 헤더: 12바이트]├── version (1바이트): 프로토콜 버전├── type (..