Range Request로 대용량 파일 끊김 없이: 이어받기와 병렬 다운로드의 원리

큰 파일을 통째로 받지 않아도 되는 이유

수십 GB짜리 게임 패치나 소프트웨어 배포 파일을 받다가 중간에 끊기면, 처음부터 다시 받아야 한다면 곤란하죠. 그래서 HTTP에는 파일의 필요한 부분만 요청하는 방법이 있습니다. Range 요청이에요. RFC 9110은 Range를 두고 "큰 표현의 부분 검색(partial retrieval)"을 위한 기능이라고 설명합니다. 취소된 요청이나 끊긴 연결로 중단된 데이터 전송이 흔한 상황에서, 이미 받은 부분은 두고 나머지만 다시 요청하는 편이 전체를 다시 받는 것보다 낫다는 것이죠.

MDN도 같은 맥락으로 짚습니다. Range 요청은 "서버에 리소스의 일부를 클라이언트로 보내 달라고 요청하는 것"으로, 랜덤 액세스가 필요한 미디어 플레이어, 큰 파일의 일부만 필요한 데이터 도구, 일시정지와 재개를 지원하는 다운로드 매니저에 유용하다고 해요. 이 글은 Range 요청이 어떻게 생겼고, 이어받기와 병렬 다운로드가 어떻게 가능해지는지를 표준 문서 기준으로 정리합니다.

Range 요청의 문법: bytes=0-1023에서 206까지

먼저 서버가 Range를 지원하는지는 응답의 Accept-Ranges 헤더로 확인합니다. MDN 기준 이 헤더가 none이 아닌 값을 가지면 서버가 Range 요청을 지원하고, 아예 없으면 부분 요청을 지원하지 않는다는 뜻이에요. 값으로는 Accept-Ranges: bytes가 쓰이는데, MDN 설명대로 현재 바이트 외의 단위는 없습니다. RFC 9110도 바이트 범위 단위를 규정하고 있고요.

요청은 Range 헤더에 원하는 범위를 적습니다. MDN 예시처럼 Range: bytes=0-1023이면 앞의 1024바이트를 달라는 뜻이에요. 그러면 서버는 206 Partial Content로 응답합니다. 이때 Content-Length는 전체 크기가 아니라 요청한 범위의 크기이고, Content-Range 헤더가 이 부분이 전체 리소스의 어디에 해당하는지를 알려줘요. 예를 들어 Content-Range: bytes 0-1023/146515는 14만여 바이트 중 앞 1024바이트라는 의미입니다. 206과 416 같은 상태 코드 자체는 HTTP 상태 코드 글에서 더 다뤘습니다.

이어받기와 병렬 다운로드의 원리

Range의 진가는 두 가지 시나리오에서 드러납니다. 첫째는 이어받기예요. 다운로드가 중간에 끊겨 파일의 일부만 저장돼 있다면, RFC 9110 표현대로 "그 표현의 나머지를 이어서 요청"하면 됩니다. 이미 받은 곳 다음 바이트부터 Range로 청하는 것이죠. 다만 조건이 하나 있습니다. MDN은 "리소스의 더 많은 부분을 이어서 요청할 때는 마지막 조각을 받은 이후 리소스가 변경되지 않았음을 보장해야 한다"고 짚어요.

그 보장을 해 주는 것이 If-Range입니다. RFC 9110은 If-Range를 두고 "두 번째 요청을 단축(short-circuit)"한다고 설명하고, MDN은 더 구체적으로 "조건이 충족되면 206으로 요청한 부분을, 충족되지 않으면 200으로 전체 리소스를 돌려준다"고 정리합니다. 파일이 그대로면 이어받고, 바뀌었으면 통째로 다시 받게 해 안전하게 재개하는 셈이죠. 둘째는 병렬 다운로드입니다. MDN 기준 Range: bytes=0-50, 100-150처럼 여러 구간을 한 번에 요청하거나, 구간을 나눠 동시에 여러 요청을 보내면 여러 조각을 나란히 받아 속도를 끌어올릴 수 있어요. 스피디 CDN 백서도 50GB 이상의 게임 패치 배포에서 클라이언트가 특정 바이트 범위만 요청하면 그 부분만 전달해, 중단 후 재개와 병렬 다운로드가 가능하다고 밝힙니다.

실패 신호와 조건: 416·GET·장기 TTL

Range 요청이 늘 성공하는 것은 아닙니다. 범위가 리소스 밖이면 서버는 416 Range Not Satisfiable로 응답해요. RFC 9110은 이를 "요청의 Range 헤더에 담긴 범위 집합이 거부됐다"고, MDN은 "요청한 범위 값이 리소스의 범위와 하나도 겹치지 않는다"고 설명합니다. 예를 들어 모든 범위의 시작 바이트가 리소스 길이보다 크면 이 코드가 나오죠. 또 하나 알아 둘 점은 RFC 9110 기준 Range 처리가 정의된 메서드는 GET뿐이라는 것입니다.

CDN 관점에서 Range는 대용량 파일 전략의 핵심입니다. 스피디 CDN 백서는 대용량 파일에 Range Request와 함께 장기 TTL을 유지해, 최초 접속 이후에는 엣지 캐시에서만 응답되도록 설계함으로써 출시 시점 이후의 오리진 부하를 최소화한다고 밝혀요. 큰 파일을 엣지에 오래 캐시해 두면, 수많은 사용자가 각자 필요한 바이트 범위를 요청해도 오리진까지 갈 일이 줄어드는 셈입니다. TTL 설계 자체는 Cache-Control TTL 설계 글에서 더 다뤘습니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)