SSH가 iperf3보다 느리게 실행되는 이유는 무엇입니까?

openssh 클라이언트/서버의 최대 실행 속도는 약 1.03GB/s인 반면 iperf3은 동일한 지점 간 링크에서 7.03GB/s를 쉽게 유지할 수 있다는 점이 실망스럽습니다.

• 나겔을 강요하다,
• nc를 SSH ProxyCommand로 사용,
• [압축 비활성화](https://gist.github.com/KartikTalwar/4393116,
• 특정 비밀번호를 강제 적용,

이 중 어느 것도 효과가 없습니다.

• iperf 테스트와 ssh 전송 테스트 중에 두 시스템의 CPU 로드는 70%(총 2400%) 미만이었습니다.
• 관련된 블록 장치 없음

이해가 안 돼요. ssh는 10gbe를 전혀 지원할 수 없나요? 비밀번호나 해시로 인해 속도가 느려지나요? openssl 클라이언트 소스 코드에 기가비트 제한을 하드코딩한 사람이 있나요? 이 파이프를 통해 회선 속도로 데이터를 전송하려면 8개 이상의 별도 SSH 연결을 열어야 합니까?

---

아래에 표시된 것처럼 작은 녹색 얼룩은 입니다 cat /dev/zero | ssh target 'cat >/dev/null'. 보라색/주황색 얼룩은 SSH 포트 전달을 기반으로 하는 iperf3이고 키가 큰 얼룩은 일반 iperf3입니다.

일부 통계;

• 전용 링크의 iperf3: 7.11Gbits/s

  (파이버를 잘못 취급하여 원래의 ~9Gbit 성능이 저하된 것 같습니다. 새로운 se la vi)

• 전용 링크를 통한 iperf3(mtu=9000): 7.55Gbits/s

• gbe LAN의 iperf3: 941Mbits/s
• 직접 링크를 통한 SSH 기반 iperf3: 1.03Gbits/s

• 기가비트 LAN을 통한 SSH 기반 iperf3: 941Mbits/s

  (분명히 ssh는 올바른 라우팅을 사용하고 있으며 여전히 일반 gbe 사용보다 약간 빠릅니다.)

• SSH를 통해 ProxyCommand NC를 사용하는 iperf3: 1.1Gbit/s

  (또 다른 매우 작은 이득)

• ProxyCommand nc를 사용하는 SSH를 통한 iperf3(mtu=9000): 1.01Gbit/s

  (이 경우 mtu는 링크 속도를 늦추는 것 같습니다)