SSH가 때때로 빠른 연결에서 일시적으로 중단됩니다.

몇 초 동안 패킷이 수신되지 않은 다음 약 6개의 패킷이 빠르게 연속해서 다시 전송됩니다.

이는 네트워크 정체 또는 네트워크 중단(대개 정체로 인해)이라는 두 가지 유사한 현상의 증상입니다.

첫 번째 경우, 여기와 저기 사이의 라우터에서 사용자 활동과 관련 없는 트래픽 버스트가 발생하여 트래픽이 일부 중간 라우터에서 버퍼링됩니다. 그들은 대역폭을 사용할 수 있을 때까지 자신의 차례를 기다립니다. 이와 같은 정체는 YouTube 트래픽의 갑작스러운 급증(새로운 새끼 고양이 동영상!!!)이나 심지어 SYN_ACK 공격 시도로 인해 발생할 수 있습니다. 지구상 어딘가에 무작위 장치로 트래픽을 자발적으로 보내는 수많은 감염된 시스템이 있기 때문에 실제로 우리가 생각하는 것보다 더 많은 악의적인 공격 시도가 있습니다. SYN_ACK 및 유사한 공격은 이제 감지 후 바로 취소되지만, 감지 및 취소로도 라우터를 몇 초 동안 계속 사용할 수 있습니다.

두 번째 시나리오는 트래픽이 과부하된 장치에 도달하고,확실히버퍼 트래픽. 추가 버퍼 메모리가 없거나 버퍼링이 종종 자체적으로 문제를 일으키기 때문입니다. 예를 들어, "한 홉 거리에 있는 라우터가 현재 너무 바빠서 트래픽을 버퍼링했습니다. 따라서 일단 사용할 수 있게 되면 저장된 트래픽으로 라우터를 공격하여 지나치게 바쁠 것입니다..."무기한. 이 경우 TCP 연결이 시작됩니다지수 백오프이로 인해 발신인이 지연될 수 있습니다. 역사적으로 이것은 폭발적인 인터넷을 처리하는 좋은 방법이었습니다. 많이있다문제의 핵심 부분입니다전송 프로토콜이지만 좋은 해결책은 없습니다.

불행하게도 이러한 지연 급증은 ISP, 통신업체 및 다양한 시스템 관리자의 열정적인 도움 없이는 진단하기가 거의 불가능합니다. 피크 트래픽으로 인해 초과 구독된 장치는 사용자가 전혀 접근할 수 없는 곳에 있을 가능성이 있으며, 운영자는 해당 장치가 초과 구독되었거나 관리되고 있다는 사실조차 알지 못할 수도 있습니다.

인터넷 프로토콜은 다음과 같이 설계되었습니다.최선을 다해 배송패킷이 목적지에 도달한다는 보장은 없습니다. 제가 상상하지 못했던 부하에도 불구하고 여전히 작동한다는 것은 제게는 작은 기적입니다. 공용 인터넷이 제공할 수 있는 것보다 더 나은 서비스가 필요한 경우 누군가가 기꺼이 높은 가격에 목적지까지 전용선을 판매할 수 있습니다. 그렇지 않으면, 고속도로 교통이나 식료품점의 무작위로 길게 늘어선 줄처럼, 그것은 단지 감수해야 하는 현대 생활의 불편일 수도 있습니다.

그런데 물리적 근접성은 위상적 근접성과 낮은 상관관계가 있습니다. 여가 시간에는 traceroute destination-host여기에서 다른 곳으로 이동하기 위해 트래픽이 얼마나 많은 장치를 통과해야 하는지 생각해 보십시오. 1km 전송이 1메가미터와 20개의 장치를 거쳐 목적지에 도달하는 것은 드문 일이 아닙니다.

응답 댓글을 추가하세요.

동일한 컴퓨터의 Windows 파티션에서 PuTTY를 사용할 때 문제를 발견하지 못했습니다.

"Windows 파티션에서"라는 말은 "Windows에서 실행 중"을 의미합니까? 나는 그럴 것이라고 생각한다.

더 정확한 데이터가 없으면 처음에는 눈치 채지 못했을 수도 있지만 확실하지 않습니다. 또 다른 가설은 PuTTY가 분명히 다른 SSH 구현을 사용하기 때문에 대기 시간 스파이크가 발생하지 않을 것이라는 것입니다. 위의 핑 차트에서와 같이 대기 시간 급증이 없음을 수량화할 수 있으면 네트워크 문제와 클라이언트 문제를 구별하는 데 도움이 됩니다.

