ทำไมการเปรียบเทียบ checksums เมื่อดาวน์โหลดไฟล์เป็นเรื่องที่ดี

เว็บไซต์ที่จัดหาไฟล์ ISO สำหรับดาวน์โหลดมักจะให้เช็คซัม md5 ของไฟล์เหล่านั้นซึ่งเราสามารถใช้เพื่อยืนยันว่าไฟล์นั้นดาวน์โหลดอย่างถูกต้องและไม่เสียหาย

ทำไมถึงจำเป็น แน่นอนว่าคุณสมบัติการแก้ไขข้อผิดพลาดของ TCP นั้นเพียงพอแล้ว หากแพ็กเก็ตไม่ได้รับอย่างถูกต้องมันจะถูกส่งใหม่ ลักษณะการเชื่อมต่อ TCP / IP ไม่รับประกันความสมบูรณ์ของข้อมูลหรือไม่

ตามที่ได้รับการบันทึกไว้โดยผู้อื่นมีความเป็นไปได้มากมายสำหรับความเสียหายของข้อมูลที่การตรวจสอบใด ๆ ที่เลเยอร์การขนส่งไม่สามารถช่วยได้เช่นการทุจริตเกิดขึ้นแล้วก่อนการตรวจสอบการคำนวณจะถูกคำนวณที่ด้านการส่งการสกัดกั้น MITM เป็น checksums) ความเสียหายที่เกิดขึ้นหลังจากการตรวจสอบการตรวจสอบในตอนท้ายที่ได้รับ ฯลฯ

ถ้าเราไม่สนใจความเป็นไปได้อื่น ๆ เหล่านี้ทั้งหมดและมุ่งเน้นไปที่ข้อมูลเฉพาะของการตรวจสอบ TCPเองและสิ่งที่มันทำในแง่ของการตรวจสอบความถูกต้องของข้อมูลนั้นปรากฎว่าคุณสมบัติของการตรวจสอบนี้ไม่ครอบคลุมในแง่ของการตรวจสอบข้อผิดพลาด วิธีที่อัลกอริทึมการตรวจสอบนี้ถูกเลือกค่อนข้างสะท้อนถึงความต้องการความเร็วรวมกับช่วงเวลา (ช่วงปลายปี 1970)

นี่คือวิธีคำนวณการตรวจสอบ TCP :

เช็คซัม: 16 บิต

เขตข้อมูล checksum เป็นส่วนเติมเต็ม 16 บิตสำหรับส่วนเติมเต็มของคำทั้งหมด 16 บิตในส่วนหัวและข้อความ หากเซ็กเมนต์มีจำนวนส่วนหัวและอ็อกเท็ตข้อความเป็นจำนวนคี่ที่ต้องทำการตรวจสอบออคเต็ตสุดท้ายจะถูกเติมด้านขวาด้วยศูนย์เพื่อสร้างคำ 16 บิตสำหรับจุดประสงค์ในการตรวจสอบ แผ่นไม่ได้ส่งเป็นส่วนหนึ่งของส่วน ในขณะที่คำนวณการตรวจสอบข้อมูลตัวตรวจสอบตัวเองจะถูกแทนที่ด้วยศูนย์

ซึ่งหมายความว่าการทุจริตใด ๆ ที่ยอดคงเหลือเมื่อรวมข้อมูลด้วยวิธีนี้จะไม่ถูกตรวจพบ มีความเสียหายหลายประเภทในข้อมูลที่จะอนุญาต แต่เป็นเพียงตัวอย่างเล็กน้อย: การเปลี่ยนลำดับของคำ 16 บิตจะไม่ถูกตรวจพบ

ในทางปฏิบัติมันจับข้อผิดพลาดทั่วไปจำนวนมาก แต่ไม่ได้รับประกันความสมบูรณ์ มันยังได้รับการช่วยเหลือด้วยวิธีที่เลเยอร์ L2 ทำการตรวจสอบความสมบูรณ์ (เช่น CRC32 ของเฟรมอีเธอร์เน็ต) แม้ว่าจะเป็นเพียงการส่งข้อมูลบนโลคัลลิงก์และหลายกรณีของข้อมูลที่เสียหาย

