Noq: อิมพลีเมนเทชัน QUIC แบบใหม่บน Rust จาก n0

 (iroh.computer)
4 คะแนน โดย GN⁺ 2026-03-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • noq ที่พัฒนาโดยทีม n0 คือ อิมพลีเมนเทชัน QUIC แบบใช้งานทั่วไปที่เขียนด้วย Rust และรองรับ multipath กับ NAT traversal
  • พัฒนาขึ้นโดยเปลี่ยนมาใช้ codebase อิสระ เพื่อแก้ข้อจำกัดของ โครงสร้างเดิมที่อิง Quinn ใน iroh
  • มีฟีเจอร์ต่าง ๆ เช่น QUIC Multipath, NAT Traversal, Address Discovery, ส่วนขยาย QLog และ WeakConnectionHandle
  • เริ่มใช้งานใน สภาพแวดล้อมโปรดักชันตั้งแต่ iroh v0.96 และทดสอบ interoperability กับ picoquic เรียบร้อยแล้ว
  • ในอนาคตจะเดินหน้าร่วมมือกับ QUIC Working Group และทีม Quinn ต่อไป และพัฒนาให้เป็นเทคโนโลยีพื้นฐานสำหรับ นักพัฒนาแอปพลิเคชันเครือข่ายบน Rust

การประกาศ noq

  • noq คือ อิมพลีเมนเทชัน QUIC แบบใช้งานทั่วไปที่พัฒนาโดยทีม n0 และรองรับฟีเจอร์ multipath และ NAT traversal
  • ถูกใช้งานเป็น transport layer ตั้งแต่ iroh v0.96 และไม่ได้จำกัดเฉพาะ iroh แต่สามารถนำไปใช้เพื่อวัตถุประสงค์ทั่วไปได้

การเปลี่ยนจาก Quinn ไปเป็น noq

  • เดิม iroh ใช้ QUIC โดยอิงกับ Quinn แต่มีฟังก์ชันซับซ้อนจำนวนมาก เช่น NAT traversal และการสลับเส้นทาง ที่ต้องจัดการนอกตัว QUIC
  • ด้วยข้อจำกัดเชิงโครงสร้างเหล่านี้ ทำให้แก้ไขจากภายนอกได้ยาก จึงตัดสินใจทำ hard fork ของ Quinn
  • ขณะเดียวกันยังคงรักษาความร่วมมือกับ Quinn เอาไว้ และเปลี่ยนทิศทางมาสู่ codebase อิสระ เพื่อรองรับความต้องการเฉพาะของ iroh

ฟีเจอร์หลักของ noq

  • QUIC Multipath

    • ทำ สเปก QUIC Multipath ได้ครบถ้วน โดยรวมเส้นทาง relay และเส้นทางตรงของ iroh (IPV4, IPV6) เข้ากับ แนวคิดเรื่อง path แบบ first-class ของ QUIC
    • สามารถรักษา สถานะการควบคุมความหนาแน่นของทราฟฟิก แยกตามแต่ละเส้นทาง และเลือกเส้นทางที่เหมาะสมที่สุดได้
    • ก่อนหน้านี้ iroh จัดการเส้นทางไว้ใต้ชั้น QUIC แต่ตอนนี้ QUIC สามารถรับรู้และจัดการสิ่งเหล่านี้ได้ด้วยตัวเอง
    • ออกแบบให้เป็น อิมพลีเมนเทชัน multipath แบบใช้งานทั่วไป ที่สามารถใช้ได้นอกเหนือจาก iroh

  • QUIC NAT Traversal

    • ตีความและอิมพลีเมนต์ draft ของ QUIC NAT traversal ขึ้นเอง และระบุว่าเป็นกรณีแรกที่มี ความเสถียรระดับโปรดักชัน
    • ผ่านการทดสอบใช้งานจริงบนอุปกรณ์ iroh หลายแสนเครื่อง
    • ทำ NAT hole punching โดยตรงในชั้น QUIC ทำให้ ตัวควบคุม congestion และการตรวจจับ packet loss ทำงานได้แม่นยำยิ่งขึ้น

  • QUIC Address Discovery

    • ใช้ QUIC Address Discovery (QAD) มาตั้งแต่ iroh v0.32
    • เรียนรู้ public IP address ของไคลเอนต์ผ่านการเชื่อมต่อ QUIC แทน STUN
    • ใช้ การส่งแพ็กเก็ตที่เข้ารหัส เพื่อลด protocol ossification และ เพิ่มการคุ้มครองความเป็นส่วนตัว

  • QLog ส่วนขยาย

    • บันทึกเหตุการณ์ต่าง ๆ ของการเชื่อมต่อ QUIC โดยอิงจาก draft มาตรฐาน QLog
    • รองรับเหตุการณ์ได้มากกว่าเดิมมาก และเพิ่ม เหตุการณ์ที่เกี่ยวข้องกับ multipath เข้ามาด้วย
    • ใช้งานร่วมกับเครื่องมือแสดงผลอย่าง qvis ได้ และยังมี ต้นแบบ viewer สำหรับแสดงการไหลของแพ็กเก็ตแบบหลายเส้นทาง

  • WeakConnectionHandle

    • เป็นชนิดข้อมูลที่ไม่ต้องคงการเชื่อมต่อไว้ตลอด แต่สามารถ เลื่อนระดับเป็นอ็อบเจ็กต์ Connection ได้เมื่อจำเป็น
    • คล้ายกับ std::sync::Weak แต่ไม่จำเป็นต้องใช้ Arc
    • สามารถนำไปใช้ได้อย่างมีประโยชน์ในงานอย่าง ตัวจัดการการเชื่อมต่อ

