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

Tổng quan về Multipath TCP

  • Multipath TCP (MPTCP) là phần mở rộng của TCP tiêu chuẩn, được mô tả trong RFC 8684
  • Cho phép thiết bị sử dụng đồng thời nhiều giao diện để gửi và nhận các gói TCP thông qua một kết nối MPTCP duy nhất
  • MPTCP 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
  • Ngoài ra, ngay cả khi một đường truyền bị gián đoạn, vẫn có thể failover và lưu lượng sẽ được chuyển tiếp mượt mà sang đường khác

Các trường hợp sử dụng của MPTCP

  • Việc dùng MPTCP để có thể sử dụng nhiều đường truyền theo kiểu song song hoặc đồng thời đã tạo ra các trường hợp sử dụng mới so với TCP:
    • Seamless handovers: chuyển từ một đường truyền sang đường khác mà vẫn giữ kết nối. Apple đã chủ yếu sử dụng MPTCP trên smartphone vì lý do này từ năm 2013.
    • Best network selection: sử dụng đường truyền “tốt nhất” dựa trên một số điều kiện như độ trễ, mất gói, chi phí, băng thông, v.v.
    • Network aggregation: sử dụng đồng thời nhiều đường truyền để đạt thông lượng cao hơn. Ví dụ: kết hợp mạng cố định và mạng di động để gửi tệp nhanh hơn.

Khái niệm MPTCP

  • Khi tạo socket mới bằng giao thức IPPROTO_MPTCP (chỉ dành cho Linux), các subflow (hoặc path) gồm các kết nối TCP thông thường dùng để truyền dữ liệu qua một giao diện sẽ được tạo ra
  • Các subflow bổ sung có thể được đàm phán sau giữa các host
  • Một trường mới được thêm vào trường tùy chọn TCP của subflow TCP cơ sở để host từ xa có thể phát hiện việc sử dụng MPTCP
  • Trường này bao gồm các tùy chọn như MP_CAPABLE để báo cho host kia rằng hãy sử dụng MPTCP nếu có hỗ trợ
  • Nếu host từ xa hoặc middlebox ở giữa không hỗ trợ MPTCP, trường tùy chọn TCP của gói SYN+ACK trả về sẽ không chứa tùy chọn MPTCP
  • Trong trường hợp đó, kết nối sẽ được “hạ cấp” xuống TCP thông thường và tiếp tục trên một đường duy nhất

Hành vi này có được nhờ hai thành phần nội bộ là Path Manager và Packet Scheduler.

Path Manager

  • Path Manager phụ trách các subflow từ lúc tạo đến khi xóa, đồng thời cũng phụ trách thông báo địa chỉ
  • Thông thường, phía client sẽ khởi tạo subflow và phía server sẽ thông báo thêm địa chỉ thông qua các tùy chọn ADD_ADDR và REMOVE_ADDR
  • Tính đến Linux v5.19, có 2 Path Manager được điều khiển bằng sysctl net.mptcp.pm_type:
    • in-kernel (loại 0): áp dụng cùng một quy tắc cho mọi kết nối (tham khảo ip mptcp)
    • userspace (loại 1): được điều khiển bởi daemon không gian người dùng (ví dụ: mptcpd) và có thể áp dụng các quy tắc khác nhau cho từng kết nối

Packet Scheduler

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

Các tính năng chính của MPTCP (tính đến Linux v6.10)

  • Hỗ trợ giao thức IPPROTO_MPTCP trong lời gọi hệ thống socket()
  • Chuyển từ MPTCP sang TCP khi peer hoặc middlebox không hỗ trợ MPTCP
  • Quản lý đường truyền bằng path manager trong kernel hoặc ở không gian người dùng
  • Các tùy chọn socket thường được sử dụng trên socket TCP
  • Tính năng debug bao gồm bộ đếm MIB, hỗ trợ diag (được dùng trong lệnh ss) và tracepoint