การตรวจสอบความถูกต้องของข้อมูลโดยใช้แฮชที่แข็งแกร่งหรือโดยเฉพาะอย่างยิ่งลายเซ็นเข้ารหัสนั้นอยู่ในระดับที่แตกต่างกันโดยสิ้นเชิงในแง่ของการรับรองความถูกต้องของข้อมูล ทั้งสองแทบจะไม่สามารถเปรียบเทียบได้

อาจเป็นเหตุผลที่หนึ่งพันล้านทำไมเราควรตรวจสอบ md5sum แต่มีบางคนที่มาถึงใจฉัน:

• กิจกรรมที่เป็นอันตราย - ISO ของคุณอาจถูกรบกวนจากเซิร์ฟเวอร์
• หน้านั้นปลอมแปลง (ดีที่สุดที่จะลงนาม md5sums ด้วย :))
• ดาวน์โหลดเสีย (แม้จะมีการแก้ไขข้อผิดพลาด TCP) (ลองดูนี่สิ )
• ISO ถูกเผาอย่างไม่ถูกต้อง

และใช้เวลาเพียงไม่กี่วินาทีเท่านั้น

TCP / IP รับประกันความถูกต้องของข้อมูล * แต่ไม่รับประกันว่าจะดาวน์โหลดไฟล์ได้ 100% มีหลายสาเหตุที่อาจเกิดขึ้น ตัวอย่างเช่น: เป็นไปได้ที่คุณสามารถเมานท์ ISO ที่ขาดหนึ่งหรือสองไบต์ที่กลาง คุณจะไม่มีปัญหากับมันจนกว่าคุณจะต้องการไฟล์หนึ่งหรือสองไฟล์ที่เสียหาย การเปรียบเทียบ checksums ทำให้แน่ใจได้ว่าคุณได้ดาวน์โหลดทั้งไฟล์จริงๆ

* ดูความคิดเห็น

การตรวจสอบ TCP เป็นเพียง 16 บิต ซึ่งหมายความว่าในกรณีที่ไม่มีเช็คซัมอื่น ๆ หนึ่งในทุก ๆ 65536 แพ็กเก็ตที่เสียหายจะได้รับการยอมรับว่าไม่เสียหาย ตัวอย่างเช่นหากคุณกำลังดาวน์โหลดอิมเมจ 8GB จากลิงค์ที่มีเสียงรบกวนซึ่งมีอัตราความเสียหาย 1% คุณจะคาดหวังว่าจะได้แพ็คเก็ตที่ 81 ที่ไม่สามารถตรวจจับได้

MD5 เป็น checksum ที่ใหญ่กว่ามากที่ 128 bits อัตราต่อรองของแพ็คเก็ต 81 เหล่านั้นผลิตสิ่งที่มีเช็คซัมเดียวกันกับต้นฉบับประมาณ 1 ใน 1,000,000,000,000,000,000,000,000,000,000,000,000,000

มีเหตุผลหลายประการในการตรวจสอบการตรวจสอบไฟล์ที่ดาวน์โหลดผ่าน HTTP:

• มั่นใจได้ว่าคุณได้รับไฟล์ทั้งหมด
  • ลูกค้าบางรายเช่นFirefoxอาจถือว่าการเชื่อมต่อถูกขัดจังหวะเป็นการดาวน์โหลดสำเร็จทำให้คุณมีไฟล์ที่ถูกตัดทอน แต่อ้างว่าดาวน์โหลดเรียบร้อย
