Skąd mała popularność FTP?

1

Czym jest FTP, nie trzeba pisać. A jeżeli problemem jest przesyłanie danych jawnym tekstem, to wymyślono FTPS. Jest jeszcze SFTP, które jest zupełnie innym protokołem, ale służącym do tych samych celów z szyfrowaniem.

Mam takie wrażenie, że FTP "odchodzi do lamusa", bo:

  1. Różne "dyski chmurowe", np. Google Drive, Chomikuj i inne mają swój interfejs w HTML/JS służący do wysyłania i odbierania plików.
  2. Dyski chmurowe można obsługiwać z systemu operacyjnego, ale zamiast standardowego FTP to mają jakieś swoje aplikacje do wysyłania i odbierania danych, jakby ich autorzy zapomnieli, po co wymyślono FTP.
  3. W ogóle, to jakoś rzadko się widzi, żeby dostęp do zasobów plikowych gdzieś był dostępny po FTP.
  4. Jakieś 10-15 lat temu, zanim chmury zdobyły popularność, firma Komputronik oferowała usługę "backup na serwerze", która z dzisiejszego punktu widzenia była tak naprawdę chmurą, jak Google Drive. Tutaj też nie było dostępu po FTP, tylko dedykowany program. Z usługi nie korzystałem, więc nie wiem, jak wygląda.

Moim zdaniem FTP i FTPS ma przewagę nad istniejącymi rozwiązaniami:

  1. Został specjalnie wymyślony do transferu plików i zdalnych katalogów (już samo rozwinięcie skrótu wyjaśnia przeznaczenie), nie potrzeba wymyślać nowego protokołu ani nowego programu do obsługi, wystarczy opracować serwer lub też uruchomić istniejący, których też nie brakuje, w tym open source.
  2. Co najmniej kilka klientów na każdy istniejący system operacyjny, a w niektórych przypadkach nawet i żaden dodatkowy program nie jest potrzebny, żeby się dostać na serwer FTP.
  3. Zapewne wiele bibliotek do każdego języka programowania w przypadku, gdy wysłanie lub odbiór pliku jest częścią większego projektu.

Żeby nie było, FTP ma też i wady, ale nie są jakieś uciążliwe:

  1. Wysyła hasło logowania i dane tekstem jawnym, ale ta wadę zniwelowało FTPS.
  2. Otwiera tak naprawdę dwa połączenia, przy czym jedno jest z puli portów zamiast jednego robiącego pewien kłopot przy konfiguracji przekierowań portów na routerze i trochę obniżając bezpieczeństwo sieciowe, choć to zależy od konfiguracji klienta FTP. Z drugiej strony, kilka połączeń do jednej czynności to żaden problem dla klienta, a nawet dla serwera, który to udźwignie dla wielu klientów.
  3. Przeglądarki internetowe Google Chrome, Firefox teoretycznie obsługują FTP, ale w praktyce nie jest możliwe wysłanie i usuwanie plików pomimo prawa do tej czynności. Jednak to nie jest wada FTP jako takiego, tylko efekt niechęci lub niedopatrzenia programistów tych przeglądarek (same przeglądarki mają ponad 10 lat, za nimi stoją tysiące godzin pracy programistów, a nikomu nie chce się poświęcić kilka godzin do pełnej obsługi FTP).

Pytanie jest takie: Dlaczego FTP został jakby zapomniany pomimo swoich niezaprzeczalnych zalet? Dlaczego się odeszło od niego na rzecz aplikacji i bibliotek dedykowanych konkretnemu serwerowi? Trudno uwierzyć, że nie jest możliwe zastosowanie protokołu FTPS, jedynie być może potrzebne byłoby niestandardowe działanie serwera w niektórych przypadkach. Wymienione wyżej wady są zbyt słabe, żeby całkowicie rezygnować z FTP i FTPS.

1

Ja korzystam sobie z sshfs, mega wygodne podmontowuje sobie katalog jaki chce i mam wszystko w jednym, a to czasem tunnel jakiś, a to zwykły shell, ssh jest mega uniwersalne.

ftp/sftp nie pamiętam kiedy ostatnio używałem, chyba że jakiś program w tle z tego korzystał, a nie wiedziałem.

0

może używałem złych klientów ale dla mnie był po prostu za wolny, każda zmiana folderu, transfer wielu małych plików, wszystko działało mega topornie. FTP było ostatnią deską ratunku gdy wszystko inne zawiodło, zazwyczaj nawet kiepskie interfejsy HTTP były dużo bardziej responsywne.

4

Konieczność otwierania wielu portów to deal breaker dla większości firewalli. Nawet na swoim ruterze mam wyłączoną możliwość otwierania jakiś losowych portów. FTP wymyślono przed internetem i od razu próbował być czymś więcej niż tylko protokołem do transferu, ale także w jakimś stopniu do zarządzania zdalną lokacją przez co nie wyskalował zbyt dobrze do dzisiejszej chmurowej rzeczywistości. Teoretycznie można by go nadal użyć do samego transferu, ale w sumie po co skoro nawet w takim zastosowaniu scp jest prostsze w zastosowaniu dla admina, bo tenże i tak pewnie używa ssh, a rsync jest szybszy i ma większe możliwości.

Dla zastosowań aplikacyjnych FTP/FTPS wiąże Ci ręce i pewnie skończysz z czymś co zalatuje terminalem z lat 80', nie używałem niczego na bazie FTP/FTPS, co byłoby przyjemne w użyciu. Lepiej skroić coś własnego pod swoje potrzeby do zarządzania lokacją a do transferu użyć rsync albo SFTP.

2

Za FTP w 2022 powinni zamykać w więzieniach, tak jak za wiele innych protokołów, które są toporne, niewygodne, dziurawe i bezsensowne w dzisiejszych czasach z racji alternatyw.

