ssh 세션이 느려지는 원인은 무엇입니까? [닫은]

원격 호스트에서 ssh하지만 터미널 성능이 좋지 않습니다. 입력하는 기호가 즉시 표시되지 않지만 약간의 지연이 있습니다. 때때로 지연 후 한 번에 두 개의 기호가 표시됩니다.

높은 대기 시간은 ssh 성능 저하의 또 다른 원인입니다. traceroute를 더 잘 대체하기 위해 mtr을 사용하는 것이 좋습니다. 네트워크 문제가 발생할 수있는 위치에 대한 정보를 제공 할 수 있어야합니다.

필요하지 않은 경우 X11 전달을 비활성화 (ssh -x)하고 압축 (ssh -C)을 활성화하면 세션 속도가 빨라질 수 있습니다.

두 가지 가능한 원인을 생각할 수 있습니다.

1. 연결에서 패킷 손실
2. 서버의 부하가 높습니다.

터미널이 정상이라는 것을 곧 발견하여 네트워크 성능을 측정하려고했습니다. 무슨 일이 일어난?

두 개의 인터넷 채널 라우터간에로드 밸런싱이 있습니다. 때로는 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를 기다려야 할 수 있으므로 연결을 최대한 활용하려는 경우에 중요 할 수 있습니다.

다른 사람들이 이미 말했듯이 대기 시간, 네트워크 손실, 느린 서버에서 발생할 수 있습니다.
현대 TCP 스택은 Naggle 이라는 알고리즘을 사용하기 때문에 한 유형에 2 문자가 표시되는 경우가 있습니다 .

또한 연결을 조절하는 SSH Brute Force 시도 일 수 있습니다. 세션이 느리게 실행될 때마다 로그를 확인하고 많은 경우 누군가가 미친 것처럼 암호를 시도하고 있습니다.

잘못 구성된 DNS로 인해이 문제가 발생할 수 있습니다. 서버는 일단 로그인하면 제대로 응답하고 파일을 상당히 빠르게 업로드 및 다운로드하지만 SSH 로그인 속도는 느려집니다.

살펴볼 한 가지는 단순히 서버 메모리입니다. 256Mb의 메모리로 Ubuntu VM을 실행하고 있었고 SSH가 실제로 느 렸습니다. 이것을 512Mb로 두 배로하면 문제가 해결되었습니다.