
Mục lục bài viết 10 phần
Multipath TCP (MPTCP) cho phép một kết nối logic sử dụng nhiều TCP subflow, nhưng “có hai đường” không đồng nghĩa throughput sẽ cộng tuyến tính hoặc ứng dụng không bị gián đoạn. Test plan phải kiểm handshake, scheduler, reordering, fallback và service continuity dưới các fault có kiểm soát.
Bài viết giúp bạn
- Câu hỏi kỹ thuật cần trả lời
- Topology và điều kiện đo
- Biến số phải kiểm soát
Câu hỏi kỹ thuật cần trả lời
#RFC 8684 mô tả MPTCP phiên bản 1: hai endpoint thiết lập một kết nối MPTCP và có thể thêm nhiều subflow TCP. Bài thử cần xác định endpoint có thực sự đàm phán MPTCP, subflow nào được tạo, dữ liệu được ánh xạ thế nào và khi không đàm phán được thì fallback có an toàn hay không.
Các câu hỏi chính là: MPTCP có cải thiện độ sẵn sàng hay goodput trong topology mục tiêu; một đường kém có kéo chậm toàn kết nối; và NAT, firewall, proxy hoặc load balancer có làm hỏng option hay state. Kết luận phải dựa trên ứng dụng end-to-end, không chỉ số subflow ở kernel.
Topology và điều kiện đo
#Topology tối thiểu có client/server hỗ trợ MPTCP, hai access path độc lập, network emulator trên từng path và observation point trước/sau NAT hoặc middlebox. Một đường có thể đại diện broadband, đường kia cellular; tránh dùng chung bottleneck rồi gọi là path diversity.
Lấy baseline TCP đơn đường và MPTCP một subflow trước khi thêm path thứ hai. Phát flow ngắn, tải xuống dài, upload và request/response. Đồng bộ clock; lưu packet capture ở hai đầu vì capture tại một vị trí không thấy đủ Data Sequence Number, NAT rewrite và retransmission trên đường khác.

Biến số phải kiểm soát
#Khóa MPTCP implementation/kernel, path manager, packet scheduler, congestion control, backup flag, address advertisement và subflow limit. Ghi rõ MSS/MTU, receive window, NIC offload, crypto, application buffer và server concurrency. Một thay đổi scheduler hoặc congestion control có thể đảo kết quả.
Trên từng path, điều khiển capacity, base latency, jitter, packet loss, reordering, outage, NAT lifetime và asymmetric routing. Không áp một impairment aggregate cho cả hai đường. Nếu TLS chạy phía trên, giữ cùng cipher, session reuse và object size để tách ảnh hưởng transport khỏi handshake ứng dụng.
KPI và bằng chứng đầu ra
#Đo connection success, thời gian MP_CAPABLE, thời gian tạo MP_JOIN, active/backup subflow, application goodput, completion time, latency percentile, retransmission, reordering, CPU và byte share từng path. Khi fault, đo detection, data migration, packet loss và service restoration.
Bằng chứng gồm PCAP hai đầu, MPTCP socket/subflow telemetry, emulator event log, application transaction log và resource counter. Báo cáo cần phân biệt wire throughput với goodput hữu ích, TCP sequence với Data Sequence Number, và transport alive với giao dịch hoàn tất.
Ma trận quyết định pass/fail
#Pass/fail nên có ngưỡng riêng cho flow tương tác, tải file và streaming. MPTCP đạt availability nhưng completion time kém baseline vẫn cần ghi là đánh đổi, không phải pass tuyệt đối.
- Case: Hai path tương đương · Kỳ vọng: Phân phối theo policy đã cấu hình · KPI chính: goodput, byte/path · Dấu hiệu fail: một subflow không hình thành ngoài dự kiến
- Case: Path phụ latency cao · Kỳ vọng: Scheduler tránh làm xấu SLO ứng dụng · KPI chính: completion time, reorder · Dấu hiệu fail: thêm path làm tail latency tăng quá ngưỡng
- Case: Hard failure path chính · Kỳ vọng: Kết nối logic tiếp tục trên path còn lại · KPI chính: outage, transaction success · Dấu hiệu fail: reset toàn kết nối
- Case: NAT xóa state · Kỳ vọng: Subflow lỗi được loại bỏ, session xử lý đúng · KPI chính: RTO, reinjection · Dấu hiệu fail: treo không phục hồi
- Case: Middlebox bỏ option · Kỳ vọng: Fallback về TCP theo implementation · KPI chính: handshake + application · Dấu hiệu fail: loop/reset hoặc downgrade không quan sát được
- Case: Cả hai path chung bottleneck · Kỳ vọng: Không tuyên bố bandwidth cộng · KPI chính: queue delay, fairness · Dấu hiệu fail: diễn giải sai path diversity
Test plan handshake, subflow và fallback
#Xác nhận MP_CAPABLE trên kết nối đầu, rồi kiểm MP_JOIN và authentication khi thêm địa chỉ/path. Thử server không hỗ trợ MPTCP, middlebox loại option, SYN retransmission và thay đổi NAT mapping. Fallback phải được nhận diện trong telemetry, không suy từ việc ứng dụng vẫn mở được. Phân biệt subflow đầu với subflow bổ sung: nếu MP_CAPABLE không đi qua được ở kết nối đầu, có thể trở về TCP thường; nếu MP_JOIN bị chặn khi thêm đường cho kết nối MPTCP đã tồn tại, subflow bổ sung bị đóng, không tự biến thành một TCP độc lập mang cùng luồng ứng dụng (RFC 8684, mục 3.7).
- Baseline TCP và MPTCP một subflow.
- Thêm subflow chủ động và theo address advertisement.
- Kiểm active/backup policy theo từng chiều.
- Chặn hoặc sửa option trong lab cô lập để kiểm fallback.
- Kiểm TLS, HTTP và giao dịch ứng dụng không bị nhân đôi.
- Đối soát byte/path và Data Sequence Mapping.
- Lặp lại với IPv4, IPv6 hoặc NAT theo phạm vi triển khai.
Path failure, reordering và service continuity
#Tạo link-down, blackhole một chiều, tăng loss, giảm capacity, tăng latency đột ngột và NAT timeout. Hard down dễ phát hiện hơn silent blackhole; vì vậy phải đo cả hai. Quan sát retransmission hoặc reinjection sang subflow khác, duplicate và thời điểm giao dịch đầu tiên hoàn tất lại.
Tạo độ lệch latency có kiểm soát để đo reordering và head-of-line tại lớp MPTCP/ứng dụng. So flow ngắn và dài: một scheduler tối ưu aggregate goodput có thể làm tail latency xấu. Thử đường phục hồi để xác minh subflow được tái sử dụng theo policy mà không gây oscillation.