0
andrzejlisek napisał(a):
  1. Dyski chmurowe można obsługiwać z systemu operacyjnego, ale zamiast standardowego FTP to mają jakieś swoje aplikacje do wysyłania i odbierania danych, jakby ich autorzy zapomnieli, po co wymyślono FTP.

Obsługa zdalnych dysków / plików chyba nigdy nie była natywna cechą systemów operacyjnych.
Tak wiec i to, co piszesz, to (dobrze zintegrowana) nakładka na rdzeń systemu, i tylko nie było woli, aby takie coś zrobić dla FTP (a moze było około Win98??? nie pamiętam)

Wady FTP: firewall, niejasne zachowanie w sytuacji po-awarii, ogrom patchy na oryginalny protokół FTP, w praktyce każdy serwer ftp "coś" dodaje, a "rasowy" klient ftp to zgaduje.

Np transmisja pliku po HTTP łatwiej się mieści w głowie "odpal event po zakończeniu" - nawet tu na forum widac, jak ludzie się boksują, aby mieć dynamiczną wiedzę o starcie i końcu transmisji (pochodna tego, ze używaja FTP w roli Web-API, co jest głupota)
Żaden chyba serwer FTP nie daje się skryptować, co na HTTP jets w zasadzie oczywiste.

0

lepsze rozwiązania wypierają gorsze ot i wszystko !

jak bym chciał użyć FTP to chyba bym musiał sam zainstalować serwer :) w moim otoczeniu nikt już tego nie używa jest to tak przestarzałe jak Clipper (język programowania) :D

0
Adamek Adam napisał(a):

jak bym chciał użyć FTP to chyba bym musiał sam zainstalować serwer :) w moim otoczeniu nikt już tego nie używa jest to tak przestarzałe jak Clipper (język programowania) :D

Eeee, jednemu z podmiotów, któremu robiłem studium wdrożenia ERP-a, sprzedano apkę w Cliperze zaledwie 5-8 lat temu. :)

Adamek Adam napisał(a):

lepsze rozwiązania wypierają gorsze ot i wszystko !

Zdecydowanie nie jest to zasadą w życiu, a nawet Kopernik pisał n/t studium

0
ZrobieDobrze napisał(a):
andrzejlisek napisał(a):
  1. Dyski chmurowe można obsługiwać z systemu operacyjnego, ale zamiast standardowego FTP to mają jakieś swoje aplikacje do wysyłania i odbierania danych, jakby ich autorzy zapomnieli, po co wymyślono FTP.

Obsługa zdalnych dysków / plików chyba nigdy nie była natywna cechą systemów operacyjnych.
Tak wiec i to, co piszesz, to (dobrze zintegrowana) nakładka na rdzeń systemu, i tylko nie było woli, aby takie coś zrobić dla FTP (a moze było około Win98??? nie pamiętam)

System nigdy nie ma natywnej obsługi zdalnych dysków. Chodzi o to, że do Microsoft OneDrive nożna do Windowsa doinstalować jakiś program i wtedy zdalny dysk pokazuje się jako kolejny dysk (podobnie, jak mapowane dyski sieciowe). Słyszałem, że Google Drive umożliwia podobną rzecz, ale tego nie jestem pewien.

dzek69 napisał(a):

Za FTP w 2022 powinni zamykać w więzieniach, tak jak za wiele innych protokołów, które są toporne, niewygodne, dziurawe i bezsensowne w dzisiejszych czasach z racji alternatyw.

Jak nie FTP lub FTPS, to jaki protokół do transferu plików jest teraz "na topie", można zainstalować serwer i ma klientów też od groma?
Przyjrzymy się popularnym programom mogące być klientami:

  1. Total Commander: FTP i FTPS
  2. Krusader: FTP, SFTP, FISH, NFS, SMB, WebDav
  3. WinScp: SFTP, SCP,FTP, WebDav, Amazon S3

Wygląda na to, że dobrym protokołem jest SFTP (pomimo podobieństwa do FTP w nazwie to zupełnie inny protokół) lub WebDav. Czy to prawda?

several napisał(a):

Dla zastosowań aplikacyjnych FTP/FTPS wiąże Ci ręce i pewnie skończysz z czymś co zalatuje terminalem z lat 80', nie używałem niczego na bazie FTP/FTPS, co byłoby przyjemne w użyciu. Lepiej skroić coś własnego pod swoje potrzeby do zarządzania lokacją a do transferu użyć rsync albo SFTP.

Ja pytam o FTP w kontekście wysyłania plików na zdalny nośnik, przeglądania katalogów na zdalnym nośniku i pobierania plików. Możliwe, że pierwotnie miał jeszcze inne zastosowania. Z drugiej strony, protokół SSH i program taki, jak PuTTY podobno "ma się dobrze", pomimo, że jest to właśnie terminal zgodny z VT102 rodem z lat 80, jednak niektórym użytkownikom służy nie tylko do nauki i zabawy.

