Multipath TCP สำหรับลินุกซ์ (ปี 2022)

 (mptcp.dev)
1 คะแนน โดย GN⁺ 2024-04-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • MPTCP คือส่วนขยายของ TCP ตาม RFC 8684 ที่ช่วยให้การเชื่อมต่อหนึ่งรายการใช้อินเทอร์เฟซเครือข่ายหลายตัวพร้อมกัน เพื่อปรับปรุงแบนด์วิดท์ ความหน่วง และการรับมือความขัดข้อง
  • เนื่องจากมีโครงสร้างที่ใช้หลายเส้นทางแบบขนาน จึงสามารถ รวมแบนด์วิดท์, เลือกใช้เส้นทางที่มีความหน่วงต่ำกว่า และฉีดทราฟฟิกซ้ำไปยังเส้นทางอื่นเมื่อเส้นทางขัดข้องได้
  • บน Linux จะสร้างซ็อกเก็ตด้วย IPPROTO_MPTCP และประกอบ subflow ซึ่งเป็นการเชื่อมต่อ TCP ปกติ หากปลายทางหรืออุปกรณ์กลางไม่รองรับ ก็จะลดระดับไปเป็น TCP เส้นทางเดียวโดยอัตโนมัติ
  • การจัดการเส้นทางใน Linux ณ เวอร์ชัน v5.19 มีทั้งแบบในตัวเคอร์เนลและแบบเดมอนใน user space เช่น mptcpd และ ณ Linux v6.8 packet scheduler มีเพียงตัวเดียวที่ควบคุมผ่าน sysctl ของ net.mptcp
  • ณ Linux v6.10 ความสามารถครอบคลุมถึงการรองรับ socket(), การลดระดับเป็น TCP, การจัดการเส้นทางในเคอร์เนล/user space, ตัวเลือกซ็อกเก็ต TCP, ตัวนับ MIB, การวินิจฉัยด้วย ss และฟีเจอร์ดีบัก tracepoint

MPTCP เปลี่ยนรูปแบบการเชื่อมต่อ TCP อย่างไร

  • Multipath TCP(MPTCP) เป็นส่วนขยายของ TCP มาตรฐาน ซึ่งกำหนดไว้ใน RFC 8684
  • การเชื่อมต่อ MPTCP หนึ่งรายการสามารถใช้อินเทอร์เฟซหลายตัวพร้อมกันเพื่อส่งและรับแพ็กเก็ต TCP ได้
  • สามารถ รวมแบนด์วิดท์ ของหลายอินเทอร์เฟซ หรือให้ความสำคัญกับอินเทอร์เฟซที่มีเวลาแฝงต่ำที่สุดก่อน
  • หากเส้นทางหนึ่งหลุด จะฉีดทราฟฟิกซ้ำไปยังอีกเส้นทางได้อย่างราบรื่นเพื่อทำ failover
  • ต่างจาก TCP ปกติที่ใช้เส้นทางเดียวในแต่ละครั้ง MPTCP สามารถใช้หลายเส้นทาง เช่น 5G และ Wi‑Fi ร่วมกันเป็น subflow ได้

กรณีใช้งานหลัก

  • การแฮนด์โอเวอร์แบบไม่สะดุด

    • สามารถสลับจากเส้นทางหนึ่งไปยังอีกเส้นทางหนึ่งโดยยังคงรักษาการเชื่อมต่อเดิมไว้ได้
    • Apple ใช้ Multipath TCP บนสมาร์ตโฟนมาตั้งแต่ปี 2013 โดยส่วนใหญ่ด้วยเหตุผลนี้

  • การเลือกเครือข่ายที่เหมาะสมที่สุด

    • เลือกเส้นทางที่ “ดีที่สุด” จากเส้นทางที่ใช้งานได้ โดยพิจารณาเงื่อนไขอย่างเวลาแฝง การสูญเสียแพ็กเก็ต ค่าใช้จ่าย และแบนด์วิดท์

  • การรวมเครือข่าย

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

วิธีที่การเชื่อมต่อเกิดขึ้นบน Linux

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

