TCP đa đường (MPTCP, Multipath TCP)

1. Tổng quan

A. Định nghĩa

MPTCP (Multipath TCP) là một phần mở rộng tầng giao vận truyền tải một kết nối TCP duy nhất đồng thời trên nhiều đường mạng (subflow), trong khi vẫn trình bày cho ứng dụng thứ trông như một socket TCP tiêu chuẩn duy nhất. IETF chuẩn hóa nó thành RFC 6824 (v0, 2013) và sửa đổi thành RFC 8684 (v1, 2020); nó dùng trường tùy chọn của TCP để gộp nhiều giao diện (LTE, Wi-Fi, v.v.) thành một kết nối logic duy nhất.

B. Bối cảnh ra đời và sự cần thiết

Thiết bị ngày nay thường giữ nhiều hơn một giao diện mạng cùng lúc. Điện thoại thông minh có di động (LTE/5G) và Wi-Fi, máy chủ trung tâm dữ liệu có nhiều NIC, máy tính xách tay có cả có dây lẫn không dây. Tuy nhiên, TCP truyền thống bị ghim vào bộ 4-tuple gồm IP nguồn/đích và cổng được chọn khi thiết lập kết nối, nên dù một đường bị đứt hay tắc nghẽn thì nó cũng không thể chuyển sang giao diện khác. Trường hợp điển hình là một lượt tải xuống bị dừng khi tín hiệu Wi-Fi yếu đi, dù di động vẫn sống khỏe. Nói cách khác, thiết bị có tài nguyên dư thừa, nhưng mô hình kết nối cứng nhắc của TCP không dùng được nó — một sự kém hiệu quả về mặt cấu trúc.

Câu trả lời trực giác là "dùng nhiều đường cùng lúc," nhưng việc hiện thực không đơn giản. Internet đầy middlebox như NAT, tường lửa và proxy vốn kiểm tra và viết lại tiêu đề TCP, nên một giao thức giao vận hoàn toàn mới dễ bị chặn trên đường đi. MPTCP chấp nhận thực tế này và chọn thiết kế giữ tương thích ở mức đường truyền (wire) với TCP thông thường. Thay vì dùng một số hiệu giao thức mới, nó mang thông tin điều khiển trong trường tùy chọn của các phân đoạn TCP hiện có, sao cho với middlebox nó trông như TCP bình thường trong khi chỉ hai máy đầu cuối hiểu nó là đa đường. Chính "khả năng triển khai tăng dần (incremental deployability)" này là lý do cốt lõi khiến MPTCP, trong số nhiều đề xuất giao vận đa đường, thực sự đạt tới triển khai thương mại.

Sự cần thiết hội tụ vào ba giá trị. Thứ nhất là gộp băng thông (bandwidth aggregation): kết hợp băng thông của nhiều đường để truyền nhanh hơn. Thứ hai là khả năng phục hồi (resilience): giữ kết nối sống trên các đường còn lại ngay cả khi một đường rớt, mang lại chuyển giao liền mạch. Thứ ba là cân bằng tải (load balancing): dời lưu lượng từ đường tắc nghẽn sang đường còn dư địa, nâng hiệu quả của toàn mạng. Ba giá trị này càng quan trọng khi các môi trường đa kết nối — di động, trung tâm dữ liệu, IoT — trở thành chuẩn mực.

C. Mục tiêu thiết kế và đặc điểm

Thiết kế của MPTCP được tóm gọn trong ba mục tiêu mà RFC 6356 nêu rõ. (1) Cải thiện thông lượng: một kết nối MPTCP dùng nhiều đường không được kém hơn chỉ dùng một đường tốt nhất. (2) Không gây hại (do no harm): tổng phần mà toàn bộ các subflow của một kết nối MPTCP chiếm trên một nút cổ chai dùng chung không được vượt quá phần mà một kết nối TCP đơn đường chiếm trên cùng nút cổ chai đó. (3) Cân bằng tắc nghẽn (balance congestion): dồn lưu lượng sang các đường ít tắc nghẽn hơn bất cứ khi nào có thể, hạ tắc nghẽn trên toàn mạng.