Natomiast FTP wymyśliłem jakiś czas temu ze względu na następujące potrzeby:

  1. Potrzebuję skopiować jakieś dane z jednego komputera będącego w domu do drugiego komputera będącego poza domem. Na jednym komputerze wprowadzam na swój FTP, a na drugim komputerze pobieram z FTP. Nie potrzebuję szukać pendrive ani nie ma opcji, że się go zapomni zabrać.
  2. Potrzebuję udostępnić jakieś pliki (nawet duże) którejś osobie, lub też potrzebuję otrzymać pliki od tej osoby. Zakładam kolejny login i hasło na serwerze FTP, wprowadzam tam te pliki i podaję login i hasło tej osobie. Poczta elektroniczna nie zawsze udźwignie większą ilość danych, a nawet jak już, to jeszcze przygotowanie, wysyłanie, pobieranie, co przy większej ilości danych jest kłopotliwe. Jak to przestanie być potrzebne, to usuwam pliki, hasło i już.
  3. Podobnie, jak punkt wyżej, jak regularnie mam aktualizować jakieś pliki tej drugiej osobie, to łatwiej sprawdzić, co jest na FTP (do którego ma dostęp ta druga osoba) niż szukać po mailach, pendrivach i przypominać sobie co i kiedy tej osobie ostatnio przekazałem.
  4. Komputer, na którym uruchomiłem serwer FTP służy nie tylko jako serwer. Jak potrzebuję, żeby coś zrobił na większej ilości danych, to wprowadzam i wyprowadzam właśnie poprzez FTP. Ewentualnie mogę za pomocą RDP, ale zauważyłem, że wysyłane tego samego przez RDP trwa dłużej niż przez FTP i bywa zawodne.

Na routerze ustawiłem przekierowania portów 21, 80, 989, 990, 50000-65535 na tamten komputer, na nim nie przechowuję danych, których utrata będzie bolesna, a jak już, to jest to tylko kopia danych przechowywanych w innym miejscu.

W powyższych zastosowaniach FTP sprawdza się bardzo dobrze, działa FTP i FTPS. Przy korzystaniu z niego nie stwierdziłem żadnych problemów, nic się nie psuje (a jeśli już, to bardzo rzadko). W takim razie, którym protokołem powinienem zastąpić FTP i FTPS mając nadal ten sam zestaw zastosowań?

1

Dlaczego FTP został jakby zapomniany pomimo swoich niezaprzeczalnych zalet?

Nie został zapomniany i wciąż jest używany tam gdzie ma sens. Po prostu do pewnych zastosowań są lepsze narzędzia i protokoły.

Jeżeli popatrzymy z punktu widzenia aplikacji takiej jak MS Teams czy innej tego typu do wspólnej pracy z plikami, dużo łatwiej jest to ogarnąć programiście za pomocą HTTP niż FTP. Dlatego też taki SharePoint jaki cały pakiet O365 wystawia swoją funkcjonalność poprzez HTTP API. To samo tyczy się trzymania danych w storage chmurowym jak AWS S3, które zapewniają, praktycznie nieograniczone miejsce, większą dostępność plików dzięki geo-replikacji, każdy plik ma swój unikalny link pod którym się znajduje, szyfrowanie in-transit oraz at-rest i wiele innych.

Nie ma co bić piany tylko używać tego czego akurat potrzebujemy i co jest najlepsze dla projektu.

EDIT:
Co do prywatnego użytku to jak ktoś lubi konfigurować sobie serwery i je utrzymywać, otwierać/blokować porty na routerze, nie potrzebuje wysokiej dostępności, uważa że robi to lepiej i bezpieczniej niż zespoły inżynierów Microsoftu czy Amazonu to niech to robi. Większość użytkowników jednak jest wygodna i woli korzystać z gotowych narzędzi, a te najlepiej obsługuje się poprzez HTTP bo każdy komputer i router domyślnie ma otwarte porty 80 i 443.

1

Ja nadal korzystam z sftp chociażby do pobierania dużych plików z serwera. Nie raz po http przy 90% miałem jakiś błąd pobierania i trzeba było zaczynać od nowa, nie wiem czy teraz przeglądarki obsługują wznowienie pobierania natomiast pobieranie np. przez filezilla po prostu zawsze mi działa i jest stabilne nawet jeżeli utracę na chwilę połączenie.

0
markone_dev napisał(a):

Nie ma co bić piany tylko używać tego czego akurat potrzebujemy i co jest najlepsze dla projektu.

Nie chcę bić piany bez sensu, tylko ustalić, co jest powodem tego, że w niektórych zastosowaniach, do których FTP był specjalnie opracowany, stosuje się własnościowe aplikacje i protokoły (opracowane przez właściciela "chmury" i współpracujące tylko z tą chmurą). Ja uruchomiłem serwer FTP, bo wydawał się, że najbardziej odpowiada moim potrzebom, ale jeżeli jest protokół i program lepszy do tych samych zastosowań, to z wielką chęcią wymienię, bo nie ma sensu tkwić przy archaicznych, wadliwych i zawodnych rozwiązaniach, jak nie jest to konieczne.

Co do prywatnego użytku to jak ktoś lubi konfigurować sobie serwery i je utrzymywać, otwierać/blokować porty na routerze, nie potrzebuje wysokiej dostępności, uważa że robi to lepiej i bezpieczniej niż zespoły inżynierów Microsoftu czy Amazonu to niech to robi. Większość użytkowników jednak jest wygodna i woli korzystać z gotowych narzędzi, a te najlepiej obsługuje się poprzez HTTP bo każdy komputer i router domyślnie ma otwarte porty 80 i 443.

Ja nie uważam się za lepszego eksperta od inżynierów największych przedsiębiorstw informatycznych, powiedział bym nawet, że jestem amatorem, ale też jestem "wygodnym człowiekiem". Wyciągnąłem z piwnicy stary, nieużywany komputer, zainstalowałem FileZilla Server, założyłem login, hasło i do tego wskazałem konkretny katalog. Na routerze ustawiłem przekierowanie portów, założyłem domenę na no-ip, wpisałem logowanie do serwera na routerze, sprawdziłem, czy wszystko działa od wewnątrz, od zewnątrz i to wszystko. Prościej się chyba nie da.

Jedyny koszt utrzymania serwera to nieznacznie wyższe rachunki za prąd i niewielki dodatkowy hałas w mieszkaniu.

