Multipath TCP สำหรับ Linux (ปี 2022)

 (mptcp.dev)
1 คะแนน โดย GN⁺ 2024-04-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ภาพรวมของ Multipath TCP

  • Multipath TCP (MPTCP) เป็นส่วนขยายของ TCP มาตรฐานและมีการอธิบายไว้ใน RFC 8684
  • ช่วยให้อุปกรณ์สามารถใช้หลายอินเทอร์เฟซพร้อมกันเพื่อส่งและรับแพ็กเก็ต TCP ผ่านการเชื่อมต่อ MPTCP เดียว
  • MPTCP สามารถรวมแบนด์วิดท์ของหลายอินเทอร์เฟซเข้าด้วยกัน หรือเลือกใช้อินเทอร์เฟซที่มีเวลาแฝงต่ำที่สุดเป็นหลัก
  • นอกจากนี้ แม้เส้นทางหนึ่งจะล่มก็ยังสามารถทำ failover ได้ และทราฟฟิกจะถูกส่งต่อไปยังเส้นทางอื่นอย่างราบรื่น

กรณีการใช้งานของ MPTCP

  • การที่ MPTCP ทำให้สามารถใช้หลายเส้นทางแบบขนานหรือพร้อมกันได้ ทำให้เกิดกรณีการใช้งานใหม่เมื่อเทียบกับ TCP:
    • Seamless handovers: สลับจากเส้นทางหนึ่งไปอีกเส้นทางหนึ่งโดยยังคงรักษาการเชื่อมต่อไว้ Apple ใช้ MPTCP บนสมาร์ตโฟนเป็นหลักด้วยเหตุผลนี้มาตั้งแต่ปี 2013
    • Best network selection: ใช้เส้นทางที่ "ดีที่สุด" ตามเงื่อนไขบางอย่าง เช่น latency, loss, cost และ bandwidth
    • Network aggregation: ใช้หลายเส้นทางพร้อมกันเพื่อให้ได้ throughput สูงขึ้น เช่น รวมเครือข่ายแบบมีสายและเครือข่ายมือถือเพื่อส่งไฟล์ได้เร็วขึ้น

แนวคิดของ MPTCP

  • เมื่อสร้างซ็อกเก็ตใหม่ด้วยโปรโตคอล IPPROTO_MPTCP (เฉพาะ Linux) จะมีการสร้าง subflow (หรือ path) ซึ่งประกอบด้วยการเชื่อมต่อ TCP ปกติที่ใช้ส่งข้อมูลผ่านอินเทอร์เฟซหนึ่ง
  • สามารถเจรจาเพิ่ม subflow เพิ่มเติมระหว่างโฮสต์ได้ในภายหลัง
  • มีการเพิ่มฟิลด์ใหม่ใน TCP option field ของ TCP subflow หลัก เพื่อให้โฮสต์ปลายทางตรวจพบว่ามีการใช้ MPTCP
  • ฟิลด์นี้มีตัวเลือกอย่าง MP_CAPABLE ซึ่งแจ้งให้อีกโฮสต์ใช้งาน MPTCP หากรองรับ
  • หากโฮสต์ปลายทางหรือ middlebox ระหว่างทางไม่รองรับ MPTCP ใน TCP option field ของแพ็กเก็ต SYN+ACK ที่ตอบกลับจะไม่มี MPTCP option
  • ในกรณีนี้ การเชื่อมต่อจะถูก "downgrade" เป็น TCP ปกติและดำเนินต่อไปแบบเส้นทางเดียว

พฤติกรรมนี้เกิดขึ้นได้จากองค์ประกอบภายในสองส่วนคือ Path Manager และ Packet Scheduler