Ý kiến của GN⁺

  • MPTCP là công nghệ rất hữu ích khi thiết bị đầu cuối được kết nối với nhiều mạng. Có thể được tận dụng hiệu quả cho handover 5G-Wi-Fi hoặc gộp các mạng dị chủng.
  • Tuy nhiên, cả phía server và client đều phải được triển khai hỗ trợ MPTCP, đồng thời mạng trung gian cũng cần hỗ trợ MPTCP, đây là một ràng buộc đáng kể. Có vẻ sẽ cần thời gian để công nghệ này trở nên phổ biến.
  • Giao thức QUIC của Google cũng cung cấp tính năng multipath tương tự, và do QUIC đơn giản hơn, dựa trên UDP nên được dự đoán sẽ phổ biến nhanh hơn. Có thể sẽ có sự cạnh tranh giữa MPTCP và QUIC.
  • Khác với cách triển khai MPTCP cho Linux phụ thuộc vào kernel, Apple tự triển khai MPTCP trong không gian người dùng và tích hợp vào iOS và macOS. Google cũng có vẻ có khả năng chọn cách tiếp cận tương tự.
  • Để việc điều khiển đường truyền và chính sách lập lịch của MPTCP được tối ưu theo yêu cầu của ứng dụng, có vẻ cần có sự trao đổi thông tin giữa ứng dụng và MPTCP thông qua API. Hiện vẫn chưa thấy có phương án tiêu chuẩn hóa cho việc này.

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-04-21
Ý kiến trên Hacker News
  • Khi lần đầu nghe về MPTCP vào năm 2013, tôi đã nghĩ nó sẽ giúp cải thiện đáng kể trải nghiệm người dùng vì lúc đó các ứng dụng di động phản ứng khá kém trước việc thay đổi mạng, nhưng thật đáng thất vọng khi suốt 10 năm qua nó hầu như không được chú ý
  • Tôi không biết nên thấy buồn hơn vì không gian địa chỉ 32 bit của IPv4 hay vì TCP dùng địa chỉ IP nguồn/đích trong bộ tứ kết nối. Nếu có cỗ máy thời gian, tôi muốn quay về quá khứ để thay đổi cả hai điều này
  • Cách dùng thực tế của MPTCP là kết hợp mạng di động và Wi‑Fi để tăng tốc độ, nhưng với gói cước dữ liệu di động thì cá nhân tôi luôn tắt nó nên chẳng có ích gì
  • Thật tiếc là không có liên kết đến các dự án sử dụng MPTCP như những dự án phái sinh của OpenWrt. Tôi đã hướng dẫn một sinh viên trong GSOC suốt 2 năm để vá hỗ trợ MPTCP vào OpenWrt
  • Nếu có cơ chế fallback trong suốt thì tôi thắc mắc vì sao ứng dụng vẫn cần phải explicit opt-in. Có vẻ hợp lý nhất là kernel xử lý minh bạch cho mọi kết nối TCP và đưa ra các quyết định toàn cục về gộp đường truyền/ưu tiên liên kết
  • Tôi làm công việc hỗ trợ/debug/chỉnh sửa Linux network stack và driver, nên khá ngạc nhiên trước mức độ tiếp nhận thấp của MPTCP. Có vẻ như mọi thứ từng cố thay thế TCP hiện có, như SCTP, đều có số phận chỉ được một nhóm nhỏ lập trình viên dùng tới rồi bị phần còn lại của thế giới lãng quên
  • Tôi đã tìm được một bài báo giải thích sự khác biệt kiến trúc giữa MPTCP và QUIC, cùng với giao thức MPQUIC do các tác giả đề xuất. QUIC ghép kênh các application stream trên một luồng UDP duy nhất, còn MPTCP chia một luồng duy nhất thành nhiều TCP subflow. MPQUIC kết hợp cả hai bằng cách ghép kênh các application stream trên nhiều UDP subflow
  • Apple cũng hỗ trợ MPTCP và đang dùng nó cho Siri
  • Có vẻ khá hạn chế ở chỗ nếu middlebox ở giữa không hỗ trợ tùy chọn MPTCP thì gói SYN+ACK sẽ không chứa tùy chọn MPTCP. Có phải yêu cầu duy nhất với middlebox là chuyển tiếp nguyên vẹn tùy chọn MPTCP không?
  • MPTCP có thể hữu ích cho các thiết lập bảo mật/quyền riêng tư. Ví dụ, nếu chia lưu lượng qua nhiều kênh uplink thì tường lửa của chính phủ Trung Quốc sẽ khó gộp lưu lượng lại để chặn hơn