A jak chodzi o HTTP, to czy masz na myśli rozwiązania pracujące w przeglądarce, czy rozwiązania wykorzystujące klientów menedżerów plików? Czy chodzi o WebDav, czy coś jeszcze innego?

1

Niektóre rzeczy chyba muszą pozostać niepojęte :)
ja np. nie rozumiem dlaczego moje dzieci graja w Minecraft i im się ta gra podoba :D

nie rozumiem też po co powstał ten wątek, i dlaczego do jednego wora trafiają wszystkie usługi które potrafią przesłać plik
używa się tego co jest najbardziej odpowiednie do potrzeb/możliwości ,

ja pamiętam FTP jak coś co się strasznie sypało i sprawiało masę problemów,
do moich skromnych potrzeb to najczeście uzywam , scp, rsync i borg wszystko po SSH

0

Po co miałbym używać FTP? Chyba tylko do deploy'u paczek na server. Ale po co mam używać jak milion razy lepszy jest rysnc. A jak nie rsync to copy scp, jak nie to, to chyba bym się wolał zalogować po ssh i wrzucić tak. A nawet jak nie to to już wolałbym wrzucić kod na gita i zrobić git clone'a artefaktu. I może jak już żywcem nie miałbym opcji jak wrzucić, to może wtedy bym sięgnął po FTP, chociaż raczej nie.

0

FTP jest jak Winamp.

1

co jest powodem tego, że w niektórych zastosowaniach, do których FTP był specjalnie opracowany, stosuje się własnościowe aplikacje i protokoły (opracowane przez właściciela "chmury" i współpracujące tylko z tą chmurą).

Możesz podać jakiś przykład tych własnościowych protokołów bo pracuję już kilka lat jako architekt i inżynier chmurowy i pomijając jakieś szczególne przypadki to cała komunikacja z chmurą i jej usługami odbywa się poprzez ogólnie znane i dostępne protokoły jak SSH, FTP/SFTP, HTTP, VPNy (PPTP, IPSec, SSTP) itd.

Nawet jak dostawca udostępnia własną aplikację do pracy z chmurą taką jak Azure Data Studio to ona pod spodem korzysta z HTTP do komunikacji z API Azure. Nie ma tam żadnych własnościowych protokołów.

Ja nie uważam się za lepszego eksperta od inżynierów największych przedsiębiorstw informatycznych, powiedział bym nawet, że jestem amatorem, ale też jestem "wygodnym człowiekiem". Wyciągnąłem z piwnicy stary, nieużywany komputer, zainstalowałem FileZilla Server, założyłem login, hasło i do tego wskazałem konkretny katalog. Na routerze ustawiłem przekierowanie portów, założyłem domenę na no-ip, wpisałem logowanie do serwera na routerze, sprawdziłem, czy wszystko działa od wewnątrz, od zewnątrz i to wszystko. Prościej się chyba nie da.

Spoko, widać że cię to kręci i git. Ja na przykład mimo 12 lat pracy jako programista i architekt, nie wyobrażam sobie tego robić u siebie. To już nie te czasy. Wolę wrzucić plik na OneDrive czy coś podobnego, udostępnić komuś za pomocą jego adresu email i gotowe. A co ma powiedzieć typowa Grażyna albo Mietek, którzy chcą udostępnić swojemu bratu lub siostrze zdjęcia z pobytu na wakacjach. No chyba że bym przesyłał jakieś super tajne rzeczy, ale tu też można sobie z tym poradzić stosując odpowiednie szyfrowanie danych, których dostawca takiego wirtualnego dysku nie odszyfruje. Tu ciekawostka, że usługi końcowe klientów banku PKO BP łącznie z danymi siedzą sobie w chmurze Google (GCP) i wszystko jest zgodne z regulacjami prawnymi.

A jak chodzi o HTTP, to czy masz na myśli rozwiązania pracujące w przeglądarce, czy rozwiązania wykorzystujące klientów menedżerów plików?

Jedno i drugie. Aplikacje pracujące w przeglądarce takie jak Office 365 czy Google Workspace, muszą komunikować się z API na backendzie. Więc nie ważne czy jest to aplikacja webowa czy desktopowa, gdzieś tam zawsze jest backend który udostępnia swoją funkcjonalność za pomocą HTTP API i te aplikacje się z tym API komunikują po HTTP.

0
markone_dev napisał(a):

co jest powodem tego, że w niektórych zastosowaniach, do których FTP był specjalnie opracowany, stosuje się własnościowe aplikacje i protokoły (opracowane przez właściciela "chmury" i współpracujące tylko z tą chmurą).

Możesz podać jakiś przykład tych własnościowych protokołów bo pracuję już kilka lat jako architekt i inżynier chmurowy i pomijając jakieś szczególne przypadki to cała komunikacja z chmurą i jej usługami odbywa się poprzez ogólnie znane i dostępne protokoły jak SSH, FTP/SFTP, HTTP, VPNy (PPTP, IPSec, SSTP) itd.

Nawet jak dostawca udostępnia własną aplikację do pracy z chmurą taką jak Azure Data Studio to ona pod spodem korzysta z HTTP do komunikacji z API Azure. Nie ma tam żadnych własnościowych protokołów.

  1. Chomikuj
  2. Degoo
  3. Nazwa
  4. Tencent - nie wiem, czy aktualne, bo informacja sprzed 10 lat.

Wszystkie wyżej wymienione mają wspólne cechy: Brak informacji, jakim standardowym programem lub protokołem można się podłączyć, interfejs przeglądarkowy lub własnościowa aplikacja. Nawet, jeżeli pod spodem jest HTTP, a nawet REST API lub WSDL, to bez ichniego programu się nie obejdzie, a więc można powiedzieć, że zrobili własny protokół.

