我們遇到的問題是,從多個客戶端網路透過 Wireguard Tunnel 到伺服器上的 Samba 共享的連線速度很慢,但奇怪的是,它只會影響 Windows 10 並且只影響上傳。
Linux 主機可以以高達 120MB/s 的速度上傳,而 Windows 只能以 10-50MB/s 的速度上傳(根據我們擁有的不同網路而有所不同)。不限於 smb,我使用 Iperf(udp 和 tcp)得到了完全相同的測試結果。
出於好奇,我測試了 Windows 11 是否也受到影響,結果是不是!這可能是什麼以及我該如何解決它?
答案1
他們在 0.4.8 版本中添加的實驗性核心驅動程式打破了 Windows 上傳速度。只需運行舊版本,直到他們修復它。
https://download.wireguard.com/windows-client/wireguard-amd64-0.4.7.msi
答案2
這似乎與 Dropbox 描述的問題相同或至少相似(https://dropbox.tech/infrastruct/boosting-dropbox-upload-speed)。據我了解(請糾正我!)當Linux網關使用帶有Wireguard的NIC多隊列時,會發生大量套件重新排序,顯然Windows 10不能很好地處理這個問題。包重新排序以某種方式導致 Windows 10 透過在幾乎每個發送的資料包後等待確認而不是發送多個資料包並接受選擇性確認來減慢發送速度。
遺憾的是,我忘記對我分析的 Wireshark 會話進行螢幕截圖,但很明顯,下載時,Windows 主機在發送 ack 之前通常會收到大約 10-20 個 tcp 封包。但是上傳時我收到了每個發送的資料包的 TCP 確認。
解決此問題的解決方案是在 Linux 主機上停用多隊列。
ethtool -L PHYSICAL_LOCAL_INTERFACE combined 1
ethtool -L PHYSICAL_NETWORK_INTERFACE combined 1
要查看它是否被應用,可以使用
ethtool -l INTERFACENAME
Channel parameters for INTERFACENAME:
Pre-set maximums:
RX: 0
TX: 0
Other: 1
Combined: 63
Current hardware settings:
RX: 0
TX: 0
Other: 1
Combined: 1
最後一行應該是 1。對 Debian 來說可能是這樣的:
cat /etc/network/interfaces
auto INTERFACE
iface INTERFACE inet static
address IPADDR
netmask NETMASK
gateway GATEWAY
# This is the relevant line
post-up ethtool -L INTERFACE combined 1
如果網關沒有強大的 CPU,這可能會造成瓶頸。我們使用 AMD EPYC 7262 8 核心處理器,並獲得完整的 1Gbit 上傳和下載,其中一個核心的使用率約為 70%。