提供ISO檔案下載的網站通常會提供這些檔案的md5校驗和，我們可以用它來確認檔案是否已正確下載，並且沒有損壞。
為什麼這是必要的？當然，TCP 的糾錯特性已經足夠了。如果資料包未正確接收，則會重新傳輸。 TCP/IP 連線的本質難道不能保證資料完整性嗎？
答案1
正如其他人所指出的，資料損壞的可能性有很多，傳輸層的任何校驗和都無濟於事，例如在發送端計算校驗和之前就已經發生損壞，MITM 攔截並修改流（資料以及作為校驗和），在接收端驗證校驗和後發生損壞等。
如果我們忽略所有這些其他可能性並專注於具體情況TCP校驗和事實證明，該校驗和的屬性在檢測錯誤方面根本不全面。選擇這種校驗和演算法的方式反映了對速度與時間段（1970 年代末）的結合的要求。
這就是如何TCP校驗和計算得出：
校驗和：16位
校驗和欄位是標頭和文字中所有 16 位元字的補碼和的 16 位元補碼。如果一個段包含奇數個要校驗和的標頭和文字八位元字節，則最後一個八位元組在右側用零填充，以形成用於校驗和目的的 16 位元字。 pad 不會作為段的一部分進行傳輸。在計算校驗和時，校驗和欄位本身將被替換為零。
這意味著以這種方式匯總資料時平衡的任何損壞都不會被發現。這將允許多種類型的資料損壞，但僅舉一個簡單的例子：更改 16 位元字的順序將始終不會被偵測到。
在實踐中，它捕獲了許多典型錯誤，但根本不能“保證”完整性。 L2 層如何進行完整性檢查（例如乙太網路訊框的 CRC32）也有幫助，儘管僅適用於本地鏈路上的傳輸，並且許多損壞的資料甚至從未傳遞到 TCP 堆疊。
使用強哈希（或最好是加密簽章）驗證資料在確保資料完整性方面處於完全不同的水平。兩者幾乎無法相提並論。
答案2
人們應該檢查 md5sum 的原因可能有無數，但我確實想到了一些：
- 惡意活動 - 您的 ISO 可能在從伺服器發出的途中被竄改
- 該頁面本身是欺騙性的（最好也簽署 md5sums :) ）
- 下載損壞（儘管進行了 TCP 錯誤更正）（檢查這出去）
- ISO 燒錄不正確
無論如何，它只需要幾秒鐘。
答案3
TCP/IP 確實保證資料完整性*。但它不保證文件已 100% 下載。發生這種情況的原因可能有很多。例如：您可能掛載的 ISO 在中間某處遺失了一兩個位元組。除非您需要一兩個損壞的特定文件，否則您不會遇到任何問題。比較校驗和可確保您確實下載了整個檔案。
* 見評論
答案4
驗證透過 HTTP 下載的檔案的校驗和有多種原因：
- 確保您收到整個文件
- 一些客戶，例如火狐瀏覽器，可能會將中斷的連接視為成功下載，留下一個被截斷的文件，但聲稱下載正常
- 確保您收到正確的文件
- 例如，有缺陷、受損或惡意的伺服器可能會向您發送其他內容
- 有人可能會篡改傳輸（中間人攻擊） - 如果您的系統受到 Superfish 等攻擊，或者所使用的加密方法較弱，即使是 HTTPS 也不安全
- 他們也可能只是向您提供一個錯誤的下載頁面，因此您甚至沒有連接到真正的伺服器（但在這種情況下，如果您從同一個假伺服器獲取校驗和，則校驗和不會有太大幫助）
- 許多 ISP 被發現會因各種原因而向傳輸中的頁面注入 Javascript 1；根據其實施情況，它也可能會破壞一些文件下載
- 鏡像可能託管該文件的過時版本，或者管理員可能上傳了錯誤的文件
- 確保檔案沒有被 TCP 無法偵測到的內容損壞
- 例如，檔案可能在伺服器上損壞，因此 TCP 將僅確保已損壞的檔案在傳輸中不會進一步受到損壞
- 或者它在到達您這邊後可能會因記憶體/磁碟故障、有缺陷的檔案系統驅動程式等而損壞
- TCP 校驗和只有 16 位，因此無法偵測到損壞資料包的可能性並不是天文數字（65536 分之一）
- 使用 ISO，確保光碟正確燒錄
評論中有1 個來源，因為哈哈代表