Vì sao chia sẻ tệp qua VPN có cảm giác chậm: các vòng khứ hồi, không phải Mbps

Mở một thư mục chia sẻ qua VPN và chờ danh sách thư mục bò từng chút là trải nghiệm quen thuộc, và phản xạ đầu tiên là đổ lỗi cho băng thông. Thường thì đường truyền gần như nhàn rỗi. Giao thức dành thời gian chờ phản hồi, và mỗi lần chờ tốn một vòng khứ hồi đầy đủ mà mạng LAN chưa bao giờ tính. Sửa lại hình dạng công việc, và việc chia sẻ lại dùng được.

Bản sao làm việc từ xa có hình dạng sai

SMB mở tệp, đọc siêu dữ liệu và xác nhận trong nhiều lần trao đổi nhỏ. Bản sao làm việc của hệ thống quản lý phiên bản trên ổ đĩa đã ánh xạ giả định độ trễ của hệ thống tệp cục bộ và đọc nhiều tệp nhỏ. Cơ sở dữ liệu trên máy tính để bàn kéo các trang khi người dùng làm việc. Mỗi điều đó biến độ trễ thành hệ số nhân, vì chi phí tăng theo số lần trao đổi mà thao tác thực hiện; vì vậy một đường hầm 40 ms biến vài trăm thao tác thành vài giây. Kích thước tải trọng gần như không liên quan trong phép tính đó.

Chi phí mã hóa là một phần nhỏ; mất gói tệ hơn, vì một lần truyền lại cộng với cửa sổ tắc nghẽn sụp đổ tốn nhiều hơn hẳn số byte liên quan.

Đếm vòng khứ hồi trước khi tính megabyte

Đo độ trễ trước khi mua băng thông. Một lệnh ping cho biết mỗi lần trao đổi phải trả gì.

ping -c 10 fileserver.example.net

Bản tóm tắt cho thời gian khứ hồi nhỏ nhất, trung bình và lớn nhất, và độ phân tán quan trọng ngang với giá trị trung bình. Nhân giá trị trung bình với số lần trao đổi mà một danh sách thư mục thực hiện, rồi so với thời gian bạn thực sự quan sát. Nếu một tệp lớn được truyền nhanh trong khi duyệt chậm, ràng buộc là độ trễ và số yêu cầu. Thêm mười lần băng thông vào một đường truyền không bao giờ bão hòa không thay đổi gì cả.

Di chuyển công việc, không phải byte

Thay đổi nơi công việc diễn ra thay vì trả tiền cho ống rộng hơn. Phục vụ kho lưu trữ thay vì gắn kết nó, và sao chép hàng loạt bằng công cụ chỉ gửi khác biệt.

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

Phục vụ kho lưu trữ, như hgweb hay Git từ xa làm, cho phép máy khách làm việc trên một bản sao cục bộ nên các lệnh gọi hệ thống tệp của nó không bao giờ vượt qua đường hầm. rsync đi qua cả hai phía và gửi các khối đã thay đổi, loại bỏ phần lớn các lần trao đổi mà một bản sao ngây thơ phải trả. Cơ sở dữ liệu trên máy tính để bàn nên nằm trên một động cơ phía máy chủ với máy khách thu gọn thành giao diện, hoặc toàn bộ máy khách chạy trên một máy chủ nội bộ. Mỗi lựa chọn thay đổi mức độ trễ mà giao thức phải chịu, và đó là điểm mấu chốt.

Khựng ở cùng một kích thước là triệu chứng MTU

Các lần truyền lớn dừng lại sau khoảng cùng một lượng dữ liệu, trong khi ping và các trang nhỏ vẫn hoạt động, chỉ ra kích thước gói chứ không phải băng thông.

ping -M do -s 1400 -c 3 fileserver.example.net

Một phép thử thành công nghĩa là gói IP 1428 byte đi qua đường mà không bị phân mảnh, vì tiêu đề ICMP và IP thêm 28 byte. Thất bại với cờ cấm phân mảnh cho thấy MTU dùng được của đường hầm nhỏ hơn máy chủ giả định. Một máy chủ gửi bộ đệm 9000 byte vào đường 1500 byte buộc phải phân mảnh hoặc mất gói, và việc dò MTU đường đi có thể âm thầm thất bại khi ICMP bị lọc. Hạ MTU của đường hầm, bật mssfix trên OpenVPN, hoặc thu nhỏ bộ đệm của máy chủ, rồi chạy lại cùng lần truyền để xác nhận.

Đo khoảng cách có ý nghĩa

Chạy cùng thao tác theo ba cách nơi chính sách cho phép: cục bộ, qua đường hầm và qua đường internet trực tiếp. Với mỗi cách, ghi lại thời gian khứ hồi, tốc độ của một luồng lớn và thời gian một danh sách thư mục hoặc việc mở ứng dụng mất bao lâu. So sánh lần chạy cục bộ với lần chạy qua đường hầm cho thấy chi phí nào chiếm ưu thế. Một bản sao kết thúc chậm gợi ý vấn đề tốc độ hoặc độ trễ, trong khi bản sao chết ở một điểm cố định gợi ý kích thước gói hoặc thiết bị giữ trạng thái trên đường đi.

Khi chỉ vài megabyte đầu bị kéo lê, hãy xem xác thực và siêu dữ liệu; khi mọi thứ bò, hãy xem băng thông và mất gói. Sửa nguyên nhân tương ứng, và đừng chờ mong một đường WAN cư xử như cáp LAN.