Các mục tiêu này căng thẳng lẫn nhau. Chỉ đuổi theo thông lượng thì tổn hại tính công bằng; chỉ giữ công bằng thì xóa mất lợi ích đa đường. Lý do MPTCP đưa ra cơ chế đặc biệt là điều khiển tắc nghẽn ghép (coupled congestion control) chính là để đạt được sự cân bằng này. Nghĩa là, cốt lõi kỹ thuật của MPTCP không đơn thuần là "dùng nhiều đường," mà là dùng nhiều đường trong khi điều khiển chúng công bằng và vô hại với hệ sinh thái Internet hiện có.

2. Cấu trúc tổng thể MPTCP và ngăn xếp giao thức

MPTCP chèn một tầng MPTCP giữa ứng dụng và các subflow TCP riêng lẻ. Ứng dụng gọi send()/recv() trên một socket duy nhất như thường lệ, nhưng bên dưới, tầng MPTCP chia dữ liệu trên nhiều subflow và ghép lại theo thứ tự ở phía nhận. Mỗi subflow bản thân là một kết nối TCP chính quy hoàn chỉnh, quản lý độc lập số thứ tự, cửa sổ tắc nghẽn và truyền lại của riêng mình. Sơ đồ dưới đây cho thấy quan hệ phân tầng này và cấu tạo của hai subflow.

flowchart TB
  APP["Ứng dụng (API socket duy nhất)"]
  subgraph MP["Tầng MPTCP"]
    SCH["Bộ lập lịch (gửi trên đường nào)"]
    DSS["Ánh xạ chuỗi dữ liệu (DSS)"]
    PM["Trình quản lý đường (tạo/xóa subflow)"]
  end
  subgraph SF["Subflow (mỗi cái là TCP chính quy)"]
    SF1["Subflow 1 : đường Wi-Fi"]
    SF2["Subflow 2 : đường LTE"]
  end
  APP --> MP
  SCH --> SF1
  SCH --> SF2
  DSS -. "bảo đảm thứ tự mức kết nối" .-> SF1
  DSS -. "bảo đảm thứ tự mức kết nối" .-> SF2
  SF1 --> NET["Mạng IP (đi qua middlebox)"]
  SF2 --> NET

Ở trung tâm của cấu trúc là hai không gian chuỗi. Mỗi subflow giữ nguyên số thứ tự TCP của riêng mình để đánh lừa middlebox. Đồng thời MPTCP duy trì một Số thứ tự dữ liệu 64-bit mức kết nối (DSN) riêng, theo dõi mỗi byte thuộc về đâu trong toàn bộ luồng dữ liệu. Thứ nối hai cái lại là tùy chọn DSS (Data Sequence Signal), vốn mang ánh xạ "các byte từ X đến Y trên subflow này ánh xạ tới DSN Z mức kết nối." Phía nhận ghép lại (reassembly) các mảnh đến xen kẽ qua nhiều subflow theo đúng thứ tự dựa trên ánh xạ DSS trước khi trao cho ứng dụng.

Thiết kế chuỗi kép này là tinh túy của MPTCP. Không có chuỗi mức kết nối, phía nhận không thể biết thứ tự toàn cục của dữ liệu đến qua các đường khác nhau; ngược lại, không có chuỗi mức subflow, middlebox có thể phán đoán nhầm rằng "có lỗ hổng trong chuỗi" và cắt hoặc giả mạo kết nối. Bằng cách tách hai không gian, MPTCP đạt tương thích middlebox và độc lập đường cùng lúc. Các thành phần chính được tóm tắt dưới đây.

Thành phần	Vai trò	Ghi chú
Subflow	Một kết nối TCP chính quy phục vụ một đường	cwnd/truyền lại độc lập
Ánh xạ DSS	Ánh xạ subflow ↔ chuỗi mức kết nối	DSN 64-bit, cơ sở ghép lại
Token/khóa	Nhận dạng kết nối, xác thực subflow	kiểm tra MP_JOIN dựa trên HMAC
Trình quản lý đường	Quyết định thêm/xóa subflow	full-mesh, ndiffports, v.v.
Bộ lập lịch	Quyết định gói đi trên đường nào	minRTT (mặc định), BLEST, RR, v.v.

3. Quy trình thiết lập kết nối và quản lý subflow

