Nó có vẻ giống hoặc ít nhất là một vấn đề tương tự như được mô tả bởi Dropbox (https://dropbox.tech/infrastructure/boosting-dropbox-upload-speed).
Theo như tôi hiểu (vui lòng sửa lỗi cho tôi!) Khi Cổng Linux sử dụng đa hàng đợi NIC với Wireguard, rất nhiều việc sắp xếp lại gói xảy ra và dường như Windows 10 không thể xử lý tốt việc đó.
Việc sắp xếp lại gói bằng cách nào đó khiến Windows 10 làm chậm tốc độ gửi bằng cách đợi xác nhận sau hầu hết mọi gói dữ liệu đã gửi thay vì gửi nhiều gói và chấp nhận xác nhận có chọn lọc.
Rất tiếc, tôi đã quên tạo ảnh chụp màn hình của các phiên Wireshark mà tôi đã phân tích nhưng có thể thấy rất rõ là khi tải xuống, máy chủ lưu trữ windows thường nhận được khoảng 10-20 gói dữ liệu tcp trước khi gửi ack. Nhưng khi tải lên, tôi nhận được TCP ack cho mỗi gói dữ liệu được gửi.
Giải pháp để khắc phục điều này là vô hiệu hóa multiqueuing trên máy chủ Linux.
ethtool -L PHYSICAL_LOCAL_INTERFACE kết hợp 1
ethtool -L PHYSICAL_NETWORK_INTERFACE kết hợp 1
Để xem nó có được áp dụng hay không, người ta có thể sử dụng
ethtool -l INTERFACENAME
Tham số kênh cho INTERFACENAME:
Cài đặt trước tối đa:
thu: 0
TX: 0
Khác: 1
Kết hợp: 63
Cài đặt phần cứng hiện tại:
thu: 0
TX: 0
Khác: 1
Kết hợp: 1
Dòng cuối cùng phải là 1. Lệnh trên chỉ thiết lập tạm thời, để làm cho nó bền bỉ, các công cụ cụ thể của bản phân phối cần được sử dụng.
Đối với Debian, nó có thể giống như thế này:
con mèo/etc/mạng/giao diện
GIAO DIỆN ô tô
iface GIAO DIỆN inet tĩnh
địa chỉ IPADDR
mặt nạ mạng NETMASK
cổng GATEWAY
# Đây là dòng có liên quan
post-up ethtool -L INTERFACE kết hợp 1
Điều này có thể tạo ra nút cổ chai nếu cổng không có CPU mạnh. Chúng tôi sử dụng Bộ xử lý 8 nhân AMD EPYC 7262 và tải lên và tải xuống đầy đủ 1Gbit với mức sử dụng ~70% của một lõi.
