Amazon S3에서 객체 무결성 확인
Amazon S3는 체크섬 값을 사용하여 업로드하거나 다운로드하는 데이터의 무결성을 확인합니다. 또한 Amazon S3에 저장하는 모든 객체에 대해 다른 체크섬 값을 계산하도록 요청할 수 있습니다. 데이터를 업로드, 복사 또는 일괄 복사할 때 사용할 체크섬 알고리즘을 선택할 수 있습니다.
데이터를 업로드하면 Amazon S3는 서버 측에서 체크섬을 계산하기 위해 선택한 알고리즘을 사용하고, 객체를 저장하고 체크섬을 객체 메타데이터의 일부로 저장하기 전에 제공된 값으로 검증합니다. 이 검증은 단일 파트 및 멀티파트 업로드 모두에 대해 암호화 모드, 객체 크기 및 스토리지 클래스에서 일관되게 작동합니다. 그러나 데이터를 복사하거나 일괄 복사하면 Amazon S3는 소스 객체의 체크섬을 계산하여 대상 객체로 이동합니다.
참고
단일 파트 또는 멀티파트 업로드를 수행할 때 필요에 따라 사전 계산된 체크섬을 요청의 일부로 포함하고 전체 객체 체크섬 유형을 사용할 수 있습니다. 여러 객체에서 사전 계산된 값을 사용하려면 AWS CLI 또는 AWS SDK를 사용합니다.
지원되는 체크섬 알고리즘 사용
Amazon S3를 사용하면 업로드 중에 데이터를 검증할 체크섬 알고리즘을 선택할 수 있습니다. 그러면 지정된 체크섬 알고리즘이 객체와 함께 저장되며 다운로드 중에 데이터 무결성을 검증하는 데 사용할 수 있습니다. 다음 보안 해시 알고리즘(SHA) 또는 순환 중복 검사(CRC) 체크섬 알고리즘 중 하나를 선택해 체크섬 값을 계산할 수 있습니다.
-
CRC-64/NVME(
CRC64NVME
) -
CRC-32(
CRC32
) -
CRC-32C(
CRC32C
) -
SHA-1(
SHA1
) -
SHA-256(
SHA256
)
또한 Content-MD5 헤더를 사용하여 각 요청에 체크섬을 제공할 수 있습니다.
객체를 업로드할 때 사용할 알고리즘을 지정합니다.
-
AWS Management Console을 사용하는 경우 사용할 체크섬 알고리즘을 선택합니다. 필요에 따라 객체의 체크섬 값을 지정할 수 있습니다. Amazon S3가 객체를 수신하면 지정한 알고리즘을 사용하여 체크섬 값을 계산합니다. 두 체크섬 값이 일치하지 않으면 Amazon S3가 오류를 생성합니다.
-
SDL를 사용할 경우 다음 사항에 유의해야 합니다.
-
ChecksumAlgorithm
파라미터를 Amazon S3에서 사용할 알고리즘으로 설정합니다. 사전 계산된 체크섬이 이미 있는 경우 체크섬 값을 AWS SDK에 전달하면 SDK가 요청에 값을 포함합니다. 체크섬 값을 전달하지 않거나 체크섬 알고리즘을 지정하지 않으면 SDK는 자동으로 체크섬 값을 계산하고 무결성 보호를 제공하기 위해 요청과 함께 체크섬 값을 포함합니다. 개별 체크섬 값이 체크섬 알고리즘의 설정 값과 일치하지 않는 경우 Amazon S3에서BadDigest
오류와 함께 요청이 실패합니다. -
업그레이드된 AWS SDK를 사용하는 경우 SDK가 체크섬 알고리즘을 선택합니다. 그러나 이 체크섬 알고리즘을 재정의할 수 있습니다.
-
체크섬 알고리즘을 지정하지 않고 SDK도 체크섬을 계산하지 않는 경우 S3는 CRC-64/NVME(
CRC64NVME
) 체크섬 알고리즘을 자동으로 선택합니다.
-
-
REST API를 사용하는 경우
x-amz-sdk-checksum-algorithm
파라미터를 사용하면 안 됩니다. 그 대신 알고리즘별 헤더 중 하나를 사용합니다(예:x-amz-checksum-crc32
).
Amazon S3에 이미 업로드된 객체에 이러한 체크섬 값을 적용하려면 객체를 복사하고 기존 체크섬 알고리즘을 사용할지, 새 체크섬 알고리즘을 사용할지 지정하면 됩니다. 알고리즘을 지정하지 않으면 S3는 기존 알고리즘을 사용합니다. 소스 객체에 지정된 체크섬 알고리즘 또는 체크섬 값이 없는 경우 Amazon S3는 CRC-64/NVME 알고리즘을 사용하여 대상 객체의 체크섬 값을 계산합니다. S3 배치 작업을 포함하여 객체를 복사할 때도 체크섬 알고리즘을 지정할 수 있습니다.
중요
복합(또는 파트 수준) 체크섬에 대해 체크섬을 통해 멀티파트 업로드를 사용하는 경우 멀티파트 업로드 파트 번호는 연속적이어야 하고 1로 시작해야 합니다. 연속되지 않는 파트 번호로 멀티파트 업로드 요청을 완료하려고 하면 Amazon S3에서 HTTP 500 Internal Server
오류가 생성됩니다.
전체 객체 및 복합 체크섬 유형
Amazon S3에는 지원되는 체크섬 유형이 두 가지입니다.
-
전체 객체 체크섬: 전체 객체 체크섬은 멀티파트 업로드의 모든 콘텐츠를 기반으로 계산되며, 첫 번째 파트의 첫 번째 바이트부터 마지막 파트의 마지막 바이트까지 모든 데이터를 포함합니다.
참고
모든 PUT 요청에는 전체 객체 체크섬 유형이 필요합니다.
-
복합 체크섬: 복합 체크섬은 멀티파트 업로드에 있는 각 파트의 개별 체크섬을 기반으로 계산됩니다. 이 접근 방식은 모든 데이터 콘텐츠를 기반으로 체크섬을 계산하는 대신 파트 수준 체크섬(첫 번째 파트부터 마지막 파트까지)을 집계하여 전체 객체에 대한 하나의 결합된 체크섬을 생성합니다.
참고
객체가 멀티파트 업로드로 업로드되면 객체의 엔터티 태그(ETag)는 전체 객체의 MD5 다이제스트가 아닙니다. 대신, Amazon S3는 업로드될 때 각 개별 파트의 MD5 다이제스트를 계산합니다. MD5 다이제스트는 최종 객체의 ETag를 결정하는 데 사용됩니다. Amazon S3는 MD5 다이제스트에 대한 바이트를 함께 연결한 다음 이러한 연결된 값의 MD5 다이제스트를 계산합니다. ETag 생성의 마지막 단계에서 Amazon S3는 끝에 총 파트의 수와 함께 대시를 추가합니다.
Amazon S3는 다음과 같은 전체 객체 및 복합 체크섬 알고리즘 유형을 지원합니다.
-
CRC-64/NVME(
CRC64NVME
): 전체 객체 알고리즘 유형만 지원합니다. -
CRC-32(
CRC32
): 전체 객체 및 복합 알고리즘 유형을 모두 지원합니다. -
CRC-32C(
CRC32C
): 전체 객체 및 복합 알고리즘 유형을 모두 지원합니다. -
SHA-1(
SHA1
): 전체 객체 및 복합 알고리즘 유형을 모두 지원합니다. -
SHA-256(
SHA256
): 전체 객체 및 복합 알고리즘 유형을 모두 지원합니다.
단일 파트 업로드
단일 파트(PutObject
사용)로 업로드된 객체의 체크섬은 전체 객체 체크섬으로 처리됩니다. Amazon S3 콘솔에서 객체를 업로드할 때 S3에서 사용할 체크섬 알고리즘을 선택하고 원한다면 사전 계산된 값도 제공할 수 있습니다. 그러면 Amazon S3는 객체와 해당 체크섬 값을 저장하기 전에 이 체크섬을 검증합니다. 객체 다운로드 중에 체크섬 값을 요청할 때 객체의 데이터 무결성을 확인할 수 있습니다.
멀티파트 업로드
MultipartUpload
API를 사용하여 객체를 여러 파트로 업로드할 때 Amazon S3에서 사용할 체크섬 알고리즘과 체크섬 유형(전체 객체 또는 복합)을 지정할 수 있습니다.
다음 표는 멀티파트 업로드에서 각 체크섬 알고리즘에 대해 지원되는 체크섬 알고리즘 유형을 나타냅니다.
체크섬 알고리즘 | 전체 객체 | 복합 |
---|---|---|
CRC-64/NVME(CRC64NVME ) |
예 | 아니요 |
CRC-32(CRC32 ) |
예 | 예 |
CRC-32C(CRC32C ) |
예 | 예 |
SHA-1(SHA1 ) |
예 | 예 |
SHA-256(SHA256 ) |
예 | 예 |
멀티파트 업로드에 전체 객체 체크섬 사용
멀티파트 업로드를 생성하거나 수행할 때 업로드 시 검증에 전체 객체 체크섬을 사용할 수 있습니다. 즉, 업로드된 객체에 대한 파트 경계를 더 이상 추적할 필요가 없으므로 MultipartUpload
API에 대한 체크섬 알고리즘을 제공하여 무결성 검증 도구를 간소화할 수 있습니다. CompleteMultipartUpload
요청에서 전체 객체의 체크섬을 객체 크기와 함께 제공할 수 있습니다.
멀티파트 업로드 중에 전체 객체 체크섬을 제공하면 AWS SDK는 체크섬을 Amazon S3에 전달하고 S3는 서버 측의 객체 무결성을 검증하여 수신된 값과 비교합니다. 그런 다음 값이 일치하면 Amazon S3가 객체를 저장합니다. 두 값이 일치하지 않으면 S3에서 BadDigest
오류와 함께 요청이 실패합니다. 객체의 체크섬은 나중에 객체의 데이터 무결성을 검증하는 데 사용할 객체 메타데이터에도 저장됩니다.
전체 객체 체크섬의 경우 S3에서 CRC-64/NVME(CRC64NVME
), CRC-32(CRC32
) 또는 CRC-32C(CRC32C
) 체크섬 알고리즘을 사용할 수 있습니다. 멀티파트 업로드의 전체 객체 체크섬은 전체 객체 체크섬으로 선형화할 수 있으므로 CRC 기반 체크섬에서만 사용할 수 있습니다. 이 선형화를 통해 Amazon S3는 성능 향상을 위한 요청을 병렬화할 수 있습니다. 특히 S3는 파트 수준 체크섬에서 전체 객체의 체크섬을 계산할 수 있습니다. 이 검증 유형은 SHA 및 MD5와 같은 다른 알고리즘에는 사용할 수 없습니다. S3에는 기본 무결성 보호 기능이 있으므로 객체가 체크섬 없이 업로드되면 S3는 권장되는 전체 객체 CRC-64/NVME(CRC64NVME
) 체크섬 알고리즘을 객체에 자동으로 연결합니다.
참고
멀티파트 업로드를 시작하려면 체크섬 알고리즘과 전체 객체 체크섬 유형을 지정하면 됩니다. 체크섬 알고리즘과 전체 객체 체크섬 유형을 지정한 후 멀티파트 업로드에 대한 전체 객체 체크섬 값을 제공할 수 있습니다.
멀티파트 업로드에 파트 수준의 체크섬 사용
객체를 Amazon S3에 업로드할 때 단일 객체로 업로드하거나 멀티파트 업로드 프로세스를 통해 여러 파트로 업로드할 수 있습니다. 멀티파트 업로드에 대한 체크섬 유형을 선택할 수 있습니다. 멀티파트 업로드 파트 수준 체크섬(또는 복합 체크섬)의 경우 Amazon S3는 지정된 체크섬 알고리즘을 사용하여 각 개별 파트의 체크섬을 계산합니다. UploadPart
를 사용하여 각 파트의 체크섬 값을 제공할 수 있습니다. Amazon S3 콘솔에서 업로드하려는 객체가 CRC-64/NVME(CRC64NVME
) 체크섬 알고리즘을 사용하도록 설정되어 있고 16MB를 초과하는 경우 전체 객체 체크섬으로 자동 지정됩니다.
그런 다음 Amazon S3는 저장된 파트 수준 체크섬 값을 사용하여 각 파트가 올바르게 업로드되었는지 확인합니다. 전체 객체에 대해 각 파트의 체크섬이 제공되면 S3는 각 파트의 저장된 체크섬 값을 사용하여 전체 객체 체크섬을 내부적으로 계산하여 제공된 체크섬 값과 비교합니다. 이 방법으로 S3가 파트의 체크섬을 사용하여 전체 객체의 체크섬을 계산할 수 있으므로 컴퓨팅 비용이 최소화됩니다. 멀티파트 업로드에 대한 자세한 내용은 Amazon S3에서 멀티파트 업로드를 사용한 객체 업로드 및 복사 및 멀티파트 업로드에 전체 객체 체크섬 사용 섹션을 참조하세요.
객체가 완전히 업로드되면 계산된 최종 체크섬을 사용하여 객체의 데이터 무결성을 확인할 수 있습니다.
멀티파트 업로드의 일부를 업로드할 때는 다음 사항에 유의하세요.
-
전체 객체를 구성하는 파트의 수를 포함하여 객체에 대한 정보를 검색하려면
GetObjectAttributes
작업을 사용하면 됩니다. 추가 체크섬을 사용하면 파트의 체크섬 값을 비롯한 각 개별 파트에 대한 정보를 복구할 수도 있습니다. -
완료된 업로드의 경우,
GetObject
또는HeadObject
작업을 사용하고 단일 파트에 해당하는 파트 번호나 바이트 범위를 지정하여 개별 파트의 체크섬을 가져올 수도 있습니다. 아직 진행 중인 멀티파트 업로드의 개별 부분에 대한 체크섬 값을 검색하려면ListParts
를 사용하면 됩니다. -
Amazon S3가 멀티파트 객체에 대한 체크섬을 계산하는 방식 때문에 객체를 복사할 경우 객체의 체크섬 값이 변경될 수 있습니다. SDK 또는 REST API를 사용하고 있으며
CopyObject
를 직접 호출하는 경우 Amazon S3는CopyObject
API 작업의 크기 한도에 도달할 때까지 객체를 복사합니다. Amazon S3는 객체가 단일 요청으로 업로드되었는지 또는 멀티파트 업로드의 일부로 업로드되었는지 여부에 관계없이 이 복사 작업을 단일 작업으로 수행합니다. 복사 명령을 사용하면 객체의 체크섬은 전체 객체의 직접 체크섬입니다. 객체가 원래 멀티파트 업로드를 사용하여 업로드된 경우 데이터가 변경되지 않아도 체크섬 값이 변경됩니다. -
CopyObject
API 작업의 크기 한도보다 큰 객체는 멀티파트 업로드 복사 명령을 사용해야 합니다. -
AWS Management Console을 사용하여 일부 작업을 수행할 때 객체의 크기가 16MB를 초과하는 경우 Amazon S3는 멀티파트 업로드를 사용합니다.
체크섬 작업
객체를 업로드한 후 체크섬 값을 가져와 사전 계산된 체크섬 값 또는 동일한 알고리즘 유형의 이전에 저장된 체크섬 값과 비교할 수 있습니다. 다음 예시에서는 데이터 무결성을 확인하는 데 사용할 수 있는 체크섬 작업 또는 메서드를 보여줍니다.
콘솔 사용 방법과 객체를 업로드할 때 사용할 체크섬 알고리즘을 지정하는 방법을 자세히 알아보려면 객체 업로드 및 자습서: 추가 체크섬을 사용하여 Amazon S3 내 데이터 무결성 확인
다음 예시는 AWS SDK를 사용하여 멀티파트 업로드로 대량의 파일을 업로드 및 다운로드하고, 파일 검증에 SHA-256을 사용하여 멀티파트 업로드 파일을 검증하는 방법을 보여줍니다.
REST 요청을 전송하고 체크섬 값을 사용하여 객체를 업로드하여 PutObject로 데이터의 무결성을 확인할 수 있습니다. GetObject 또는 HeadObject를 사용하여 객체의 체크섬 값을 검색할 수도 있습니다.
PUT
요청을 보내 한 번의 작업으로 최대 5GB의 객체를 업로드할 수 있습니다. 자세한 내용은 AWS CLI 명령 참조의 PutObject
를 참조하십시오. get-object
및 head-object
를 사용하여 이미 업로드된 객체의 체크섬을 검색함으로써 데이터 무결성을 확인할 수도 있습니다.
자세한 내용은 AWS Command Line Interface 사용 설명서의 Amazon S3 CLI FAQ를 참조하세요.
객체를 업로드할 때 Content-MD5 사용
업로드 후 객체의 무결성을 확인하는 또 다른 방법은 객체를 업로드할 때 객체의 MD5 다이제스트를 제공하는 것입니다. 객체에 대한 MD5 다이제스트를 계산하면 Content-MD5
헤더를 사용하여 PUT
명령으로 다이제스트를 제공할 수 있습니다.
객체를 업로드한 후 Amazon S3는 객체의 MD5 다이제스트를 계산하여 사용자가 제공한 값과 비교합니다. 두 다이제스트가 일치하는 경우에만 요청이 성공합니다.
MD5 다이제스트를 제공할 필요는 없지만 업로드 프로세스의 일부로 객체의 무결성을 확인하는 데 사용할 수 있습니다.
Content-MD5 및 ETag를 사용하여 업로드된 객체 확인
객체의 엔터티 태그(ETag)는 해당 객체의 특정 버전을 나타냅니다. ETag는 객체의 콘텐츠에 대한 변경 사항만 반영하고 메타데이터에 대한 변경 사항은 반영하지 않는다는 점을 명심하세요. 객체의 메타데이터만 변경되는 경우 ETag는 동일하게 유지됩니다.
객체에 따라 객체의 ETag가 객체 데이터의 MD5 다이제스트일 수 있습니다.
-
객체가
PutObject
,PostObject
또는CopyObject
작업으로, 또는 AWS Management Console을 통해 생성되며 해당 객체가 일반 텍스트 또는 Amazon S3 관리형 키(SSE-S3)를 통한 서버 측 암호화를 사용하여 암호화되는 경우 해당 객체에는 객체 데이터의 MD5 다이제스트인 ETag가 있습니다. -
객체가
PutObject
,PostObject
또는CopyObject
작업으로, 또는 AWS Management Console을 통해 생성되며 해당 객체가 고객 제공 키를 통한 서버 측 암호화(SSE-C) 또는 AWS Key Management Service(AWS KMS) 키를 통한 서버 측 암호화(SSE-KMS)를 사용하여 암호화되는 경우 해당 객체에는 객체 데이터의 MD5 다이제스트가 아닌 ETag가 있습니다. -
멀티파트 업로드 프로세스 또는
UploadPartCopy
작업을 통해 객체가 생성되는 경우 암호화 방법에 관계없이 객체의 ETag는 MD5 다이제스트가 아닙니다. 객체가 16MB보다 큰 경우 AWS Management Console은 해당 객체를 멀티파트 업로드로 업로드하거나 복사하므로 ETag가 MD5 다이제스트가 아닙니다.
ETag가 객체의 Content-MD5
다이제스트인 객체의 경우 해당 객체의 ETag 값을 계산된 또는 이전에 저장된 Content-MD5
다이제스트와 비교할 수 있습니다.
후행 체크섬 사용
Amazon S3에 객체를 업로드할 때 객체에 대해 사전 계산된 체크섬을 제공하거나 AWS SDK를 사용하여 사용자를 대신하여 청크 업로드에 대해 후행 체크섬을 자동으로 생성하도록 할 수 있습니다. 후행 체크섬을 사용하는 경우 Amazon S3는 지정된 알고리즘을 사용해 자동으로 체크섬을 생성하여 업로드 시 청크 업로드에 속한 객체의 무결성을 검증합니다.
AWS SDK를 사용할 때 후행 체크섬을 생성하려면 ChecksumAlgorithm
파라미터를 원하는 알고리즘으로 채웁니다. SDK는 해당 알고리즘을 사용하여 객체(또는 객체 파트)에 대한 체크섬을 계산하고 청크 업로드 요청 끝에 자동으로 추가합니다. 이 동작은 Amazon S3가 단일 패스로 데이터의 확인 및 업로드를 모두 수행하므로 시간을 절약할 수 있습니다.
중요
S3 객체 Lambda를 사용하는 경우 S3 객체 Lambda에 대한 모든 요청은 s3
대신 s3-object-lambda
를 사용하여 서명됩니다. 이 동작은 후행 체크섬 값의 서명에 영향을 줍니다. S3 객체 Lambda에 대한 자세한 내용은 S3 객체 Lambda를 사용하여 객체 변환 섹션을 참조하십시오.
후행 체크섬 헤더
청크 콘텐츠 인코딩 요청을 수행하려면 Amazon S3에서 요청을 올바르게 구문 분석하기 위해 클라이언트 서버에 몇 가지 헤더를 포함해야 합니다. 클라이언트 서버에 다음 헤더를 포함해야 합니다.
-
x-amz-decoded-content-length
: 이 헤더는 요청과 함께 Amazon S3에 업로드되는 실제 데이터의 일반 텍스트 크기를 나타냅니다. -
x-amz-content-sha256
: 이 헤더는 요청에 포함된 청크 업로드 유형을 나타냅니다. 후행 체크섬이 있는 청크 업로드의 경우 헤더 값은 페이로드 서명을 사용하지 않는 요청의 경우STREAMING-UNSIGNED-PAYLOAD-TRAILER
이고 SigV4 페이로드 서명을 사용하는 요청의 경우STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER
입니다. (서명된 페이로드를 구현하는 방법에 대한 자세한 내용은 Signature calculations for the authorization header: Transferring a payload in multiple chunks를 참조하세요.) -
x-amz-trailer
: 이 헤더는 요청에 있는 후행 헤더의 이름을 나타냅니다. 후행 체크섬이 있는 경우(AWS SDK가 인코딩된 요청 본문에 체크섬을 추가함)x-amz-trailer
헤더 값에x-amz-checksum-
접두사가 포함되고 알고리즘 이름으로 끝납니다. 현재 다음x-amz-trailer
값이 지원됩니다.-
x-amz-checksum-crc32
-
x-amz-checksum-crc32c
-
x-amz-checksum-crc64nvme
-
x-amz-checksum-sha1
-
x-amz-checksum-sha256
-
참고
요청에 청크 값과 함께 Content-Encoding
헤더를 포함할 수도 있습니다. 이 헤더는 필수는 아니지만 이 헤더를 포함하면 인코딩된 데이터를 전송할 때 HTTP 프록시 문제를 최소화할 수 있습니다. 요청에 다른 Content-Encoding
헤더(예: gzip)가 있는 경우 Content-Encoding
헤더는 쉼표로 구분된 인코딩 목록에 청크 값을 포함합니다. 예: Content-Encoding:
aws-chunked, gzip
.
청크 파트
청크 인코딩을 사용하여 Amazon S3에 객체를 업로드하는 경우 업로드 요청에는 다음 유형의 청크(목록에 나열된 순서대로 형식이 지정됨)가 포함됩니다.
-
객체 본문 청크: 청크 업로드 요청과 연결된 본문 청크가 하나, 여러 개 또는 0개 있을 수 있습니다.
-
완료 청크: 청크 업로드 요청과 연결된 본문 청크가 하나, 여러 개 또는 0개 있을 수 있습니다.
-
후행 청크: 후행 체크섬은 완료 청크 뒤에 나열됩니다. 후행 청크는 하나만 허용됩니다.
참고
모든 청크 업로드는 요청의 종료를 나타내기 위해 최종 CRLF(예: \r\n
)로 끝나야 합니다.
청크 형식 지정의 예는 예: 후행 체크섬이 있는 청크 업로드 섹션을 참조하세요.
객체 본문 청크
객체 본문 청크는 S3에 업로드되는 실제 객체 데이터가 포함된 청크입니다. 이러한 청크에는 일관된 크기 및 형식 제약 조건이 있습니다.
객체 본문 청크 크기
이러한 청크에는 최소 8,192바이트(즉, 8KiB)의 객체 데이터가 포함되어야 합니다. 단, 최종 본문 청크는 더 작을 수 있습니다. 명시적인 최대 청크 크기는 없지만 모든 청크가 5GB의 최대 업로드 크기보다 작을 것으로 예상할 수 있습니다. 청크 크기는 클라이언트 서버 구현에 따라 청크마다 다를 수 있습니다.
객체 본문 청크 형식
객체 본문 청크는 객체 본문 청크의 바이트 수에 대한 16진수 인코딩으로 시작되며, 그 뒤에 CRLF(캐리지 리턴 라인 피드), 해당 청크의 객체 바이트 및 다른 CRLF가 옵니다.
예시:
hex-encoding-of-object-bytes-in-chunk
\r\nchunk-object-bytes
\r\n
그러나 청크에 서명하면 객체 본문 청크는 다른 형식을 따르며, 여기서 서명은 세미콜론 구분 기호를 사용하여 청크 크기에 추가됩니다. 예시:
hex-encoding-of-object-bytes-in-chunk
;chunk-signature
\r\nchunk-object-bytes
\r\n
청크 서명에 대한 자세한 내용은 Signature calculations for the Authorization Header: Transferring a payload in multiple chunks (AWS Signature Version 4)를 참조하세요. 청크 형식 지정에 대한 자세한 내용은 RFC Editor 웹 사이트의 Chunked transfer encoding
완료 청크
완료 청크는 모든 청크 업로드의 최종 객체 본문 청크여야 합니다. 완료 청크의 형식은 본문 청크와 비슷하지만 항상 0바이트의 객체 데이터를 포함합니다. (객체 데이터의 0바이트는 모든 데이터가 업로드되었음을 나타냅니다.) 청크 업로드에는 다음과 같은 형식을 따라 최종 객체 본문 청크로 완료 청크가 포함되어야 합니다.
0\r\n
그러나 콘텐츠 인코딩 요청이 페이로드 서명을 사용하는 경우 대신 다음 형식을 따릅니다.
0;
chunk-signature
\r\n
트레일러 청크
트레일러 청크는 모든 S3 업로드 요청에 대해 계산된 체크섬을 보유합니다. 트레일러 청크에는 헤더 이름 필드 하나와 헤더 값 필드 하나가 포함됩니다. 업로드 요청의 헤더 이름 필드는 x-amz-trailer
요청 헤더에 전달된 값과 일치해야 합니다. 예를 들어 요청에 x-amz-trailer: x-amz-checksum-crc32
가 포함되어 있고 트레일러 청크의 헤더 이름이 x-amz-checksum-sha1
인 경우 요청이 실패합니다. 트레일러 청크의 값 필드에는 해당 객체에 대한 빅엔디언 체크섬 값의 base64 인코딩이 포함됩니다. (빅엔디언 순서는 가장 중요한 바이트의 데이터를 가장 낮은 메모리 주소에 저장하고 가장 덜 중요한 바이트를 가장 큰 메모리 주소에 저장합니다.) 이 체크섬을 계산하는 데 사용되는 알고리즘은 헤더 이름의 접미사(예: crc32
)와 동일합니다.
트레일러 청크 형식
트레일러 청크는 서명되지 않은 페이로드 요청에 대해 다음 형식을 사용합니다.
x-amz-checksum-
lowercase-checksum-algorithm-name
:base64-checksum-value
\n\r\n\r\n
SigV4 서명 페이로드가 있는 요청의 경우 트레일러 청크에는 트레일러 청크 뒤에 트레일러 서명이 포함됩니다.
trailer-checksum
\n\r\ntrailer-signature
\r\n
base64 체크섬 값의 끝에 CRLF를 직접 추가할 수도 있습니다. 예시:
x-amz-checksum-
lowercase-checksum-algorithm-name
:base64-checksum-value
\r\n\r\n
예: 후행 체크섬이 있는 청크 업로드
Amazon S3는 PutObject
에 aws-chunked
콘텐츠 인코딩을 사용하는 청크 업로드와 후행 체크섬이 있는 UploadPart
요청을 지원합니다.
예 1 - 후행 CRC-32 체크섬이 있는 서명되지 않은 청크 PutObject
요청
다음은 후행 CRC-32 체크섬이 있는 청크 PutObject
요청의 예입니다. 이 예시에서 클라이언트는 서명되지 않은 세 개의 청크로 17KB 객체를 업로드하고 x-amz-checksum-crc32
헤더를 사용하여 후행 CRC-32 체크섬 청크를 추가합니다.
PUT /Key+ HTTP/1.1 Host:
amzn-s3-demo-bucket
Content-Encoding: aws-chunked x-amz-decoded-content-length:17408
x-amz-content-sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER x-amz-trailer: x-amz-checksum-crc322000
\r\n // Object body chunk 1 (8192 bytes)object-bytes
\r\n2000
\r\n // Object body chunk 2 (8192 bytes)object-bytes
\r\n400
\r\n // Object body chunk 3 (1024 bytes)object-bytes
\r\n0
\r\n // Completion chunk x-amz-checksum-crc32:YABb/g==
\n\r\n\r\n // Trailer chunk (note optional \n character) \r\n // CRLF
다음은 응답의 예시입니다.
HTTP/1.1 200 ETag: ETag x-amz-checksum-crc32: YABb/g==
참고
체크섬 값 끝에 있는 라인 피드 \n
사용 여부는 클라이언트마다 다를 수 있습니다.
예 2 - 후행 CRC-32(CRC32
) 체크섬이 있는 SigV4 서명 청크 PutObject
요청
다음은 후행 CRC-32 체크섬이 있는 청크 PutObject
요청의 예입니다. 이 요청은 SigV4 페이로드 서명을 사용합니다. 이 예시에서 클라이언트는 17KB 객체를 세 개의 서명된 청크로 업로드합니다. object
body
청크 외에 completion chunk
및 trailer chunk
도 서명됩니다.
PUT /Key+ HTTP/1.1 Host:
amzn-s3-demo-bucket
.s3.amazonaws.com Content-Encoding: aws-chunked x-amz-decoded-content-length:17408
x-amz-content-sha256: STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER x-amz-trailer: x-amz-checksum-crc32authorization-code
// SigV4 headers authorization2000
;chunk-signature=signature-value
...\r\n // Object body chunk 1 (8192 bytes)object-bytes
\r\n2000
;chunk-signature
\r\n // Object body chunk 2 (8192 bytes)object-bytes
\r\n400
;chunk-signature
\r\n // Object body chunk 3 (1024 bytes)object-bytes
\r\n0
;chunk-signature
\r\n // Completion chunk x-amz-checksum-crc32:YABb/g==
\n\r\n // Trailer chunk (note optional \n character)trailer-signature
\r\n \r\n // CRLF
다음은 응답의 예시입니다.
HTTP/1.1 200 ETag: ETag x-amz-checksum-crc32: YABb/g==