HTTPS協議文件的完整性

Question

我知道當您使用HTTP/HTTPS協議從客戶端向服務器發送文件時，您可以保證所有發送的數據都成功發送到目的地。但是，如果您發送的文件很大，然後突然互聯網連接斷開，並不是所有包都發送完畢，因此您將失去文件的邏輯完整性。

在我的陳述中有沒有我缺少的觀點？

我想知道是否有目的地節點檢查文件邏輯完整性，而不使用「自定義代碼/ api」的方式。

Answer 1

HTTPS只是HTTP通過TLS層，因此，所有適用於HTTPS，太：

HTTP通常運過來的TCP/IP。現在，TCP具有流量控制（即丟失的數據包將被重新發送）和校驗和（即，沒有接收機注意到並重新請求分組數據被改變的概率較小）的校驗和。所以，如果你真的只是傳輸數據，那麼你基本上已經設置好了（只要你的HTTP服務器配置爲以字節爲單位發送文件的長度，至少對於靜態文件來說，通常是這樣）。

如果您的傳輸在您的服務器發送給客戶端的HTTP GET回覆中公佈的整個文件大小之前停止，您的客戶端將知道！許多HTTP庫/客戶端可以重新啓動HTTP傳輸（如果服務器支持它）。

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.15 甚至指定MD5校驗和標題字段。您可以將Web服務器配置爲使用該字段，客戶端可以使用它來驗證整個文件的完整性。

編輯：由rfc2616指定的Content-MD5似乎不推薦使用。您現在可以使用a content digest，這更靈活。

此外，您提到您要檢查客戶端發送到服務器的文件。這個問題可能會比較困難 - 儘管通常您完全控制了您的Web服務器，但您無法強制任意客戶端（例如瀏覽器）在上傳之前對其文件進行散列處理。另一方面，如果你實際上是在控制客戶端的HTTP實現，那麼你很可能也會使用比純HTTP更多的文件傳輸 - 比如WebDav，AtomPUB等，它們是頂層協議的HTTP，甚至更多的面向文件交換的協議，如rsync（如果你實際上正在同步東西，我會衷心推薦 - 如果雙方的版本只有部分不同，它會將網絡使用降到最低）。如果由於某種原因，您的用戶在一個定義良好的圈子中共享大部分數據（例如，您正在構建攝影師分享他們專輯的內容），那麼您甚至可以使用bittorrent， - 大塊哈希，廣泛的負載平衡選項，並允許「普通的舊HTTP種子」。

Answer 2

在HTTP/1.1中，收件人可以始終檢測它是否收到完整的消息（通過比較內容長度或正確處理傳輸編碼：分塊）。

（如果您懷疑傳輸層上存在位錯誤，則添加內容散列可以提供幫助。）

Answer 3

這裏有幾個問題：

1. 馬庫斯說是他的回答TCP保護您的字節被不期而遇損壞，但它並沒有幫助，如果下載被中斷
2. HTTPS還確保那些字節在服務器和客戶端之間沒有被篡改（你）
3. 如果你想驗證文件的完整性（其傳輸是否被中斷）你應該使用校驗和來防止意外的文件損壞（例如CRC32，可能會有更好的，你應該檢查）
   1. 如果你需要用HTTPS那麼你從蓄意攻擊安全一點，因爲你知道你的校驗OK，你得到了文件部分不被篡改。
4. 如果您使用校驗和，但不使用HTTPS（但您確實應該），那麼您應該可以安全地防止意外的數據損壞，但不能防止惡意攻擊。它可以被減輕，但它不在這個問題的範圍內