ตัวจัดการเส้นทางและตัวกำหนดตารางแพ็กเก็ต

  • ภายใน MPTCP จะแบ่งหน้าที่ให้ Path Manager และ Packet Scheduler จัดการการสร้าง subflow, การประกาศที่อยู่ และการเลือกเส้นทางส่งข้อมูล

  • Path Manager

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

  • Packet Scheduler

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

ความสามารถ ณ Linux v6.10

  • ณ Linux v6.10 MPTCP มีความสามารถดังต่อไปนี้
    • รองรับโปรโตคอล IPPROTO_MPTCP ใน system call socket()
    • ลดระดับ จาก MPTCP เป็น TCP เมื่อปลายทางหรือ middlebox ไม่รองรับ MPTCP
    • การจัดการเส้นทางโดยใช้ path manager แบบในตัวเคอร์เนลหรือแบบ user space
    • ตัวเลือกซ็อกเก็ตที่ใช้กันทั่วไปในซ็อกเก็ต TCP
    • ฟีเจอร์ดีบัก รวมถึงตัวนับ MIB, การรองรับ diag ที่คำสั่ง ss ใช้ และ tracepoint
  • ดูรายละเอียดการเปลี่ยนแปลงได้ที่ ChangeLog

ช่องทางสื่อสารและโปรเจกต์ที่เกี่ยวข้อง

  • ช่องทางสื่อสาร
  • โปรเจกต์ที่ดูแลโดยสมาชิกชุมชน MPTCP
  • โปรเจกต์ที่มีการปรับปรุงเกี่ยวกับ MPTCP
    • iproute2: สำหรับคำสั่ง ip mptcp
    • Network Manager: มีฟีเจอร์ MPTCP ตั้งแต่ v1.40
    • Multipath TCP applications: โปรเจกต์ที่ประสานงานการอัปเดต MPTCP สำหรับแอปพลิเคชัน TCP ยอดนิยม