Một kết nối MPTCP bắt đầu bằng cách đặt tùy chọn MP_CAPABLE lên một bắt tay TCP thông thường. Khi hai bên trao đổi MP_CAPABLE trong quá trình ba bước SYN / SYN/ACK / ACK, chúng xác nhận mỗi bên hỗ trợ MPTCP, và các khóa trao đổi ở đây sinh ra token duy nhất của kết nối và bí mật dùng để xác thực subflow. Nếu đối tác không hiểu MP_CAPABLE, hoặc một middlebox ở giữa gỡ bỏ tùy chọn, kết nối lặng lẽ lùi về TCP thuần (fallback). Thuộc tính "hoạt động như TCP thông thường ngay cả khi thất bại" này là nền tảng khiến MPTCP an toàn để triển khai.

Khi subflow đầu tiên đã dựng, các đường bổ sung gia nhập qua tùy chọn MP_JOIN. Khi thiết bị mở một bắt tay TCP mới trên giao diện thứ hai (ví dụ LTE) và mang token của kết nối hiện có cùng một giá trị xác thực HMAC trong MP_JOIN, đối tác xác thực và xác nhận rằng đó là một đường mới thuộc cùng kết nối logic rồi chấp nhận. Quy trình xác thực này ngăn kẻ tấn công tùy tiện chèn một subflow vào kết nối của người khác. Sơ đồ tuần tự dưới đây cho thấy luồng từ thiết lập ban đầu qua gia nhập subflow thứ hai, truyền dữ liệu, đến đóng kết nối.

sequenceDiagram
  participant C as Máy khách
  participant S as Máy chủ
  Note over C,S: Bước 1 - thiết lập subflow đầu tiên (Wi-Fi)
  C->>S: SYN + MP_CAPABLE (trao đổi khóa)
  S->>C: SYN/ACK + MP_CAPABLE
  C->>S: ACK + MP_CAPABLE
  Note over C,S: Bước 2 - gia nhập subflow thứ hai (LTE)
  C->>S: SYN + MP_JOIN (token + HMAC)
  S->>C: SYN/ACK + MP_JOIN (kiểm tra HMAC)
  C->>S: ACK
  Note over C,S: Bước 3 - truyền dữ liệu (chia/ghép qua DSS)
  C->>S: mảnh dữ liệu A (Wi-Fi, DSS)
  C->>S: mảnh dữ liệu B (LTE, DSS)
  S->>C: ACK mức kết nối (DATA_ACK)
  Note over C,S: Bước 4 - đóng (DATA_FIN)
  C->>S: DATA_FIN
  S->>C: DATA_ACK

Ngay cả sau khi thiết lập, MPTCP quản lý trạng thái đường một cách động. Các tín hiệu tiêu biểu là MP_PRIO, đánh dấu một subflow cụ thể chỉ được giữ làm dự phòng chứ không dùng trong vận hành bình thường, và REMOVE_ADDR, báo cho đối tác về một địa chỉ đã biến mất để subflow đó được dọn dẹp. Việc đóng cũng chia thành hai mức: một subflow riêng lẻ đóng bằng TCP FIN thông thường, nhưng toàn bộ kết nối kết thúc bằng DATA_FIN mức kết nối, nên tính toàn vẹn của toàn luồng dữ liệu được bảo toàn ngay cả khi vài đường đóng trước. Việc lưỡng phân tín hiệu điều khiển thành mức subflow và mức kết nối này là một dấu ấn của quản lý trạng thái MPTCP.

Chủ thể quyết định việc tạo và xóa đường là Trình quản lý đường (Path Manager). Nó quản lý, như chính sách, việc có thêm subflow ngay khi một giao diện vừa kích hoạt hay không, giữ bao nhiêu, và khi nào dọn dẹp các đường đã rớt. Bản hiện thực Linux cung cấp trình quản lý đường mô-đun; tiêu biểu là full-mesh, tạo subflow trên mọi cặp địa chỉ có thể, và ndiffports, tạo nhiều luồng trên cùng cặp địa chỉ với các cổng khác nhau. Ngoài ra, qua tín hiệu ADD_ADDR, trong đó một bên quảng bá các địa chỉ bổ sung mình có, đối tác được cho biết có thể mở subflow tới địa chỉ nào ngay cả sau một NAT phía máy chủ. Vì chính sách của trình quản lý đường trực tiếp chi phối sự đánh đổi giữa thông lượng, pin và chi phí (cước di động), các chính sách thiên về chuyển giao như "mặc định Wi-Fi, LTE khi rớt" được dùng ở di động, còn các chính sách thiên về gộp như "gộp mọi đường khả dụng" được dùng ở trung tâm dữ liệu.

