큰 파일 다운로드를 중간부터 재개하려 합니다. Range만 보내면 이전 파일과 새 파일의 바이트가 섞이지 않나요?

Range는 일부 바이트를 요청하는 기능이고 그 범위가 이전에 받던 같은 표현인지 보장하는 기능은 아닙니다. 파일 버전 validator와 If-Range 등을 사용해 변경되면 전체를 다시 받는 계약이 필요합니다.

동작 원리와 전제

앞부분을 받은 뒤 파일 내용이 바뀌었는데 같은 offset부터 새 파일을 이어 붙이면 손상됩니다. ETag·길이·Content-Range와 응답 상태를 확인하고 206 부분 응답과 200 전체 응답을 구분합니다. 서버가 Range를 무시할 수 있으므로 무조건 append하지 않습니다.

선택과 실패 처리

압축된 표현과 원본 바이트 offset을 섞지 않고 동일 인코딩·버전 기준을 유지합니다. 요청 범위가 유효하지 않으면 416 같은 응답을 처리합니다. 여러 범위 요청과 큰 범위는 서버 비용을 만들 수 있어 상한을 둡니다.

구체적인 사례와 검증

클라이언트는 받은 길이만 보고 이어 붙이지 않고 응답의 Content-Range 시작점이 요청한 offset과 맞는지 검사합니다. 서버가 200을 반환했다면 기존 부분 파일을 그대로 append하지 않고 전체 다운로드로 처리해야 합니다. 중간 파일에 버전·원래 길이·현재 완료 범위를 저장하면 프로세스 재시작 후 같은 파일인지 확인할 수 있습니다. 부분 데이터가 정상이어도 마지막 파일의 해시를 확인해야 빠진 범위나 잘못된 조합을 찾을 수 있습니다. 파일이 매우 크면 검증도 스트리밍으로 수행하고, 인증 URL 갱신이 새 객체 버전을 가리키는 경우에는 안전하게 처음부터 다시 받습니다.

파일 변경·연결 중단·서버의 전체 응답·잘못된 범위·최종 checksum을 시험합니다. 재개 성공은 받은 바이트 수뿐 아니라 최종 파일의 무결성입니다. 인증 URL이 만료되면 새 자격을 얻더라도 같은 파일 버전인지 다시 확인해야 합니다.