Multipath TCP cho Linux (2022)

 (mptcp.dev)
1 điểm bởi GN⁺ 2024-04-21 | 1 bình luận | Chia sẻ qua WhatsApp
  • MPTCP là phần mở rộng của TCP dựa trên RFC 8684, cho phép một kết nối sử dụng đồng thời nhiều giao diện mạng để cải thiện băng thông, độ trễ và khả năng ứng phó sự cố
  • Với kiến trúc dùng song song nhiều đường truyền, nó cho phép gộp băng thông, ưu tiên đường có độ trễ thấp, và tái chèn lưu lượng sang đường khác khi một đường gặp sự cố
  • Trên Linux, socket được tạo bằng IPPROTO_MPTCP và cấu thành các kết nối TCP thông thường gọi là subflow; nếu phía đối tác hoặc thiết bị trung gian không hỗ trợ, kết nối sẽ tự động hạ xuống TCP một đường truyền
  • Việc quản lý đường truyền trên Linux, tính đến v5.19, có kiểu tích hợp trong kernel và kiểu daemon không gian người dùng như mptcpd; tính đến Linux v6.8, chỉ có một packet scheduler được điều khiển bằng sysctl net.mptcp
  • Tính đến Linux v6.10, các tính năng bao gồm hỗ trợ socket(), hạ xuống TCP, quản lý đường truyền ở kernel/người dùng, tùy chọn socket TCP, cùng các tính năng gỡ lỗi như MIB, chẩn đoán ss và tracepoint

MPTCP thay đổi cách thiết lập kết nối TCP

  • Multipath TCP(MPTCP) là phần mở rộng của TCP tiêu chuẩn, được định nghĩa trong RFC 8684
  • Một kết nối MPTCP có thể đồng thời sử dụng nhiều giao diện để gửi và nhận gói TCP
  • Có thể gộp băng thông của nhiều giao diện hoặc ưu tiên giao diện có độ trễ thấp nhất
  • Nếu một đường bị ngắt, lưu lượng có thể được tái chèn mượt mà sang đường khác để thực hiện chuyển đổi dự phòng
  • Khác với TCP thông thường chỉ dùng một đường tại một thời điểm, MPTCP có thể dùng đồng thời nhiều đường như 5G và Wi‑Fi dưới dạng subflow

Các trường hợp sử dụng tiêu biểu

  • Chuyển giao không gián đoạn

    • Có thể chuyển từ đường này sang đường khác mà vẫn giữ nguyên kết nối hiện tại
    • Apple đã sử dụng Multipath TCP trên smartphone chủ yếu vì lý do này từ năm 2013

  • Chọn mạng tối ưu

    • Chọn đường “tốt nhất” trong các đường khả dụng dựa trên các điều kiện như độ trễ, mất gói, chi phí và băng thông

  • Gộp mạng

    • Có thể tăng thông lượng bằng cách dùng đồng thời nhiều đường
    • Ví dụ là kết hợp mạng cố định và mạng di động để truyền tệp nhanh hơn

Cách kết nối được thiết lập trên Linux

  • Khi tạo socket mới bằng giao thức riêng của Linux IPPROTO_MPTCP, một subflow hoặc path sẽ được tạo ra
  • subflow là một kết nối TCP thông thường truyền dữ liệu qua một giao diện duy nhất
  • Sau đó, thông qua quá trình thương lượng giữa các host, có thể tạo thêm các subflow
  • Trong trường TCP option của subflow TCP nền tảng, có thêm các trường mới để host bên kia có thể nhận biết việc sử dụng MPTCP
    • Các trường này bao gồm tùy chọn MP_CAPABLE để thông báo cho đối tác biết MPTCP đang được sử dụng
  • Nếu host đối tác hoặc middlebox ở giữa không hỗ trợ MPTCP, trường TCP option trong gói SYN+ACK trả về sẽ không có tùy chọn MPTCP
    • Trong trường hợp này, kết nối sẽ hạ xuống TCP thông thường và tiếp tục với một đường duy nhất

