Perchè HTTP è per ipertesti ed FTP no?

[Matrixbob]

Perchè HTTP dopo ogni trasmissione chiude la connessione ed FTP non la chiude?
Quindi a lungo andare ci sarebbe un collasso del Web?

In che senso dopo ogni connessione? Intendi dopo ogni Hit?

Esiste il KEEP ALIVE comunque.

[variabilepippo]

Perchè HTTP dopo ogni trasmissione chiude la connessione ed FTP non la chiude?

Perché una Fiat 500 può essere parcheggiata ovunque mentre con un Hummer potresti incontrare difficoltà nel trovare parcheggio nell'ora di punta? HTTP e FTP sono due protocolli pensati per soddisfare esigenze diverse, dunque funzionano in maniera diversa.

Quindi a lungo andare ci sarebbe un collasso del Web?

Perché?

[Matrixbob]

io nella mia tesina ho scritto così:

Prima del WWW di Tim Berners-Lee per l'accesso ai dati da remoto veniva impiegato il FTP (File Transfer Protocol), non molto idoneo per la navigazione attraverso gli ipertesti, in quanto le connessioni permanenti avrebbero portato al collasso il sistema. Per questo motivo si è dovuto introdurre un protocollo appositamente progettato per gli ipertesti, l'HTTP (HyperText Transfer Protocol).

Potete essere + esaurienti raga?

[variabilepippo]

Ti sei risposto da solo...

Potete essere + esaurienti raga

Ci sarebbe troppo da dire per un post in un forum, dovresti restringere un po' i termini del confronto tra FTP e HTTP.

[Matrixbob]

Originariamente inviato da Sgurbat

In che senso dopo ogni connessione? Intendi dopo ogni Hit?

Esiste il KEEP ALIVE comunque.

[EDIT] (CMQ io ho scritto trasmissione non connessione)

HTTP 1.1? o da sempre?
CMQ non sono ferratissimo sui protocolli, quindi non parlate troppo ambiguo o difficile plz

[Matrixbob]

Originariamente inviato da variabilepippo

Ti sei risposto da solo...

Ma è giusto almeno quanto dico?

Sarebbero tante connessioni FTP per ogni link premuto?

[airon]

Io non ho ancora capito quale sia il problema.
Sono due protocolli inventati per due sigenze diverse. La tua frase della tesina quindi per me non ha alcun senso.

Il timeout o il mantenimento della connessione non sono mai propri del protocollo ma è una cosa che si fa a livello sistema operativ o o a livello applicativo.

[71104]

Originariamente inviato da airon

Il timeout o il mantenimento della connessione non sono mai propri del protocollo ma è una cosa che si fa a livello sistema operativ o o a livello applicativo.

in genere è così, ma nulla vieta che un protocollo stabilisca dei limiti in termini di timeout o di mantenimento della connessione.

[Therock2709]

Originariamente inviato da Matrixbob

Perchè HTTP dopo ogni trasmissione chiude la connessione ed FTP non la chiude?
Quindi a lungo andare ci sarebbe un collasso del Web?

In realtà FTP apre 2 connessioni per sessione: una per il controllo remoto (navigazione cartelle, richiesta file, ecc...) che rimane aperta finché non si chiude la sessione, mentre la seconda connessione viene aperta per il trasferimento vero e proprio di ogni file e subito dopo viene chiusa.

In pratica se tu devi scaricare 5 file, il client apre una connessione e la lascia attiva x il controllo e inoltre apre-e-chiude 5 connessioni.

[Matrixbob]

Originariamente inviato da airon

Io non ho ancora capito quale sia il problema.
Sono due protocolli inventati per due sigenze diverse. La tua frase della tesina quindi per me non ha alcun senso.

Il timeout o il mantenimento della connessione non sono mai propri del protocollo ma è una cosa che si fa a livello sistema operativ o o a livello applicativo.

Ma come fai a non capire?
Devo spiegare perchè nel Web (NON Internet) si utilizza HTTP e non il vecchio FTP, che ovviamente è tutt'oggi usato, ma non x la navigazione tra ipertesti.

Adesso è chiaro o hai preferenze linguistiche?

[Matrixbob]

Originariamente inviato da 71104

in genere è così, ma nulla vieta che un protocollo stabilisca dei limiti in termini di timeout o di mantenimento della connessione.

Infatti, protocollo significa appunto insieme di regole.
So che HTTP è stateless, quindi da questo suppongo che all'ultimo pacchetto della sua trsmissione farà una chiusura della connessione.

Altrimenti non mi spiego lo stateless e nemmeno il perchè sia stato inventato.

[airon]

Originariamente inviato da 71104

in genere è così, ma nulla vieta che un protocollo stabilisca dei limiti in termini di timeout o di mantenimento della connessione.

Si certo io parlavo in linea generale e a quanto ne so i protocolli ftp e http non hanno questo funzionalità (a parte l'opzione keep-alive dell'http che deve essere cmq implementata e attiva sul serverweb e lato client). Anche perchè piu' connessioni "aperte" si tengono piu' son cazzi

[Matrixbob]

Originariamente inviato da Therock2709

In realtà FTP apre 2 connessioni per sessione: una per il controllo remoto (navigazione cartelle, richiesta file, ecc...) che rimane aperta finché non si chiude la sessione, mentre la seconda connessione viene aperta per il trasferimento vero e proprio di ogni file e subito dopo viene chiusa.

