Tại sao tải xuống qua VPN bị giới hạn bởi tốc độ tải lên của máy chủ
Một lượt tải xuống về phía máy khách từ xa tiêu tốn băng thông tải lên của máy chủ. Hãy lập ngân sách theo hướng trước khi đổ lỗi cho bo mạch, bus hay thuật toán mã hóa.
Máy khách hiển thị một đường xuống nhanh, máy chủ nằm trên kết nối cáp quang, vậy mà việc truyền vẫn lết từng bước. Con số người ta so sánh thường là con số in trên gói dịch vụ của máy khách, trong khi gói tin thực ra phải đi qua đường truy cập ra của máy chủ trước. Đường đó chính là ngân sách mà việc truyền phải nằm trong. Trên một kết nối gia đình nhỏ, đó là con số nhỏ nhất trên đường đi.
Con số bạn đọc được nằm ở hướng sai
Một lượt tải xuống về phía máy khách từ xa tiêu tốn dung lượng tải lên ở đầu máy chủ của đường hầm. Tốc độ tải xuống được quảng cáo của máy chủ mô tả hướng ngược lại và không nói gì về hướng này. Sự bất đối xứng ấy đảo chiều khi máy khách tải lên, nên một hướng có thể có vẻ ổn trong khi hướng kia không dùng được.
Chi phí đóng gói và mọi lưu lượng cạnh tranh đều tiêu một phần của cùng ngân sách đó. Cả hai đều không hiện ra trong một bài kiểm tra tốc độ chỉ đo máy khách.
Hãy viết đường đi thành ngân sách
Liệt kê mọi ranh giới mà gói tin phải vượt qua và cho mỗi ranh giới một con số cùng đơn vị. Việc phân phối từ nguồn, xử lý trên máy chủ, đường tải lên của máy chủ, đoạn đường trung gian, đường xuống của máy khách và xử lý tại máy khách đều được tính. Tốc độ dùng được là con số nhỏ nhất trong số đó trừ chi phí, và không cấu hình nào vượt trần ấy làm thay đổi kết quả. Hãy viết danh sách trước khi đo, vì nó cho bạn biết nên nghi ngờ con số nào.
Với đường tải lên của máy chủ 20 Mbit/s và đường xuống của máy khách 100 Mbit/s, máy chủ giới hạn việc truyền rất lâu trước khi máy khách nhận ra. Chi phí và bất kỳ lượt truyền đồng thời nào lấy thêm một phần, và một đường tải lên đã bão hòa còn làm chậm các xác nhận, khiến một lượt truyền TCP xuống dưới trần thô. Không hiệu ứng nào trong hai hiệu ứng ấy xuất hiện trong một so sánh gói dịch vụ.
Hãy tách megabit và megabyte ra, và nói rõ mỗi con số đo lưu lượng của đường đã mã hóa hay tải trọng của ứng dụng. Trộn hai thứ đó là lý do phổ biến nhất khiến một ngân sách có vẻ không khớp. Dán nhãn cho mỗi con số kèm đơn vị và điểm đo.
Nơi bo mạch thực sự khiến bạn tốn kém
Khi đường truy cập đủ lớn, phần cứng ở đầu cuối trở nên nhìn thấy được, và chỉ khi đó bộ xử lý mới có ý nghĩa. Hãy xác định kiểu máy, cách bố trí giao diện và cách hiện thực đang dùng. Một nhận xét về bus chia sẻ của một bo mạch đời đầu không mô tả mọi bản sửa đổi sau đó.
Hãy so sánh từng đường xử lý riêng lẻ thay vì một mức trung bình CPU duy nhất. Một tải tổng thể vừa phải có thể che giấu một lõi đã bão hòa làm toàn bộ công việc cho mỗi gói, và tần số xung nhịp không chuyển giữa các thiết kế bộ xử lý như một điểm số hiệu năng. Tốc độ gói tin quan trọng ngang với thông lượng, vì gói nhỏ tốn kém hơn trên mỗi byte so với gói lớn. Hãy đo bằng những kích thước gói mà khối lượng công việc của bạn thực sự dùng.
Các giới hạn nhiệt và nguồn cũng quyết định hành vi bền vững. Một đợt bùng ngắn có thể trông tuyệt vời trong khi một lượt truyền mười phút bị hạ xung, nên một bài đo vài giây là hướng dẫn tồi cho một bản sao lưu ban đêm.
Hướng dẫn hiệu năng của nhà cung cấp tách băng thông truy cập, CPU, xử lý gói tin, truyền tải và kích thước gói thành những ràng buộc riêng. Đáng đọc chúng trước khi đổi thuật toán mã hóa, vì một thay đổi mã hóa hiếm khi dịch chuyển một ranh giới chưa bao giờ là giới hạn.
Hãy đo trước khi đổi thuật toán mã hóa
Chạy một bài kiểm tra theo hướng báo cáo tốc độ thực sự đạt được qua đường hầm, rồi chạy chính bài kiểm tra đó trên giao diện thô để so sánh. Chênh lệch giữa hai con số ấy là chi phí của đường hầm, và trần nhỏ hơn trong hai trần cho bạn biết nên tấn công ranh giới nào.
Hãy giữ nguyên chính sách bảo mật trong khi so sánh. Một kết quả cũ thu được với thuật toán mã hóa yếu hoặc bo mạch ép xung không phải là kế hoạch cho triển khai hiện tại.
iperf3 -c 10.44.0.1 -R -t 30
iperf3 -c 10.44.0.1 -t 30
ethtool eth0 | grep -i speedLưu các kết quả theo hướng bên cạnh các quan sát đầu cuối của cùng lần chạy. Thay đổi tiếp theo nên nhắm vào trần đã đo chứ không phải linh kiện trông nhỏ nhất trên bảng thông số.