Znalazłem ranking chmur, ale przy żadnej nie ma informacji, z jakiego standardowego protokołu korzystają lub za pomocą jakiego programu (niezależnego od zarządcy chmury) można się podłączyć. Jako "standardowy protokół" rozumiem taki, że wpisze w google "ftp client" lub "ssh client" lub "WebDav client", czy jakikolwiek inny protokół ze słowem "client", to jakikolwiek program wezmę (i to taki, którego autor nie ma nic wspólnego z dostawcą chmury), będę mógł korzystać z dysku zdalnego.

Patrząc w drugą stronę, na przykład popularny program WinSCP obsługuje kilka protokołów dysku zdalnego, ale wątpię, żebym za pomocą tego programu mógł się podłączyć do wyżej wymienionych chmur.

Spoko, widać że cię to kręci i git. Ja na przykład mimo 12 lat pracy jako programista i architekt, nie wyobrażam sobie tego robić u siebie. To już nie te czasy. Wolę wrzucić plik na OneDrive czy coś podobnego, udostępnić komuś za pomocą jego adresu email i gotowe. A co ma powiedzieć typowa Grażyna albo Mietek, którzy chcą udostępnić swojemu bratu lub siostrze zdjęcia z pobytu na wakacjach. No chyba że bym przesyłał jakieś super tajne rzeczy, ale tu też można sobie z tym poradzić stosując odpowiednie szyfrowanie danych, których dostawca takiego wirtualnego dysku nie odszyfruje. Tu ciekawostka, że usługi końcowe klientów banku PKO BP łącznie z danymi siedzą sobie w chmurze Google (GCP) i wszystko jest zgodne z regulacjami prawnymi.>

Szyfrowanie to nie problem, przecież można skompresować pliki z hasłem, taką możliwość oferuje np. 7zip. Niedawno potrzebowałem udostępnić zdjęcia z wakacji takiej właśnie Grażynie, która też miała mi udostępnić swoje. Założyłem kolejny login na FTP, wgrałem swoje zdjęcia, podałem tej osobie adres, hasło i login. Ona nie wiedziała, co z tym zrobić, ale miała już zainstalowany Total Commander, tylko pół godziny tłumaczyłem, jak skonfigurować połączenie FTP. Jak się udało ustawić i połączyć, to poszło "z górki", bo w TC, katalog na FTP funkcjonuje tak samo, jak katalog na komputerze i kopiowanie plików w obie strony to już nie problem.

Kilka lat temu popularne były "hostingi", w których wprowadzało się plik, generowało się link i wysyłało się go drugiej osobie, która na podstawie tego linku mogła pobrać. Z tym, to taka Grażyna czy Mietek sobie poradzi, ale to jest dobre na jednorazową akcję, bo pobieranie jest celowo utrudnione (odczekanie kilka minut i sztucznie ograniczona prędkość transferu) i pliki znikają po jakimś czasie.

A jak chodzi o HTTP, to czy masz na myśli rozwiązania pracujące w przeglądarce, czy rozwiązania wykorzystujące klientów menedżerów plików?

Jedno i drugie. Aplikacje pracujące w przeglądarce takie jak Office 365 czy Google Workspace, muszą komunikować się z API na backendzie. Więc nie ważne czy jest to aplikacja webowa czy desktopowa, gdzieś tam zawsze jest backend który udostępnia swoją funkcjonalność za pomocą HTTP API i te aplikacje się z tym API komunikują po HTTP.

Przy aplikacji webowej jestem skazany na to, co wymyślił zarządca chmury, choć funkcjonalność jest coraz lepsza, ale np. trudno jest powiązać to z œłasnym oprogramowaniem. Natomiast przy apce desktopowej są dwa podejścia:

  1. Zarządca chmury tworzy własną aplikację, która podłącza się do chmury w nieopisany sposób, choć może to być REST API wykorzystujący HTTP. Jednakże za pomocą innej, niezależnej aplikacji nie ma możliwości podłączyć się do chmury.
  2. Zarządca chmury podaje do wiadomości, że dysk chmurowy wykorzystuje standardowy protokół transferu plików, np. SFTP, FTPS, WebDav, SSH, rsync, cokolwiek i że można podłączyć się standardowym klientem, który można znaleźć na każdy system, tylko wystarczy wpisać w google np. "rsync client linux" i już znajdzie się niejeden program obsługujący każdy serwer Rsync.
0
Adamek Adam napisał(a):

Niektóre rzeczy chyba muszą pozostać niepojęte :)
ja np. nie rozumiem dlaczego moje dzieci graja w Minecraft i im się ta gra podoba :D

W przypadku gier komputerowych nie ma gier obiektywnie lepszych i gorszych, dlatego jednym podoba się Minecraft, drugiemu Fortnite, trzeciemu CounterStrike i to nie podlega dyskusji.

Adamek Adam napisał(a):

nie rozumiem też po co powstał ten wątek, i dlaczego do jednego wora trafiają wszystkie usługi które potrafią przesłać plik
używa się tego co jest najbardziej odpowiednie do potrzeb/możliwości ,

Wątek powstał w celu uzyskania odpowiedzi na pytanie, dlaczego FTP odchodzi w niepamięć i czym powinien być zastąpiony. Wymienione zostały wady i bolączki FTP. Natomiast mi chodzi o protokoły będące zamiennikiem FTP, a nie koniecznie wszystkie, za pomocą których da się wysłać plik, pomimo, że nie do tego celu zostały wymyślone.

Kiedyś popularny był Peer2Mail, ale to wcale nie znaczy, że mogę powiedzieć, iż jedną z opcji transferu pliku jest protokół SMTP i POP3 jako alternatywa dla FTP.

Adamek Adam napisał(a):

ja pamiętam FTP jak coś co się strasznie sypało i sprawiało masę problemów,
do moich skromnych potrzeb to najczeście uzywam , scp, rsync i borg wszystko po SSH

