NC에서 파일 전송이 완료된 시점을 확인하는 방법


11

netcat이 시스템간에 파일 전송을 완료 한 시점을 알 수있는 방법이 있습니까?

현재 명령 :

기계 # 2 : nc -lp 5555 > test.txt

기계 # 1 : nc MachineIP Port < test.txt

전송이 이루어 지지만 완료되었다는 시각적 표시는 없습니다.

답변:


19

먼저 몇 가지 배경

nc (1)-Linux 매뉴얼 페이지 또는 nc (1) BSD 일반 명령 매뉴얼 에서 nc찾을 수 있듯이 다른 버전 의이 있습니다 . 전송 직후 연결이 종료되어야합니다. 링크 된 두 사이트 모두에 예제가 있습니다.

출력을 파일로 캡처하여 nc를 사용하여 특정 포트에서 청취하십시오.

$ nc -l 1234 > filename.out

두 번째 머신을 사용하여 리스닝 nc 프로세스에 연결하여 전송할 파일을 제공하십시오.

$ nc host.example.com 1234 < filename.in

파일이 전송되면 연결이 자동으로 닫힙니다.

당신은 netcat그것을 (들)은 위에서 설명한 것과 다른, 그래서 전송 한 후 연결을 종료하지 않습니다. Debian Jessie의 Netcat 1.10처럼 동작합니다. 이 동작은 /usr/share/doc/netcat-traditional/README.gz(내 컴퓨터)에 굵게 표시되어 있습니다.

가장 간단한 사용법에서 "nc 호스트 포트"는 지정된 대상 호스트의 지정된 포트에 대한 TCP 연결을 만듭니다. 그런 다음 표준 입력이 호스트로 전송되고 연결을 통해 되돌아 오는 모든 것이 표준 출력으로 전송됩니다. 연결의 네트워크 쪽이 종료 될 때까지 무한정 계속됩니다. 이 동작은 표준 입력에서 모든 파일을 종료하고 파일 끝 이후에 종료되는 대부분의 다른 응용 프로그램과 다릅니다.

이 행동에 대한 추론은 다음과 같습니다.

"텔넷을 사용하여 임의의 포트에 연결하지 않는 이유는 무엇입니까?" 유효한 질문이며 몇 가지 이유가 있습니다. 텔넷에는 "표준 입력 EOF"문제가 있으므로 네트워크 출력이 완료되도록 스크립트를 구동 할 때 계산 지연이 발생해야합니다. 이것이 네트워크 측이 닫힐 때까지 netcat이 계속 실행되는 주된 이유 입니다.

Wikipedia에는 다양한 구현 방법이 있습니다. 그래도 차이점을 말할 수는 없습니다. 다른 사람이 할 수 있습니까?


이제 솔루션

1

nc파일을 읽은 후 종료하도록 지시 할 수 있습니다 . 이 옵션은 유용합니다 :

-q seconds   after EOF on stdin, wait the specified number  of  seconds
             and then quit. If seconds is negative, wait forever.

송신 측에서이 명령을 사용하는 경우 :

nc -q 0 MachineIP Port < test.txt

ncEOF를 읽은 후 즉, 파일이 종료 된 직후에 0 초가 종료됩니다. 그런 다음 종료되고 수신 종료 nc됩니다.

패킷이 전달되지 않으면 어떻게되는지 궁금하다면 Juraj의 의견입니다.

모든 패킷이 전달되지 않으면 시스템은이를 감지하여 응용 프로그램을 알리지 않고 다시 전송합니다 (또는 가능하지 않은 경우 응용 프로그램에 시간 초과 오류가 발생 함). 안정적인 전달은 OS 커널이 제공하는 TCP 프로토콜의 목적입니다 nc. 이를 사용하지 않는 UDP 프로토콜을 요청할 수 nc -u있지만 , 그렇지 않습니다 .

2

전술 한에 원래 예제가 있는데 README.gz, 이는 -w시간 초과를 기반으로하며 -q구현에 옵션이 필요하지 않습니다 .

Netcat은 간단한 데이터 전송 에이전트로 사용될 수 있으며 어느 쪽이 리스너이고 어느 쪽이 클라이언트인지는 중요하지 않습니다. 한쪽의 입력이 다른 쪽의 출력으로 도착합니다. 제한 시간을 지정하지 않고 수신 측에서 리스너를 시작한 다음 송신 측에 작은 시간 초과를 제공하면 도움이됩니다. 이렇게하면 리스너는 사용자가 연락 할 때까지 청취 상태를 유지하며, 데이터 흐름이 중단 된 후 클라이언트는 시간 초과, 종료 및 청취자를 가져옵니다. 중재 네트워크에 문제가 발생하지 않으면 완전히 신뢰할 수 있어야하며 항상 시간 초과를 늘릴 수 있습니다. "rsh"라는 전형적인 예는 종종 다음과 같은 용도로 사용됩니다.

nc -l -p 1234 | uncompress -c | tar xvfp -

그리고 다른쪽에

tar cfp - /some/dir | compress -c | nc -w 3 othermachine 1234

.rhosts 파일, 사용자 계정 또는 inetd 구성에 대해 걱정할 필요없이 한 시스템에서 다른 시스템으로 디렉토리의 내용을 전송합니다.


이 기능이 작동하지 않는 것 같습니다. -q를 수행하면 명령이 존재하지 않습니다. -w는 비슷하게 보이지만 연결이 종료되지는 않습니다.
Anthony Russell

당신의 nc버전은 무엇입니까 ? 확인하려면 : nc -h첫 줄.

응, 예, 꽤 낡았다. 리눅스의 오래된 이미지에 임. 나는 그것을 업데이 트하고 또 갈 것이다
Anthony Russell

내 답변을 업데이트했습니다.

1
모든 패킷이 전달되지 않으면 운영 체제는이를 감지하여 응용 프로그램을 알리지 않고 다시 전송합니다 (또는 여전히 실패하면 응용 프로그램에 시간 초과 오류가 발생 함). 안정적인 전달은 nc가 사용하는 OS 커널이 제공하는 TCP 프로토콜의 목적입니다. nc -u를 사용하여이를 수행하지 않는 UDP 프로토콜을 요청할 수 있지만, 그렇지 않습니다.
Juraj
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.