• มั่นใจว่าคุณได้รับไฟล์ที่ถูกต้อง
  • เช่นเซิร์ฟเวอร์ buggy ที่ถูกบุกรุกหรือเป็นอันตรายอาจส่งสิ่งอื่นมาให้คุณ
  • บางคนอาจยุ่งเกี่ยวกับการถ่ายโอน (การโจมตีจากคนกลาง) - แม้ HTTPS จะไม่ปลอดภัยจากสิ่งนี้หากระบบของคุณถูกบุกรุกโดยเช่น Superfish หรือวิธีการเข้ารหัสที่อ่อนแอ
  • พวกเขาอาจเพียงแค่นำเสนอคุณด้วยหน้าดาวน์โหลดที่ผิดดังนั้นคุณจึงไม่ได้เชื่อมต่อกับเซิร์ฟเวอร์จริง (แต่ในกรณีนี้การตรวจสอบจะไม่ช่วยอะไรมากหากคุณได้มาจากเซิร์ฟเวอร์ปลอมตัวเดียวกัน)
  • มีผู้ให้บริการอินเทอร์เน็ตจำนวนหนึ่งที่ถูกฉีดจาวาสคริปต์เข้าสู่หน้าเว็บในการส่งด้วยเหตุผลต่างๆ¹ ; ขึ้นอยู่กับว่ามีการนำไปใช้งานด้วยวิธีใดมันอาจทำให้การดาวน์โหลดไฟล์บางอย่างแย่ลง
  • มิเรอร์อาจโฮสต์ไฟล์รุ่นที่ล้าสมัยหรือผู้ดูแลระบบอาจอัปโหลดไฟล์ผิด
• การทำให้มั่นใจว่าไฟล์ไม่เสียหายจากสิ่งที่ TCP ตรวจไม่พบ
  • เช่นไฟล์อาจเสียหายบนเซิร์ฟเวอร์ดังนั้น TCP จะตรวจสอบให้แน่ใจว่าไฟล์ที่เสียหายไปแล้วนั้นไม่ได้รับการจัดการในการส่งต่อ
  • หรืออาจเกิดความเสียหายหลังจากที่คุณมาถึงจุดสิ้นสุดโดยหน่วยความจำ / ดิสก์ผิดพลาดไดรเวอร์ระบบไฟล์ buggy ฯลฯ
  • TCP checksums นั้นมีเพียง 16 บิตดังนั้นโอกาสที่จะไม่ดาราศาสตร์ (1 ใน 65536) จะไม่ตรวจจับแพ็คเก็ตที่เสียหาย
• ด้วย ISO ทำให้มั่นใจได้ว่าแผ่นดิสก์ไหม้ได้อย่างถูกต้อง

แหล่งที่มาในความคิดเห็น^{1 รายการ}เนื่องจาก lol rep

Daniel ขึ้นอยู่กับเครื่องมือที่คุณใช้สำหรับดาวน์โหลด ISO ต่อคำพูด ถ้ามันคือ Say Firefox .. มันอาจแสดงไฟล์ที่ดาวน์โหลด อย่างไรก็ตามคุณอาจไม่ได้รับ ISO ครบถ้วน หากคุณเบิร์นให้ลองใช้งานข้อมูลอาจหายไป สิ่งนี้เกิดขึ้นเป็นครั้งคราวในไฟล์โฮสต์เว็บเซิร์ฟเวอร์ที่แตกต่างกัน

เป็นวิธีปฏิบัติที่ดีในการเปรียบเทียบขนาดไฟล์อย่างน้อย (ไบต์ทั้งหมดหรือบิต) ตรวจสอบให้แน่ใจว่าตรงกัน Windows จะแสดงจำนวนไฟล์ที่แตกต่างกันแล้วพูดว่า Linux การตรวจสอบผลรวม MD5 จะแสดงค่าเดียวกันไม่มีวัสดุที่ใช้ระบบปฏิบัติการ หวังว่านี่จะช่วยได้เล็กน้อย ไชโย ...

ฉันสังเกตเห็นคำตอบที่น่าสนใจมากมาย แต่มีสิ่งสุดท้ายที่ต้องพิจารณา: ปัญหาของนายพลสองคน

ปัญหาของนายพลทั้งสองและปัญหาของนายพลไบแซนไทน์พิจารณาโดยเฉพาะถึงผลกระทบของการถ่ายโอนข้อมูลที่เชื่อถือได้ผ่านช่องทางที่ไม่น่าเชื่อถือ

ผลรวมตรวจสอบเป็นอีกชั้นหนึ่งของ "การเพิ่มความน่าเชื่อถือ" และชั้นหนึ่งที่มีโอกาสเกิดความล้มเหลวน้อยมาก นี่คือเหตุผลว่าทำไมมันจึงเป็นที่นิยม