[kamikazee]

który z protokołów (SFTP, SCP) jest szybszy i mniej obciążający procesor?
#linux #debian #rasberry #raspberrypi

[patrolez]

@kamikazee: SCP z powodu z deka innych przypadków użycia

[maniac777]

mniej obciążający procesor?

@kamikazee: przy transferze wiekszych plikow prawdopodobnie bez roznicy lub w zaleznosci od wybranych funkcji kryptograficznych, a nie w zaleznosci od protokolu. Przy transferze duzej ilosci mniejszych plikow stawialbym na scp bo spodziewam sie ze negocjacja tls bedzie zachodzila przy kazdym pliku przy sftp. Najszybszy bedziej jednak w tej sytuacji rsync przez ssh.

[patrolez]

@maniac777: należy odróżniać SFTP (protokół oparty o SSH) i FTPS (FTP po SSL/TLS)

[kamikazee]

@maniac777: a FTP?

[patrolez]

@kamikazee: ale co chcesz osiągnąć, bo w sumie chyba o to się rozchodzi.

[ksiak]

a FTP?

@kamikazee: a to ktoś tego jeszcze używa?

[maniac777]

@patrolez: fuck rypnalem sie. Masz racje. Wiec odpowiedz - bez roznicy prawdopodobnie.

@kamikazee: ftp nie uzywa szyfrlwanych polaczen chyba ze ftps wtedy tak jak napisalem.

[patrolez]

@kamikazee: w zależności od zastosowania:

* wiele/mało/jeden plik/i,
* duże/małe plik/i,
* czy potrzebujesz widzieć/przeglądać pliki na serwerze docelowym,
* mirroring/synchornizacja live, czy może chodzi ci o transfer na żądanie.

Każda z tych kombinacji to różne potencjalne narzędzia, aczkolwiek wspomniany wyżej rsync faktycznie wpasowuje się w większość.

[kamikazee]

@patrolez: synchronizacja/backup plików różnej wielkości od 1 MB do 20 GB z Windows, narazie testuje rclone bo rsync jest tylko dostępny przez cygwin

[K.....7]

@kamikazee: może https://syncthing.net/?

[dict]

mniej obciążający procesor

@kamikazee: A co Ty, ekologiem jesteś, czy przebieg mierzysz?

[kamikazee]

@KKK1337: sprawdzę

[kamikazee]

@dict: nie jest ekooszołomem, jak nie masz nic sensownego do dodania to się nie udzielaj

[RARvolt]

@kamikazee: Duplicati, a w konfiguracji możesz wyłączyć kompresję, weryfikację czy też zwiększyć rozmiar bloku coby zmniejszyć obciazenje cpu. Mam codzienny backup ~100GB /home, a na Win katalogu domowego i partycji do pracy i nawet nie zauważam tego.

[Kryspin013]

A co Ty, ekologiem jesteś, czy przebieg mierzysz?

@dict: przy dużych danych szyfrowanie po ssh znacząco spowalnia transfer więc nie chodzi tylko o prąd.

@kamikazee: a musisz szyfrować dane w locie? Bo wszystko co idzie po SSH (SFTP, SCP to to samo) będzie mieć swój narzut.

[kamikazee]

@Kryspin013: nie potrzebuje szyfrowania transmisji pytam się który z protokołów jest najszybszy i najmniej obciążający procesor bo docelową maszynką jest Raspberrypi 1

[Kryspin013]

pytam się który z protokołów jest najszybszy

@kamikazee: żaden bo oba to to samo - dosłownie. A rsync też idzie po ssh.

maszynką jest Raspberrypi 1

@kamikazee: O panie.

Najszybsze to będzie coś co nie ma warstwy szyfrującej, np zwykły netcat, smb albo nawet rsync ale z wyłączeniem transjmisji po ssh (bo domyślnie rsync obecnie kopiuje dane przez tunel ssh):
https://stackoverflow.com/questions/8575345/rsync-without-ssh-access

Możesz sobie porównać wyniki kopiując plik 1GB przez netcat

[kamikazee]

@Kryspin013: dzięki sprawdzę,
netcat jest jeszcze szybszy niż FTP?

[o.....a]

@kamikazee: a to ktoś tego jeszcze używa?

@ksiak: tak gdzie ważna jest szybkość przesyłu (można zwiększać liczbe równoległych połączeń, otwierajac zakresy portów) albo klient nie może uzywać sftp/scp np Mainframy (zOS) a konkretnie jego operator nie potrafi obsłużyć innych JQL niz ftp-owe

@kamikazee: ftp nie uzywa szyfrlwanych polaczen chyba ze ftps wtedy tak jak napisalem.

@maniac777: to szyfrowanie to zależy kto inicjuje z tego co pamietam bo tam