VPN을 통해 VIM을 사용할 때 TCP 창 크기가 0이 되는 이유는 무엇입니까?

VPN을 통해 VIM을 사용할 때 TCP 창 크기가 0이 되는 이유는 무엇입니까?

저는 일반적인(즉 형편없는) 무선 홈 네트워크를 통해 Mac OS 노트북을 사용하고 VPN을 통해 작업에 연결합니다. 직장 사무실에 있는 Linux(우분투) 데스크탑에 SSH로 접속합니다. (내가 "I ssh"라고 말할 때: 'ssh'를 사용할 것이라고 알려주는 버튼을 클릭하면 "터미널" 창이 열리고 내 데스크탑에 로그인됩니다.)

자주(하루에 최대 몇 번) 'vim'을 사용하면 'vim'이 응답을 멈추고 1~2분 후에 데스크톱 연결이 끊어지고 터미널에서 연결이 끊어졌다고 알립니다. . 데스크탑에 한 번에 여러 개의 터미널 창이 열려 있는 경우가 종종 있는데, 'vim'을 사용하는 터미널 창만 중단됩니다. 다른 창은 연결되어 있고 사용할 수 있는 상태로 유지됩니다.

최근에 나는 tcpdump를 사용하여 앞뒤로 이동하는 패킷을 추적하고 있었고 vim 세션이 중단되고 종료되는 추적을 캡처했습니다. 중단되기 몇 분 전에 데스크탑의 패킷이 0에 도달할 때까지 창 크기가 꾸준히 줄어들면서 도착했고 조금 후에 연결이 끊어졌습니다.

예를 들어 데스크탑이 중단된 동안 삽입 모드에 들어가서 문자를 입력하기 시작했고 데스크탑이 망가진 동안 입력으로 창을 채웠다는 것을 거의 이해할 수 있었습니다. 시작 창 크기는 약 12,500이었고 내가 입력한 각 문자는 48바이트 패킷을 생성하는 것으로 보이므로 약 250자가 TCP 버퍼를 채울 수 있습니다.

그러나 vim이 중단되면 페이지다운(control-f)을 수행한 다음 삽입 모드로 들어간 다음 몇 글자를 입력하기 시작하는 것과 비슷합니다. 내 명령과 문자가 에코되어 vim이 문자를 수신하고 처리하고 있음을 나타냅니다.

소켓과 'vim' 사이에 tpc 버퍼가 어디에 있는지 확실하지 않습니다. 아마도 tty 드라이버는 실제로 tcp 버퍼에서 문자를 선택하여 나에게 다시 에코하고 vim에 전달하고 vim의 출력을 나에게 다시 전달하는 것 같습니다. 그러나 이러한 모든 작업은 TCP 버퍼에서 바이트를 가져오며 창 크기는 0이 되지 않습니다.

소프트웨어 스택의 작동 방식에 대해 내가 이해하지 못하는 점은 무엇이며, 창 크기가 0이 되는 이유는 무엇이며, 문제를 해결하려면 어떻게 해야 합니까?

보너스 질문:

1) 데스크탑에서 창 크기를 약 64K가 아닌 약 12,500으로 설정하는 이유는 무엇입니까?

2) Mac에서 tcpdump를 사용할 때 "host 호스트 이름", "호스트 ipaddress" 또는 "포트 22" 표현식('hostname' 및 'ipaddress'는 이름 또는 IP 주소로 대체됨)을 사용하면 출력이 없습니다. 내 데스크탑). 이러한 표현식 중 하나를 지정하지 않으면 많은 출력이 표시되고 출력에는 명령줄에서 지정한 호스트 이름, ipaddress 또는 포트가 명확하게 포함됩니다. tcpdump가 작동하지 않는 Mac에 특별한 것이 있습니까? 명령줄을 망칠 수 있는 표준 방법이 있습니까? tcpdump에 무엇을 요청하는지 혼란스럽습니다.

고마워, CS

답변1

먼저, TCP 창 크기는 버퍼가 아니라 승인 임계값입니다. 트래픽을 수신하는 노드는 x 패킷마다 ACK 패킷만 보냅니다. 신뢰할 수 있는 네트워크에서 이 숫자는 처리량을 위해 가능한 한 커야 합니다. 일부 데이터가 손실되면 전체 창을 다시 전송해야 한다는 단점이 있습니다. 이로 인해 일반적으로 TCP 스택은 창 크기를 점진적으로 줄여서 문제가 발생하지 않도록 합니다. 향후 패킷 손실이 발생할 경우 너무 많은 데이터를 재전송합니다. 사용 가능한 메모리(수신 버퍼)와 관련된 구성 요소가 있지만 최신 시스템에서는 이는 대부분 관련이 없습니다.위키피디아

이 문제의 근본 원인은 네트워크 연결 상태가 좋지 않기 때문일 수 있습니다. VPN은 무선 네트워크와 마찬가지로 대기 시간이 길거나 패킷 손실이 발생할 수 있습니다. 실험적으로, 무선 대신 하드라인을 통해 연결하면 문제가 개선/해결됩니까?

관련 정보