Path Manager

  • Path Manager รับผิดชอบ subflow ตั้งแต่การสร้างจนถึงการลบ และรับผิดชอบการประกาศที่อยู่ด้วย
  • โดยทั่วไป ฝั่งไคลเอนต์จะเป็นผู้เริ่ม subflow และฝั่งเซิร์ฟเวอร์จะแจ้งที่อยู่เพิ่มเติมผ่านตัวเลือก ADD_ADDR และ REMOVE_ADDR
  • ณ Linux v5.19 มี Path Manager 2 แบบที่ควบคุมด้วย sysctl knob net.mptcp.pm_type:
    • in-kernel (type 0): ใช้กฎเดียวกันกับทุกการเชื่อมต่อ (ดู ip mptcp)
    • userspace (type 1): ควบคุมโดย userspace daemon (เช่น mptcpd) และสามารถใช้กฎต่างกันในแต่ละการเชื่อมต่อได้

Packet Scheduler

  • Packet Scheduler มีหน้าที่เลือก subflow ที่จะใช้ส่งแพ็กเก็ตข้อมูลถัดไปจากบรรดา subflow ที่พร้อมใช้งาน
  • สามารถตัดสินนโยบายต่าง ๆ ได้ตามการตั้งค่า เช่น ใช้แบนด์วิดท์ที่มีอยู่ให้มากที่สุด หรือเลือกเฉพาะเส้นทางที่มีเวลาแฝงต่ำที่สุด
  • ณ Linux v6.8 มี Packet Scheduler เพียงตัวเดียวที่ควบคุมด้วย sysctl knob ของ net.mptcp

คุณสมบัติหลักของ MPTCP (ณ Linux v6.10)

  • รองรับโปรโตคอล IPPROTO_MPTCP ใน system call socket()
  • fallback จาก MPTCP เป็น TCP หาก peer หรือ middlebox ไม่รองรับ MPTCP
  • การจัดการเส้นทางโดยใช้ path manager ภายในเคอร์เนลหรือใน userspace
  • socket options ที่มักใช้กับ TCP socket ทั่วไป
  • ความสามารถด้านดีบัก รวมถึง MIB counters, การรองรับ diag (ใช้ในคำสั่ง ss) และ trace points