การใช้งานจริงและ interoperability

  • noq ถูกใช้งานใน สภาพแวดล้อมโปรดักชันตั้งแต่ iroh v0.96
  • นอกจากอิมพลีเมนเทชัน multipath ของตัวเองแล้ว ยังผ่านการทดสอบ interoperability กับ picoquic เรียบร้อยแล้ว

แผนในอนาคต

  • มีแผนจะพัฒนา noq ให้เป็น เทคโนโลยีพื้นฐานระยะยาว
  • เดินหน้าปรับปรุง NAT traversal และ เพิ่มประสิทธิภาพ บนพื้นฐานของ multipath
  • รักษาความร่วมมือกับ QUIC Working Group และทีม Quinn ต่อไป
  • ขยายความร่วมมือกับนักพัฒนาที่ทำงานด้านอิมพลีเมนเทชัน QUIC, การขนส่งแบบ P2P และแอปพลิเคชันที่ต้องทำงานในสภาพแวดล้อมเครือข่ายที่หลากหลาย
  • จัดเตรียม เอกสารและโค้ดตัวอย่าง เพื่อให้นักพัฒนาสามารถลองใช้งาน QUIC multipath implementation บน Rust ได้โดยตรง

ภาพรวมของ Iroh

  • Iroh คือไลบรารีเครือข่ายแบบ “dial-any-device” ที่รองรับ การจัดองค์ประกอบเครือข่ายอย่างยืดหยุ่นผ่านการผสมโปรโตคอล
  • มีการใช้งานจริงบนอุปกรณ์หลายแสนเครื่องแล้ว และเผยแพร่เป็น โอเพนซอร์ส
  • สามารถเข้าร่วมโครงการได้ผ่านเอกสาร โค้ด และช่อง Discord

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

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

 
GN⁺ 2026-03-21
ความคิดเห็นจาก Hacker News

  • ชอบที่ได้เห็นทีม Iroh พูดคุยกันอย่างให้เกียรติใน เธรดนี้ ระหว่างกระบวนการตัดสินใจ fork

    • เป็นปฏิสัมพันธ์ที่ยอดเยี่ยมมาก ในอดีตผู้ดูแลโปรเจกต์มักมองการ fork ว่าเป็น การกระทำเชิงเป็นปฏิปักษ์ หรือเหมือน “ขโมยโค้ดของเรา” แต่ครั้งนี้แตกต่างออกไป
      มันยังสะท้อนให้เห็นชัดว่าการส่งการเปลี่ยนแปลงภายในกลับขึ้นไปยัง upstream นั้นยากแค่ไหน พวกเขาบอกว่าไม่มีเวลาพอจะซอยการเปลี่ยนแปลงของตัวเองออกเป็น PR เล็ก ๆ หลายร้อยอันเพื่อให้รีวิวได้ เพราะในมุมบริษัทมันเป็นการ ลงทุนด้านเวลา ที่มากเกินไป
      ถึงอย่างนั้นก็ยังหวังให้ยังคงใกล้เคียงกับโปรเจกต์ต้นทางและรายละเอียดของการพัฒนาไว้ หลังจากนิ่งพอแล้วก็น่าจะสามารถ รวมแบบก้อนใหญ่ ได้ ไม่จำเป็นต้องเป็นหน่วยเล็กเสมอไป
    • บทสนทนาที่สุภาพแบบนี้ดูดีมาก และตัดกับ ดราม่า ที่พบได้บ่อยในคอมมูนิตี้โอเพนซอร์ส

  • iroh ดูเป็น ผลิตภัณฑ์ที่วางตำแหน่งมาได้ดี สำหรับยุคที่การสร้างแอปส่วนตัวทำได้รวดเร็ว
    ฉันอยากลองใช้มันทำ “app relay” ที่ทำให้ผู้ใช้เข้าถึงแอปหรือข้อมูลในเครือข่ายของตัวเองจากระยะไกลได้โดยไม่ต้องตั้งค่าเพิ่ม เป็น โซลูชัน OSS แบบ zero-config ซึ่งต่างจาก network relay อย่าง Tailscale

    • ในทางปฏิบัติ zero-config ทำได้ยาก ฉันเคยทำ discovery แบบอิง mDNS บนโฮมเน็ตเวิร์กหลายแบบ แล้วเจอว่าราวเตอร์จำนวนมากบล็อกหรือจำกัด multicast สุดท้ายเลยต้องซ้อน fallback หลายชั้น และเขียน heuristic เพื่อเดาว่าเส้นทางไหนใช้งานได้จริง ถ้า QUIC มี multipath ในตัวมาตั้งแต่แรกก็คงง่ายกว่านี้มาก
    • ถ้าสนใจเรื่องนี้ ลองดู awesome-tunneling list ได้ โดยเฉพาะ OpenZiti ที่ใช้แนวทางคล้ายกันในการฝัง tunnel เข้าไปในแอปโดยตรง

  • ฉันชอบทีม n0 มาก ฉันใช้ sendme CLI ของพวกเขาบ่อย ๆ สำหรับส่งไฟล์แบบ P2P

    • ฉันก็เหมือนกัน ชุดเครื่องมือของพวกเขาให้ประสบการณ์พัฒนาที่ เร็ว เสถียร และใช้งานเพลิน รู้สึกเหมือนเป็นตัวเปลี่ยนเกมจริง ๆ
    • ขอบคุณสำหรับข้อมูลดี ๆ ปกติฉันใช้ magic wormhole แต่มี Python module เยอะเกินไปจนไม่อยากติดตั้งบนเซิร์ฟเวอร์ เลยใช้ทางเลือกที่เรียบง่ายกว่าอย่าง toothpyk บน Windows SQL Server หรือไม่ก็แก้ปัญหาด้วย wget แทน คงต้องลอง sendme ดูแล้ว

  • ฉันสงสัยว่า noq/iroh รีเลย์แพ็กเก็ต QUIC กันอย่างไร QUIC ติดตามได้ยาก แล้ว relay รู้ได้อย่างไรว่าควรส่งแพ็กเก็ตไหนไปที่ไหน หรือว่าห่อ QUIC ด้วยโปรโตคอลอื่นอีกที

    • ตัว noq เองไม่ได้ทำลอจิกรีเลย์ iroh relay แค่ทำงานเหมือนเป็น IP subnet อีกอันหนึ่ง
      ในทางปฏิบัติคือส่ง QUIC datagram โดย ห่อด้วย WebSocket ส่วน header จะมี EndpointId เป้าหมาย (กุญแจสาธารณะ ed25519) และฝั่งส่งก็ยืนยันตัวตนของ EndpointId ผ่าน handshake
      พูดอีกแบบคือเป็นการ tunnel QUIC datagram ผ่าน HTTPS over TCP ถึงจะเข้ารหัสซ้อนกันสองชั้น แต่ก็ทำงานได้ในสภาพแวดล้อมที่บล็อก UDP และถูกออกแบบมาให้ดูเหมือนทราฟฟิกทั่วไป

  • ทีม iroh ยัง พัฒนาอย่างรวดเร็ว อยู่เสมอ
    ฉันวางแผนว่าจะหาเวลาช่วงสุดสัปดาห์มาลองสร้าง overlay network แบบ Nebula ด้วย iroh

    • โปรเจกต์ที่เกี่ยวข้องซึ่งมีพูดถึงใน Discord ของพวกเขา ได้แก่ iroh-lan และ iron

  • แนวทางแบบ QUIC ยังเป็นโครงสร้างที่ผูกความต่อเนื่องของการเชื่อมต่อไว้กับ สถานะของทรานสปอร์ตอย่างแน่นแฟ้น
    ฉันกำลังคิดอยู่ว่าจะสามารถแยก session identity ออกจากชั้นทรานสปอร์ตได้อย่างสมบูรณ์ เพื่อให้ความล้มเหลวของทรานสปอร์ตกลายเป็นแค่เหตุการณ์ที่กู้คืนได้หรือไม่ อยากรู้ว่ามีใครเคยเห็น ระบบเชิงปฏิบัติ ที่ไปไกลกว่า QUIC ไหม

  • อ้างอิง โค้ดสไนเป็ตของ noq

  • ข่าวเกี่ยวกับ ฟีเจอร์ custom transport ของ iroh ที่เพิ่งประกาศล่าสุดก็น่าสนใจเช่นกัน
    ดูรายละเอียดได้ใน บล็อกโพสต์ iroh 0.97.0

  • มีใครลองดู nQUIC บ้างไหม ถ้าเอา Noise มารวมเข้ากับ Noq ก็น่าสนใจดี

    • มีการทดลองจริงอยู่แล้ว → โปรเจกต์ nquinn
      noq (และ Quinn ที่เป็นฐานของมัน) สามารถ implement “Session” trait ของตัวเองได้ จึงเลือกใช้ได้ทั้ง TLS หรือ nQUIC

  • อย่าสับสนกับ Noq ของ tsoding เพราะอันนั้นชื่อนี้มาจาก “Not Coq”