원격 호스트에서 ssh하지만 터미널 성능이 좋지 않습니다. 입력하는 기호가 즉시 표시되지 않지만 약간의 지연이 있습니다. 때때로 지연 후 한 번에 두 개의 기호가 표시됩니다.
답변
높은 대기 시간은 ssh 성능 저하의 또 다른 원인입니다. traceroute를 더 잘 대체하기 위해 mtr을 사용하는 것이 좋습니다. 네트워크 문제가 발생할 수있는 위치에 대한 정보를 제공 할 수 있어야합니다.
답변
필요하지 않은 경우 X11 전달을 비활성화 (ssh -x)하고 압축 (ssh -C)을 활성화하면 세션 속도가 빨라질 수 있습니다.
답변
두 가지 가능한 원인을 생각할 수 있습니다.
- 연결에서 패킷 손실
- 서버의 부하가 높습니다.
답변
터미널이 정상이라는 것을 곧 발견하여 네트워크 성능을 측정하려고했습니다. 무슨 일이 일어난?
두 개의 인터넷 채널 라우터간에로드 밸런싱이 있습니다. 때로는 s1 트래픽을 wan1을 통해 라우팅하고 때로는 wan2를 통해 라우팅합니다. 하나의 채널에만 문제가 있다고 제안했습니다. 그래서 두 채널에 대해 mtr (great tool!)을 사용하여 네트워크 성능을 별도로 측정했습니다.
네! wan2에는 110ms의 21 홉이 있고 wan1에는 21ms의 15 개가 있습니다! wan2 대기 시간이 문제입니다.
답변
압축 및 압축 수준 9를 사용하십시오. 약간 도움이 될 것입니다. / etc / ssh / ssh_config에서 이러한 매개 변수를 구성 할 수 있습니다. 그러나 실제 네트워크가 매우 열악하면이 트릭은별로 좋지 않습니다.
답변
이 동작의 가장 명백한 원인은 포화되거나 손실 된 패킷 인 링크입니다. 워크 스테이션에서 ssh ‘s하고있는 기계까지 몇 개의 홉이 있습니까? 해당되는 경우 추적 경로를 분석 했습니까?
답변
긴 지방 파이프 (높은 대역폭 + 높은 대기 시간)에서 OpenSSH를 사용하는 경우 OpenSSH가 더 큰 tcp 창 크기를 사용하도록 수정하기 때문에 양쪽에서 버전 4.7 이상을 사용하고 있는지 확인하십시오.
* The SSH channel window size has been increased, and both ssh(1)
sshd(8) now send window updates more aggressively. These improves
performance on high-BDP (Bandwidth Delay Product) networks.
그렇지 않으면 발신자가 전송을 계속하기 전에 ack를 기다려야 할 수 있으므로 연결을 최대한 활용하려는 경우에 중요 할 수 있습니다.
