Logo

3장 다운로드 경로: 병렬 다운로드, 복구 및 재조립(핵심)

수신자에게 "더 빠르다"는 주로 두 가지로 나타납니다. 여러 청크를 병렬로 가져와 처리량을 높이는 것, 그리고 약한 네트워크나 네트워크 전환 상황에서도 처음부터 다시 시작하지 않고 복구할 수 있는 것입니다. 엔지니어링 관점에서 다운로드 경로는 업로드 경로와 대칭을 이룹니다.

3.1 다운로드 객체와 매니페스트

  • 다운로드하기 전에 클라이언트는 매니페스트를 가져와 전체 청크 수, 순서, 각 객체의 위치를 확인하는 것이 좋습니다(SHOULD).
  • 매니페스트는 각 청크의 위치를 고유하게 특정할 수 있어야 합니다(MUST). 객체 키 규칙이나 이에 상응하는 인덱스를 사용합니다.

3.2 병렬 다운로드

  • 클라이언트는 대역폭 상한에 가까워지도록 여러 청크를 동시에 다운로드하는 것이 좋습니다(SHOULD).
  • 클라이언트는 동시 연결 수를 제한해서 사용하고, 오류율이 높아지면 이를 줄이는 것이 좋습니다(SHOULD).
  • 지역 간 RTT가 클수록 동시 다운로드의 이점이 더 커지는 경우가 많습니다. 단일 연결은 RTT와 지터의 영향을 더 쉽게 받기 때문입니다.

3.3 이어받기 가능한 다운로드

  • 클라이언트는 완료된 청크 집합(예: 비트맵 / 인덱스 집합)을 기록할 수 있어야 합니다(MUST).
  • 중단된 뒤에는 파일 전체를 다시 다운로드하지 않고 누락된 청크만 가져오는 것이 좋습니다(SHOULD).
  • 서버가 다운로드 횟수 제한을 적용하는 경우, 클라이언트는 복구 중 중복 다운로드를 최소화하여 횟수가 낭비되지 않도록 하는 것이 좋습니다(SHOULD).

3.4 재조립

  • 클라이언트는 chunkIndex 순서대로 출력 파일을 재조립해야 합니다(MUST).
  • 클라이언트는 스트리밍 쓰기 / 점진적 재조립을 사용해 메모리 사용량의 최대치를 줄이는 것이 좋습니다(SHOULD). 특히 매우 큰 파일에서 그렇습니다.
  • 여러 파일을 묶어 패키징한 경우, 클라이언트는 파일별로 출력하거나 컨테이너 형식을 사용할 수 있습니다(MAY). 제품 설계에 따라 달라집니다.

3.5 무결성 검사(요약)

  • 다운로드가 끝나면 클라이언트는 청크를 검증하는 것이 좋습니다(SHOULD). 예: 해시/길이 일치 여부.
  • 검증에 실패하면 반드시 실패 시 차단 방식으로 처리하고(MUST) 해당 청크를 다시 받아야 합니다.
  • 암호화/인증 실패와 관련한 경계는 보안 및 개인정보 보호 백서의 관련 섹션을 참조하세요.