本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
Amazon S3 使用檢查總和值來驗證您上傳或下載的資料完整性。此外,您可以請求為儲存在 Amazon S3 中的任何物件計算另一個檢查總和值。您可以選擇要在上傳、複製或批次複製資料時使用的檢查總和演算法。
當您上傳資料時,Amazon S3 會使用您選擇的演算法在伺服器端計算檢查總和,並使用提供的值進行驗證,再儲存物件並將檢查總和作為物件中繼資料的一部分儲存。無論是單一組件上傳還是分段上傳,此驗證一致適用於各種加密模式、物件大小和儲存類別。不過,當您複製或批次複製資料時,Amazon S3 會計算來源物件的檢查總和,並將其移至目的地物件。
注意
當您執行單一組件上傳或分段上傳時,您可以選擇在請求中包含預先計算的檢查總和,並使用完整物件檢查總和類型。若要搭配多個物件使用預先計算的值,請使用 AWS CLI AWS SDKs。
使用支持的檢查總和演算法
透過 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 會產生錯誤。
-
當您使用 SDK 時,請注意下列事項:
-
將
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 Batch Operations 複製物件時指定檢查總和演算法。
重要
如果您搭配檢查總和使用分段上傳以取得複合 (或組件層級) 檢查總和,分段上傳的組件編號必須是連續的。如果您嘗試使用非連續的組件編號完成分段上傳請求,則 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 開發套件會將檢查總和傳遞給 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
) 檢查總和演算法且超過 16 MB,則會自動將其指定為完整的物件檢查總和。
然後,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,如果物件大小大於 16 MB,Amazon S3 會使用分段上傳。
檢查總和操作
上傳物件之後,您可以取得檢查總和值,並將其與相同演算法類型之預先計算或先前儲存的檢查總和值進行比較。下列範例顯示您可以使用哪些檢查總和操作或方法來驗證資料完整性。
若要進一步了解如何使用主控台,以及如何指定上傳物件時要使用的檢查總和演算法,請參閱 上傳物件 和教學課程:使用其他檢查總和來檢查 Amazon S3 中資料的完整性
下列範例示範如何使用 AWS SDKs 上傳包含分段上傳的大型檔案、下載大型檔案,以及驗證分段上傳檔案,方法都是使用 SHA-256 進行檔案驗證。
您可以發送 REST 請求以上傳具有檢查總和值的物件,以使用 PutObject 驗證資料的完整性。您也可以使用適用於 GetObject 或 HeadObject 物件擷取檢查總和的值。
您可以傳送 PUT
請求,以便在單一操作中上傳多達 5 GB 的物件。如需詳細資訊,請參閱《AWS CLI 命令參考》中的 PutObject
。您也可以使用 get-object
和 head-object
以擷取已上傳物件的檢查總和以驗證資料的完整性。
如需相關資訊,請參閱《AWS Command Line Interface 使用者指南》中的 Amazon S3 CLI 常見問答集。
上傳物件時使用 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) 的伺服器端加密或加密,則物件的 ETag 是該物件資料的 MD5 摘要。 -
如果物件是由
PutObject
、PostObject
或CopyObject
操作建立,或透過 建立 AWS Management Console,且該物件是透過使用客戶提供的金鑰 (SSE-C) 的伺服器端加密,或使用 AWS Key Management Service (AWS KMS) 金鑰 (SSE-KMS) 的伺服器端加密,則該物件的 ETag 不是其物件資料的 MD5 摘要。 -
如果物件是由分段上傳程序或
UploadPartCopy
操作所建立,則無論加密方法為何,物件的 ETag 都不會是 MD5 摘要。如果物件大於 16 MB, 會將該物件 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-object-lambda
而不是 s3
。此行為會影響追蹤檢查總和值的簽名。如需 S3 Object Lambda 的詳細資訊,請參閱 使用 S3 Object Lambda 轉換物件。
追蹤檢查總和標頭
若要提出區塊內容編碼請求,Amazon S3 需要用戶端伺服器包含多個標頭,才能正確剖析請求。用戶端伺服器必須包含下列標頭:
-
x-amz-decoded-content-length
:此標頭表示透過請求上傳至 Amazon S3 的實際資料的純文字大小。 -
x-amz-content-sha256
:此標頭表示包含在請求中的區塊上傳類型。對於具有結尾檢查總和的區塊上傳,標頭值STREAMING-UNSIGNED-PAYLOAD-TRAILER
適用於不使用承載簽署的請求,STREAMING-AWS4-HMAC-SHA256-PAYLOAD-TRAILER
以及使用 SigV4 承載簽署的請求。(如需實作已簽署承載的詳細資訊,請參閱授權標頭的簽章計算:在多個區塊中傳輸承載。) -
x-amz-trailer
:此標頭表示請求中的結尾標頭名稱。如果存在結尾檢查總和 (其中 AWS SDKs將檢查總和附加到編碼的請求內文),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 時,上傳請求會包含下列區塊類型 (依列出的順序格式化):
-
物件內文區塊:與區塊上傳請求相關聯的內文區塊可以是一個、多個或零。
-
完成區塊:可以有一個、多個或零與區塊上傳請求相關聯的主體區塊。
-
追蹤區塊:追蹤檢查總和會在完成區塊後列出。僅允許一個結尾區塊。
注意
每個區塊上傳都必須以最終 CRLF 結尾 (例如 \r\n
),以表示請求的結尾。
如需區塊格式的範例,請參閱 範例:具有結尾檢查總和的區塊上傳。
物件內文區塊
物件內文區塊是包含要上傳至 S3 之實際物件資料的區塊。這些區塊具有一致的大小和格式限制。
物件主體區塊大小
這些區塊必須包含至少 8,192 個位元組 (或 8 KiB) 的物件資料,但最終內文區塊除外,這可以較小。沒有明確的區塊大小上限,但您可以預期所有區塊都小於 5 GB 的最大上傳大小。區塊大小可能會因用戶端伺服器實作而有所不同。
物件內文區塊格式
物件內文區塊的開頭是物件內文區塊中位元組數的十六進位編碼,後面接著 CRLF (Carriage Return Line Feed)、該區塊的物件位元組,以及另一個 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
如需區塊簽署的詳細資訊,請參閱Authorization標頭的簽章計算:在多個區塊中傳輸承載 (AWS 簽章版本 4)。如需區塊格式化的詳細資訊,請參閱 RFC 編輯器網站上的區塊傳輸編碼
完成區塊
完成區塊必須是每個區塊上傳的最終物件內文區塊。完成區塊的格式類似於內文區塊,但一律包含零位元組的物件資料。(物件資料的零位元組表示所有資料都已上傳。) 區塊上傳必須包含完成區塊做為其最終物件內文區塊,格式如下:
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
您也可以直接將 CRLF 新增至 base64 檢查總和值的結尾。例如:
x-amz-checksum-
lowercase-checksum-algorithm-name
:base64-checksum-value
\r\n\r\n
範例:具有結尾檢查總和的區塊上傳
Amazon S3 支援使用aws-chunked
內容編碼的區塊上傳,PutObject
以及具有結尾檢查總和的UploadPart
請求。
範例 1 – 未簽署的區塊PutObject
請求,具有結尾 CRC-32 檢查總和
以下是具有結尾 CRC-32 檢查總和的區塊PutObject
請求範例。在此範例中,用戶端會在三個未簽章區塊中上傳 17 KB 物件,並使用 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
結尾的 linefeed 用量可能因用戶端而異。
範例 2 – SigV4-signed的區塊PutObject
請求,具有結尾 CRC-32 (CRC32
) 檢查總和
以下是具有結尾 CRC-32 檢查總和的區塊PutObject
請求範例。此請求使用 SigV4 承載簽署。在此範例中,用戶端會在三個簽章區塊中上傳 17 KB 物件。除了區塊之外, completion chunk
和 object body
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==