4. Cơ chế cốt lõi: bộ lập lịch và điều khiển tắc nghẽn

A. Bộ lập lịch gói

Bộ lập lịch là bộ não quyết định tại mỗi thời điểm gửi "subflow nào nên mang mảnh dữ liệu này." Bộ lập lịch Linux mặc định là cách tiếp cận RTT tối thiểu (minRTT): trong các subflow còn chỗ trong cửa sổ tắc nghẽn, nó ưu tiên đường có độ trễ khứ hồi ngắn nhất. Bằng cách lấp đường độ trễ thấp hơn trước và chỉ dùng đường kế khi tràn, nó kìm việc dùng không cần thiết một đường chậm trong tình huống một đường nhanh duy nhất.

Vấn đề nảy sinh khi hiệu năng của các đường khác biệt lớn (heterogeneous). Dùng Wi-Fi nhanh cùng LTE chậm, các mảnh gửi trên đường chậm đến muộn và gây nghẽn đầu hàng (Head-of-Line Blocking) ở bộ đệm nhận. Dữ liệu đến sau đã đến trên đường nhanh không thể trao cho ứng dụng và chờ cho đến khi phần trước đến qua đường chậm. Để giảm nhẹ điều này, nhiều bộ lập lịch đã được đề xuất, như BLEST (dự đoán chiếm dụng bộ đệm), ECF (Earliest Completion First, dự đoán thời điểm hoàn thành), RR (quay vòng), và redundant (gửi cùng dữ liệu trên nhiều đường để tối thiểu hóa độ trễ). Chẳng hạn, với lưu lượng điều khiển từ xa hay thoại cực kỳ nhạy độ trễ, người ta chọn một bộ lập lịch redundant bảo đảm thời gian đến ngắn nhất đánh đổi bằng băng thông.

Vì vậy, chọn bộ lập lịch là một tối ưu hóa theo đặc tính ứng dụng. Tải xuống tệp lớn quan tâm tổng thông lượng nên lấp mọi đường thì tốt hơn; hội nghị video quan tâm độ trễ/jitter nên giữ một đường duy nhất ổn định làm chính với một đường phụ dự phòng thì tốt hơn. Việc không một bộ lập lịch nào có thể tối ưu trong mọi tình huống là một thách thức cốt lõi của vận hành MPTCP, và gần đây nghiên cứu bộ lập lịch thích ứng dựa trên học tăng cường rất sôi động.

Các nghiên cứu thực nghiệm gần đây trên mạng không đồng nhất cho thấy sự kết hợp của bộ lập lịch và điều khiển tắc nghẽn chi phối hiệu năng. Ví dụ, họ bộ lập lịch minRTT/ECF/RR cho thông lượng tốt hơn họ BLEST/LLHD khi ghép với điều khiển tắc nghẽn ghép dựa trên mất gói, trong khi trên các đoạn có phương sai độ trễ cực đoan, ECF — vốn dự đoán thời điểm hoàn thành — kìm nghẽn đầu hàng tốt hơn. Rốt cuộc nó quy về không phải "bộ lập lịch nào tuyệt đối ưu việt" mà là câu hỏi cấu hình "cặp bộ lập lịch/điều khiển tắc nghẽn nào hợp với tổ hợp đường cho trước và nhu cầu ứng dụng," điều này biến MPTCP thành vấn đề về năng lực vận hành chứ không phải một tính năng đơn giản.

B. Điều khiển tắc nghẽn ghép (Coupled Congestion Control)

Nếu mỗi subflow chỉ đơn giản chạy điều khiển tắc nghẽn TCP độc lập, một kết nối MPTCP sẽ hành xử như n kết nối TCP thông thường trên một nút cổ chai dùng chung và chiếm n lần băng thông của người dùng khác — một sự bất công. Để ngăn điều này, MPTCP ghép sự tăng trưởng cửa sổ tắc nghẽn của nhiều subflow của mình, kìm toàn kết nối sao cho nó chỉ hung hãn xấp xỉ bằng một TCP thông thường duy nhất trên nút cổ chai dùng chung. Đồng thời nó tăng cửa sổ của các đường ít tắc nghẽn hơn nhiều hơn, dời lưu lượng sang đó một cách tự nhiên.