더 많은 데이터를 전송하려면 PuTTY를 사용하여 scp컴퓨터와 해당 호스트 간에 대용량 파일을 복사하겠습니다. 당신은 그것을 사용할 수 있습니다라인샤크패킷 간 시간을 기록합니다.

차트의 핑 테스트에 몇 가지 결함이 있습니다. 첫 번째는 ping이 TCP/IP와 완전히 다르며 일반적으로 IP 트래픽보다 우선 순위가 낮고 중간 라우터에서 삭제될 가능성이 더 높은 ICMP 패킷을 사용한다는 것입니다. 빠른 확인으로 이 데이터는 유용하지만 TCP/IP 연결을 추적하려면 IP 패킷을 사용하는 것이 더 낫기 때문에 scp를 권장합니다. Unix에서 동일한 scp/wireshark 조합을 사용하여 비교할 수도 있습니다.

핑 테스트의 또 다른 문제점은 60초가 주기적인 동작을 전체적으로 파악하기에는 너무 짧은 시간이라는 것입니다. 요약 도구가 이미 준비되어 있는 것 같으므로 10분이 1분보다 낫거나 1시간보다 더 좋습니다.

테스트할 때 컴퓨터 간에 전달되는 데이터를 변경합니다. 다음은 엔트로피가 많고 엔트로피가 거의 없는 파일을 생성하기 위한 매우 빠르고 더러운 스크립트입니다.

#!/usr/bin/env python2.7

import random

def data_bytes(outf, ordered=False):
    """write a series of ordered or random octets to outf"""
    for block in range(1024):
        for char in range(1024):
            if ordered:
                c = char % 0x100
            else:
                c = random.randint(0, 0xff)
            outf.write(chr(c))

def main():
    with open('random.dat', 'wb') as outf:
        data_bytes(outf, ordered=False)
    with open('sequen.dat', 'wb') as outf:
        data_bytes(outf, ordered=True)

if __name__ == '__main__':
    main()

이것이 당연하다면 용서해주세요.

귀하의 일화적인 관찰은 이 질문을 흥미롭게 만듭니다. 더 나아가려면 하드 데이터가 필요합니다.

아직 이것을 시도하지 않았다면 SSH 클라이언트에 연결 유지를 추가해 볼 수 있습니다. 그냥 추가하세요

ServerAliveInterval 30

어딘가에 가서 ~/.ssh/configssh를 다시 시작하세요.

실제 네트워크 토폴로지를 알지 못한 채 점보 프레임을 사용하는 기가비트 네트워크와 관련이 있을 수 있다고 생각했습니다. ssh는 점보 프레임을 좋아하지 않습니다. 표준 1500바이트 크기 패킷에 최적화되어 있으며 패킷이 그보다 크면 문제가 발생합니다. (예: 6000바이트)

점보 프레임이 활성화된 두 워크스테이션이 있는 인트라넷에서 이를 확인할 수 있습니다. (물론 그들 사이에는 기가비트 네트워크가 있습니다!)

멀리서 서버에 연결하고 패킷이 고르지 않게 전달되는 경우 (네트워크 설정에 따라) 라우터가 패킷을 최적화하고 서버가 점보 프레임을 받게 되어 통신이 실패하는 일이 발생할 수 있습니다.

서버 구성에 점보 프레임이 활성화되어 있는지 확인해야 합니다.

SSH가 다시 중단될 때까지 핑을 계속 실행하도록 했습니다. 몇 초 동안 패킷이 수신되지 않은 다음 약 6개의 패킷이 빠르게 연속해서 다시 전송됩니다.

vmware에 2개의 가상 서버가 있습니다. 그들 중 누구도 DNS에 없습니다. 두 가상 서버는 모두 동일한 ESX에 있습니다. 퍼티는 하나만 얼어 붙습니다. vmware 가상 머신 콘솔이 정지되지 않습니다.

그래서 저는 Windows 클라이언트에서 서버로 TRACERT를 했습니다. 머신이 멈추고 이전 DNS 이름이 표시됩니다. 방금 서버 IP 주소를 변경했는데 문제가 해결되었습니다.