Ja natomiast mam pozytywne wspomnienia, w 95% przypadków nie było takich problemów, jak zrywanie połączeń, pobieranie i wysyłanie plików do połowy, nadmierne obciążenie zasobów i łącza internetowego.

0

Wszystkie wyżej wymienione mają wspólne cechy: Brak informacji, jakim standardowym programem lub protokołem można się podłączyć, interfejs przeglądarkowy lub własnościowa aplikacja. Nawet, jeżeli pod spodem jest HTTP, a nawet REST API lub WSDL, to bez ichniego programu się nie obejdzie, a więc można powiedzieć, że zrobili własny protokół.

Nie. Po prostu nie udostępniają swojego API dla osób trzecich, czyli takich, które mogłyby sobie napisać swojego klienta. Pod spodem wszystko lata po HTTP więc nie ma mowy o żadnym własnym protokole. Protokołem do komunikacji jest HTTP. Gdybyś znał adres serwera i klucz uwierzytelniający to pewnie mógłbyś sobie sam napisać swojego klienta.

Znalazłem ranking chmur, ale przy żadnej nie ma informacji, z jakiego standardowego protokołu korzystają lub za pomocą jakiego programu (niezależnego od zarządcy chmury) można się podłączyć.

To źle szukasz. Każda z wiodących chmur (Azure, AWS, GCP) wystawia swoje API poprzez HTTP i możesz sobie napisać swojego klienta - dokumentacja API Azure https://learn.microsoft.com/en-us/rest/api/resources/

Przy aplikacji webowej jestem skazany na to, co wymyślił zarządca chmury, choć funkcjonalność jest coraz lepsza, ale np. trudno jest powiązać to z œłasnym oprogramowaniem.

Jeżeli udostępnia publiczne API (jak pokazałem wyżej każdy z wiodących dostawców to robi) to możesz sobie napisać własną aplikację desktopową, mobilną czy webową do pracy z chmurą.

Zarządca chmury tworzy własną aplikację, która podłącza się do chmury w nieopisany sposób, choć może to być REST API wykorzystujący HTTP. Jednakże za pomocą innej, niezależnej aplikacji nie ma możliwości podłączyć się do chmury.

Każdy dostawca chmury udostępnia swoje API w formie HTTP j/w. Dzięki temu powstają różne narzędzia open source do zarządzania infrastrukturą i aplikacjami w chmurze jak Terraform, Ansible, czy wszelakie SDK. Jak myślisz jak to byłoby możliwe gdyby nie publiczne i ogólnie dostępne API dostawców chmurowych na podstawie którego każdy może napisać swoją aplikację lub bibliotekę? Bez obrazy, ale widać jesteś do tyłu z technologią chmurową i tym co oferuje.

0

@markone_dev: Załóżmy, że wszyscy trzej (Azure, AWS, GCP) mają API po HTTP i udostępniają oficjalną dokumentację pozwalającą zaimplementować własnego klienta. Zaimplementuję własnego klienta, ale tylko w zakresie usług zdalnego dysku (bo chmura to nie tylko przechowalnia danych). Z jaką sytuacją będę miał do czynienia?

  1. Każdy program będzie współpracować tylko z jedną chmurą, bo każde API jest inne. To by znaczyło, że każda z firm, zamiast zastosować jakiś standardowy sposób, wymyśliła swoje API, niekompatybilne z niczym innym (sam fakt, że API jest po HTTP nie wystarczy, zestaw wywołań może się różnić). Jeżeli tak jest, to wracamy do sensu tego tematu: Po co oni wymyślają swoje API zamiast użyć powszechnie wykorzystywanych standardów?
  2. Programy będą kompatybilne ze sobą, pomimo, że każdy program jest na podstawie innej dokumentacji. Kompatybilność polegałaby na tym, że jednym i tym samym programem można podłączyć się do więcej niż jednej chmury. Jeżeli tak jest, to albo producenci się dogadali i wypracowali jakiś standard, albo wykorzystali któryś z powszechnie używanych standardów, np. WebDav, który też jest oparty na HTTP.

A może wprowadzanie i pobieranie plików odbywa się za pomocą standardowych metod HTTP, czyli PUT, GET, POST, DELETE i kilku innych przewidzianych w protokole HTTP?

A gdyby te duże firmy (Amazon, Microsoft, Google) nie miały dokumentacji, ale napisały, że "serwer wykorzystuje protokół RDP do zdalnej kontroli, RSYNC do wymiany plików", to ichnia dokumentacja nie byłaby potrzebna, bo są to standardy powszechnie opisane, tylko wpisać w google np. "rsync protocol documentation", a do tego, na 99,9% kolejna implementacja klienta nie byłaby potrzebna, bo wyjdzie ich kilkadziesiąt po wpisaniu "rsync client".

1

Myślę że tutaj temat trochę się rozdziela na dwa wątki, jeden to file storage dla deweloperów i biznesu, drugi dla przeciętnego użytkownika. Dostawcy chmurowi zapewniają SDK do swoich API i podłączenie się w danym języku jest względnie proste, deweloper nie musi nawet sam pisać wywołania metod, bo jest to często umieszczone za dostarczoną abstrakcją. Koszt napisania obsługi plików jest stosunkowo niski dzięki np. Azure SDK.

Natomiast dla przeciętnego użytkownika taki OneDrive czy Google Drive jest wygodniejszy, bo spięty z innymi usługami - Gmail, Outlook itp. Użytkownik robi zdjęcie telefonem, jednym kliknięciem wrzuca do chmury i gotowe, albo przeciąga pliki do przeglądarki czy folderu, jak w desktopowym OneDrive. To też pewnego rodzaju znak czasu, użytkownicy wrzucają głównie zdjęcia, wideo, ma być ładnie i multimedialnie, tak aby móc wygodnie udostępniać treści innym i wrzucać na socjale.