Các thuật toán cụ thể như LIA (Linked Increases Algorithm, RFC 6356) nguyên gốc, OLIA (Opportunistic LIA) cải thiện khiếm khuyết công bằng của nó, BALIA (Balanced Linked Adaptation) nhắm cân bằng độ đáp ứng và ổn định, và wVegas dựa trên độ trễ được hiện thực trong nhân Linux và chọn được qua sysctl. LIA đơn giản nhưng bị ghi nhận đôi khi quá hung hãn với TCP đơn đường, điều mà OLIA/BALIA chỉnh lại. Làm cho "nhiều đường nhưng hành xử như một với mạng" là tinh túy của điều khiển tắc nghẽn ghép, và đó là một di sản quan trọng mà MPTCP truyền lại ngay cả cho thiết kế các giao thức kế nhiệm như Multipath QUIC.

C. Bộ đệm nhận và ghép lại

Hiệu năng cảm nhận của MPTCP phụ thuộc lớn vào kích thước bộ đệm nhận. Chênh lệch độ trễ giữa các đường càng lớn, bộ đệm phải càng lớn để giữ dữ liệu đường nhanh trong khi chờ đường chậm. Nếu bộ đệm không đủ, nghẽn đầu hàng trầm trọng hơn và đa đường có thể phản tác dụng, trở nên chậm hơn một đường duy nhất. Do đó, trong thực tế, người ta định cỡ bộ đệm nhận rộng rãi có xét đặc tính đường (băng thông/độ trễ) và tinh chỉnh bộ lập lịch để giới hạn lượng nó gửi trên đường chậm. Vì tương tác này, hiệu năng MPTCP nên được xem không phải "thêm đường thì cải thiện tuyến tính" mà là một bài toán tối ưu hóa hệ thống trong đó bộ lập lịch, điều khiển tắc nghẽn và bộ đệm cài khớp vào nhau.

Một con số trực giác làm rõ điều này. Theo quy tắc định cỡ thô, bộ đệm nhận cần thiết nên ở mức tổng băng thông × RTT đường lớn nhất. Ví dụ, dùng Wi-Fi 100 Mbps (RTT 20 ms) cùng LTE 50 Mbps (RTT 80 ms), để hấp thụ 150 Mbps gộp lại trong 80 ms chậm nhất, bạn cần bộ đệm khoảng 150 Mbps × 80 ms ≈ 1,5 MB. Với mặc định của nhân (vài trăm KB) là không đủ, nên truyền bị dừng mỗi khi đường chậm đến — và đây là nguyên nhân thực sự của hiểu lầm phổ biến rằng "thêm LTE lại làm chậm hơn." Vì vậy, khi gộp các đường không đồng nhất, cùng với việc nâng bộ đệm, bạn cũng cần một thiết lập giữ một đường chậm vô ích chỉ được bộ lập lịch dùng làm dự phòng.

5. So sánh với TCP đơn đường và Multipath QUIC

Điều tách MPTCP khỏi TCP thông thường một cách quyết định là tính di động của đường. TCP thông thường bị ràng vào bộ 4-tuple nên kết nối rớt khi giao diện đổi, trong khi MPTCP giữ kết nối bằng cách thêm và xóa subflow. Nhờ vậy, một luồng video không đứt ngay cả khi bạn băng qua một vùng chết Wi-Fi và chuyển sang LTE. Tuy nhiên MPTCP không có được lợi ích này miễn phí. Nó phải lùi về khi một middlebox gỡ tùy chọn, và hai không gian chuỗi cùng logic ghép lại làm tăng độ phức tạp hiện thực và chi phí bộ đệm.

So sánh với phần mở rộng đa đường của QUIC là một luận điểm thi cử và thực tiễn quan trọng gần đây. QUIC chạy trên UDP và nhận dạng đường bằng Connection ID, nên di trú kết nối (connection migration) — tiếp tục kết nối mà không cần bắt tay ngay cả khi IP đổi — được tích hợp sẵn vào giao thức. Ngược lại, MPTCP có tương thích với hệ sinh thái TCP làm thế mạnh nhưng dễ tổn thương trước can thiệp của middlebox. Nghĩa là, chúng nên được hiểu như sản phẩm của các triết lý thiết kế khác nhau — "tương thích với hạ tầng hiện có (MPTCP)" và "linh hoạt trên UDP mã hóa (QUIC)" — và hai bên vừa là đối thủ vừa bổ sung cho nhau. Bảng dưới đây so sánh các khác biệt cốt lõi.