Path manager và packet scheduler

  • Về nội bộ, MPTCP chia việc tạo subflow, thông báo địa chỉ và chọn đường truyền thành hai thành phần: Path Manager và Packet Scheduler

  • Path Manager

    • Path Manager quản lý subflow từ lúc tạo đến lúc xóa, đồng thời phụ trách thông báo địa chỉ
    • Thông thường phía client sẽ khởi tạo subflow, còn phía server sẽ thông báo địa chỉ bổ sung bằng các tùy chọn ADD_ADDR và REMOVE_ADDR
    • Tính đến Linux v5.19, hai path manager được điều khiển bằng sysctl knob net.mptcp.pm_type
      • loại 0: cách tích hợp trong kernel, áp dụng cùng một quy tắc cho mọi kết nối. Liên quan đến ip mptcp
      • loại 1: cách không gian người dùng, được điều khiển bởi daemon như mptcpd và có thể áp dụng quy tắc khác nhau theo từng kết nối

  • Packet Scheduler

    • Packet Scheduler chọn subflow sẽ được dùng để gửi gói dữ liệu tiếp theo
    • Nó có thể tối đa hóa băng thông khả dụng, chỉ chọn các đường có độ trễ thấp hơn, hoặc áp dụng các chính sách khác theo cấu hình
    • Tính đến Linux v6.8, chỉ có một packet scheduler và nó được điều khiển bằng sysctl knob của net.mptcp

Tính năng tính đến Linux v6.10

  • Tính đến Linux v6.10, MPTCP cung cấp các tính năng sau
    • Hỗ trợ giao thức IPPROTO_MPTCP trong lời gọi hệ thống socket()
    • Hạ xuống từ MPTCP sang TCP khi phía đối tác hoặc middlebox không hỗ trợ MPTCP
    • Quản lý đường truyền bằng path manager tích hợp trong kernel hoặc ở không gian người dùng
    • Các tùy chọn socket thường được dùng trên socket TCP
    • Bộ đếm MIB, hỗ trợ diag được lệnh ss sử dụng, và các tính năng gỡ lỗi bao gồm tracepoint
  • Có thể xem chi tiết thay đổi trong ChangeLog

Kênh liên lạc và các dự án liên quan

