Najpierw jakieś tło
Istnieją różne wersje nc
, jak można znaleźć na nc (1) - Linux man manual lub nc (1) BSD General Commands Manual, połączenie powinno zostać zamknięte zaraz po transferze. Na obu połączonych stronach podano przykład:
Zacznij od użycia nc do nasłuchu na określonym porcie, z wyjściem przechwyconym do pliku:
$ nc -l 1234 > filename.out
Za pomocą drugiego komputera połącz się z procesem nasłuchiwania, podając mu plik, który ma zostać przesłany:
$ nc host.example.com 1234 < filename.in
Po przesłaniu pliku połączenie zostanie automatycznie zamknięte.
Twoje połączenie netcat
nie zostanie zamknięte po transferze, więc różni się od tego opisanego powyżej. Zachowuje się jak mój, Netcat 1.10 na Debian Jessie. To zachowanie jest udokumentowane w /usr/share/doc/netcat-traditional/README.gz
(na moim komputerze), pogrubienie jest moje:
W najprostszym użyciu „port hosta nc” tworzy połączenie TCP z danym portem na danym hoście docelowym. Standardowe dane wejściowe są następnie wysyłane do hosta, a wszystko, co wraca przez połączenie, jest wysyłane na standardowe wyjście. Trwa to w nieskończoność, dopóki strona sieciowa połączenia nie zostanie wyłączona. Zauważ, że to zachowanie różni się od większości innych aplikacji, które zamykają wszystko i wychodzą po zakończeniu pliku na standardowym wejściu.
Oto uzasadnienie tego zachowania:
Być może pytasz „dlaczego nie użyć telnetu do łączenia się z dowolnymi portami?” Ważne pytanie, a oto kilka powodów. Telnet ma problem z „standardowym wejściem EOF”, dlatego należy wprowadzić obliczone opóźnienia w skryptach sterujących, aby umożliwić zakończenie działania wyjścia sieciowego. Jest to główny powód, dla którego netcat działa, dopóki strona sieci nie zostanie zamknięta.
Wikipedia ma wiele różnych wdrożeń . Nie umiem jednak wymienić różnic. Może ktoś inny może?
Teraz rozwiązania
1
Możesz powiedzieć, nc
aby zakończyć po odczytaniu pliku. Ta opcja jest przydatna:
-q seconds after EOF on stdin, wait the specified number of seconds
and then quit. If seconds is negative, wait forever.
Jeśli użyjesz tego polecenia po stronie wysyłającej:
nc -q 0 MachineIP Port < test.txt
nc
wyjdzie 0 sekund po odczytaniu EOF, czyli zaraz po zakończeniu pliku. Następnie wyjdzie, podobnie jak koniec odbierający nc
.
Jeśli zastanawiasz się, co się stanie, jeśli pakiety nie przejdą, oto komentarz Juraja.
Kiedy wszystkie pakiety nie napotkają, system wykryje to i wyśle je ponownie bez powiadomienia aplikacji (lub jeśli nie będzie to możliwe, aplikacja otrzyma błąd przekroczenia limitu czasu). Niezawodne dostarczanie jest celem protokołu TCP zapewnianego przez jądro systemu operacyjnego, które nc
wykorzystuje. Możesz zażądać protokołu UDP, który tego nie robi, używając, nc -u
ale tak nie jest.
2)
We wspomnianym powyżej jest oryginalny przykład README.gz
, który opiera się na przekroczeniu -w
limitu czasu i nie wymaga -q
opcji obecności w implementacji.
Netcat może być używany jako prosty agent przesyłania danych i tak naprawdę nie ma znaczenia, który koniec jest odbiornikiem, a który klientem - dane wejściowe z jednej strony docierają do drugiej jako dane wyjściowe. Pomocne jest rozpoczęcie nasłuchiwania po stronie odbierającej bez określonego limitu czasu, a następnie niewielkie opóźnienie po stronie wysyłającej. W ten sposób słuchacz pozostaje nasłuchiwany, dopóki się z nim nie skontaktujesz, a gdy dane przestaną płynąć, klient przekroczy limit czasu, zamknie się i zabierze ze sobą słuchacza. O ile sieć interweniująca nie jest obarczona problemami, powinno to być całkowicie niezawodne i zawsze można zwiększyć limit czasu. Typowy przykład czegoś „rsh” jest często używany do: z jednej strony,
nc -l -p 1234 | uncompress -c | tar xvfp -
a potem po drugiej stronie
tar cfp - /some/dir | compress -c | nc -w 3 othermachine 1234
przeniesie zawartość katalogu z jednego komputera na drugi, bez konieczności martwienia się o pliki .rhosts, konta użytkowników lub konfiguracje inetd na obu końcach.
nc
wersja Aby sprawdzić:nc -h
pierwsza linia.