Phân loại	TCP đơn đường	MPTCP	Multipath QUIC
Số đường	cố định ở 1	nhiều subflow	nhiều đường
Chuyển giao diện	kết nối rớt	giữ qua subflow	di trú kết nối
Tương thích middlebox	cao	lùi về nếu tùy chọn bị gỡ	dễ tổn thương nếu UDP bị chặn
Mã hóa	tùy chọn (TLS)	tùy chọn (TLS)	tích hợp mặc định
Chi phí ghép lại	thấp	cao (chuỗi kép)	trung bình

6. Đi sâu: xu hướng chuẩn/hiện thực và trường hợp áp dụng thực tế

Về mặt chuẩn, MPTCP được sửa đổi từ RFC 6824 (v0) thành RFC 8684 (v1, 2020), chỉnh gọn định dạng tùy chọn và xử lý lùi về, và các chuẩn proxy như 0-RTT TCP Converter (RFC 8803) hỗ trợ triển khai phía máy chủ cũng xuất hiện. Linux từ lâu chỉ được cung cấp dưới dạng bản vá ngoài cây mã (multipath-tcp.org), nhưng từ nhân 5.6 (tháng 3 năm 2020), nó được tích hợp chính thức vào thượng nguồn, cung cấp sẵn trình quản lý đường, bộ lập lịch và điều khiển tắc nghẽn mô-đun. Đây là một cột mốc cho thấy MPTCP đã vượt khỏi giai đoạn nghiên cứu để trở thành một tính năng tiêu chuẩn của một hệ điều hành đa dụng.

Trường hợp thương mại được biết đến rộng rãi nhất là Siri của Apple. Apple áp dụng MPTCP cho lưu lượng Siri từ iOS 7 năm 2013, chuyển đổi (switching) giữa Wi-Fi và di động để giảm độ trễ đáp ứng và các thất bại mạng. Đáng chú ý, việc áp dụng ban đầu của Apple không phải "bonding" để kết hợp băng thông mà là chuyển đổi thiên về khả năng phục hồi để giữ đường liền mạch. Apple về sau mở một API lập trình viên ở iOS 11 và mở rộng việc dùng MPTCP sang Maps, Music, Apple Pay và nhiều ứng dụng khác.

Trường hợp tiêu biểu của Hàn Quốc là GiGA LTE của KT. Đồng phát triển với Samsung Electronics, vào tháng 6 năm 2015 KT trình làng dịch vụ thương mại đầu tiên trên thế giới gộp LTE CA 3 băng và GiGA Wi-Fi qua MPTCP để đạt tối đa lý thuyết 1,17 Gbps (buổi trình diễn cho thấy tối đa khoảng 835 Mbps và trung bình 600–700 Mbps). Theo tài liệu trình bày IETF của KT, nó đặt LTE làm subflow chính (MP_CAPABLE) và Wi-Fi làm subflow phụ (MP_JOIN), và triển khai một cổng proxy MPTCP giữa thiết bị và mạng nhà mạng để bonding hoạt động ngay cả khi máy chủ không biết MPTCP. Khác với trường hợp "chuyển đổi" của Apple, cái này tập trung vào gộp băng thông (bonding), một tương phản tốt cho thấy cùng một MPTCP cho ra các thiết kế khác nhau tùy mục tiêu ứng dụng (dù một số tài liệu thứ cấp mô tả một thiết lập dựa trên proxy SOCKS, nên kiến trúc chi tiết khác nhau theo nguồn).

Các hướng ra đề khả dĩ gồm "Luận về ba mục tiêu thiết kế của MPTCP và sự cần thiết của điều khiển tắc nghẽn ghép," "So sánh MPTCP và Multipath QUIC từ góc độ tương thích middlebox và di trú," và "Đề xuất chính sách trình quản lý đường/bộ lập lịch MPTCP phù hợp lần lượt cho chuyển giao di động và bonding trung tâm dữ liệu."