Scale, runbook và regression
#Tăng concurrent connection, subflow/connection và churn theo bậc; đo memory, CPU, port/NAT consumption và tail latency. Soak test cần path flap ngẫu nhiên có seed tái lập. Không lấy một mức scale làm khả năng chung nếu thiếu kernel, NIC, server và traffic profile.
Runbook gồm cách xác nhận MPTCP thật, buộc fallback về TCP, vô hiệu path lỗi, khôi phục scheduler và rollback kernel/config. Regression sau đổi kernel, proxy, firewall, load balancer, NAT, access network hoặc application library.
Giới hạn kết luận
#Kết quả chỉ đúng cho endpoint stack, path manager, scheduler, congestion control, middlebox, impairment và workload đã thử. Hai interface vật lý không đảm bảo hai đường không chia sẻ failure domain hoặc bottleneck upstream.
MPTCP không tự bảo đảm zero loss, bandwidth cộng, bảo mật ứng dụng hay session persistence của proxy. Fallback thành công chỉ chứng minh ứng dụng tiếp tục bằng TCP trong case đã thử, không chứng minh middlebox hỗ trợ MPTCP.
Khái niệm cần nhớ
#- MPTCP connection: kết nối logic mang dữ liệu qua một hoặc nhiều subflow.
- Subflow: một TCP flow cấu thành MPTCP connection.
- MP_CAPABLE/MP_JOIN: option đàm phán MPTCP và thêm subflow.
- Data Sequence Number: thứ tự dữ liệu ở cấp kết nối MPTCP.
- Reinjection: gửi lại dữ liệu trên subflow khác.
- Fallback: tiếp tục dưới dạng TCP khi MPTCP không được đàm phán.
- Path manager/scheduler: logic tạo path và phân phối dữ liệu.
Khái niệm cần nhớ
- DUT / SUT
- Thiết bị hoặc toàn bộ hệ thống đang là đối tượng của bài kiểm thử.
- Steady state
- Giai đoạn tải đã ổn định và đủ điều kiện để lấy số liệu đại diện.
- Pass / fail
- Kết luận dựa trên ngưỡng đã thống nhất, luôn đi cùng topology, cấu hình và điều kiện đo.
TÀI LIỆU ĐỐI CHIẾUTài liệu tham khảo3 nguồn +
Nội dung được biên soạn độc lập, theo hướng vendor-neutral và đối chiếu các tài liệu gốc dưới đây. Tính năng sản phẩm cần được kiểm tra lại theo phiên bản đang sử dụng.
NetVali ưu tiên nguồn tiêu chuẩn và tài liệu chính thức; phân biệt khuyến nghị triển khai với yêu cầu của tiêu chuẩn; không công bố thông số sản phẩm chưa gắn với phiên bản và điều kiện đo.
