2장 업로드 경로: 청킹, 동시성 및 재개(키)

2.1 청킹

• 클라이언트는 파일을 여러 청크로 분할해야 합니다. 청크는 업로드/재시도를 위한 최소 단위입니다.
• 청크는 동시성 예약 및 상태 표현을 단순화하기 위해 고정 크기(또는 파일별 크기 정책)를 사용해야 합니다.
• 즉각적인 이점: 오류가 발생하면 전체 파일이 아닌 하나의 청크에만 영향을 미칩니다.

2.2 병렬 업로드

동시성의 목적은 "더 많은 스레드"가 아니라 실제 네트워크에서 단일 연결의 세 가지 실질적인 제한을 피하는 것입니다.

• 느린 시작 및 창 증가: 특히 지역 간 RTT가 높은 경우 단일 연결이 천천히 증가합니다.
• 링크 지터: 한 연결의 지터로 인해 전체 속도가 저하될 수 있습니다. 동시성은 효과를 부드럽게 합니다.
• 흐름별 형성: 일부 네트워크는 단일 흐름을 제한합니다. 여러 흐름이 대역폭 한도에 가까워질 수 있습니다(규정 준수 제약 내에서).

• 클라이언트는 제한된 동시성(예: 4–12)을 사용해야 하며, 메모리 급증을 방지하기 위해 더 약한 장치에서는 동시성을 낮추어야 합니다.
• 클라이언트는 동시성을 조정할 수 있습니다. 처리량이 증가하면 증가합니다. 오류율이 높아지면 감소합니다.

2.3 멱등성 및 재시도

• 동일한 청크의 반복 업로드는 멱등적이어야 합니다. 중복 제출로 인해 이미 완료된 상태가 손상되어서는 안 됩니다.
• 서버는 (transferId, fileId, ChunkIndex) 또는 동등한 제약 조건을 사용하여 고유성을 적용해야 합니다.
• 클라이언트는 지수 백오프 재시도를 구현해야 합니다. 실패는 실패한 청크만 재시도해야 합니다.

2.4 재개 가능한 업로드

• 서버는 "이미 업로드된 청크"에 응답할 수 있어야 하며, 따라서 클라이언트는 완료된 청크를 건너뛸 수 있습니다.
• 업로드된 세트는 상태 크기가 청크 수에 따라 선형적으로 증가하는 것을 방지하기 위해 비트맵/범위 세트로 표시되어야 합니다.
• 속도 이점: 네트워크 중단, 브라우저 충돌 또는 네트워크 전환 후 재개가 0%에서 다시 시작되지 않습니다.

2.5 “업로드하는 동안 공유”(선택 사항)

• 시스템은 전송 작업 흐름을 가속화하기 위해 업로드가 진행 중인 동안 사용 가능한 전송 식별자와 공유 링크를 생성할 수 있습니다.
• 업로드가 완료되기 전에 공유가 허용되는 경우 수신자에게 표시되는 내용이 명시되어야 합니다. 즉, 불완전한 콘텐츠는 아직 다운로드할 수 없거나 진행 상황만 표시됩니다.