Tải xuống lớn và VPN: chọn đường ngay tại yêu cầu

“Gửi các bản tải lớn ra ngoài VPN và giữ các phản hồi nhỏ trên đó” nghe như một chính sách định tuyến, nhưng không phải. Bộ định tuyến quyết định bằng thông tin có sẵn ngay lúc đó: địa chỉ, cổng, giao thức, dấu firewall, một luồng đã nhận diện. Kích thước cuối cùng của phản hồi không nằm trong tập đó, vì nó chưa đến, và khi bộ định tuyến có thể đo byte thì nó đã đang chuyển chúng. Nếu muốn điều hướng theo tác vụ, quyết định phải chuyển đến một điểm biết tác vụ, và danh sách kiểm tra dưới đây cho biết thiết kế của bạn có điểm đó hay không.

Vì sao bộ định tuyến không thể đo một phản hồi

Tại thời điểm một gói cần đường đi, bộ định tuyến đã thấy nhiều nhất là vài gói đầu của một luồng. Nó có thể nói ai đang nói chuyện với ai, qua giao thức nào, với dấu nào và bao nhiêu byte đã đi qua. Số byte đã qua mô tả quá khứ. Kích thước phản hồi là thuộc tính của một phản hồi chưa được tạo ra, và với phản hồi bị chia nhỏ hoặc dạng luồng, có thể không bao giờ biết trước được.

Ngay cả siêu dữ liệu của chính giao thức cũng yếu hơn vẻ ngoài. HTTP cho phép phản hồi mà độ dài không được công bố trước phần thân, và một thao tác người dùng có thể sinh ra nhiều yêu cầu mà tổng chi phí không giống bất kỳ giá trị tiêu đề nào. Coi tiêu đề là kích thước của một tác vụ là lỗi mô hình hóa trước khi là lỗi định tuyến.

Kiểm tra 1: có điểm quyết định nào chọn được đường không?

Nêu tên thành phần sẽ thực hiện lựa chọn, rồi nêu nó biết gì tại thời điểm chọn. Trình cập nhật tải từ một tập máy chủ được ghi tài liệu biết mục đích của mình trước khi quá trình truyền bắt đầu. Dịch vụ tải xuống xem siêu dữ liệu rồi mở yêu cầu biết tác vụ trước khi kết nối tồn tại. Một proxy hợp tác có thể áp chính sách ở cấp yêu cầu hoặc lưu phản hồi vào bộ nhớ đệm mà không giả làm bộ định tuyến.

Nếu câu trả lời là “cổng vào”, danh sách kiểm tra đã thất bại. Cổng vào có thể phân loại các luồng đã biết theo đích, dấu hoặc phân đoạn khách hàng và gửi chúng theo một đường xác định ngay từ gói đầu, điều thường đủ cho một trình cập nhật đã được phê duyệt và không bao giờ đủ cho một kích thước phản hồi chưa biết.

Kiểm tra 2: siêu dữ liệu thực sự cho bạn biết điều gì?

Điều hướng nhận biết ứng dụng chỉ tốt bằng các trường mà nó đọc. Các quy tắc về độ dài phản hồi trong ngữ nghĩa của HTTP cho phép trường hợp độ dài không có sẵn ngay từ đầu, và mã hóa nội dung vốn đã làm số byte truyền đi khác với kích thước biểu diễn. Vì vậy một chính sách đổi đường khi tiêu đề vượt ngưỡng sẽ hành xử không nhất quán, và chủ yếu đúng ở những lần truyền lớn mà nó định bắt.

Điều siêu dữ liệu ứng dụng có thể hỗ trợ là một quyết định về tác vụ: quy trình này là đồng bộ hàng loạt, cái này tương tác, cái kia là cập nhật phần mềm từ nguồn đã biết. Đó là chính sách viết theo ngôn ngữ ý định, và đủ ổn định để kiểm thử. “Phản hồi này sẽ lớn hơn bốn mươi megabyte” không phải loại chính sách đó.

Kiểm tra 3: luồng đã tồn tại chưa?

Định tuyến có thể thay đổi cho một luồng mà không đổi danh tính của kết nối, và sự phân biệt đó đáng được giữ đúng. Một kết nối TCP được nhận diện bằng địa chỉ và cổng của hai đầu, và các gói có thể đi đường khác nếu bảng định tuyến thay đổi bên dưới. Điều không thể thay đổi một cách vô hình là trạng thái dịch địa chỉ mạng: chuyển lưu lượng sang một lối ra khác thường làm đổi bộ nguồn công cộng, và đầu xa sẽ thấy một đối tác khác mà không có trạng thái khớp.

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

Vậy quy tắc thực hành là việc chuyển giữa chừng kết nối từ lối ra này sang lối ra khác là một quan hệ mới, không phải di trú. Nếu thiết kế đòi hỏi cùng kết nối tiếp tục, quyết định phải được đưa ra trước SYN đầu tiên, và không quy tắc gói nào thêm sau đó có thể tái tạo nó một cách sạch sẽ.

Kiểm tra 4: yêu cầu thật là độ trễ, không phải lối ra?

Rất nhiều yêu cầu “gửi lưu lượng hàng loạt đi nơi khác” thực ra là phàn nàn rằng một lần truyền lớn khiến công việc tương tác có cảm giác chậm. Đó là bài toán lập lịch, và nó có câu trả lời về lập lịch: hàng đợi công bằng hoặc chính sách băng thông được hỗ trợ trên đường hiện có ngăn một luồng hàng loạt bỏ đói một tin nhắn trò chuyện mà không phải di chuyển cả hai.

tc qdisc replace dev eth0 root cake bandwidth 100mbit

Xử lý triệu chứng theo cách này giữ quyết định lối ra ở nơi chính sách bảo mật đặt nó, và có thể đảo ngược bằng một lệnh. Thay đổi lối ra cho cả một lớp lưu lượng là thay đổi chính sách với hệ quả về xác thực, ghi nhật ký và quy tắc truy cập, nên nó không nên là công cụ đầu tiên khi có phàn nàn về độ trễ.

Nếu yêu cầu thật sự là một lối ra internet khác, hãy nói bằng những từ đó và triển khai tại một ranh giới được hỗ trợ: kết nối mới từ một quy trình đã được phê duyệt, hoặc ứng dụng tự mở yêu cầu qua một lối ra đã chọn. Sau đó ghi lại tác vụ nào dùng lối ra nào, để người tiếp theo không phải suy ra từ bảng định tuyến.

Giữ danh sách kiểm tra trong bản ghi thay đổi: điểm quyết định, trường hoặc tác vụ điều khiển nó, luồng đã tồn tại chưa và triệu chứng đo được là độ trễ hay lối ra. Bốn câu hỏi, và một chính sách trả lời cả bốn là chính sách bạn có thể vận hành thay vì bảo vệ.