01-transfer — 파일은 어떻게 네트워크를 건너오는가
파일 전송은 HTTP 한 번이 아니다. 큰 파일은 잘라서(multipart/range) 보내고, 끊기면 이어서(resumable) 보내고, 멀리 보내려면 캐시(CDN)에 얹고, 보안이 필요하면 서명(presigned/signed URL)으로 잠근다. 이 챕터는 그 모든 결정의 레이어를 분해한다.
한 줄 답 (Pyramid Top)
“전송”은 단일 프로토콜이 아니라 6개의 결정 축이다 —
① 프로토콜 ② 분할 ③ 재개 ④ 분배 ⑤ 보안 ⑥ 무결성. 이 축들의 조합이 곧 5GB 동영상을 5분 안에 안전하게 받게 만드는 정답이다.
Why — 왜 “전송”을 따로 챕터로 빼는가
전송은 파일 도메인의 가장 자주 깨지는 지점이다. 이유:
- 크기 비대칭: 텍스트 1KB부터 4K 비디오 50GB까지 6자릿수 스펙트럼.
- 네트워크 비대칭: 데이터센터 10Gbps ↔ 모바일 LTE 5Mbps, RTT 5ms ↔ 300ms.
- 장애 비대칭: 작은 파일은 재시도 1회면 끝, 큰 파일은 재시도 1회마다 수 분의 비용.
- 비용 비대칭: S3 Egress는 GB당 ~$0.09. 잘못 캐시하면 월 단위 청구서가 5배 튄다.
따라서 어떤 프로토콜로, 어떻게 잘라서, 어디서 캐시하고, 어떻게 잠그느냐가 그 어떤 코덱 선택보다 사용자 체감을 크게 좌우한다.
How — 어떻게 정리했나
이 챕터는 6개 축을 6개 문서로 나눴다. 각 문서는 한 축을 깊게 본다.
| # | 파일 | 다루는 축 | 다루는 질문 |
|---|---|---|---|
| 1 | 01-http-basics.md | 프로토콜 | HTTP/1.1 vs 2 vs 3, 헤더, 캐시 헤더(ETag/Cache-Control)는 어떻게 다른가? |
| 2 | 02-multipart-and-range.md | 분할 | 5GB 영상은 어떻게 잘라 올리고, 어떻게 잘라 받는가? |
| 3 | 03-resumable-tus.md | 재개 | 95% 올라간 업로드가 끊기면 어떻게 이어붙이는가? |
| 4 | 04-cdn-signed-urls.md | 분배·보안 | CDN은 무엇을 캐시하고, 서명 URL은 어떻게 잠그는가? |
| 5 | 05-other-protocols.md | 프로토콜 | FTP/SFTP/WebDAV는 왜 거의 안 쓰이는가? |
| 6 | 06-integrity-and-checksum.md | 무결성 | 받은 파일이 받기 전과 같다고 어떻게 증명하는가? |
What — 핵심 개념 한 줄 요약
| 개념 | 한 줄 요약 |
|---|---|
| HTTP/1.1 keep-alive | TCP 한 번 열고 N번 요청 — head-of-line blocking |
| HTTP/2 multiplexing | 하나의 TCP 위에 N개 스트림 — 헤더 압축(HPACK) |
| HTTP/3 QUIC | UDP 위에 0-RTT, 패킷 손실이 다른 스트림 막지 않음 |
| multipart/form-data | 브라우저 <input type=file>의 직렬화 포맷 (RFC 7578) |
| S3 Multipart Upload | 5MB~5GB 파트로 잘라 병렬 업로드 후 합치는 S3 API |
| HTTP Range | Range: bytes=0-1023 으로 일부만 요청 — 비디오 시킹 핵심 |
| tus.io | 재개 가능 업로드 표준, PATCH + Upload-Offset |
| CDN | 사용자 가까운 PoP에 캐시, Origin은 보호 |
| Presigned URL | 서버가 서명한 임시 URL — 클라이언트가 S3에 직접 업/다운로드 |
| CloudFront Signed URL | CDN 레이어에서 재생 권한을 잠그는 서명 (Custom Policy 가능) |
| ETag | 파일 식별자 — 단일 객체는 MD5, multipart는 MD5의 MD5 |
| Content-MD5 | 업로드 시 무결성 증명, S3가 검증 후 거부 가능 |
What-if — 잘못 설계하면
| 함정 | 결과 |
|---|---|
| HTTP/1.1로 100개 작은 이미지 동시 로드 | 6개씩 직렬 — TTFB가 사용자 체감의 80% |
| 5GB 파일을 단일 PUT으로 | 90% 진행 후 끊기면 처음부터. 비용도 그만큼 |
| presigned URL 만료 1주일 | URL이 슬랙·이메일에 떠다니다 어느 봇이 긁어감 |
| CDN 캐시 만료 너무 길게 + 무효화 안 함 | 잘못된 영상이 24시간 동안 재생 |
| ETag로 데이터 중복 검사 | multipart 업로드 객체는 MD5가 아니라서 같은 파일이 다른 ETag |
Insight — 흥미로운 이야기
“S3 Multipart Upload는 1990년대 FTP의 RESUME에 클라우드 옷을 입힌 것”
FTP에는
REST(restart) 명령어가 있었다. 끊긴 지점부터 이어 받는 기능. S3는 같은 아이디어를 서버 측 상태(UploadId) 로 끌어올렸을 뿐이다. 새로운 발명이 아니라 오래된 패턴을 객체 스토리지에 이식한 것.
“presigned URL은 영원히 살지 않는다 — 그래서 다행이다”
AWS 처음 쓰는 팀이 가장 자주 하는 실수: presigned URL의 만료를 7일로 박아둔다. 그 URL이 한 번 슬랙에 올라가면 7일 동안 전 세계 누구나 그 파일에 접근 가능하다. 실사용 예: 업로드 5분, 다운로드 1시간 (이 챕터 4번 문서 참조).
다음 챕터로 가는 다리
이 챕터의 HTTP Range 개념은 다음 챕터들로 연결된다:
02-media-image→ progressive JPEG의 부분 디코딩03-media-video→ MP4의moov박스가 앞에 있어야 시킹 가능06-streaming→ HLS/DASH의 세그먼트가 결국 Range 요청의 미학적 변형
한 단락 요약
전송은 한 가지 결정이 아니라 6개 축의 조합이다. HTTP의 어떤 버전을, 어떤 분할 단위로, 어떤 재개 방식으로, 어떤 분배 망 위에, 어떤 서명을 얹어, 어떤 무결성 증명과 함께 보낼 것인가. 이 챕터의 6개 문서는 그 축들을 하나씩 깊게 본다 — 그리고 마지막엔 5GB 동영상이 어떻게 5분 안에 사용자 폰까지 안전하게 도착하는가에 답한다.