ข้อมูลผิด ๆ เกี่ยวกับ TCP ที่โปรแกรมเมอร์เชื่อ

 (lwn.net)
3 คะแนน โดย GN⁺ 2024-09-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

NetworkManager หรือ networkd

  • NetworkManager หรือ networkd

    • ผู้ใช้ได้อธิบายเหตุผลที่เปลี่ยนไปใช้การจัดการแบบ wpa_supplicant
    • นำเสนอรายการความเชื่อผิด ๆ เกี่ยวกับ TCP
    • กล่าวถึงความเข้าใจผิดเกี่ยวกับความน่าเชื่อถือของ TCP

  • รายการความเชื่อผิด ๆ เกี่ยวกับ TCP

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

  • คำอธิบาย

    • หากการเชื่อมต่อถูกตัดขณะรอ ACK ผู้ส่งจะไม่สามารถรู้ได้ว่าเซกเมนต์ถูกฝั่งรับได้รับแล้วหรือไม่
    • จำเป็นต้องใช้อัลกอริทึมอย่าง Paxos หรือ Raft และต้องมีอย่างน้อยสามโหนด
    • ปัญหานี้เกิดขึ้นได้แม้ในโปรโตคอลอย่าง SMTP

  • ความเห็นเพิ่มเติม

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

  • การอภิปรายเพิ่มเติม

    • ไม่สามารถรู้ขอบเขตที่แน่ชัดของชุดไบต์ที่ตกลงกันแล้วได้
    • ความเชื่อผิด ๆ เรื่องความโปร่งใสของเครือข่ายก่อให้เกิดปัญหา
    • มีเครือข่ายที่บล็อก ICMP หรือทิ้งแพ็กเก็ตที่ไม่เข้าใจ
    • จำเป็นต้องมีความรู้เกี่ยวกับการควบคุมความหนาแน่นของเครือข่าย

สรุปโดย GN⁺

  • บทความนี้กล่าวถึงความเชื่อผิด ๆ เกี่ยวกับความน่าเชื่อถือของ TCP และรวมถึงการถกเถียงเรื่องการเลือกใช้เครื่องมือจัดการเครือข่าย
  • อธิบายว่าปัญหาความน่าเชื่อถือของ TCP อาจต้องใช้อัลกอริทึมที่ซับซ้อนอย่าง Paxos
  • เน้นว่าความเชื่อผิด ๆ เรื่องความโปร่งใสของเครือข่ายสามารถก่อปัญหาได้จริง
  • นำเสนอปัจจัยหลากหลายที่ควรพิจารณาเมื่อเลือกเครื่องมือจัดการเครือข่าย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-09-16
ความเห็นจาก Hacker News

  • รูปแบบ "falsehoods programmers believe" ไม่ชัดเจนเลยทำให้งง

    • ไม่เข้าใจว่าทำไมถึงมีการถกเถียงกันเรื่องการมีอยู่ของ TCP packet
    • เป็นเนื้อหาที่ทำให้เกิดความสับสนเชิงปรัชญา

  • รู้สึกทึ่งที่ถึงจะถอดสาย Ethernet แล้วเสียบกลับเข้าไปใหม่ การเชื่อมต่อก็ยังคงอยู่

    • TCP ถูกออกแบบมาให้ยังทำงานได้แม้จะเกิดเหตุร้ายแรง

  • สามารถรับประกันการส่งแบบ "at most once" หรือ "at least once" ได้ แต่ไม่สามารถรับประกันการส่งแบบ "exactly once" ได้

    • นักพัฒนารุ่นจูเนียร์จำนวนมากคิดว่าถ้าไม่มีการรับประกันแบบ "exactly once" ก็ถือว่าเป็นบั๊ก

  • ถ้าการเชื่อมต่อหลุดในขณะที่ ACK ยังค้างอยู่ ฝั่งส่งจะไม่สามารถรู้ได้ว่า segment ถูกฝั่งรับได้รับแล้วหรือยัง

    • TCP ให้ท่อสื่อสารแบบสองทาง และความรับผิดชอบเรื่องการส่งได้อย่างถูกต้องเป็นหน้าที่ของแอปพลิเคชัน
    • ถ้า HTTP request ถูกตัดไปก่อนจะได้รับ response ฝั่งส่งต้องสมมติว่า request อาจไปไม่ถึงเซิร์ฟเวอร์และต้องลองใหม่ผ่านการเชื่อมต่อใหม่

  • สงสัยว่าไม่เคยได้ยินเรื่อง error correction code เลยหรือไม่

    • ใน TCP หรือ Ethernet frame มี FEC byte รวมอยู่ด้วย
    • HTTP over TLS ใช้ encrypted data frame และถ้าเกิด data loss ก็จะไม่สามารถรับข้อมูลได้
    • อินเทอร์เน็ตสมัยใหม่จำนวนมากตั้งอยู่บนพาราไดม์นี้

  • เมื่อใช้ฮาร์ดแวร์ของตัวเองภายในดาต้าเซ็นเตอร์ ก็อาจมองข้ามรายละเอียดระดับล่างได้

    • แต่การจำกัดแบนด์วิดท์, ขีดจำกัด packet RPS และ latency ก็ยังสำคัญอยู่

  • บทความนี้ยังไม่ใช่งานเขียนที่เสร็จสมบูรณ์ และชื่อเรื่องที่ส่งเข้า HN อาจทำให้เข้าใจผิดได้

  • ทำให้นึกถึงปัญหาที่เคยพยายามแก้ตอนทำงานที่ VKontakte

    • ตอนส่งข้อความในรถไฟใต้ดิน ข้อความไปถึงเซิร์ฟเวอร์ แต่สัญญาณหลุดก่อนที่ response จะกลับมาถึง
    • ไคลเอนต์รับรู้ว่าเป็นการส่งข้อความล้มเหลวแล้วจึงลองใหม่
    • แก้ปัญหาด้วยการใช้ "random ID" ที่ไคลเอนต์สร้างขึ้น
    • Telegram จะส่ง response ทั้งหมดที่ยังไม่ได้รับการยืนยันจากช่วงการเชื่อมต่อก่อนหน้า เมื่อไคลเอนต์เชื่อมต่อกับเซิร์ฟเวอร์ใหม่

  • หลายคนไม่เข้าใจว่า TCP ไม่ใช่ function call

    • เมื่อไม่นานมานี้มีตัวจำกัดความเร็ว TCP แบบใหม่ที่ออกมาในสภาพที่ผิดพลาดอย่างมาก
    • คอนเทนเนอร์ส่วนใหญ่น่าจะกำลังเจอปัญหา Bufferbloat อยู่