Jak napisał @LukeJL, FTP jest trochę Winamp. Sam używam Winampa, bo mam dużo albumów na dysku i jest to wygodne przy lokalnej bibliotece. Ale nie dziwię się, że takie Spotify czy Youtube innym wydają się wygodniejsze.

0
SkrzydlatyWąż napisał(a):

Myślę że tutaj temat trochę się rozdziela na dwa wątki, jeden to file storage dla deweloperów i biznesu, drugi dla przeciętnego użytkownika.

Jest to jak najbardziej możliwe, tym bardziej, że swój serwer FTP wykorzystuję zarówno do celów związanych z pracą, jak i do prywatnych. Przy rozważaniu nie zwracałem uwagi na rodzaj i wielkość przekazywanych danych, częstotliwość czynności, ani na to czy jest to czynność związana z pracą. W temacie nie rozważam całej funkcjonalności chmury, tylko funkcjonalność samego "file storage".

Dostawcy chmurowi zapewniają SDK do swoich API i podłączenie się w danym języku jest względnie proste, deweloper nie musi nawet sam pisać wywołania metod, bo jest to często umieszczone za dostarczoną abstrakcją. Koszt napisania obsługi plików jest stosunkowo niski dzięki np. Azure SDK.

No to jeszcze lepiej, nie ma większego znaczenia, czy to nazwiemy SDK, czy biblioteką. Jakiś czas temu potrzebowałem nietypowego klienta FTP (ze względu na rodzaj udostępnionych danych), znalazłem pierwszą lepszą bibliotekę do .NET i w jeden dzień zrealizowałem to, co potrzebuje. Podobnie, jak można to zrobić wykorzystując SDK. Ale zmienia to faktu, że apka wykorzystująca SDK od Google raczej nie będzie współpracować z Microsoft OneDrive i na odwrót. A gdyby Google i Microsoft wykorzystały istniejący standard, to jedna apka umiałaby korzystać z OneDrive, z GoogleDrive i jeszcze z innych "file storage". SDK nie byłby do tego potrzebny, bo do każdego typowego protokołu istnieje wiele niezależnych bibliotek ułatwiających wykorzystanie. Ale nie, i Google, i Microsoft musiał zrobić po swojemu, a z drugiej strony wypuścić SDK, żeby umożliwić korzystanie z tego. Biznesowo to też bez sensu, bo zarabiają na udostępnianiu miejsca na dysku, a nie na sprzedaży SDK.

Natomiast dla przeciętnego użytkownika taki OneDrive czy Google Drive jest wygodniejszy, bo spięty z innymi usługami - Gmail, Outlook itp. Użytkownik robi zdjęcie telefonem, jednym kliknięciem wrzuca do chmury i gotowe, albo przeciąga pliki do przeglądarki czy folderu, jak w desktopowym OneDrive. To też pewnego rodzaju znak czasu, użytkownicy wrzucają głównie zdjęcia, wideo, ma być ładnie i multimedialnie, tak aby móc wygodnie udostępniać treści innym i wrzucać na socjale.

Do wysłania paru zdjęć to storage w darmowym wydaniu jest wystarczający. To żaden problem wgrać kilka gigabajtów, poczekać, aż druga osoba pobierze i skasować. To powiązanie to tylko zamiana kilku czynności na jedną czynność, co staje się wygodniejsze. Słyszałem o przypadkach, ze IPhone ma taką funkcję, że zdjęcie jest wrzucane do chmury zaraz po jego zrobieniu. Wygodne, bo nic się nie traci w przypadku utraty lub usterki telefonu, ale to jest bardziej trochę popisywanie się Apple niż coś bardzo potrzebnego (chociaż przydatne w sytuacji, w której ryzyko utraty telefonu przed przyjazdem do domu jest spore).

Jak napisał @LukeJL, FTP jest trochę Winamp. Sam używam Winampa, bo mam dużo albumów na dysku i jest to wygodne przy lokalnej bibliotece. Ale nie dziwię się, że takie Spotify czy Youtube innym wydają się wygodniejsze.

To prawda, zaprzestanie rozwoju Winamp nie czyni tego programu gorszym, nawet jest bardzo dobrym programem i nie ma nic złego w korzystaniu z niego, także pod Linuxem (program WinAmp dobrze działa z WINE).

1

Używanie standardu w stylu protokołu rsynca jest słabym pomysłem, bo cloud storage to nie system plików. Do tego każdy cloud udostępnia dodatkowe ficzery. Jak sobie wyobrażasz taką implementację? Dostawca chmury implementuje część otwartego standardu (np. FTP) a reszta idzie po HTTP? Po co kombinować.

Co do tego samego interfejsu to jak zwykle to bywa: jak coś jest potrzebne to powstaje: https://rclone.org/

0

Jak to jest obecnie w hostingach, zarówno amatorskich, jak niegdyś republika.onet.pl i webpark.pl, jak i profesjonalnych, gdzie wykupuje się hosting w firmie serwerowej (ale nie serwer dedykowany, na którym instaluje się, co się chce)?

Dawniej, do tych celów wykorzystywało się właśnie FTP i wydawał się, że idealnie się do tego nadaje, bo chodzi o wrzucenie plików na serwer. Należało podłączyć FTP, wrzucić pliki i już. A jak się robiło zmiany, to nie trzeba było w całości, tylko wystarczyło zmieniany plik. Skoro od FTP się odchodzi z powodów wymienionych w tym wątku, to jaki protokół czy jakie narzędzie jest "na topie" w tym zastosowaniu? Czy tu używa się coś w rodzaju GIT lub SVN, czy coś innego? Jak się coś testuje, to nieraz na serwer aktualizację wrzuca się dziesiątki razy jednego dnia, więc rejestrowanie i opisywanie każdej aktualizacji nie ma żadnego sensu.