In pratica se tu devi scaricare 5 file, il client apre una connessione e la lascia attiva x il controllo e inoltre apre-e-chiude 5 connessioni.

Ecco, ora ci siamo.
Ragionando in FTP:
Quindi se io sono arrivo su 1 sito inizio la sessione.
Poi ogni pagina che apro (cioè scarico 1 file.html) apro una connessione.
Se visito 10 pagine sono 10 connessioni?
Se arriva un'altro utente che fa come me sono 20 connessioni?

Le connessioni sono 1 per porta? Io direi che sono sulla stessa porta 80/8080, solo che non so effettivamente l'entità connessione come sia fatta.

[variabilepippo]

Ragionando in FTP:
Quindi se io sono arrivo su 1 sito inizio la sessione.
Poi ogni pagina che apro (cioè scarico 1 file.html) apro una connessione.

Con il protocollo FTP ti connetti ad un server FTP e non ad un web-server, di conseguenza non ha molto senso parlare di pagine HTML ed hyperlink assortiti.

[marco.r]

Originariamente inviato da Matrixbob

Ma come fai a non capire?
Devo spiegare perchè nel Web (NON Internet) si utilizza HTTP e non il vecchio FTP, che ovviamente è tutt'oggi usato, ma non x la navigazione tra ipertesti.

Adesso è chiaro o hai preferenze linguistiche?

Perche' il protocollo FTp e' stato pensato per il File Transfer mentre l'HTtp per l'HyperText ? .
L'ftp permette appunto solo il trasferimento di file, che puo' andare bene solo finche' fai uso di pagine statiche. Ma quando devi recuperare pagine dinamiche ? Fare un POST ? E i cookies ? Autenticazioni diverse su parti diverse di uno stesso sito ? Ti immagini se il forum di hwupgrade fosse implementato tramite ftp ? Rabbrividisco al solo pensiero...
Il motivo per cui l'FTP e' sopravvisuto e' perche' costituisce un modo abbastanza semplice per poter fare l'upload di file su di un archivio comune, ma per quel che riguarda per me puo' tranquillamente morire e' intrinsecamente insicuro e pensato per una Rete diversa da quella odierna (una occhiata a wikipedia ti dara un po' di esempi su quel che voglio dire).

[Matrixbob]

Leggendo su Wikipedia direi che è un casino da matti 1 connessione FTP:

L'FTP usa il TCP per creare una connessione per le informazioni di controllo (detta out of band in quanto 'secondaria' a quella dati), poi crea una seconda connessione sempre TCP per il trasferimento dei dati. La connessione di controllo usa telnet per scambiare comandi e messaggi tra host. Per effettuare una connessione c'è bisogno che ci sia un server in ascolto sulla porta 21 (porta di default per la connessione out of band) e in seguito alla richiesta c'è bisogno di mandare informazioni riguardanti l'autenticazione, in genere login e password.

Burocratica, lenta e bella pesante!
I server si infosserebbero per le continue autenticazioni ed esecuzioni di comandi (anche se automatizzate).
Poi tutti in coda sulla porta 21 se c'è casino?
E' proprio il meccanismo che direi non andare.
Giusto?

Come lo riassumereste in poche parole?
Come dico io burocratico, lento e pesante?

[airon]

Originariamente inviato da marco.r

Perche' il protocollo FTp e' stato pensato per il File Transfer mentre l'HTtp per l'HyperText ? .
L'ftp permette appunto solo il trasferimento di file, che puo' andare bene solo finche' fai uso di pagine statiche. Ma quando devi recuperare pagine dinamiche ? Fare un POST ? E i cookies ? Autenticazioni diverse su parti diverse di uno stesso sito ? Ti immagini se il forum di hwupgrade fosse implementato tramite ftp ? Rabbrividisco al solo pensiero...
Il motivo per cui l'FTP e' sopravvisuto e' perche' costituisce un modo abbastanza semplice per poter fare l'upload di file su di un archivio comune, ma per quel che riguarda per me puo' tranquillamente morire e' intrinsecamente insicuro e pensato per una Rete diversa da quella odierna (una occhiata a wikipedia ti dara un po' di esempi su quel che voglio dire).

Sono due protocolli diversi nati per scopi diversi. Stop. Non c'è nessuna questione prestazionale lato server o lato client.

[airon]

Originariamente inviato da Matrixbob

Leggendo su Wikipedia direi che è un casino da matti 1 connessione FTP:

Burocratica e bella pesante!
I server si infosserebbero per le continue autenticazioni ed esecuzioni di comandi (anche se automatizzate).
Poi tutti in coda sulla porta 21 se c'è casino?
E' proprio il meccanismo che direi non andare.
Giusto?

Come lo riassumereste in poche parole?
Come dico io burocratico, lento e pesante?

Scusa ma che cavolo fai una tesina su un argomento che non sai?? Che sara' mai una connessione ftp...Coda sulla porta 21?? Bah...non offenderti pero' eh.

[Matrixbob]

Originariamente inviato da variabilepippo

Con il protocollo FTP ti connetti ad un server FTP e non ad un web-server, di conseguenza non ha molto senso parlare di pagine HTML ed hyperlink assortiti.

Si ho capito, ma il webserver lo hanno fatto in coppiata al HTTP. Avrebbero potuto modificare leggermente un ftpserver e via.
Questa mi pare una scusante, più che altro.