☰

Wireguard는 느리지만 Windows 업로드에만 해당됩니다.

tag-icon • tag-icon windows-10 upload slow-connection wireguard
Wireguard는 느리지만 Windows 업로드에만 해당됩니다.

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/infrastructure/boosting-dropbox-upload-speed). 내가 이해하는 한(수정해 주세요!) Linux 게이트웨이가 Wireguard와 함께 NIC 다중 대기열을 사용할 때 많은 패키지 재정렬이 발생하며 Windows 10에서는 이를 제대로 처리할 수 없는 것 같습니다. 패키지 재정렬로 인해 Windows 10은 여러 패킷을 보내고 선택적 응답을 수락하는 대신 거의 모든 데이터 패킷 전송 후 응답을 기다리므로 전송 속도가 느려집니다.

슬프게도 내가 분석한 Wireshark 세션의 스크린샷을 만드는 것을 잊었지만 다운로드할 때 Windows 호스트는 일반적으로 ack를 보내기 전에 약 10-20 tcp 데이터 패킷을 얻었습니다. 하지만 업로드할 때 전송된 각 데이터 패키지에 대해 TCP ack를 받았습니다.

이 문제를 해결하는 방법은 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이어야 합니다. 위 명령은 이를 일시적으로만 설정하여 배포판 관련 도구를 사용해야 하는 지속성을 유지합니다. 데비안의 경우 다음과 같을 수 있습니다:

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코어 프로세서를 사용하고 코어 1개를 최대 70% 사용하여 전체 1Gbit 업다운로드를 얻습니다.

관련 정보