0

Niedawna sytuacja skłoniła mnie do podbicia tematu:

Musiałem szybko przenieść zdjęcie z telefonu na komputer. Łączę kablem, wybieram transfer plików, telefon zgłasza się, ale nie mogę wyświetlić jego zawartości. Nie chciało mi się szukać, co jest przyczyną problemu, może wystarczył restart komputera i telefonu.

Wykonałem transfer w najprostszy możliwy sposób dostępny dla mnie. W domu stoi serwer FTP. W telefonie mam zainstalowany darmowy klient FTP. Za pomocą tej apki wysyłam na serwer te pliki, które chcę wysłać. Następnie, w komputerze pobieram te pliki z serwera na dysk jakimś innym klientem FTP. Prościej chyba się już nie da, a serwer FTP uratował mnie. Tą samą metodą przenosiłem pliki między komputerem a telefonem w obie strony jakiś czas temu, kiedy miałem popsute złącze USB (możliwe było tylko ładowanie baterii, transfer danych już niemożliwy), a okazało się, że usterka była na płycie głównej i potrzebna była jej wymiana, czyli musiałem zachować wszystkie pliki, których nie chcę utracić.

To w takim razie pytanie: Jak najczęściej współcześnie wykonuje się wyżej opisaną czynność? Chodzi o transport plików między komputerem a telefonem bez bezpośredniego łączenia tych urządzeń ze sobą kablem lub bluetooth?

Opisany serwer FTP służy też do backupu najważniejszych dla mnie danych. Mam w nim ok. 700GB miejsca (dysk 1TB minus to, co zajmuje system i inne rzeczy na tym komputerze, bo FTP to nie jedyne jego zastosowanie). Jak będzie trzeba, to wymienię dysk na taki o większej pojemności (akurat w tym komputerze da się zamontować tylko jeden dysk 3,5 cala). Wydaję parę stów, instaluję system, przenoszę dane i zapominam o sprawie. Proszę pokazać mi coś ala Google Drive czy inną tego typu usługę, gdzie mogę mieć 500GB do dyspozycji bez regularnych opłat.

2

@andrzejlisek: Dodajesz plik w aplikacji, np. OneDrive w telefonie, w tle się synchronizuje. Otwierasz folder OneDrive w Windowsie, przeglądarce i masz pliki.

Samsung dawał 1 TB na OneDrive za założenie konta u siebie.

Edit - teraz jakieś 100 GB

Ludziom nie chce się bawić w kable, nawet bluetooth, wolą podpiąć kartę kredytową do subskrypcji, klikać kolorowy przycisk i gotowe.

0

@andrzejlisek: Total Commander legalny ?

0
SkrzydlatyWąż napisał(a):

Ludziom nie chce się bawić w kable, nawet bluetooth, wolą podpiąć kartę kredytową do subskrypcji, klikać kolorowy przycisk i gotowe.

No tak, łatwiej zapłacić niż samemu coś zrobić. Do tej pory myślałem, że podłączenie kabla raz w tygodniu na kilka minut to nie jest tak duży wysiłek, żeby bardziej opłacało się mieć subskrypcję.

Jak ktoś wymyśli technologię i usługę, że za opłatą miesięczną telefon pozostawiony na wierzchu sam się ładuje energią z fal radiowych (coś, jak niegdyś odbiorniki radiowe detektorowe, które nie miały zasilania, a jakoś grały), to też niektórzy się rzucą, bo za trudno jest wziąć kabel, zrobić kilka kroków i podłączyć telefon do prądu.

0

@andrzejlisek: Wiele rzeczy można zrobić samemu. Nasiona warzyw przykładowo kosztują kilka złotych, ziemia i woda też. Możesz mieć np. mnóstwo zdrowej sałaty w doniczkach za grosze, a jednak ludzie kupują skrawki sałaty, która przejechała prawie całą Europę spod folii w Hiszpanii.

Czemu tak jest? Z wielu powodów. Konsumentom nie chce się szukać wiedzy, lubią iść na łatwiznę, a regularny, niewielki wydatek z portfela mocno nie boli.

Rolnikowi sałata z folii może wydawać się irracjonalna, tak jak informatykowi niekorzystanie z FTP.

0
andrzejlisek napisał(a):

To w takim razie pytanie: Jak najczęściej współcześnie wykonuje się wyżej opisaną czynność? Chodzi o transport plików między komputerem a telefonem bez bezpośredniego łączenia tych urządzeń ze sobą kablem lub bluetooth?

Np. aplikacją tego typu: https://play.google.com/store/apps/details?id=com.smarterdroid.wififiletransfer&hl=pl&gl=US&pli=1

andrzejlisek napisał(a):

Do tej pory myślałem, że podłączenie kabla raz w tygodniu na kilka minut to nie jest tak duży wysiłek, żeby bardziej opłacało się mieć subskrypcję.

Wysiłek to jedno, ale chmura daje po prostu więcej. Masz kopię zapasową w innej lokalizacji, odporną na kradzież Twojego sprzętu, i przede wszystkim dostępną z innych urządzeń.

Jak ktoś wymyśli technologię i usługę, że za opłatą miesięczną telefon pozostawiony na wierzchu sam się ładuje energią z fal radiowych (coś, jak niegdyś odbiorniki radiowe detektorowe, które nie miały zasilania, a jakoś grały), to też niektórzy się rzucą, bo za trudno jest wziąć kabel, zrobić kilka kroków i podłączyć telefon do prądu.

Taka technologia już istnieje. :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1