ความเห็นของ GN⁺

  • MPTCP เป็นเทคโนโลยีที่มีประโยชน์มากเมื่ออุปกรณ์ปลายทางเชื่อมต่อกับหลายเครือข่าย สามารถนำไปใช้ได้อย่างมีประสิทธิภาพกับ 5G-Wi-Fi handover หรือการรวมเครือข่ายต่างชนิด
  • อย่างไรก็ตาม มีข้อจำกัดว่าทั้งฝั่งเซิร์ฟเวอร์และไคลเอนต์ต้องมีการติดตั้งรองรับ MPTCP และเครือข่ายระหว่างทางก็ต้องรองรับ MPTCP ด้วย จึงน่าจะต้องใช้เวลากว่าจะใช้งานกันอย่างแพร่หลาย
  • โปรโตคอล QUIC ของ Google ก็มีความสามารถแบบ multipath ที่คล้ายกัน และคาดว่า QUIC ซึ่งเรียบง่ายกว่าและอยู่บนพื้นฐานของ UDP จะกระจายตัวได้เร็วกว่า จึงน่าจะเกิดการแข่งขันระหว่าง MPTCP กับ QUIC
  • ต่างจากการติดตั้งใช้งาน MPTCP สำหรับ Linux ที่ผูกกับเคอร์เนล Apple ได้พัฒนา MPTCP ใน user space ของตนเองและใส่มาใน iOS และ macOS แล้ว Google ก็มีแนวโน้มว่าจะเลือกแนวทางที่คล้ายกัน
  • หากต้องการให้การควบคุมเส้นทางและนโยบายการจัดตารางของ MPTCP เหมาะสมกับความต้องการของแอปพลิเคชัน ก็อาจจำเป็นต้องมีการแลกเปลี่ยนข้อมูลระหว่างแอปพลิเคชันกับ MPTCP ผ่าน API ซึ่งจากที่ทราบยังไม่มีแนวทางที่เป็นมาตรฐานในเรื่องนี้

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

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

 
GN⁺ 2024-04-21
ความคิดเห็นจาก Hacker News
  • ตอนที่ได้ยินเรื่อง MPTCP ครั้งแรกในปี 2013 คิดว่ามันน่าจะช่วยยกระดับประสบการณ์ผู้ใช้ได้มาก เพราะตอนนั้นแอปมือถือรับมือกับการเปลี่ยนเครือข่ายได้ไม่ดี แต่ก็น่าผิดหวังมากที่ผ่านไป 10 ปีแล้วมันแทบไม่ได้รับความสนใจเลย
  • ไม่รู้ว่าอะไรน่าเศร้ากว่ากันระหว่างพื้นที่ที่อยู่ 32 บิตของ IPv4 กับการที่ TCP ใช้ที่อยู่ IP ต้นทาง/ปลายทางใน connection tuple ถ้ามีไทม์แมชชีนก็อยากย้อนกลับไปแก้สองอย่างนี้
  • การใช้งาน MPTCP ที่ดูเป็นประโยชน์จริงคือใช้เครือข่ายมือถือกับ Wi‑Fi ร่วมกันเพื่อเพิ่มความเร็ว แต่สำหรับผมมันไม่มีประโยชน์เพราะปกติปิดไว้ตลอดเนื่องจากแพ็กเกจข้อมูลมือถือ
  • น่าเสียดายที่ไม่มีลิงก์ไปยังโปรเจกต์ที่ใช้ MPTCP เช่นโปรเจกต์สาย OpenWrt ที่แตกแขนงออกมา ผมเคยเป็นเมนเทอร์ให้นักศึกษาที่แพตช์เพิ่มการรองรับ MPTCP ให้ OpenWrt ใน GSOC อยู่ 2 ปี
  • ถ้ามี transparent fallback ก็สงสัยว่าทำไมแอปพลิเคชันยังต้อง opt-in อย่างชัดเจน ดูเหมือนว่าสมเหตุสมผลที่สุดคือให้เคอร์เนลจัดการแบบโปร่งใสกับทุกการเชื่อมต่อ TCP แล้วตัดสินใจระดับระบบเกี่ยวกับ path aggregation / link preference
  • ผมทำงานด้านการรองรับ/ดีบัก/แก้ไข Linux network stack และไดรเวอร์ เลยแปลกใจกับอัตราการยอมรับใช้ MPTCP ที่ต่ำ ดูเหมือนว่าทุกอย่างที่พยายามมาแทนที่ TCP เดิมอย่าง SCTP สุดท้ายจะถูกใช้โดยนักพัฒนาเพียงกลุ่มเล็ก ๆ แล้วโลกที่เหลือก็ลืมมันไป
  • เจอบทความที่อธิบายความแตกต่างด้านสถาปัตยกรรมระหว่าง MPTCP กับ QUIC รวมถึงโปรโตคอล MPQUIC ที่ผู้เขียนเสนอ QUIC ทำ multiplex application streams บน UDP flow เดียว ส่วน MPTCP แบ่ง stream เดียวออกเป็นหลาย TCP subflows ขณะที่ MPQUIC รวมความสามารถทั้งสองอย่างด้วยการทำ multiplex application streams บนหลาย UDP subflows
  • Apple ก็รองรับ MPTCP เช่นกัน และใช้อยู่ใน Siri
  • ถ้า middlebox ระหว่างทางไม่รองรับตัวเลือก MPTCP ก็จะไม่มีตัวเลือก MPTCP อยู่ในแพ็กเก็ต SYN+ACK ซึ่งดูเป็นข้อจำกัดพอสมควร ข้อกำหนดเดียวของ middlebox คือแค่ส่งต่อ MPTCP option ตามเดิมใช่ไหม?
  • MPTCP อาจช่วยเรื่องการตั้งค่าความปลอดภัย/ความเป็นส่วนตัวได้ เช่น ถ้าแยกทราฟฟิกไปหลาย uplink channels ก็จะทำให้ไฟร์วอลล์ของรัฐบาลจีนรวมทราฟฟิกเพื่อบล็อกได้ยากขึ้น