Tài nguyên phát triển kernel

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-04-21
Ý kiến trên Hacker News

  • MPTCP thì tôi đã nghe từ năm 2013 rồi
    Nghĩ đến việc hồi đó ứng dụng di động không thực sự vững khi mạng thay đổi, tôi tưởng mức cải thiện UX sẽ lớn nên nó sẽ nhanh chóng được chấp nhận
    Nhưng trong 10 năm qua nó gần như không có traction, và giờ mới thấy xuất hiện tùy chọn kernel thì khá đáng buồn. Trong lúc đó, mọi người đã bọc các lệnh gọi HTTP bằng nhiều cơ chế retry, còn hệ điều hành di động thì trừu tượng hóa kết nối mạng đến mức cảm giác gần như dùng zeromq hơn là TCP

    • Có vẻ nhiều năng lượng đổi mới đã chuyển sang QUIC. Vì với TCP, dù có tạo ra biến thể mới tốt đến đâu thì thiết bị trung gian vẫn có thể tùy ý làm hỏng nó
      Xem ví dụ tại https://blog.apnic.net/2021/12/08/efficient-multipath-transp...
    • Tôi đã muốn thích nó, và Apple cũng đưa vào iOS, nhưng hỗ trợ trên server thực tế thì quá khó
      Khi triển khai trên FreeBSD không có load balancer thì không có bản vá mới nhất, và ngay cả nếu có thì cũng cần khá nhiều công sức để không quảng bá IP mạng riêng làm tuyến thay thế
      Khi ở sau load balancer trên Linux, việc gửi stream đến đúng chỗ quá phức tạp, và load balancer cũng không muốn làm việc đó
      Xử lý hai stream cùng nhau đồng nghĩa đưa độ phức tạp lớn vào đường xử lý thông lượng cao, nên rủi ro lớn, và muốn thay đổi còn cần reboot
      Dù làm hết như vậy, lợi ích chủ yếu chỉ dành cho người dùng iOS, mà những người đó ngay từ đầu thường đã dùng mạng tốt hơn
    • SCTP ra đời năm 2000 cũng đáng quan tâm. Cái này đến nay cũng gần như chưa được chấp nhận
      https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
    • Khi làm robot giao hàng, tôi từng kỳ vọng vào MPTCP vì muốn failover tức thì với 2 modem di động
      Cuối cùng, để tiết kiệm thời gian phát triển, chúng tôi dùng SpeedFusion của PepLink, nhưng phí license đắt. Hy vọng sau này sẽ có giải pháp miễn phí cho 2 mạng di động và failover dưới 50ms
      UDP đa đường + OpenVPN có lẽ cũng có thể là một giải pháp thực dụng
    • Ngược lại, việc nó nhận được sự chú ý không xứng đáng mới đáng buồn. TCP không nên tiếp tục thêm từng hack chỉ tạm phù hợp với khoảng một nửa use case trong môi trường hiện đại rồi cho chọn cách kết hợp, mà nên được thay thế bằng SCTP

  • Tôi không biết điều gì đáng buồn hơn: không gian địa chỉ IPv4 chỉ có 32 bit, hay TCP dùng địa chỉ IP nguồn/đích trong tuple kết nối
    Nếu có cỗ máy thời gian, tôi muốn quay về gặp Cerf và Kahn để bảo họ đổi cả hai

    • Tôi tò mò ý bạn là sẽ thay đổi TCP như thế nào
      Ý bạn là cấu trúc phải theo dõi kết nối bằng địa chỉ IP và cổng của hai bên, tức 4 trường đó à?
    • Có lẽ họ sẽ nói rằng họ đã cho chúng ta source routing, đó là một nửa thứ bạn muốn, và nó đã được đặc tả đúng dưới dạng option

  • Thật tiếc là không có link đến các dự án dùng MPTCP, ví dụ như dự án phái sinh của OpenWrt
    Tôi từng mentor sinh viên trong GSOC suốt 2 năm để patch MPTCP vào OpenWrt
    https://blog.freifunk.net/2017/05/29/gsoc-2017-add-mptcp-sup...

    • Dự án này có thể thú vị: https://github.com/Ysurac/openmptcprouter
      Gần đây tôi mua một bất động sản không lắp được đường cáp quang đầy đủ, nhưng 5G đạt 150~400Mbps. Tôi đang nghĩ đến việc dùng 2 đường 5G và tunnel traffic bằng MPTCP đến một VPS để gộp băng thông
    • Gần đây nó đã được bật trong kernel Home Assistant HAOS
      https://github.com/home-assistant/operating-system/pull/3248
    • Một ví dụ trên OpenWrt là đây
      http://www.openmptcprouter.com/
    • Tôi thắc mắc router OpenWrt hỗ trợ MPTCP thì có lợi ích gì
      Có vẻ việc web server và thiết bị di động hỗ trợ mới là quan trọng nhất

  • Nếu có tuyến thay thế trong suốt, tôi không hiểu vì sao ứng dụng lại cần lựa chọn rõ ràng
    Tôi nghĩ kernel nên xử lý trong suốt cho mọi kết nối TCP thì mới có thể đưa ra quyết định toàn cục tốt hơn, như gộp đường truyền hay ưu tiên liên kết

    • Tôi hiểu đây là điều kiện mà các maintainer của subsystem TCP/networking trên Linux gần như đã áp đặt. Nhìn các thảo luận upstream ban đầu[1] thì điều này đã được đặt làm quy tắc cơ bản
      Triển khai Multipath TCP cũ trước khi upstream vốn được thiết kế để hoàn toàn trong suốt với ứng dụng, và tôi nghĩ hướng đó phù hợp hơn với mục tiêu của giao thức
      Dĩ nhiên trong nhiều trường hợp MPTCP sẽ tốt hơn nếu nhận chỉ dẫn từ ứng dụng, nhưng chỉ cần một cách tiếp cận hệ thống chuẩn, chẳng hạn tạo subflow trên kết nối LTE để sẵn sàng failover tự động nhưng không gửi dữ liệu qua subflow đó, thì cũng đã đủ cho 95% trường hợp
      [1] https://lore.kernel.org/all/alpine.OSX.2.21.1707181728570.11...
    • Dùng cái này nghĩa là với một kết nối TCP, mỗi endpoint có thể gắn với nhiều IP. Trong nhiều trường hợp, ứng dụng sẽ cần hỗ trợ hoặc nhận biết rõ ràng
    • Cho phép nhiều IP giao tiếp trên cùng một kết nối TCP có thể tạo ra lỗ hổng bảo mật mới
      Ví dụ, có thể nghĩ đến một ứng dụng kiểm tra IP client với whitelist tại thời điểm kết nối và giả định rằng sau đó nó sẽ không thay đổi

  • Với tôi, ứng dụng thực tế duy nhất của MPTCP là dùng mạng di động cùng với Wi‑Fi để tăng tốc độ. Cả iOS lẫn WeChat đều hỗ trợ việc này
    Nhưng mạng di động tính theo dung lượng nên tôi luôn tắt. Vì vậy với cá nhân tôi, MPTCP không hữu ích

    • Tôi từng xử lý vấn đề này. Nội bộ gọi đó là lỗi bãi đỗ xe
      Đó là tình huống tín hiệu Wi‑Fi vẫn hiện nhưng kết nối không hoạt động đúng. Có MPTCP thì sẽ failover sang mạng di động

  • Tôi làm công việc hỗ trợ, debug và sửa Linux network stack cùng driver, nên khá ngạc nhiên khi nó được áp dụng ít đến vậy
    Giống như SCTP và những thứ từng cố thay thế TCP thông thường, MPTCP có vẻ vẫn chỉ là một công nghệ ngách mà một số nhà phát triển ứng dụng tiếp tục dùng, còn phần còn lại của thế giới thì quên mất

    • Apple Siri dùng MPTCP, nên nếu xét theo số lượng thiết bị thì khó nói nó chỉ là ngách

  • Tôi tìm được tài liệu giải thích khác biệt về kiến trúc giữa MPTCP và QUIC, đồng thời giới thiệu giao thức MPQUIC do các tác giả đề xuất
    QUIC ghép kênh các stream ứng dụng trên một luồng UDP, còn MPTCP chia một stream thành nhiều subflow TCP. MPQUIC kết hợp hai đặc điểm này, ghép kênh các stream ứng dụng trên nhiều subflow UDP
    [1]: "Multipath QUIC: A Deployable Multipath Transport Protocol" https://www.researchgate.net/publication/327122884_Multipath...
    Giờ tôi tò mò các giao thức này so sánh với nhau trong môi trường vận hành thực tế ra sao. Có ai đã dùng cả hai chưa?

    • MPQUIC vẫn đang được thảo luận tại IETF. Ngay cả ở cuộc họp IETF vừa rồi cũng có thêm nhiều thay đổi được bàn tới, và đáng tiếc là vì thế việc được chấp nhận đang chậm lại
      https://lwn.net/Articles/964377/
      Cả hai đều cố đạt cùng một mục tiêu. Về mặt kỹ thuật, có thể tạo ra hành vi rất giống nhau. MPTCP được triển khai trong kernel Linux, còn QUIC nằm ở phía user space

  • Apple cũng hỗ trợ và dùng trong Siri
    https://developer.apple.com/documentation/foundation/urlsess...

    • Các app khác cũng có thể dùng khá dễ dàng. Nó nằm trong tính năng mặc định
      Năm 2011, tôi đã ngạc nhiên khi thấy app VoIP của chúng tôi hoạt động khá bền bỉ :D

  • Việc chỉ cần một thiết bị trung gian không hỗ trợ là trong trường TCP option của gói SYN+ACK trả về sẽ không có option MPTCP nghe có vẻ khá hạn chế
    Yêu cầu duy nhất đối với thiết bị trung gian có phải chỉ là chuyển tiếp nguyên vẹn option MPTCP không?

    • Trước khi chốt đặc tả, chúng tôi đã thử nghiệm rất nhiều để đảm bảo bật MPTCP không làm hỏng kết nối
      Hoặc là đi qua đúng cách, hoặc là fallback an toàn về TCP một đường
      Nói chung, nếu thiết bị trung gian chuyển tiếp các option không nhận biết mà không sửa đổi, và không ép buộc không gian thứ tự TCP mà nó nhìn thấy phải liên tục, thì MPTCP có thể đi qua và hoạt động qua thiết bị đó
      Nếu quan tâm thì có hai bài báo liên quan
      [1] https://www.usenix.org/conference/nsdi12/technical-sessions/...
      [2] https://www.researchgate.net/publication/229002024_Is_it_sti...

  • Có thể hữu ích trong các thiết lập bảo mật và quyền riêng tư
    Ví dụ, nghĩ đến Great Firewall của Trung Quốc, nếu có thể chia lưu lượng ra nhiều kênh uplink, liệu tường lửa có khó ghép lại để thực thi hơn không?

    • Nếu là lưu lượng không biết thì chỉ cần chặn hoặc giới hạn tốc độ thật mạnh là được