WebSocket vs HTTP for 파일 전송: A Comparison
Compare WebSocket and HTTP protocols for 파일 전송. Performance benchmarks, use cases, and implementation trade-offs explained.
개인정보 보호법(PIPA) 제29조는 개인정보를 처리하는 시스템에 기술적 보호 조치를 요구합니다. 파일 전송 프로토콜 선택—WebSocket이냐 HTTP냐—은 TLS 1.3 적용 방식, CDN 호환성, 서버 리소스 관리에 직접적인 영향을 미칩니다. 결론부터 말하면, 파일 전송에서는 HTTP가 거의 모든 상황에서 우세합니다.
핵심 프로토콜 차이
HTTP는 무상태(stateless), 요청-응답 방식이며 캐시 가능합니다. HTTP/2는 단일 TCP 연결에서 다중 요청을 처리하고, HTTP/3(RFC 9114)는 QUIC 위에서 동작해 패킷 손실 복구와 0-RTT 재개를 지원합니다. WebSocket(RFC 6455)은 HTTP Upgrade 요청으로 시작해 TCP 연결을 양방향 프레임 기반 프로토콜로 전환합니다. 이 지속적인 채널은 인터랙티브 앱에 강력하지만, 파일 전송처럼 흐름이 압도적으로 단방향인 경우엔 구조적으로 불리합니다.
처리량과 지연 시간 벤치마크
도쿄 클라이언트와 US-East 서버 간 기가비트 링크 벤치마크: HTTP/1.1 단일 PUT은 40~80 Mbps, HTTP/2 멀티파트(8개 병렬 스트림, 8MB 파트)는 400~800 Mbps, HTTP/3 over QUIC는 패킷 손실 환경에서 10~30% 더 우세, WebSocket 바이너리 프레임은 단일 연결 흐름 제어 병목으로 200~500 Mbps에 그칩니다. WebSocket이 빠르지 않은 이유는 내부적으로 여전히 TCP를 사용하지만 병렬 HTTP 요청보다 연결을 덜 효율적으로 사용하기 때문입니다.
청크 업로드와 재개 가능 업로드
HTTP에는 잘 정의된 청크 업로드 표준이 있습니다. tus.io 프로토콜은 Upload-Offset 헤더와 함께 HTTP PATCH를 사용하고, S3 Multipart Upload는 파트 번호와 ETag를 활용합니다. 두 방식 모두 네트워크 중단 시에도 IndexedDB에 저장된 상태 덕분에 마지막 성공 청크부터 재시작할 수 있습니다. WebSocket 청크는 애드혹 방식입니다. 자체 프레이밍, 시퀀스 번호, 확인 응답을 직접 정의해야 하며, 재개 로직은 대부분 검증된 HTTP 옵션보다 취약합니다.
CDN과 에지 호환성
Cloudflare, CloudFront, Fastly, Akamai 같은 CDN은 HTTP 응답을 에지 PoP에서 캐시해 글로벌 다운로드 시간을 절반으로 줄이는 경우가 많습니다. WebSocket 트래픽은 CDN을 통과하지만 캐시되지 않으며, 많은 기업 프록시가 WebSocket Upgrade를 차단하거나 제한합니다. TLS 프록시를 사용하는 기업 네트워크는 WebSocket을 완전히 차단할 수 있습니다. 글로벌 사용자를 대상으로 하는 파일 전송 서비스라면 이것만으로도 HTTP를 선택할 충분한 이유가 됩니다.
서버 측 리소스 사용
HTTP 서버는 요청이 단명하기 때문에 최소한의 메모리로 수천 개의 동시 연결을 처리합니다. Nginx, Caddy, Go의 net/http는 노드당 10,000개 이상의 동시 연결을 지원합니다. WebSocket 연결은 각각 TCP 소켓, 읽기/쓰기 버퍼, 애플리케이션 상태를 보유하는 장수 연결입니다. 대규모 WebSocket 플릿은 ulimit, TCP keepalive, 연결당 메모리에 대한 세밀한 조정이 필요하며, Kubernetes의 롤링 배포 중 스티키 세션 문제도 발생합니다.
프리사인 URL과 직접 스토리지 업로드
파일 전송에서 HTTP의 핵심 기능은 프리사인 URL입니다. 앱이 S3, R2, GCS를 직접 가리키는 서명된 URL을 생성하면 클라이언트는 오브젝트 스토리지로 직접 업로드합니다. 앱 서버는 바이트를 처리하지 않습니다. WebSocket에는 이에 상응하는 기능이 없습니다. WebSocket 업로드는 앱 서버를 통해 프록시된 후 스토리지에 기록되어 대역폭 비용이 두 배가 됩니다. 10GB WebSocket-앱-S3 파이프라인은 서버 대역폭 20GB를 소비하지만, HTTP 직접 업로드는 소량의 메타데이터 호출만 사용합니다.
WebSocket이 실제로 유용한 경우
WebSocket은 파일 인접 워크플로에 잘 맞습니다. 탭·기기 간 실시간 업로드 진행 알림, yjs나 Automerge 같은 CRDT 라이브러리를 사용하는 협업 편집(실제 대용량 에셋은 HTTP로 전송), WebRTC P2P 전송을 위한 라이브 시그널링 등입니다. 패턴은 명확합니다: WebSocket은 이벤트에, HTTP는 바이트에.
HTTP/2와 HTTP/3의 장점
HTTP/2(RFC 7540)와 HTTP/3(RFC 9114)는 WebSocket이 활용하던 격차를 대부분 해소합니다. HTTP/2는 단일 TCP 연결에서 요청을 멀티플렉싱하고, HTTP/3는 QUIC 위에서 동작해 스트림별로 패킷 손실을 처리합니다. Server-Sent Events(EventSource)는 WebSocket보다 간단하게 HTTP 기반 서버-클라이언트 단방향 푸시를 제공합니다.
보안과 출처 제어
HTTP의 보안 체계는 성숙합니다. CORS가 업로드·다운로드 출처를 제어하고, CSP가 클라이언트 페치를 제한하며, TLS 1.3이 전송을 보호합니다. 프리사인 URL에는 변조 방지를 위한 HMAC 서명이 포함되며 만료 시간을 설정할 수 있습니다. WebSocket은 출처 제어가 취약합니다. Origin 헤더는 비브라우저 클라이언트에 의해 스푸핑될 수 있어 크로스사이트 WebSocket 하이재킹 공격에 노출될 수 있습니다.
HexaTransfer는 HTTP + 청크 멀티파트 + S3 직접 업로드 아키텍처를 사용하며, 실시간 진행률이나 수신자 알림 이벤트에는 선택적으로 WebSocket을 추가 계층으로 활용합니다.
https://hexatransfer.com — 무료, 계정 불필요, 최대 10GB.
엔드투엔드 암호화로 대용량 파일을 안전하게 전송
엔드투엔드 암호화로 최대 10GB의 파일을 무료로 전송하세요. 계정이 필요하지 않습니다. 업로드 전에 브라우저에서 파일이 암호화되어 다른 사람은 읽을 수 없습니다.
파일 보내기