7. Cân nhắc và hàm ý

Chiến lược áp dụng (tách chính sách theo mục đích): MPTCP phát huy tốt nhất không phải với việc áp dụng đồng nhất "luôn gộp mọi đường," mà khi trình quản lý đường và bộ lập lịch được thiết kế tách riêng thành thiên khả năng phục hồi (chuyển giao) cho di động và thiên thông lượng (bonding) cho trung tâm dữ liệu. Có xét cước di động và pin, chính sách dùng Wi-Fi lúc bình thường và chuyển sang LTE khi cần là thực tế ở di động.
Đánh đổi (hiệu năng ↔ độ phức tạp/bộ đệm): thêm đường không làm nhanh lên tuyến tính. Khi phương sai độ trễ giữa các đường lớn, nghẽn đầu hàng và chi phí ghép lại triệt tiêu lợi ích, nên định cỡ bộ đệm nhận và tinh chỉnh kìm đường chậm phải đi trước. Trên các đường không đồng nhất, giảm số subflow thực ra có thể tốt hơn.
Middlebox/khả năng triển khai: trong các môi trường tường lửa/NAT gỡ hoặc viết lại tùy chọn, MPTCP lùi về TCP thuần. Trước thực tế rằng các máy chủ đầu cuối không hỗ trợ MPTCP, một kiến trúc đặt một proxy/converter MPTCP trong mạng nhà mạng là mẫu hình cốt lõi của triển khai thương mại.
Góc độ an ninh: xác thực HMAC của MP_JOIN chặn chiếm quyền subflow, nhưng các mối đe dọa đặc thù đa đường như giả mạo ADD_ADDR và tấn công liên đường vẫn tồn tại. Kết hợp với mã hóa đầu cuối TLS theo từng đường, tính toàn vẹn mức kết nối phải được bảo đảm cùng lúc.
Triển vọng và công nghệ liên quan: triết lý thiết kế của đa đường đang được kế thừa và mở rộng bởi Multipath QUIC, và nó gắn chặt với đa kết nối 5G/Wi-Fi 7, ATSSS (điều hướng lưu lượng đa truy nhập của 5G) và bonding đường của SD-WAN. Giữa xu hướng truyền tải mã hóa trở thành chuẩn, sự phân vai giữa MPTCP và Multipath QUIC là một luận điểm cốt lõi trong tương lai.

Tài liệu tham khảo

IETF, "TCP Extensions for Multipath Operation with Multiple Addresses (RFC 8684)", https://datatracker.ietf.org/doc/html/rfc8684
IETF, "Coupled Congestion Control for Multipath Transport Protocols (RFC 6356)", https://datatracker.ietf.org/doc/html/rfc6356
Wikipedia, "Multipath TCP", https://en.wikipedia.org/wiki/Multipath_TCP
multipath-tcp.org, "Configure MPTCP (Linux >= v5.6)", https://multipath-tcp.org/pmwiki.php/Users/ConfigureMPTCP
KT/IETF, "GiGA LTE Mobile MPTCP Proxy Development (IETF 97 slides)", https://www.ietf.org/proceedings/97/slides/slides-97-banana-kt-giga-lte-mobile-mptcp-proxy-development-00.pdf
Netmanias, "KT's GiGA LTE: World's First Commercial Wireless 1Gbps", https://netmanias.com/en/post/korea_ict_news/7591/kt-korea-lte-mptcp-wi-fi/kt-s-giga-lte-world-s-first-commercial-wireless-1-giga-3-band-ca-giga-wifi

Tóm tắt một câu: MPTCP là một phần mở rộng tầng giao vận đặt ánh xạ DSS và MP_CAPABLE/MP_JOIN lên các tùy chọn TCP hiện có để gộp nhiều đường thành một kết nối logic duy nhất, đạt thông lượng, khả năng phục hồi và cân bằng tắc nghẽn một cách công bằng qua điều khiển tắc nghẽn ghép trong khi bù cho các giới hạn của lùi về middlebox, nghẽn đầu hàng và chi phí bộ đệm bằng proxy, bộ lập lịch và tinh chỉnh bộ đệm — được tiếp nối từ Siri (chuyển đổi) và KT GiGA LTE (bonding) sang Multipath QUIC.