ทรัพยากรสำหรับการพัฒนาเคอร์เนล

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

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

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

  • เคยได้ยินเรื่อง MPTCP มาตั้งแต่ปี 2013 แล้ว
    ตอนนั้นพอนึกถึงว่าแอปมือถือยังไม่ค่อยทนต่อการเปลี่ยนเครือข่ายมากนัก ก็คิดว่ามันน่าจะถูกนำไปใช้เร็วเพราะช่วยปรับปรุง UX ได้มาก
    แต่ตลอด 10 ปีที่ผ่านมาแทบไม่ได้ traction เลย และเพิ่งจะมาเห็นเป็นตัวเลือกในเคอร์เนลตอนนี้ก็ค่อนข้างน่าเศร้า ระหว่างนั้นทุกคนก็ห่อ HTTP call ไว้ด้วยตัวจัดการ retry หลายชั้นกันหมดแล้ว และระบบปฏิบัติการมือถือก็ทำเรื่องการเชื่อมต่อเครือข่ายให้เป็นนามธรรมมากเกินไป จนให้ความรู้สึกใกล้กับการใช้ zeromq มากกว่า TCP

    • ดูเหมือนพลังของนวัตกรรมจำนวนมากจะย้ายไปอยู่ที่ QUIC แล้ว เพราะบน TCP ต่อให้สร้างรูปแบบใหม่ได้ดีแค่ไหน อุปกรณ์กลางทางก็อาจทำให้พังแบบสุ่มได้
      ดูตัวอย่างได้ที่ https://blog.apnic.net/2021/12/08/efficient-multipath-transp...
    • อยากจะชอบมันเหมือนกัน และ Apple ก็ใส่มาใน iOS แล้ว แต่การรองรับบนเซิร์ฟเวอร์จริงทำได้ยากเกินไป
      ตอนนำไปใช้บน FreeBSD โดยไม่มี load balancer แพตช์ล่าสุดยังไม่มี และถึงจะมี ก็ยังต้องทำงานอีกมากเพื่อไม่ให้มีการประกาศ private network IP เป็นเส้นทางสำรอง
      บน Linux เวลาวางไว้หลัง load balancer การส่งสตรีมไปยังปลายทางที่ถูกต้องซับซ้อนเกินไป และตัว load balancer เองก็ไม่ได้พยายามจะทำแบบนั้น
      การจัดการสองสตรีมร่วมกันคือการเพิ่มความซับซ้อนอย่างมากให้กับ เส้นทางที่มีปริมาณงานสูง ซึ่งเสี่ยงมาก และถ้าจะเปลี่ยนก็ต้องรีบูตด้วย
      ต่อให้ทำทั้งหมดนั้นแล้ว ประโยชน์หลักก็ยังตกกับผู้ใช้ iOS เป็นหลัก ซึ่งผู้ใช้กลุ่มนี้ก็มักมีเครือข่ายที่ดีกว่าอยู่แล้ว
    • SCTP ที่ออกมาตั้งแต่ปี 2000 ก็น่าสนใจเช่นกัน อันนี้ก็ยังแทบไม่ได้รับการยอมรับเช่นกัน
      https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
    • ตอนทำหุ่นยนต์ส่งของ เคยหวังพึ่ง MPTCP เพราะอยากทำ failover ทันทีด้วย เซลลูลาร์โมเด็ม 2 ตัว
      สุดท้ายเพื่อประหยัดเวลาพัฒนาเลยใช้ SpeedFusion ของ PepLink แต่ค่าไลเซนส์แพงมาก หวังว่าในอนาคตจะมีทางออกฟรีสำหรับการใช้เครือข่ายเซลลูลาร์ 2 เส้นพร้อม failover ต่ำกว่า 50ms
      multipath UDP + OpenVPN ก็น่าจะเป็นทางออกที่ใช้งานได้จริงเหมือนกัน
    • กลับกัน รู้สึกน่าเศร้าที่มันได้รับความสนใจมากเกินกว่าที่ควรได้รับ TCP ไม่ควรถูกเติมแฮ็กเพิ่มทีละอย่างเพื่อให้พอเหมาะแบบครึ่ง ๆ กลาง ๆ กับกรณีใช้งานในสภาพแวดล้อมสมัยใหม่เพียงประมาณครึ่งหนึ่ง แต่ควรถูก แทนที่ด้วย SCTP

  • ไม่แน่ใจว่าอะไรน่าเศร้ากว่ากัน ระหว่างพื้นที่ адрес IPv4 ที่มีแค่ 32 บิต กับการที่ TCP ใช้ IP ต้นทาง/ปลายทางใน connection tuple
    ถ้ามีไทม์แมชชีนก็อยากย้อนกลับไปหา Cerf กับ Kahn แล้วให้แก้ทั้งสองอย่าง

    • สงสัยว่าหมายถึงจะเปลี่ยน TCP อย่างไร
      หมายถึงโครงสร้างที่ต้องติดตามการเชื่อมต่อด้วย 4 ฟิลด์ คือ IP และพอร์ตของทั้งสองฝั่งใช่ไหม?
    • พวกเขาคงจะบอกว่าได้ให้ source routing มาแล้ว ซึ่งนั่นคือครึ่งหนึ่งของสิ่งที่คุณต้องการ และมันก็ถูกระบุไว้อย่างถูกต้องในฐานะออปชัน

  • เสียดายที่ไม่มีลิงก์ไปยังโปรเจกต์ที่ใช้ MPTCP เช่น โปรเจกต์สาย OpenWrt
    เคยเป็นเมนเทอร์ให้นักศึกษาใน GSOC อยู่ 2 ปี โดยทำแพตช์ MPTCP ให้กับ OpenWrt
    https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-sup...

    • โปรเจกต์นี้อาจน่าสนใจ: https://github.com/Ysurac/openmptcprouter
      ไม่นานมานี้ผมซื้ออสังหาริมทรัพย์ที่ยังติดตั้งไฟเบอร์เต็มรูปแบบไม่ได้ แต่ใช้ 5G ได้ราว 150~400Mbps เลยกำลังคิดจะใช้ 5G สองเส้นแล้ว tunnel ทราฟฟิกผ่าน MPTCP ไปยัง VPS เพื่อรวมลิงก์เข้าด้วยกัน
    • เพิ่งถูกเปิดใช้ใน เคอร์เนล Home Assistant HAOS ไม่นานนี้
      https://github.com/home-assistant/operating-system/pull/3248
    • ตัวอย่างหนึ่งบน OpenWrt คืออันนี้
      http://www.openmptcprouter.com/
    • สงสัยว่าถ้าเราเตอร์ OpenWrt รองรับ MPTCP จะมีข้อดีอะไรบ้าง
      ดูเหมือนว่าสิ่งที่สำคัญที่สุดน่าจะเป็นการรองรับบนเว็บเซิร์ฟเวอร์และอุปกรณ์พกพา

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

    • เข้าใจว่านี่เป็นเงื่อนไขที่ผู้ดูแล Linux TCP/ระบบย่อยเครือข่ายกำหนดไว้แทบจะเป็นข้อบังคับ ถ้าดูการอภิปรายช่วงต้นก่อน upstream[1] ก็จะเห็นว่านี่ถูกตั้งเป็นกติกาหลักไว้
      implementation multipath TCP รุ่นเก่าก่อนเข้า upstream ตั้งใจให้โปร่งใสต่อแอปพลิเคชันอย่างสมบูรณ์ และผมคิดว่านั่นสอดคล้องกับเป้าหมายของโปรโตคอลมากกว่า
      แน่นอนว่าในหลายกรณี MPTCP จะดีกว่าถ้าได้รับคำแนะนำจากแอปพลิเคชัน แต่ตัวอย่างเช่น ถ้ามีเพียงแนวทางมาตรฐานระดับระบบที่สร้าง subflow บนการเชื่อมต่อ LTE เพื่อเตรียม automatic failover ไว้ แต่ไม่ส่งข้อมูลผ่าน subflow นั้น ก็อาจเพียงพอสำหรับ 95% ของกรณีใช้งานแล้ว
      [1] https://lore.kernel.org/all/alpine.OSX.2.21.1707181728570.11...
    • การใช้สิ่งนี้หมายความว่าสำหรับ TCP connection เดียว หนึ่ง endpoint แต่ละฝั่งสามารถผูกกับ หลาย IP ได้ ในหลายกรณีจึงต้องการการรองรับหรืออย่างน้อยการรับรู้แบบชัดเจนจากแอปพลิเคชัน
    • ถ้าอนุญาตให้หลาย IP สื่อสารอยู่บน TCP connection เดียวกัน ก็อาจเกิด ช่องโหว่ด้านความปลอดภัย แบบใหม่ได้
      เช่น อาจมีแอปพลิเคชันที่ตอนเริ่มเชื่อมต่อจะตรวจสอบ IP ของไคลเอนต์กับ whitelist แล้วหลังจากนั้นก็ถือว่า IP จะไม่เปลี่ยนอีก

  • สำหรับฉัน การใช้งาน MPTCP ที่ใช้งานได้จริงเพียงอย่างเดียวคือ ใช้เครือข่ายมือถือกับ Wi-Fi พร้อมกันเพื่อเพิ่มความเร็ว โดยทั้ง iOS และ WeChat รองรับสิ่งนี้
    แต่เครือข่ายมือถือคิดค่าบริการตามปริมาณข้อมูลเลยปิดไว้ตลอด ดังนั้นสำหรับฉัน MPTCP จึงไม่มีประโยชน์

    • เคยจัดการปัญหานี้มาก่อน เรียกกันภายในว่า บั๊กลานจอดรถ
      คือสถานการณ์ที่ยังเห็นสัญญาณ Wi-Fi อยู่ แต่เชื่อมต่อใช้งานจริงไม่ได้ ถ้ามี MPTCP ก็จะสลับไปใช้เครือข่ายเซลลูลาร์เมื่อเกิดปัญหา

  • ฉันทำงานด้านสนับสนุน ดีบัก และแก้ไข Linux network stack กับไดรเวอร์ และแปลกใจที่มันถูกนำไปใช้น้อยขนาดนี้
    เหมือนกับสิ่งอื่น ๆ อย่าง SCTP ที่พยายามมาแทน TCP ทั่วไป MPTCP ก็ดูจะยังเป็น เทคโนโลยีเฉพาะทาง ที่มีนักพัฒนาแอปบางส่วนใช้กันต่อไป ขณะที่โลกที่เหลือก็ลืมมันไป

    • Apple Siri ใช้ MPTCP ดังนั้นถ้ามองจากจำนวนอุปกรณ์ก็คงไม่อาจเรียกว่าเป็นแค่ของเฉพาะทางได้เต็มปาก

  • ฉันเจอเอกสารที่อธิบายความต่างเชิงโครงสร้างระหว่าง MPTCP กับ QUIC และยังแนะนำโปรโตคอล MPQUIC ที่ผู้เขียนเสนอไว้ด้วย
    QUIC ทำ multiplex แอปพลิเคชันสตรีมบน UDP flow เดียว ส่วน MPTCP แบ่งสตรีมเดียวออกเป็นหลาย TCP subflow และ MPQUIC รวมสองคุณลักษณะนี้เข้าด้วยกันโดยทำ multiplex แอปพลิเคชันสตรีมบนหลาย UDP subflow
    [1]: "Multipath QUIC: A Deployable Multipath Transport Protocol" https://www.researchgate.net/publication/327122884_Multipath...
    ตอนนี้เลยสงสัยว่าในสภาพแวดล้อม production โปรโตคอลพวกนี้เปรียบเทียบกันอย่างไร มีใครเคยใช้ทั้งสองอย่างไหม?

    • MPQUIC ยังอยู่ระหว่างการหารือใน IETF ในการประชุม IETF ครั้งล่าสุดก็ยังมีการพูดถึงการเปลี่ยนแปลงเพิ่มเติมอีก และน่าเสียดายว่าทำให้การนำไปใช้ยิ่งช้าลง
      https://lwn.net/Articles/964377/
      ทั้งสองอย่างพยายามบรรลุเป้าหมายเดียวกัน ในทางเทคนิคสามารถทำให้พฤติกรรมคล้ายกันมากได้ MPTCP ถูกอิมพลีเมนต์ใน Linux kernel ส่วน QUIC อยู่ฝั่ง user space

  • Apple ก็รองรับและใช้กับ Siri
    https://developer.apple.com/documentation/foundation/urlsess...

    • แอปอื่นก็ใช้งานได้ค่อนข้างง่ายเช่นกัน มันมีอยู่ในฟีเจอร์พื้นฐาน
      ตอนปี 2011 ฉันยังแปลกใจอยู่เลยที่แอป VoIP ของเราทำงานได้ทนทานขนาดนั้น :D

  • ถ้ามีอุปกรณ์กลางแม้แต่ตัวเดียวที่ไม่รองรับ แล้วแพ็กเก็ต SYN+ACK ที่ส่งกลับมาไม่มีตัวเลือก MPTCP อยู่ในฟิลด์ TCP options แบบนี้ฟังดู มีข้อจำกัด พอสมควร
    ข้อกำหนดเพียงอย่างเดียวของอุปกรณ์กลางคือแค่ต้องส่งผ่านตัวเลือก MPTCP ไปตรง ๆ เท่านั้นหรือ?

    • ก่อนจะสรุปสเปก เราทดสอบกันเยอะมากว่าเปิด MPTCP แล้วการเชื่อมต่อจะไม่พัง
      คือไม่ก็ผ่านไปได้อย่างถูกต้อง ไม่ก็ fallback กลับเป็น single-path TCP อย่างปลอดภัย
      โดยทั่วไปแล้ว หากอุปกรณ์กลางส่งผ่านตัวเลือกที่ตัวเองไม่รู้จักโดยไม่แก้ไข และไม่ได้บังคับว่า TCP sequence space ที่มันมองเห็นต้องต่อเนื่องกัน MPTCP ก็สามารถทำงานผ่านอุปกรณ์นั้นได้
      ถ้าสนใจ มีบทความที่เกี่ยวข้องสองฉบับ
      [1] https://www.usenix.org/conference/nsdi12/technical-sessions/...
      [2] https://www.researchgate.net/publication/229002024_Is_it_sti...

  • มันอาจช่วยได้ในแง่การตั้งค่าความปลอดภัยและความเป็นส่วนตัว
    ตัวอย่างเช่นถ้าคิดถึง Great Firewall ของจีน ถ้าสามารถแบ่งทราฟฟิกออกไปหลาย uplink channel ได้ แบบนั้นไฟร์วอลล์จะประกอบกลับขึ้นมาเพื่อบังคับใช้นโยบายได้ยากขึ้นหรือเปล่า?

    • ถ้าเป็นทราฟฟิกที่ไม่รู้จัก ก็แค่บล็อกทิ้งหรือไม่ก็จำกัดความเร็วอย่างหนักก็พอ