Hai đường lên nhưng một đường hầm: chuyển đổi, cân bằng hay gộp kênh
Chuyển đổi khi sự cố, cân bằng theo luồng và gộp một luồng là ba lời hứa khác nhau. Hai tuyến mặc định cho bạn điều thứ nhất, và không cho hai điều còn lại.
Hai đường internet có thể làm một VPN sẵn sàng hơn, và làm nó nhanh hơn với một số khối lượng công việc, nhưng cơ chế mới quyết định điều nào trong hai điều đó xảy ra. Một router có hai tuyến mặc định không phải là gộp kênh, và một đường hầm mang hàng nghìn kết nối bên trong vẫn là một luồng bên ngoài duy nhất. Gọi tên lời hứa trước là khác biệt giữa một thiết kế và một thất vọng đắt giá. Bảng dưới đây phân tách các lựa chọn theo điều mỗi cách cần ở đầu xa và điều mất kết nối làm với một lần truyền.
Ba lời hứa, và chỉ một cần đối tác
Chuyển đổi khi sự cố giữ một đường đi sẵn sàng khi kết nối ưu tiên biến mất. Cân bằng theo băm luồng trải các luồng độc lập trên cả hai đường lên. Gộp một luồng cho phép một lần truyền dùng cả hai kết nối cùng lúc. Đó là những sản phẩm khác nhau với yêu cầu khác nhau, và chỉ cái cuối cần sự hợp tác của một thứ gì đó ngoài router của bạn.
| Mechanism | Far-end requirement | Effect on one transfer | What breaks under a link loss |
|---|---|---|---|
| Packet-spraying overlay | A cooperating endpoint that reassembles the stream | Packets can spread across both links | Reordering and buffering on the surviving path; its own recovery logic decides what continues |
| MPTCP subflows | A peer or proxy that accepts subflows | Subflows can share one connection | Surviving subflows continue if the peer keeps them alive |
| Flow-hash balancing | Nothing new; the existing tunnel endpoint is enough | One outer flow still follows one link | Flows hashed onto the dead link move; established sessions break |
| Link failover | Nothing new | One path at a time; the second link sits idle | The session stalls or restarts on the other link |
Không có gì trong bảng đó là lý do để mua đường thứ hai. Điều nó làm là ngăn một thiết kế chuyển đổi bị đánh giá như thể đó là gộp kênh.
Vì sao một đường hầm trông như một luồng với router
Router cân bằng tải băm địa chỉ nguồn và đích cùng với cổng, rồi gửi toàn bộ luồng đến nơi băm chỉ tới. Đường hầm VPN là một luồng như vậy theo góc nhìn của router, bất kể thứ gì chạy bên trong. Các kết nối bên trong không bao giờ tới được quyết định băm, vì tiêu đề bên ngoài đã quyết định đường đi. Đó là lý do một đường lên thứ hai có thể gấp đôi tổng dung lượng cho nhiều người dùng và không thay đổi gì ở lần truyền lớn của một người dùng.
Hai đường hầm riêng biệt có thể cho bạn hai ứng viên, nhưng chúng vẫn cần một chính sách có chủ đích để phân bổ lưu lượng và giữ các phản hồi trên đường đã mang yêu cầu đi. Định tuyến bất đối xứng là kết quả thường gặp của việc bỏ qua bước đó. Mức tối thiểu là một chính sách nêu tên luồng, kết nối ưu tiên và kết nối dự phòng.
Gộp Ethernet không vượt qua các nhà cung cấp không liên quan, vì đầu xa phải tham gia giao thức gộp. Gộp qua hai nhà cung cấp internet là một dự án nghiên cứu trừ khi có một điểm cuối hợp tác.
TCP đa đường cần gì ở cả hai đầu
Tài liệu của Linux về Multipath TCP mô tả một số luồng con thuộc về một kết nối. Hỗ trợ của nhân ở một đầu tự nó không thay đổi gì, vì đối tác cũng phải chấp nhận những luồng con đó. Một proxy ở phía xa là cách bố trí phổ biến khác, và nó trở thành một thành phần có dung lượng và tính sẵn sàng riêng cần được lập kế hoạch. Cùng logic đó loại bỏ một câu trả lời dễ dàng cho WireGuard, vì vận chuyển của nó là UDP: MPTCP phát triển các luồng con TCP và không thể gộp đường hầm đó mà không có thứ gì khác trong thiết kế.
Hãy kiểm tra xem tính năng của nhân có được bật không trước khi thiết kế quanh nó, vì nhiều bản phân phối giao nó ở trạng thái tắt. Ba lệnh này trả lời điều đó trong một phút.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits showChọn theo khối lượng công việc, không theo tài liệu quảng cáo
Nếu khối lượng công việc là nhiều phiên độc lập, cân bằng theo băm luồng có thể thêm dung lượng mà không cần hợp tác ở đầu xa. Nếu là một lần truyền lớn, chỉ một thiết kế gộp mới giúp được, và thiết kế đó cần một đối tác hợp tác. Nếu yêu cầu là công việc tiếp tục khi một kết nối chết, câu trả lời là chuyển đổi và thông lượng của một lần truyền là không liên quan.
Viết yêu cầu thành một câu có động từ trong đó: một bản sao lưu xong nhanh gấp đôi, hoặc một kết nối rơi không kết thúc một phiên. Mục tiêu mơ hồ tạo ra những thiết kế không ai có thể chấp nhận hay từ chối. Sau đó quyết định đầu xa được phép là gì, vì lựa chọn rẻ nhất thường là cái không đòi hỏi gì mới ở đó. Ràng buộc đó loại bỏ phần lớn tuyên bố trong tài liệu quảng cáo trước cuộc họp đầu tiên.
Giữ ba lời hứa tách biệt trong tài liệu yêu cầu. Một thiết kế tuyên bố cả ba thường giao một cái và lặng lẽ giả định những cái còn lại. Phần tiếp theo kiểm tra cái nào thực sự được giao.
Thử một lần truyền và nhiều lần, rồi rút một kết nối
So sánh một lần truyền liên tục với vài lần truyền song song tới cùng đích, và ghi lại mất mát, độ trễ và mức sử dụng của từng kết nối. Lợi ích chỉ có với các phiên song song cho thấy sự phân bổ luồng, không phải gộp một luồng. Hãy thử mất một đường lên riêng, vì dung lượng khi cả hai kết nối hoạt động không nói gì về chuyển đổi cho một phiên đã thiết lập. Ghi lại tuyến, socket và các bộ đếm truyền lại trước và sau mỗi lần thử.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5Khi lần truyền đơn vẫn dùng một đường lên, thiết kế đang làm đúng điều mà băm luồng ngụ ý. Khi các lần truyền song song trải trên cả hai, cân bằng hoạt động và gộp thì không. Ghi lại lời hứa nào trong ba lời thiết kế thực sự giữ, và cuộc trò chuyện dung lượng tiếp theo bắt đầu từ bằng chứng chứ không phải tuyên bố của nhà cung cấp.