Matrixbob
01-11-2007, 18:43
Perchè HTTP dopo ogni trasmissione chiude la connessione ed FTP non la chiude?
Quindi a lungo andare ci sarebbe un collasso del Web?
Quindi a lungo andare ci sarebbe un collasso del Web?
View Full Version : Perchè HTTP è per ipertesti ed FTP no?
anonimizzato
01-11-2007, 18:47
In che senso dopo ogni connessione? Intendi dopo ogni Hit?
Esiste il KEEP ALIVE comunque.
Esiste il KEEP ALIVE comunque.
variabilepippo
01-11-2007, 18:51
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é?
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
01-11-2007, 18:52
:boh: 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? :(
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
01-11-2007, 18:53
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.
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
01-11-2007, 18:57
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 :(
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
01-11-2007, 18:58
Ti sei risposto da solo... ;)
Ma è giusto almeno quanto dico?
Sarebbero tante connessioni FTP per ogni link premuto?
Ma è giusto almeno quanto dico?
Sarebbero tante connessioni FTP per ogni link premuto?
airon
01-11-2007, 19:41
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.
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
01-11-2007, 19:53
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
01-11-2007, 19:53
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. ;)
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
01-11-2007, 20:04
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? :D
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? :D
Matrixbob
01-11-2007, 20:06
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. :boh:
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. :boh:
airon
01-11-2007, 20:07
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 :D
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 :D
Matrixbob
01-11-2007, 20:11
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. :)
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
01-11-2007, 20:16
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.
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
01-11-2007, 20:18
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? :D
Perche' il protocollo FTp e' stato pensato per il File Transfer mentre l'HTtp per l'HyperText ? :D.
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... :D
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).
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? :D
Perche' il protocollo FTp e' stato pensato per il File Transfer mentre l'HTtp per l'HyperText ? :D.
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... :D
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
01-11-2007, 20:19
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?
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
01-11-2007, 20:24
Perche' il protocollo FTp e' stato pensato per il File Transfer mentre l'HTtp per l'HyperText ? :D.
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... :D
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).
:read: :read:
Sono due protocolli diversi nati per scopi diversi. Stop. Non c'è nessuna questione prestazionale lato server o lato client.
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... :D
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).
:read: :read:
Sono due protocolli diversi nati per scopi diversi. Stop. Non c'è nessuna questione prestazionale lato server o lato client.
airon
01-11-2007, 20:26
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. :)
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
01-11-2007, 20:26
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.
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.
Matrixbob
01-11-2007, 20:28
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. :)
Ah perchè tu se fai una testi su un macro argomento diverso sai tutto delle cose tangenti ad esso?
Un fenomeno sei praticamente, complimenti!
Ma poi non preoccuparti di questo, o non rispondi o rispondi in topic.
C'è altro da guardare nella sezione programmazione.
Grazie.
Ah perchè tu se fai una testi su un macro argomento diverso sai tutto delle cose tangenti ad esso?
Un fenomeno sei praticamente, complimenti!
Ma poi non preoccuparti di questo, o non rispondi o rispondi in topic.
C'è altro da guardare nella sezione programmazione.
Grazie.
Matrixbob
01-11-2007, 20:32
Perche' il protocollo FTp e' stato pensato per il File Transfer mentre l'HTtp per l'HyperText ? :D.
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... :D
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).
Ignorate airon magari, fa + caos che altro.
Qui forse mi illumini.
Quindi tu pensi che al CERN avesero già in mente tutte queste cose?
Quindi diciamo che se il Web deve essere un middleware deve permettere appunto quelle possibilità rappresentate da POST, GET, Cockies, ecc?
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... :D
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).
Ignorate airon magari, fa + caos che altro.
Qui forse mi illumini.
Quindi tu pensi che al CERN avesero già in mente tutte queste cose?
Quindi diciamo che se il Web deve essere un middleware deve permettere appunto quelle possibilità rappresentate da POST, GET, Cockies, ecc?
airon
01-11-2007, 20:36
Ah perchè tu se fai una testi su un macro argomento diverso sai tutto delle cose tangenti ad esso?
Un fenomeno sei praticamente, complimenti!
Ma poi non preoccuparti di questo, o non rispondi o rispondi in topic.
Grazie.
Ti è gia stata data una risposta ma tu continui imperterrito a dire castronerie. Vai quà e la su internet prendendo stralci di informazioni e le interpreti a modo tuo, sbagliato tra l'altro.
Ripeto, sono due protocolli diversi che svolgono funzionalità diverse. Stop. Non ce altro da sapere.
Un fenomeno sei praticamente, complimenti!
Ma poi non preoccuparti di questo, o non rispondi o rispondi in topic.
Grazie.
Ti è gia stata data una risposta ma tu continui imperterrito a dire castronerie. Vai quà e la su internet prendendo stralci di informazioni e le interpreti a modo tuo, sbagliato tra l'altro.
Ripeto, sono due protocolli diversi che svolgono funzionalità diverse. Stop. Non ce altro da sapere.
nuovoUtente86
01-11-2007, 20:43
Fare un confronto fra http e ftp ha poco senso...è come dire che a calcio non si gioca con le mani e nel volley si....l' ftp non è altro(semplificando molto) che la gestione di un "hard disk" su macchina remota,mentre oggi l' http serve per gestire pagine per lo piu dinamiche alle quali vanno passati dati con i metodi post o get.
Per inteso non è neppure vero quello che dici ovvero che Http preveda la chiusura della connessione tcp dopo la risposta del server.Questo era vero con l' implementazione 1.0 ma con la 1.1 la connessione rimane aperta per ulteriori per ulteriori richieste-risposte .
Come ti è stato detto l' ftp richiede in realtà 2 connessioni:1 di controllo sulla porta 21 e una di traffico dati sulla 20.
Per inteso non è neppure vero quello che dici ovvero che Http preveda la chiusura della connessione tcp dopo la risposta del server.Questo era vero con l' implementazione 1.0 ma con la 1.1 la connessione rimane aperta per ulteriori per ulteriori richieste-risposte .
Come ti è stato detto l' ftp richiede in realtà 2 connessioni:1 di controllo sulla porta 21 e una di traffico dati sulla 20.
Matrixbob
01-11-2007, 20:44
Ti è gia stata data una risposta ma tu continui imperterrito a dire castronerie. Vai quà e la su internet prendendo stralci di informazioni e le interpreti a modo tuo, sbagliato tra l'altro.
Ripeto, sono due protocolli diversi che svolgono funzionalità diverse. Stop. Non ce altro da sapere.
Ancora? Insisti? Ok che sei libero di rispondere quanto vuoi finchè non spacchi il mouse, ma per piacere basta.
Sei proprio cafone ed inutile.
Poi quando un servizio od un processo non può accedere alla risorsa e c'è un meccanismo per metterlo in attesa senza farti ritornare l'errore o il problema tu come lo chiami?
Io lo astraggo con "in coda".
Inoltre se 1 individuo non ha le idee chiare cerca ulteriori spiegazioni fichè non capisce, o almeno finchè non incontra un altro individuo nullificante come te, che rende il risutato = 0.
Ripeto, sono due protocolli diversi che svolgono funzionalità diverse. Stop. Non ce altro da sapere.
Ancora? Insisti? Ok che sei libero di rispondere quanto vuoi finchè non spacchi il mouse, ma per piacere basta.
Sei proprio cafone ed inutile.
Poi quando un servizio od un processo non può accedere alla risorsa e c'è un meccanismo per metterlo in attesa senza farti ritornare l'errore o il problema tu come lo chiami?
Io lo astraggo con "in coda".
Inoltre se 1 individuo non ha le idee chiare cerca ulteriori spiegazioni fichè non capisce, o almeno finchè non incontra un altro individuo nullificante come te, che rende il risutato = 0.
71104
01-11-2007, 20:47
OT: mi è venuto in mente che esiste il fenomeno inverso a quello discusso in questo thread, ovvero esiste un protocollo per il file transfer basato su HTTP: WebDAV :D
che vantaggi ci sono secondo voi nell'utilizzare WebDAV anziché FTP? questa questione ha molto più senso e mi interessa; se non volete discuterne qui apro un altro thread.
che vantaggi ci sono secondo voi nell'utilizzare WebDAV anziché FTP? questa questione ha molto più senso e mi interessa; se non volete discuterne qui apro un altro thread.
Matrixbob
01-11-2007, 20:49
Fare un confronto fra http e ftp ha poco senso...è come dire che a calcio non si gioca con le mani e nel volley si....l' ftp non è altro(semplificando molto) che la gestione di un "hard disk" su macchina remota,mentre oggi l' http serve per gestire pagine per lo piu dinamiche alle quali vanno passati dati con i metodi post o get.
Per inteso non è neppure vero quello che dici ovvero che Http preveda la chiusura della connessione tcp dopo la risposta del server.Questo era vero con l' implementazione 1.0 ma con la 1.1 la connessione rimane aperta per ulteriori per ulteriori richieste-risposte .
Come di è stato detto l' ftp richiede in realtà 2 connessioni:1 di controllo sulla porta 21 e una di traffico dati sulla 20.
Riguardo al HTTP:
quindi diciamo che il client comunica col server, nel senso che invia informazioni sulla base del quel il server gliene elabora e rinvia delle altre.
Riguardo l'FTP:
il client chiede qualla informazione ed il server gliela invia a mo di dettato e stop.
+/- astrattamente funziona così?
Per inteso non è neppure vero quello che dici ovvero che Http preveda la chiusura della connessione tcp dopo la risposta del server.Questo era vero con l' implementazione 1.0 ma con la 1.1 la connessione rimane aperta per ulteriori per ulteriori richieste-risposte .
Come di è stato detto l' ftp richiede in realtà 2 connessioni:1 di controllo sulla porta 21 e una di traffico dati sulla 20.
Riguardo al HTTP:
quindi diciamo che il client comunica col server, nel senso che invia informazioni sulla base del quel il server gliene elabora e rinvia delle altre.
Riguardo l'FTP:
il client chiede qualla informazione ed il server gliela invia a mo di dettato e stop.
+/- astrattamente funziona così?
Matrixbob
01-11-2007, 20:50
OT: mi è venuto in mente che esiste il fenomeno inverso a quello discusso in questo thread, ovvero esiste un protocollo per il file transfer basato su HTTP: WebDAV :D
che vantaggi ci sono secondo voi nell'utilizzare WebDAV anziché FTP? questa questione ha molto più senso e mi interessa; se non volete discuterne qui apro un altro thread.
Magari meglio che ne apri un'altra sai..:fagiano:
che vantaggi ci sono secondo voi nell'utilizzare WebDAV anziché FTP? questa questione ha molto più senso e mi interessa; se non volete discuterne qui apro un altro thread.
Magari meglio che ne apri un'altra sai..:fagiano:
Matrixbob
01-11-2007, 20:52
Fare un confronto fra http e ftp ha poco senso...è come dire che a calcio non si gioca con le mani e nel volley si....l' ftp non è altro(semplificando molto) che la gestione di un "hard disk" su macchina remota,mentre oggi l' http serve per gestire pagine per lo piu dinamiche alle quali vanno passati dati con i metodi post o get.
Per inteso non è neppure vero quello che dici ovvero che Http preveda la chiusura della connessione tcp dopo la risposta del server.Questo era vero con l' implementazione 1.0 ma con la 1.1 la connessione rimane aperta per ulteriori per ulteriori richieste-risposte .
Come ti è stato detto l' ftp richiede in realtà 2 connessioni:1 di controllo sulla porta 21 e una di traffico dati sulla 20.
Almeno capisco che il problema non è il numero delle connessioni giusto?
Il problema sta nelle capacità di un protocollo giusto?
Se HTTP è nato x quello allora naturalmente ha quella capacità, giusto?
Tutto qui?
Per inteso non è neppure vero quello che dici ovvero che Http preveda la chiusura della connessione tcp dopo la risposta del server.Questo era vero con l' implementazione 1.0 ma con la 1.1 la connessione rimane aperta per ulteriori per ulteriori richieste-risposte .
Come ti è stato detto l' ftp richiede in realtà 2 connessioni:1 di controllo sulla porta 21 e una di traffico dati sulla 20.
Almeno capisco che il problema non è il numero delle connessioni giusto?
Il problema sta nelle capacità di un protocollo giusto?
Se HTTP è nato x quello allora naturalmente ha quella capacità, giusto?
Tutto qui?
Matrixbob
01-11-2007, 20:57
Quindi mi confermate che queste scritte su Wikipedia sono cazzate:
HTTP differisce da altri protocolli di livello 7 come FTP, per il fatto che le connessioni vengono generalmente chiuse una volta che una particolare richiesta (o una serie di richieste correlate) è stata soddisfatta. Questo comportamento rende il protocollo HTTP ideale per il World Wide Web, in cui le pagine molto spesso contengono dei collegamenti (link) a pagine ospitate da altri server. Talvolta però pone problemi agli sviluppatori di contenuti web, perché la natura senza stato (stateless) costringe ad utilizzare dei metodi alternativi per conservare lo stato dell'utente. Spesso questi metodi si basano sull'uso dei cookie .
HTTP differisce da altri protocolli di livello 7 come FTP, per il fatto che le connessioni vengono generalmente chiuse una volta che una particolare richiesta (o una serie di richieste correlate) è stata soddisfatta. Questo comportamento rende il protocollo HTTP ideale per il World Wide Web, in cui le pagine molto spesso contengono dei collegamenti (link) a pagine ospitate da altri server. Talvolta però pone problemi agli sviluppatori di contenuti web, perché la natura senza stato (stateless) costringe ad utilizzare dei metodi alternativi per conservare lo stato dell'utente. Spesso questi metodi si basano sull'uso dei cookie .
nuovoUtente86
01-11-2007, 20:57
La generazione di una pagina web funziona pressoche cosi:
il client invia la richiesta contenente eventualmente i dati richiesti secondo i metodi prevesti dall' implementazione,il server la elabora attraverso un' interfaccia CGI e la restituisce al client.Secondo http 1.0 ora termina la sessione e la connessione TCP va terminata per come il protocollo prevede.Secondo gli standard successivi la connessione rimane aperta e il client puo chiedere altro.
Ftp:il client ove previsto si logga ed accede ad un file system remoto dove prelevare file di testo o binari.Stop
il client invia la richiesta contenente eventualmente i dati richiesti secondo i metodi prevesti dall' implementazione,il server la elabora attraverso un' interfaccia CGI e la restituisce al client.Secondo http 1.0 ora termina la sessione e la connessione TCP va terminata per come il protocollo prevede.Secondo gli standard successivi la connessione rimane aperta e il client puo chiedere altro.
Ftp:il client ove previsto si logga ed accede ad un file system remoto dove prelevare file di testo o binari.Stop
71104
01-11-2007, 20:59
Magari meglio che ne apri un'altra sai..:fagiano: attendo risposte disinteressate :ciapet:
Matrixbob
01-11-2007, 21:00
La generazione di una pagina web funziona pressoche cosi:
il client invia la richiesta contenente eventualmente i dati richiesti secondo i metodi prevesti dall' implementazione,il server la elabora attraverso un' interfaccia CGI e la restituisce al client.Secondo http 1.0 ora termina la sessione e la connessione TCP va terminata per come il protocollo prevede.Secondo gli standard successivi la connessione rimane aperta e il client puo chiedere altro.
Ma quando cade la connessione TCP a quel webserver allora?
Quando cambio URI il browser gli manda qualche segnale al webserver o va in timeout il webserver?:confused: :confused: :confused:
il client invia la richiesta contenente eventualmente i dati richiesti secondo i metodi prevesti dall' implementazione,il server la elabora attraverso un' interfaccia CGI e la restituisce al client.Secondo http 1.0 ora termina la sessione e la connessione TCP va terminata per come il protocollo prevede.Secondo gli standard successivi la connessione rimane aperta e il client puo chiedere altro.
Ma quando cade la connessione TCP a quel webserver allora?
Quando cambio URI il browser gli manda qualche segnale al webserver o va in timeout il webserver?:confused: :confused: :confused:
airon
01-11-2007, 21:00
Almeno capisco che il problema non è il numero delle connessioni giusto?
Il problema sta nelle capacità di un protocollo giusto?
Se HTTP è nato x quello allora naturalmente ha quella capacità, giusto?
Tutto qui?
Eureka!! Finalmente hai capito. :D
Il problema sta nelle capacità di un protocollo giusto?
Se HTTP è nato x quello allora naturalmente ha quella capacità, giusto?
Tutto qui?
Eureka!! Finalmente hai capito. :D
nuovoUtente86
01-11-2007, 21:02
Quindi mi confermate che queste scritte su Wikipedia sono cazzate:
se la leggi non conoscendo il protocolllo ti crea solo confusione perchè è scritto malissimo e non è di certo la fonte migliore e pramaria per queste informazioni.
Leggendola conoscendo il protocollo ne cogli il senso.Ti dice facendo un mix ch la connessione viene chiusa ad ogni risposta(HTTP 1.0) o dopo varie risposte(http 1.1).
Perchè non chiede subito la connessione:perchè instaurare un tcp richiede la procedura chiamae 3-way-handshake che cmq utilizza tempo e risorsa
se la leggi non conoscendo il protocolllo ti crea solo confusione perchè è scritto malissimo e non è di certo la fonte migliore e pramaria per queste informazioni.
Leggendola conoscendo il protocollo ne cogli il senso.Ti dice facendo un mix ch la connessione viene chiusa ad ogni risposta(HTTP 1.0) o dopo varie risposte(http 1.1).
Perchè non chiede subito la connessione:perchè instaurare un tcp richiede la procedura chiamae 3-way-handshake che cmq utilizza tempo e risorsa
71104
01-11-2007, 21:03
Eureka!! Finalmente hai capito. :D
ora possiamo parlare del WebDAV :stordita:
ora possiamo parlare del WebDAV :stordita:
nuovoUtente86
01-11-2007, 21:04
Ma quando cade la connessione TCP a quel webserver allora?
Quando cambio URI il browser gli manda qualche segnale al webserver o va in timeout il webserver?:confused: :confused: :confused:
quando cambi url cade di certo...quando il webserver ti butta via lo decide in base alla sua implementazione...ma non dipende strettamente da http.
Quando cambio URI il browser gli manda qualche segnale al webserver o va in timeout il webserver?:confused: :confused: :confused:
quando cambi url cade di certo...quando il webserver ti butta via lo decide in base alla sua implementazione...ma non dipende strettamente da http.
Matrixbob
01-11-2007, 21:07
Browser!
GET /wiki/Pagina_principale HTTP/1.1
Connection: Keep-Alive
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: en
Host: it.wikipedia.org
>>? DATI DI RICHIESTA ?<<
(a capo)(a capo)
Webserver!
HTTP/1.0 200 OK
Date: Mon, 28 Jun 2004 10:47:31 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4
X-Powered-By: PHP/4.3.4
Vary: Accept-Encoding,Cookie
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Content-Language: it
Content-Type: text/html; charset=utf-8
Age: 7673
X-Cache: HIT from wikipedia.org
Connection: close
>>? DATI DI RISPOSTA ?<<
I dati sarano in ASCII o Unicode immagino ...
GET /wiki/Pagina_principale HTTP/1.1
Connection: Keep-Alive
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: en
Host: it.wikipedia.org
>>? DATI DI RICHIESTA ?<<
(a capo)(a capo)
Webserver!
HTTP/1.0 200 OK
Date: Mon, 28 Jun 2004 10:47:31 GMT
Server: Apache/1.3.29 (Unix) PHP/4.3.4
X-Powered-By: PHP/4.3.4
Vary: Accept-Encoding,Cookie
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Content-Language: it
Content-Type: text/html; charset=utf-8
Age: 7673
X-Cache: HIT from wikipedia.org
Connection: close
>>? DATI DI RISPOSTA ?<<
I dati sarano in ASCII o Unicode immagino ...
airon
01-11-2007, 21:10
ora possiamo parlare del WebDAV :stordita:
In pratica WebDAV è una serie di estensioni fatte al protocollo http per permettere di gestire in maniera piu' efficace la condivisione e la gestione di file
tramite internet. La pagina di wikipedia è ben fatta. Non come quella su http e ftp. :D
In pratica WebDAV è una serie di estensioni fatte al protocollo http per permettere di gestire in maniera piu' efficace la condivisione e la gestione di file
tramite internet. La pagina di wikipedia è ben fatta. Non come quella su http e ftp. :D
nuovoUtente86
01-11-2007, 21:17
Browser!
Webserver!
I dati sarano in ASCII o Unicode immagino ...
in questo caso la connessione sara chiusa e riaperta ad ogni richiesta.
dove ha preso queste intestazioni ?
Webserver!
I dati sarano in ASCII o Unicode immagino ...
in questo caso la connessione sara chiusa e riaperta ad ogni richiesta.
dove ha preso queste intestazioni ?
airon
01-11-2007, 21:17
Browser!
Webserver!
I dati sarano in ASCII o Unicode immagino ...
Leggere le rfc no eh??
Si mi piace punzecchiarti :D
La richiesta il browser la fa con la prima riga
GET Uri Protocollo
Il server risponde con
Protocollo ok/errore
E successivamente la pagina
Se noti.
Tu stai usando ktml che supporta http 1.1 infatti richiedi una connessione keep-alive.
Il server risponde che è solo http 1.0 quindi setta la connessione su close.
Webserver!
I dati sarano in ASCII o Unicode immagino ...
Leggere le rfc no eh??
Si mi piace punzecchiarti :D
La richiesta il browser la fa con la prima riga
GET Uri Protocollo
Il server risponde con
Protocollo ok/errore
E successivamente la pagina
Se noti.
Tu stai usando ktml che supporta http 1.1 infatti richiedi una connessione keep-alive.
Il server risponde che è solo http 1.0 quindi setta la connessione su close.
Matrixbob
01-11-2007, 21:22
in questo caso la connessione sara chiusa e riaperta ad ogni richiesta.
dove ha preso queste intestazioni ?
Ma dammi pure del tu dai! L:DL
Le ho prese da Wikipedia dopo evere visto che sono sensate.
Solo mi chiedevo dove cavolo e come cavolo erano fatti i dati annessi al pacchetto. :O
dove ha preso queste intestazioni ?
Ma dammi pure del tu dai! L:DL
Le ho prese da Wikipedia dopo evere visto che sono sensate.
Solo mi chiedevo dove cavolo e come cavolo erano fatti i dati annessi al pacchetto. :O
Matrixbob
01-11-2007, 21:24
Leggere le rfc no eh??
Si mi piace punzecchiarti :D
La richiesta il browser la fa con la prima riga
GET Uri Protocollo
Il server risponde con
Protocollo ok/errore
E successivamente la pagina
Se noti.
Tu stai usando ktml che supporta http 1.1 infatti richiedi una connessione keep-alive.
Il server risponde che è solo http 1.0 quindi setta la connessione su close.
Quello l'ho visto, mi sto chiedendo come dove sono i dati nel pacchetto.
Sono in append?
IMHO sono in chiaro ed in append, altrimenti non mi spiego la possibilità di criptarli.
Si mi piace punzecchiarti :D
La richiesta il browser la fa con la prima riga
GET Uri Protocollo
Il server risponde con
Protocollo ok/errore
E successivamente la pagina
Se noti.
Tu stai usando ktml che supporta http 1.1 infatti richiedi una connessione keep-alive.
Il server risponde che è solo http 1.0 quindi setta la connessione su close.
Quello l'ho visto, mi sto chiedendo come dove sono i dati nel pacchetto.
Sono in append?
IMHO sono in chiaro ed in append, altrimenti non mi spiego la possibilità di criptarli.
nuovoUtente86
01-11-2007, 21:31
la ichiesta è in ASCII mentre la risposta è in rfc 822
I dati nella richiesta sono accodota all' url se si usa il metodo get come qui sul forum oppure nel body se si usa il metodo post.La risposta è annessa invece sempre al body ed è formattata in html per essere interpretata dal browser.
Se mi linki la pagina dove hai preso le intestazioni gli do un' occhiata.
I dati nella richiesta sono accodota all' url se si usa il metodo get come qui sul forum oppure nel body se si usa il metodo post.La risposta è annessa invece sempre al body ed è formattata in html per essere interpretata dal browser.
Se mi linki la pagina dove hai preso le intestazioni gli do un' occhiata.
airon
01-11-2007, 21:36
la ichiesta è in ASCII mentre la risposta è in rfc 822
I dati nella richiesta sono accodota all' url se si usa il metodo get come qui sul forum oppure nel body se si usa il metodo post.La risposta è annessa invece sempre al body ed è formattata in html per essere interpretata dal browser.
Se mi linki la pagina dove hai preso le intestazioni gli do un' occhiata.
la rfc 822 è old ora ce la RFC 1341 (mime) ;)
Non ho voglia di riavviare se no postavo qualhe pacchetto tcp e si vedeva bene il tutto.
I dati nella richiesta sono accodota all' url se si usa il metodo get come qui sul forum oppure nel body se si usa il metodo post.La risposta è annessa invece sempre al body ed è formattata in html per essere interpretata dal browser.
Se mi linki la pagina dove hai preso le intestazioni gli do un' occhiata.
la rfc 822 è old ora ce la RFC 1341 (mime) ;)
Non ho voglia di riavviare se no postavo qualhe pacchetto tcp e si vedeva bene il tutto.
Matrixbob
01-11-2007, 21:44
la ichiesta è in ASCII mentre la risposta è in rfc 822
I dati nella richiesta sono accodota all' url se si usa il metodo get come qui sul forum oppure nel body se si usa il metodo post.La risposta è annessa invece sempre al body ed è formattata in html per essere interpretata dal browser.
Se mi linki la pagina dove hai preso le intestazioni gli do un' occhiata.
Sei stato piuttosto esauriente.
>> LiNk << (http://it.wikipedia.org/wiki/Http#Esempi_di_messaggi_HTTP)
I dati nella richiesta sono accodota all' url se si usa il metodo get come qui sul forum oppure nel body se si usa il metodo post.La risposta è annessa invece sempre al body ed è formattata in html per essere interpretata dal browser.
Se mi linki la pagina dove hai preso le intestazioni gli do un' occhiata.
Sei stato piuttosto esauriente.
>> LiNk << (http://it.wikipedia.org/wiki/Http#Esempi_di_messaggi_HTTP)
nuovoUtente86
01-11-2007, 21:45
la rfc 822 è old ora ce la RFC 1341 (mime) ;)
Non ho voglia di riavviare se no postavo qualhe pacchetto tcp e si vedeva bene il tutto.
con cosa li monitori i paccheti tcp?
Non ho voglia di riavviare se no postavo qualhe pacchetto tcp e si vedeva bene il tutto.
con cosa li monitori i paccheti tcp?
Matrixbob
01-11-2007, 21:46
la rfc 822 è old ora ce la RFC 1341 (mime) ;)
Non ho voglia di riavviare se no postavo qualhe pacchetto tcp e si vedeva bene il tutto.
Riavvia e posta scansafatiche! ;)
Non ho voglia di riavviare se no postavo qualhe pacchetto tcp e si vedeva bene il tutto.
Riavvia e posta scansafatiche! ;)
Matrixbob
01-11-2007, 21:47
con cosa li monitori i paccheti tcp?
Ethereal?
Nmap?
Ethereal?
Nmap?
nuovoUtente86
01-11-2007, 21:49
la rfc 822 è old ora ce la RFC 1341 (mime) ;)
Non ho voglia di riavviare se no postavo qualhe pacchetto tcp e si vedeva bene il tutto.
da quanto esattamente.Sui libri ho sempre trovato rfc 822 mentre MIME per la posta elettronica
Non ho voglia di riavviare se no postavo qualhe pacchetto tcp e si vedeva bene il tutto.
da quanto esattamente.Sui libri ho sempre trovato rfc 822 mentre MIME per la posta elettronica
nuovoUtente86
01-11-2007, 21:51
Ethereal?
Nmap?
chiedevo esattamente con cosa.
Nmap?
chiedevo esattamente con cosa.
marco.r
01-11-2007, 22:00
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. :boh:
stateless vuol dire che non viene preservato lo "stato" tra un comando e l'altro, ovvero non c'è memoria di quanto precedentemente scambiato tra client e server.
Questo non vuol dire necessariamente che ogni comando richieda una connessione separata, pero' lo si puo' fare. Al contrario, un protocollo stateful come l'FTP richiede una unica connessione per la durata dell'intera sessione.
Tanto per fare un esempio pratico, una sessione HTTP potrebbe essere (dal punto di vista del client) composta dai seguenti comandi
GET /index.html HTTP/1.0
GET /somewhere/somepage.html HTTP/1.0
DELETE /somewhere/something.png HTTP/1.1
ogni comando è indipendente dall'altro e autocontenuto, per cui posso sapere il risultato della terza riga indipendemente dalle altre due. Questo vuol pure dire che ogni volta devo specificare in un qualche modo tutte le informazioni che mi interessano, ad esempio con che utente mi sto collegando, o in che sottocartella voglio cancellare il file, anche se e' la stessa del comando precedente.
Per converso in una sessione FTP il risultato di ogni comando dipende da quelli che l'hanno preceduto
USER user
PASS pwd
PASV
RETR index.html
CDW somewhere
RETR somepage.html
DELETE something.png
QUIT
Nota storica: originariamente un ipertesto era una semplice pagina di testo autocontenuta con molti riferimenti, soprattutto esterni, per cui ĺ'uso tipico prevedeva di prelevare un unico file (in un breve lasso di tempo) da quel server. Da qui l'idea di una connessione per comando. Oggi una pagina contiene molti elementi "embedded" (immagini, flash etc.) che sono necessari per la sua visualizzazione per cui ha senso richiederli uno dietro l'altro, da cui la versione 1.1 dell'HTTP che da la possibilita' di mandare piu' comandi in sequenza.
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. :boh:
stateless vuol dire che non viene preservato lo "stato" tra un comando e l'altro, ovvero non c'è memoria di quanto precedentemente scambiato tra client e server.
Questo non vuol dire necessariamente che ogni comando richieda una connessione separata, pero' lo si puo' fare. Al contrario, un protocollo stateful come l'FTP richiede una unica connessione per la durata dell'intera sessione.
Tanto per fare un esempio pratico, una sessione HTTP potrebbe essere (dal punto di vista del client) composta dai seguenti comandi
GET /index.html HTTP/1.0
GET /somewhere/somepage.html HTTP/1.0
DELETE /somewhere/something.png HTTP/1.1
ogni comando è indipendente dall'altro e autocontenuto, per cui posso sapere il risultato della terza riga indipendemente dalle altre due. Questo vuol pure dire che ogni volta devo specificare in un qualche modo tutte le informazioni che mi interessano, ad esempio con che utente mi sto collegando, o in che sottocartella voglio cancellare il file, anche se e' la stessa del comando precedente.
Per converso in una sessione FTP il risultato di ogni comando dipende da quelli che l'hanno preceduto
USER user
PASS pwd
PASV
RETR index.html
CDW somewhere
RETR somepage.html
DELETE something.png
QUIT
Nota storica: originariamente un ipertesto era una semplice pagina di testo autocontenuta con molti riferimenti, soprattutto esterni, per cui ĺ'uso tipico prevedeva di prelevare un unico file (in un breve lasso di tempo) da quel server. Da qui l'idea di una connessione per comando. Oggi una pagina contiene molti elementi "embedded" (immagini, flash etc.) che sono necessari per la sua visualizzazione per cui ha senso richiederli uno dietro l'altro, da cui la versione 1.1 dell'HTTP che da la possibilita' di mandare piu' comandi in sequenza.
airon
01-11-2007, 22:08
Potete usare wireshark, molto intuitivo, ce anche per windows. Oppure ettercap (sviluppato da due italiani) o anche altri.
Ora vi sposo qualche screen.
http://img227.imageshack.us/img227/9213/wszj0.th.png (http://img227.imageshack.us/my.php?image=wszj0.png)
Si vede che ho richiesto www.google.it
E il server risponde con il codice html. Notate le millemila connessioni, ricostruzioni dei pacchetti ecc.
Ora vi sposo qualche screen.
http://img227.imageshack.us/img227/9213/wszj0.th.png (http://img227.imageshack.us/my.php?image=wszj0.png)
Si vede che ho richiesto www.google.it
E il server risponde con il codice html. Notate le millemila connessioni, ricostruzioni dei pacchetti ecc.
marco.r
01-11-2007, 22:12
OT: mi è venuto in mente che esiste il fenomeno inverso a quello discusso in questo thread, ovvero esiste un protocollo per il file transfer basato su HTTP: WebDAV :D
che vantaggi ci sono secondo voi nell'utilizzare WebDAV anziché FTP? questa questione ha molto più senso e mi interessa; se non volete discuterne qui apro un altro thread.
Vantaggi:
- Non hai il problema legato alla doppia connessione.
- Autenticazione piu' granulare (e.g. : ad unf ile ci puoi accedere e ad un altro no. In ftp o accedi a tutto o a niente)
- Viene piu' naturale mappare i file a qualcosa che non sia il file system. Ad esempio in zope i file finiscono nel suo database ad oggetti, mentre con subversion puoi accedere alle varie revisioni di un file. (Questo non e' legato tanto al protocollo in se')
Svantaggi:
- Piu' complesso e meno maturo, anche se forse negli ultimi anni questo e' migliorato.
che vantaggi ci sono secondo voi nell'utilizzare WebDAV anziché FTP? questa questione ha molto più senso e mi interessa; se non volete discuterne qui apro un altro thread.
Vantaggi:
- Non hai il problema legato alla doppia connessione.
- Autenticazione piu' granulare (e.g. : ad unf ile ci puoi accedere e ad un altro no. In ftp o accedi a tutto o a niente)
- Viene piu' naturale mappare i file a qualcosa che non sia il file system. Ad esempio in zope i file finiscono nel suo database ad oggetti, mentre con subversion puoi accedere alle varie revisioni di un file. (Questo non e' legato tanto al protocollo in se')
Svantaggi:
- Piu' complesso e meno maturo, anche se forse negli ultimi anni questo e' migliorato.
nuovoUtente86
01-11-2007, 22:25
la rfc 822 è old ora ce la RFC 1341 (mime) ;)
Non ho voglia di riavviare se no postavo qualhe pacchetto tcp e si vedeva bene il tutto.
perchè hai dovuto riavviare?
Non ho voglia di riavviare se no postavo qualhe pacchetto tcp e si vedeva bene il tutto.
perchè hai dovuto riavviare?
nuovoUtente86
01-11-2007, 22:28
stateless vuol dire che non viene preservato lo "stato" tra un comando e l'altro, ovvero non c'è memoria di quanto precedentemente scambiato tra client e server.
Questo non vuol dire necessariamente che ogni comando richieda una connessione separata, pero' lo si puo' fare. Al contrario, un protocollo stateful come l'FTP richiede una unica connessione per la durata dell'intera sessione.
Tanto per fare un esempio pratico, una sessione HTTP potrebbe essere (dal punto di vista del client) composta dai seguenti comandi
GET /index.html HTTP/1.0
GET /somewhere/somepage.html HTTP/1.0
DELETE /somewhere/something.png HTTP/1.1
ogni comando è indipendente dall'altro e autocontenuto, per cui posso sapere il risultato della terza riga indipendemente dalle altre due. Questo vuol pure dire che ogni volta devo specificare in un qualche modo tutte le informazioni che mi interessano, ad esempio con che utente mi sto collegando, o in che sottocartella voglio cancellare il file, anche se e' la stessa del comando precedente.
Per converso in una sessione FTP il risultato di ogni comando dipende da quelli che l'hanno preceduto
USER user
PASS pwd
PASV
RETR index.html
CDW somewhere
RETR somepage.html
DELETE something.png
QUIT
Nota storica: originariamente un ipertesto era una semplice pagina di testo autocontenuta con molti riferimenti, soprattutto esterni, per cui ĺ'uso tipico prevedeva di prelevare un unico file (in un breve lasso di tempo) da quel server. Da qui l'idea di una connessione per comando. Oggi una pagina contiene molti elementi "embedded" (immagini, flash etc.) che sono necessari per la sua visualizzazione per cui ha senso richiederli uno dietro l'altro, da cui la versione 1.1 dell'HTTP che da la possibilita' di mandare piu' comandi in sequenza.
Il fatto che la connessione possa durare piu o meno tempo dovrebbe dipendere dall' implementazione del webserver o sbaglio?
Questo non vuol dire necessariamente che ogni comando richieda una connessione separata, pero' lo si puo' fare. Al contrario, un protocollo stateful come l'FTP richiede una unica connessione per la durata dell'intera sessione.
Tanto per fare un esempio pratico, una sessione HTTP potrebbe essere (dal punto di vista del client) composta dai seguenti comandi
GET /index.html HTTP/1.0
GET /somewhere/somepage.html HTTP/1.0
DELETE /somewhere/something.png HTTP/1.1
ogni comando è indipendente dall'altro e autocontenuto, per cui posso sapere il risultato della terza riga indipendemente dalle altre due. Questo vuol pure dire che ogni volta devo specificare in un qualche modo tutte le informazioni che mi interessano, ad esempio con che utente mi sto collegando, o in che sottocartella voglio cancellare il file, anche se e' la stessa del comando precedente.
Per converso in una sessione FTP il risultato di ogni comando dipende da quelli che l'hanno preceduto
USER user
PASS pwd
PASV
RETR index.html
CDW somewhere
RETR somepage.html
DELETE something.png
QUIT
Nota storica: originariamente un ipertesto era una semplice pagina di testo autocontenuta con molti riferimenti, soprattutto esterni, per cui ĺ'uso tipico prevedeva di prelevare un unico file (in un breve lasso di tempo) da quel server. Da qui l'idea di una connessione per comando. Oggi una pagina contiene molti elementi "embedded" (immagini, flash etc.) che sono necessari per la sua visualizzazione per cui ha senso richiederli uno dietro l'altro, da cui la versione 1.1 dell'HTTP che da la possibilita' di mandare piu' comandi in sequenza.
Il fatto che la connessione possa durare piu o meno tempo dovrebbe dipendere dall' implementazione del webserver o sbaglio?
airon
01-11-2007, 22:30
perchè hai dovuto riavviare?
Perche stavo lavorando in windows e l'occorente l'ho su linux. Cmq ho riavviato e ho postato uno screen.
Per la rfc è il contrario. Nel senso che nelle mail all'inizio si usava la 822 poi con l'avvento di internet, delle immagini, video ecc si è sentita l'esigenza di definire i mime types e quindi nuova rfc e nuove estensioni. Almeno mi pare che sia cosi ;)
Perche stavo lavorando in windows e l'occorente l'ho su linux. Cmq ho riavviato e ho postato uno screen.
Per la rfc è il contrario. Nel senso che nelle mail all'inizio si usava la 822 poi con l'avvento di internet, delle immagini, video ecc si è sentita l'esigenza di definire i mime types e quindi nuova rfc e nuove estensioni. Almeno mi pare che sia cosi ;)
airon
01-11-2007, 22:31
Il fatto che la connessione possa durare piu o meno tempo dovrebbe dipendere dall' implementazione del webserver o sbaglio?
Si certo c'e' un' opzione da settare nel file di configurazione.
Si certo c'e' un' opzione da settare nel file di configurazione.
nuovoUtente86
01-11-2007, 22:34
Perche stavo lavorando in windows e l'occorente l'ho su linux. Cmq ho riavviato e ho postato uno screen.
Per la rfc è il contrario. Nel senso che nelle mail all'inizio si usava la 822 poi con l'avvento di internet, delle immagini, video ecc si è sentita l'esigenza di definire i mime types e quindi nuova rfc e nuove estensioni. Almeno mi pare che sia cosi ;)
si ho visto ora che lo screen era su linux.
Sono andato a rivedere degli appunti,per le mail parla solo di Mime(1521)come sostituto di ASCII e per HTTP 1.1 rfc 822..purtroppo non conosco le date di aggiornamento delle dispense per cui nn so dirti con certezza.Se hai dati piu precisi e freschi ottimo a sapersi.
Per la rfc è il contrario. Nel senso che nelle mail all'inizio si usava la 822 poi con l'avvento di internet, delle immagini, video ecc si è sentita l'esigenza di definire i mime types e quindi nuova rfc e nuove estensioni. Almeno mi pare che sia cosi ;)
si ho visto ora che lo screen era su linux.
Sono andato a rivedere degli appunti,per le mail parla solo di Mime(1521)come sostituto di ASCII e per HTTP 1.1 rfc 822..purtroppo non conosco le date di aggiornamento delle dispense per cui nn so dirti con certezza.Se hai dati piu precisi e freschi ottimo a sapersi.
71104
01-11-2007, 22:37
Vantaggi:
- Non hai il problema legato alla doppia connessione.
- Autenticazione piu' granulare (e.g. : ad unf ile ci puoi accedere e ad un altro no. In ftp o accedi a tutto o a niente)
- Viene piu' naturale mappare i file a qualcosa che non sia il file system. Ad esempio in zope i file finiscono nel suo database ad oggetti, mentre con subversion puoi accedere alle varie revisioni di un file. (Questo non e' legato tanto al protocollo in se')
Svantaggi:
- Piu' complesso e meno maturo, anche se forse negli ultimi anni questo e' migliorato.
grazie 1000!
avrei alcune domande:
- Non hai il problema legato alla doppia connessione. come mai è un problema? :wtf:
- Autenticazione piu' granulare (e.g. : ad unf ile ci puoi accedere e ad un altro no. In ftp o accedi a tutto o a niente) questo fatto che con FTP o accedi a tutto o a niente non mi torna :mbe:
in questo periodo un mio amico tiene un server FTP, anzi SFTP per l'esattezza (vabbè che il certificato è farlocco :asd: ), e quando mi connetto posso scrivere solo su alcune cartelle, su altre no (se ci provo il client FTP mi stampa un errore proveniente chiaramente dal server). ho capito male io?
Svantaggi:
- Piu' complesso e meno maturo, anche se forse negli ultimi anni questo e' migliorato. quindi ammettendo di poter trascurare questo svantaggio, e considerando anche che la tecnologia è comunque in fase di miglioramento, secondo te sarebbe preferibile utilizzare sempre e in ogni caso WebDAV piuttosto che FTP?
ultima domanda: è possibile utilizzare WebDAV su SSL, o ci sono problemi? (io non ho mai provato)
- Non hai il problema legato alla doppia connessione.
- Autenticazione piu' granulare (e.g. : ad unf ile ci puoi accedere e ad un altro no. In ftp o accedi a tutto o a niente)
- Viene piu' naturale mappare i file a qualcosa che non sia il file system. Ad esempio in zope i file finiscono nel suo database ad oggetti, mentre con subversion puoi accedere alle varie revisioni di un file. (Questo non e' legato tanto al protocollo in se')
Svantaggi:
- Piu' complesso e meno maturo, anche se forse negli ultimi anni questo e' migliorato.
grazie 1000!
avrei alcune domande:
- Non hai il problema legato alla doppia connessione. come mai è un problema? :wtf:
- Autenticazione piu' granulare (e.g. : ad unf ile ci puoi accedere e ad un altro no. In ftp o accedi a tutto o a niente) questo fatto che con FTP o accedi a tutto o a niente non mi torna :mbe:
in questo periodo un mio amico tiene un server FTP, anzi SFTP per l'esattezza (vabbè che il certificato è farlocco :asd: ), e quando mi connetto posso scrivere solo su alcune cartelle, su altre no (se ci provo il client FTP mi stampa un errore proveniente chiaramente dal server). ho capito male io?
Svantaggi:
- Piu' complesso e meno maturo, anche se forse negli ultimi anni questo e' migliorato. quindi ammettendo di poter trascurare questo svantaggio, e considerando anche che la tecnologia è comunque in fase di miglioramento, secondo te sarebbe preferibile utilizzare sempre e in ogni caso WebDAV piuttosto che FTP?
ultima domanda: è possibile utilizzare WebDAV su SSL, o ci sono problemi? (io non ho mai provato)
airon
01-11-2007, 22:46
si ho visto ora che lo screen era su linux.
Sono andato a rivedere degli appunti,per le mail parla solo di Mime e per HTTP 1.1 rfc 822..purtroppo non conosco le date di aggiornamento delle dispense per cui nn so dirti con certezza.Se hai dati piu precisi e freschi ottimo a sapersi.
Non ho nulla sotto mano in questo momento. In ogni caso vedendo le rfc si nota che la 1341 è l'evoluzione della 822. La 822 è del 1982 quindi molto vecchia...
Sono andato a rivedere degli appunti,per le mail parla solo di Mime e per HTTP 1.1 rfc 822..purtroppo non conosco le date di aggiornamento delle dispense per cui nn so dirti con certezza.Se hai dati piu precisi e freschi ottimo a sapersi.
Non ho nulla sotto mano in questo momento. In ogni caso vedendo le rfc si nota che la 1341 è l'evoluzione della 822. La 822 è del 1982 quindi molto vecchia...
marco.r
01-11-2007, 23:10
grazie 1000!
avrei alcune domande:
come mai è un problema? :wtf:
Il protocollo ftp prevede l'uso di due connessioni, una per lo scambio dei comandi e l'altra per lo scambio dei file. Nella modalita' originaria (quella attiva) e' il server che si collega al client sulla porta 20 (!!!) per l'invio del file. Come puoi immaginare la cosa crea problemi in presenza di firewall o nat. E' stata quindi introdotta la modalita' passiva che preveda che sia il client a collegarsi al server, pero' su di una porta non privilegiata "random". Questo crea problemi dal lato server perche' devi cmq creare un "buco" (o redirect) di una certa dimensione.
Altra rogna: sia in modalita' attiva che passiva il lato che si mette in ascolto comunica all'altro indirizzo e porta a cui connettersi, per cui deve sapere il proprio indirizzo pubblico.
questo fatto che con FTP o accedi a tutto o a niente non mi torna :mbe:
in questo periodo un mio amico tiene un server FTP, anzi SFTP per l'esattezza (vabbè che il certificato è farlocco :asd: ), e quando mi connetto posso scrivere solo su alcune cartelle, su altre no (se ci provo il client FTP mi stampa un errore proveniente chiaramente dal server). ho capito male io?
No, ho scritto una boiata io, e non so neanche il perche' :D .
Faccio pubblica ammenda.
E' vero che di solito i permessi si impostano a livello di directory, ma probabilmente e' solo una questione implementativa.
quindi ammettendo di poter trascurare questo svantaggio, e considerando anche che la tecnologia è comunque in fase di miglioramento, secondo te sarebbe preferibile utilizzare sempre e in ogni caso WebDAV piuttosto che FTP?
Dipende dall'uso che ne vuoi fare... se devono usarlo degli utenti in carne ed ossa una volta che il tuo server funziona con le "cartelle web" di windows sei a posto, ma per chi deve scrivere un client potrebbe essere piu' difficile trovare una libreria lato client. SEnza contare che se l'interazione e' tra solo tra client e server (ovvero non ci sono piu' client che devono scambiarsi i file) vai semplicemente di GET e POST e sei felice.
ultima domanda: è possibile utilizzare WebDAV su SSL, o ci sono problemi? (io non ho mai provato)
Non ci dovrebbero essere problemi.
avrei alcune domande:
come mai è un problema? :wtf:
Il protocollo ftp prevede l'uso di due connessioni, una per lo scambio dei comandi e l'altra per lo scambio dei file. Nella modalita' originaria (quella attiva) e' il server che si collega al client sulla porta 20 (!!!) per l'invio del file. Come puoi immaginare la cosa crea problemi in presenza di firewall o nat. E' stata quindi introdotta la modalita' passiva che preveda che sia il client a collegarsi al server, pero' su di una porta non privilegiata "random". Questo crea problemi dal lato server perche' devi cmq creare un "buco" (o redirect) di una certa dimensione.
Altra rogna: sia in modalita' attiva che passiva il lato che si mette in ascolto comunica all'altro indirizzo e porta a cui connettersi, per cui deve sapere il proprio indirizzo pubblico.
questo fatto che con FTP o accedi a tutto o a niente non mi torna :mbe:
in questo periodo un mio amico tiene un server FTP, anzi SFTP per l'esattezza (vabbè che il certificato è farlocco :asd: ), e quando mi connetto posso scrivere solo su alcune cartelle, su altre no (se ci provo il client FTP mi stampa un errore proveniente chiaramente dal server). ho capito male io?
No, ho scritto una boiata io, e non so neanche il perche' :D .
Faccio pubblica ammenda.
E' vero che di solito i permessi si impostano a livello di directory, ma probabilmente e' solo una questione implementativa.
quindi ammettendo di poter trascurare questo svantaggio, e considerando anche che la tecnologia è comunque in fase di miglioramento, secondo te sarebbe preferibile utilizzare sempre e in ogni caso WebDAV piuttosto che FTP?
Dipende dall'uso che ne vuoi fare... se devono usarlo degli utenti in carne ed ossa una volta che il tuo server funziona con le "cartelle web" di windows sei a posto, ma per chi deve scrivere un client potrebbe essere piu' difficile trovare una libreria lato client. SEnza contare che se l'interazione e' tra solo tra client e server (ovvero non ci sono piu' client che devono scambiarsi i file) vai semplicemente di GET e POST e sei felice.
ultima domanda: è possibile utilizzare WebDAV su SSL, o ci sono problemi? (io non ho mai provato)
Non ci dovrebbero essere problemi.
nuovoUtente86
01-11-2007, 23:16
Non ho nulla sotto mano in questo momento. In ogni caso vedendo le rfc si nota che la 1341 è l'evoluzione della 822. La 822 è del 1982 quindi molto vecchia...
si infatti ci sono 10 anni di differenza. il 1341 è del 1992.è strano però che si sia scelto almeno inizialmente l 822 per http
si infatti ci sono 10 anni di differenza. il 1341 è del 1992.è strano però che si sia scelto almeno inizialmente l 822 per http
71104
02-11-2007, 06:54
E' stata quindi introdotta la modalita' passiva che preveda che sia il client a collegarsi al server, pero' su di una porta non privilegiata "random". Questo crea problemi dal lato server perche' devi cmq creare un "buco" (o redirect) di una certa dimensione. come mai hanno deciso di utilizzare un range di porte per la connessione dati anziché una porta sola? non ne vedo la ragione :mbe:
quando si configura un server FTP è possibile utilizzare comunque una porta sola per le connessioni dati (cioè impostare un range di una sola porta)?
quando si configura un server FTP è possibile utilizzare comunque una porta sola per le connessioni dati (cioè impostare un range di una sola porta)?
marco.r
02-11-2007, 09:37
come mai hanno deciso di utilizzare un range di porte per la connessione dati anziché una porta sola? non ne vedo la ragione :mbe:
quando si configura un server FTP è possibile utilizzare comunque una porta sola per le connessioni dati (cioè impostare un range di una sola porta)?
Perchè la connessione dati trasporta solo i file, niente di piu', per cui non c'è modo di distinguere una connessione relativa ad un certo file se non dalla porta a cui si collega. Usando la stessa porta non hai piu' modo di distinguere due connessioni che arrivano dallo stesso numero
quando si configura un server FTP è possibile utilizzare comunque una porta sola per le connessioni dati (cioè impostare un range di una sola porta)?
Perchè la connessione dati trasporta solo i file, niente di piu', per cui non c'è modo di distinguere una connessione relativa ad un certo file se non dalla porta a cui si collega. Usando la stessa porta non hai piu' modo di distinguere due connessioni che arrivano dallo stesso numero
Matrixbob
02-11-2007, 10:29
Alla fine ho scritto così, mi date un ACK sa va bene?
TNX!
Prima del WWW per l'accesso ai dati da remoto veniva impiegato il FTP (File Transfer Protocol), che però male si adatta ai meccanismi del Web, come ad esempio la navigazione tra gli ipertesti, la quale non è più un semplice scaricamento di file. Da qui il bisogno di utilizzare un protocollo appositamente progettato per gli ipertesti, l'HTTP (HyperText Transfer Protocol).
TNX!
Prima del WWW per l'accesso ai dati da remoto veniva impiegato il FTP (File Transfer Protocol), che però male si adatta ai meccanismi del Web, come ad esempio la navigazione tra gli ipertesti, la quale non è più un semplice scaricamento di file. Da qui il bisogno di utilizzare un protocollo appositamente progettato per gli ipertesti, l'HTTP (HyperText Transfer Protocol).
cionci
02-11-2007, 10:42
Volevo precisare alcune cose che sicuramente sono state già dette, ma che magari messe insieme possono rendere la cosa più chiara.
Il motivo per cui non è stato usato per il web non è quello della connessione dati che viene instaurata ad ogni richiesta (anche perché HTTP 1.0 non aveva una connessione persistente), ma perché semplicemente non è nato per trasferire dati ipertestuali, ma dati binari (a parte l'ASCII mode, ma questo per altri motivi).
Una componente fondamentale del trasferimento di ipertesti è il contesto del trasferimento...il contesto è stabilito dall'header. Il protocollo FTP non ha alcuno strumento per stabilire il contesto del file trasferito e questo lo rende inutilizzabili per trasferire ipertesti, se non per funzionalità di base.
Il motivo per cui non è stato usato per il web non è quello della connessione dati che viene instaurata ad ogni richiesta (anche perché HTTP 1.0 non aveva una connessione persistente), ma perché semplicemente non è nato per trasferire dati ipertestuali, ma dati binari (a parte l'ASCII mode, ma questo per altri motivi).
Una componente fondamentale del trasferimento di ipertesti è il contesto del trasferimento...il contesto è stabilito dall'header. Il protocollo FTP non ha alcuno strumento per stabilire il contesto del file trasferito e questo lo rende inutilizzabili per trasferire ipertesti, se non per funzionalità di base.
71104
02-11-2007, 11:07
Perchè la connessione dati trasporta solo i file, niente di piu', per cui non c'è modo di distinguere una connessione relativa ad un certo file se non dalla porta a cui si collega. Usando la stessa porta non hai piu' modo di distinguere due connessioni che arrivano dallo stesso numero
capito. certo però quando si dice un lavoro fatto male... :D
nella stesura di un protocollo si ha carta bianca; dovevano proprio complicarsi la vita in questo modo con due connessioni?
mah
capito. certo però quando si dice un lavoro fatto male... :D
nella stesura di un protocollo si ha carta bianca; dovevano proprio complicarsi la vita in questo modo con due connessioni?
mah
nuovoUtente86
02-11-2007, 11:40
Il motivo per cui non è stato usato per il web non è quello della connessione dati che viene instaurata ad ogni richiesta (anche perché HTTP 1.0 non aveva una connessione persistente), ma perché semplicemente non è nato per trasferire dati ipertestuali, ma dati binari (a parte l'ASCII mode, ma questo per altri motivi).
Forse ho inteso male il tuo pensiero..ma mi sembra che ftp matengo persistente la connessione cosi come fa http 1.1.
Forse ho inteso male il tuo pensiero..ma mi sembra che ftp matengo persistente la connessione cosi come fa http 1.1.
nuovoUtente86
02-11-2007, 11:46
Leggendo su Wikipedia direi che è un casino da matti 1 connessione FTP:
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?
mi era sfuggito questo passo.Il problema della coda è alquanto ridicolo,poichè si utilizza la programmazione multithread...in modo daa rendere l' ascoltatore cmq disponibile sulla porta.
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?
mi era sfuggito questo passo.Il problema della coda è alquanto ridicolo,poichè si utilizza la programmazione multithread...in modo daa rendere l' ascoltatore cmq disponibile sulla porta.
cionci
02-11-2007, 11:49
Forse ho inteso male il tuo pensiero..ma mi sembra che ftp matengo persistente la connessione cosi come fa http 1.1.
La connessione dati non è persistente ;)
Solo quella di controllo è persistente.
La connessione dati non è persistente ;)
Solo quella di controllo è persistente.
nuovoUtente86
02-11-2007, 12:02
La connessione dati non è persistente ;)
Solo quella di controllo è persistente.
in effetti su questo punto non mi sembra di aver letto mai qualcosa di approfondito,ma se ho capito
finito di traferire il file la tcp di trasporto cade ma resta attiva quella di controllo sfruttabile per altri download?
Solo quella di controllo è persistente.
in effetti su questo punto non mi sembra di aver letto mai qualcosa di approfondito,ma se ho capito
finito di traferire il file la tcp di trasporto cade ma resta attiva quella di controllo sfruttabile per altri download?
71104
02-11-2007, 12:04
si, esatto: puoi continuare ad usare la connessione di controllo per navigare nel file system e scegliere files da scaricare.
nuovoUtente86
02-11-2007, 12:06
la dove prevista attraverso tale connessione di controllo va gestita anchel' autenticazione mi sembra
cionci
02-11-2007, 12:08
la dove prevista attraverso tale connessione di controllo va gestita anchel' autenticazione mi sembra
Certo...tramite la connessione di controllo vengono dati TUTTI i comandi e quindi anche quelli per l'autenticazione.
Su quella dati passano, appunto, solo i dati in forma binaria...di fatto non c'è un protocollo superiore al TCP.
Certo...tramite la connessione di controllo vengono dati TUTTI i comandi e quindi anche quelli per l'autenticazione.
Su quella dati passano, appunto, solo i dati in forma binaria...di fatto non c'è un protocollo superiore al TCP.
cionci
02-11-2007, 12:10
Un punto a sfavore di FTP è anche quello che la connessione dati deve essere instaurata con il server FTP che si connette ad una porta del client FTP (quindi in direzione inversa a quella di controllo). Un tempo non era un grande problema, ma con l'avvento delle reti private e dei firewall si è dovuti ricorrere al comando PASSV che permette di creare la connessione dati in senso inverso.
71104
02-11-2007, 12:14
Certo...tramite la connessione di controllo vengono dati TUTTI i comandi e quindi anche quelli per l'autenticazione.
Su quella dati passano, appunto, solo i dati in forma binaria...di fatto non c'è un protocollo superiore al TCP. niente autenticazione sulla connessione dati?? questo si che è pessimo: è come dire che sulla macchina gira un server che concede files aggratis; IMHO la cosa rende l'FTP semplice praticamente inutilizzabile visto che chiunque stia in mezzo sa esattamente quando e su che porta connettersi per ottenere quale file. andrebbe già un po' meglio con l'FTP via SSL, ma anche là qualcuno (che non si trovi necessariamente in mezzo) potrebbe effettuare tentativi di connessione su porte random finché non gli capita che ci becca e il server gli concede un file... è una vulnerabilità difficile da sfruttare ma comunque non sottovalutabile. bene, ora so come mai conviene usare WebDAV :D
Su quella dati passano, appunto, solo i dati in forma binaria...di fatto non c'è un protocollo superiore al TCP. niente autenticazione sulla connessione dati?? questo si che è pessimo: è come dire che sulla macchina gira un server che concede files aggratis; IMHO la cosa rende l'FTP semplice praticamente inutilizzabile visto che chiunque stia in mezzo sa esattamente quando e su che porta connettersi per ottenere quale file. andrebbe già un po' meglio con l'FTP via SSL, ma anche là qualcuno (che non si trovi necessariamente in mezzo) potrebbe effettuare tentativi di connessione su porte random finché non gli capita che ci becca e il server gli concede un file... è una vulnerabilità difficile da sfruttare ma comunque non sottovalutabile. bene, ora so come mai conviene usare WebDAV :D
Matrixbob
02-11-2007, 12:35
Volevo precisare alcune cose che sicuramente sono state già dette, ma che magari messe insieme possono rendere la cosa più chiara.
Il motivo per cui non è stato usato per il web non è quello della connessione dati che viene instaurata ad ogni richiesta (anche perché HTTP 1.0 non aveva una connessione persistente), ma perché semplicemente non è nato per trasferire dati ipertestuali, ma dati binari (a parte l'ASCII mode, ma questo per altri motivi).
Una componente fondamentale del trasferimento di ipertesti è il contesto del trasferimento...il contesto è stabilito dall'header. Il protocollo FTP non ha alcuno strumento per stabilire il contesto del file trasferito e questo lo rende inutilizzabili per trasferire ipertesti, se non per funzionalità di base.
Quindi come dico qui no:
http://www.hwupgrade.it/forum/showpost.php?p=19435096&postcount=66
Il motivo per cui non è stato usato per il web non è quello della connessione dati che viene instaurata ad ogni richiesta (anche perché HTTP 1.0 non aveva una connessione persistente), ma perché semplicemente non è nato per trasferire dati ipertestuali, ma dati binari (a parte l'ASCII mode, ma questo per altri motivi).
Una componente fondamentale del trasferimento di ipertesti è il contesto del trasferimento...il contesto è stabilito dall'header. Il protocollo FTP non ha alcuno strumento per stabilire il contesto del file trasferito e questo lo rende inutilizzabili per trasferire ipertesti, se non per funzionalità di base.
Quindi come dico qui no:
http://www.hwupgrade.it/forum/showpost.php?p=19435096&postcount=66
Matrixbob
02-11-2007, 12:38
mi era sfuggito questo passo.Il problema della coda è alquanto ridicolo,poichè si utilizza la programmazione multithread...in modo daa rendere l' ascoltatore cmq disponibile sulla porta.
Ma infatti questa idea viene a cadere da quando abbiamo deto che il problema non sono le connessioni, ma le possibilità di cose da fare con i 2 protocolli differenti.
Ma infatti questa idea viene a cadere da quando abbiamo deto che il problema non sono le connessioni, ma le possibilità di cose da fare con i 2 protocolli differenti.
nuovoUtente86
02-11-2007, 12:38
Un punto a sfavore di FTP è anche quello che la connessione dati deve essere instaurata con il server FTP che si connette ad una porta del client FTP (quindi in direzione inversa a quella di controllo). Un tempo non era un grande problema, ma con l'avvento delle reti private e dei firewall si è dovuti ricorrere al comando PASSV che permette di creare la connessione dati in senso inverso.
Be però se pensiamo al passato la maggior parte dei calcolatori erano in reti private di atenei,grandi aziende ecc per cui seppur probabilmente ogni rete aveva un suo ftp raggiungerli dall' esterno non era banale.Paradassolmante è piu facile oggi trovare calcolatori dietro modem per cui raggiungibili sulle porte.Cmq penso che ormai sia sempre il client ad innestare la connessione di trasporto in quanto anche stando dietro router non nattato non si hanno problemi.
Be però se pensiamo al passato la maggior parte dei calcolatori erano in reti private di atenei,grandi aziende ecc per cui seppur probabilmente ogni rete aveva un suo ftp raggiungerli dall' esterno non era banale.Paradassolmante è piu facile oggi trovare calcolatori dietro modem per cui raggiungibili sulle porte.Cmq penso che ormai sia sempre il client ad innestare la connessione di trasporto in quanto anche stando dietro router non nattato non si hanno problemi.
Matrixbob
02-11-2007, 12:39
In definitiva, va bene questa sintesi?
Prima del WWW per l'accesso ai dati da remoto veniva impiegato il FTP (File Transfer Protocol), che però male si adatta ai meccanismi del Web, come ad esempio la navigazione tra gli ipertesti, la quale non è più un semplice scaricamento di file. Da qui il bisogno di utilizzare un protocollo appositamente progettato per gli ipertesti, l'HTTP (HyperText Transfer Protocol).
Prima del WWW per l'accesso ai dati da remoto veniva impiegato il FTP (File Transfer Protocol), che però male si adatta ai meccanismi del Web, come ad esempio la navigazione tra gli ipertesti, la quale non è più un semplice scaricamento di file. Da qui il bisogno di utilizzare un protocollo appositamente progettato per gli ipertesti, l'HTTP (HyperText Transfer Protocol).
nuovoUtente86
02-11-2007, 12:40
niente autenticazione sulla connessione dati?? questo si che è pessimo: è come dire che sulla macchina gira un server che concede files aggratis; IMHO la cosa rende l'FTP semplice praticamente inutilizzabile visto che chiunque stia in mezzo sa esattamente quando e su che porta connettersi per ottenere quale file. andrebbe già un po' meglio con l'FTP via SSL, ma anche là qualcuno (che non si trovi necessariamente in mezzo) potrebbe effettuare tentativi di connessione su porte random finché non gli capita che ci becca e il server gli concede un file... è una vulnerabilità difficile da sfruttare ma comunque non sottovalutabile. bene, ora so come mai conviene usare WebDAV :D
non vedo il problema dato che esiste appositamente la connessine di controllo
non vedo il problema dato che esiste appositamente la connessine di controllo
nuovoUtente86
02-11-2007, 12:43
In definitiva, va bene questa sintesi?
ma io ancora non capisco il perchè disquisire per forza sulle differenze tra un protocollo per il trasferimento dei file(come puo essere il p2p ed eventualmente su questo potresti confrontare)con l' http e il web che non rappresenta propriamente il trasferimento di file.
ma io ancora non capisco il perchè disquisire per forza sulle differenze tra un protocollo per il trasferimento dei file(come puo essere il p2p ed eventualmente su questo potresti confrontare)con l' http e il web che non rappresenta propriamente il trasferimento di file.
Matrixbob
02-11-2007, 12:46
ma io ancora non capisco il perchè disquisire per forza sulle differenze tra un protocollo per il trasferimento dei file(come puo essere il p2p ed eventualmente su questo potresti confrontare)con l' http e il web che non rappresenta propriamente il trasferimento di file.
O santo cielo, ma perchè sto scrivendo in letteratura!
Se qualche lettore dell'articolo si chiede "ma perchè non hanno usato l'FTP?" beh allora quella è la risposta.
Avete presente le domande che può farsi un lettore leggendo un articolo di giornale, ecco quel paragrafo serve a togliergli la curiosità.
Non sto facendo un Saggio sulle 2 tecnologie, ok?
O santo cielo, ma perchè sto scrivendo in letteratura!
Se qualche lettore dell'articolo si chiede "ma perchè non hanno usato l'FTP?" beh allora quella è la risposta.
Avete presente le domande che può farsi un lettore leggendo un articolo di giornale, ecco quel paragrafo serve a togliergli la curiosità.
Non sto facendo un Saggio sulle 2 tecnologie, ok?
Matrixbob
02-11-2007, 12:51
Voi ne conoscete protocolli di P2P?
Ci stavo pensando ieri, ed in particolare a:
IP-TV
P2P-TV
La prima dovrebbe indicare l'uso di IP in architetture client/server.
La seconda l'uso di protocolli P2P (che io non conosco) su archietetture con nodi paritari.
Quali sono i protocolli P2P popolari?
Ci stavo pensando ieri, ed in particolare a:
IP-TV
P2P-TV
La prima dovrebbe indicare l'uso di IP in architetture client/server.
La seconda l'uso di protocolli P2P (che io non conosco) su archietetture con nodi paritari.
Quali sono i protocolli P2P popolari?
nuovoUtente86
02-11-2007, 12:56
se insistiamo un motivo ci sarà:è concettualmente errato quello che vuoi scrivere,l' http è nato appositamente per il web,l' ftp è un' altra cosa:gestione di un fs remoto.Ora che all' inizio anche il web fosse un fs di pagine statiche html poco importa.è come scrivere che emule utilizza un altro protocollo piuttosto che ftp,è normale perchè sono diversi gli scopi.Oppure dire che per la portabilità di java si è scelta l' interpretazione e non la compilazione in linguaggio nativo.
Matrixbob
02-11-2007, 13:02
se insistiamo un motivo ci sarà:è concettualmente errato quello che vuoi scrivere,
Cioè è concentualmente errato che un lettore che non abbia mai visto il Web prima di adesso, ma che conosce alla perfezione tutto quanto c'era prima FTP compreso posso avere un pensiero che sia: "perchè non hanno usato l'FTP o FTP modificato per scaricare file o parti di file"?
Cioè questo non può capitare?
l' http è nato appositamente per il web,l' ftp è un' altra cosa:gestione di un fs remoto.Ora che all' inizio anche il web fosse un fs di pagine statiche html poco importa.è come scrivere che emule utilizza un altro protocollo piuttosto che ftp,è normale perchè sono diversi gli scopi.Oppure dire che per la portabilità di java si è scelta l' interpretazione e non la compilazione in linguaggio nativo.
Infatti questo dico in quella spiegazione.
Non sto mettendo a confronto proprio niente, sto rispondendo alla presunta domanda di un lettore posta sopra.
Cioè è concentualmente errato che un lettore che non abbia mai visto il Web prima di adesso, ma che conosce alla perfezione tutto quanto c'era prima FTP compreso posso avere un pensiero che sia: "perchè non hanno usato l'FTP o FTP modificato per scaricare file o parti di file"?
Cioè questo non può capitare?
l' http è nato appositamente per il web,l' ftp è un' altra cosa:gestione di un fs remoto.Ora che all' inizio anche il web fosse un fs di pagine statiche html poco importa.è come scrivere che emule utilizza un altro protocollo piuttosto che ftp,è normale perchè sono diversi gli scopi.Oppure dire che per la portabilità di java si è scelta l' interpretazione e non la compilazione in linguaggio nativo.
Infatti questo dico in quella spiegazione.
Non sto mettendo a confronto proprio niente, sto rispondendo alla presunta domanda di un lettore posta sopra.
nuovoUtente86
02-11-2007, 13:06
Cioè è concentualmente errato che un lettore che non abbia mai visto il Web prima di adesso, ma che conosce alla perfezione tutto quanto c'era prima FTP compreso posso avere un pensiero che sia: "perchè non hanno usato l'FTP o FTP modificato per scaricare file o parti di file"?
Cioè questo non può capitare?
Infatti questo dico in quella spiegazione.
Non sto mettendo a confronto proprio niente, sto rispondendo alla presunta domanda di un lettore posta sopra.
se conosce bene ftp non si fa la domanda.Quello che confondi è il concetto di file...nel www non si scambia un file ma si visualizza una pagine in formattazione html.
Cioè questo non può capitare?
Infatti questo dico in quella spiegazione.
Non sto mettendo a confronto proprio niente, sto rispondendo alla presunta domanda di un lettore posta sopra.
se conosce bene ftp non si fa la domanda.Quello che confondi è il concetto di file...nel www non si scambia un file ma si visualizza una pagine in formattazione html.
Matrixbob
02-11-2007, 13:07
Scompongo il paragrafo:
Prima del WWW per l'accesso ai dati da remoto veniva impiegato il FTP (File Transfer Protocol),
vero
che però male si adatta ai meccanismi del Web,
vero
come ad esempio la navigazione tra gli ipertesti, la quale non è più un semplice scaricamento di file.
vero
Da qui il bisogno di utilizzare un protocollo appositamente progettato per gli ipertesti, l'HTTP (HyperText Transfer Protocol).
vero
-----
Mi spiegi dove sta il problema?
Prima del WWW per l'accesso ai dati da remoto veniva impiegato il FTP (File Transfer Protocol),
vero
che però male si adatta ai meccanismi del Web,
vero
come ad esempio la navigazione tra gli ipertesti, la quale non è più un semplice scaricamento di file.
vero
Da qui il bisogno di utilizzare un protocollo appositamente progettato per gli ipertesti, l'HTTP (HyperText Transfer Protocol).
vero
-----
Mi spiegi dove sta il problema?
Matrixbob
02-11-2007, 13:08
se conosce bene ftp non si fa la domanda.Quello che confondi è il concetto di file...nel www non si scambia un file ma si visualizza una pagine in formattazione html.
Infatti nel paragrafo non lo confondo.
Facciamo che nel esempio il tizio conosca che fino a quel punto c'era FTP.
Ora va meglio? Ma non attacchiamoci al pelo plz.
Infatti nel paragrafo non lo confondo.
Facciamo che nel esempio il tizio conosca che fino a quel punto c'era FTP.
Ora va meglio? Ma non attacchiamoci al pelo plz.
nuovoUtente86
02-11-2007, 13:21
puoi scrivere quello che vuoi che il rosso è nero e viceversa..ma non cercare di imporre qualcosa che non esiste dal punto di vista logico,con il tuo discorso la tecnologia sarebbe ferma ad un unico protocollo e non avrebbero senso http,java rmi,i p2p
Matrixbob
02-11-2007, 13:26
puoi scrivere quello che vuoi che il rosso è nero e viceversa..ma non cercare di imporre qualcosa che non esiste dal punto di vista logico,con il tuo discorso la tecnologia sarebbe ferma ad un unico protocollo e non avrebbero senso http,java rmi,i p2p
Ma che discorso scusa?
Senti non esagerare dai, quello è un paragrafo che può non piacerti, ma comunque di asserzioni vere.
Se sono vere a me va bene così.
Ma che discorso scusa?
Senti non esagerare dai, quello è un paragrafo che può non piacerti, ma comunque di asserzioni vere.
Se sono vere a me va bene così.
nuovoUtente86
02-11-2007, 13:32
è vero che l' ftp nonè utilizzato nel web..macio èveroper altri 100mila protocolli,che senso ha fare un confronto del genere.
Se io scrivo qualcosa del genere..per skype non si utilizza l http ma un protocollo proprieatrio che utilizza quando possibile udp,o tcp con gli hop che fanno da server per altri hop quando la connessione diretta non è possibile...ecc è una cosa vera ma non ha alcun senso
Se io scrivo qualcosa del genere..per skype non si utilizza l http ma un protocollo proprieatrio che utilizza quando possibile udp,o tcp con gli hop che fanno da server per altri hop quando la connessione diretta non è possibile...ecc è una cosa vera ma non ha alcun senso
71104
02-11-2007, 13:34
Be però se pensiamo al passato la maggior parte dei calcolatori erano in reti private di atenei, ma non c'entra, nel passato non esisteva il NAT e quindi un IP privato era la stessa cosa di un IP esterno (credo :mbe: )... cioè credo che per connettersi ad un host interno bastava usare il suo IP interno, che era lo stesso esterno.
cionci
02-11-2007, 13:36
ma non c'entra, nel passato non esisteva il NAT e quindi un IP privato era la stessa cosa di un IP esterno (credo :mbe: )... cioè credo che per connettersi ad un host interno bastava usare il suo IP interno, che era lo stesso esterno.
Sì...
Sì...
Matrixbob
02-11-2007, 13:39
è vero che l' ftp nonè utilizzato nel web..macio èveroper altri 100mila protocolli,che senso ha fare un confronto del genere.
Se io scrivo qualcosa del genere..per skype non si utilizza l http ma un protocollo proprieatrio che utilizza quando possibile udp,o tcp con gli hop che fanno da server per altri hop quando la connessione diretta non è possibile...ecc è una cosa vera ma non ha alcun senso
Beh io il senso lo vedo, quindi chiudiamolo qui questo discorso.
TNX.
Se io scrivo qualcosa del genere..per skype non si utilizza l http ma un protocollo proprieatrio che utilizza quando possibile udp,o tcp con gli hop che fanno da server per altri hop quando la connessione diretta non è possibile...ecc è una cosa vera ma non ha alcun senso
Beh io il senso lo vedo, quindi chiudiamolo qui questo discorso.
TNX.
nuovoUtente86
02-11-2007, 13:39
Sì...
come avveniva il tutto?
come avveniva il tutto?
71104
02-11-2007, 13:40
non vedo il problema dato che esiste appositamente la connessine di controllo mettiamo che ci sia un server FTP a cui ci si connette senza SSL, e che uno degli utenti che vi si connettono con regolare account (chiamiamolo A) debba passare attraverso una macchina malfidata di uno che non ha l'account (chiamiamolo B) e che quindi di norma non è abilitato a scaricare files da quell'FTP. B per sapere quando e su che porta connettersi per scaricare un file dovrebbe semplicemente attendere che A si connetta, monitorare quello che passa sulla connessione, osservare quali files A sta chiedendo e su che porta il server in risposta chiede ad A di connettersi per ricevere quel file; a quel punto B si connetterebbe su quella porta e riceverebbe il file al posto di A, giusto?
71104
02-11-2007, 13:44
come avveniva il tutto? come vuoi che avvenisse? chi stava all'esterno iniziava un three-way handshake inviando pacchetti all'IP unico dell'host di destinazione, e quei pacchetti arrivavano senza tante storie perché i routers li mandavano lì. non esisteva il NAT (Network Address Translation), cioè non esisteva nessuna traduzione di indirizzi. oggi invece, col NAT, prima che ci si possa connettere ad un host interno il suo indirizzo interno deve essere mappato dal firewall su un indirizzo esterno allocato appositamente; e ci vanno di mezzo anche le porte (per ciascuna connessione deve esistere una mappatura tra una coppia IP:Porta interna e una coppia IP:Porta esterna allocata appositamente). scusa se l'ho spiegato in maniera confusa ^^
nuovoUtente86
02-11-2007, 13:45
mettiamo che ci sia un server FTP a cui ci si connette senza SSL, e che uno degli utenti che vi si connettono con regolare account (chiamiamolo A) debba passare attraverso una macchina malfidata di uno che non ha l'account (chiamiamolo B) e che quindi di norma non è abilitato a scaricare files da quell'FTP. B per sapere quando e su che porta connettersi per scaricare un file dovrebbe semplicemente attendere che A si connetta, monitorare quello che passa sulla connessione, osservare quali files A sta chiedendo e su che porta il server in risposta chiede ad A di connettersi per ricevere quel file; a quel punto B si connetterebbe su quella porta e riceverebbe il file al posto di A, giusto?
bisogna vedere che protezione ha la connessione di controllo e se in fase di start del download il server non chieda credenziali al client
bisogna vedere che protezione ha la connessione di controllo e se in fase di start del download il server non chieda credenziali al client
nuovoUtente86
02-11-2007, 13:46
come vuoi che avvenisse? chi stava all'esterno iniziava un three-way handshake inviando pacchetti all'IP unico dell'host di destinazione, e quei pacchetti arrivavano senza tante storie perché i routers li mandavano lì. non esisteva il NAT (Network Address Translation), cioè non esisteva nessuna traduzione di indirizzi. oggi invece, col NAT, prima che ci si possa connettere ad un host interno il suo indirizzo interno deve essere mappato dal firewall su un indirizzo esterno allocato appositamente; e ci vanno di mezzo anche le porte (per ciascuna connessione deve esistere una mappatura tra una coppia IP:Porta interna e una coppia IP:Porta esterna allocata appositamente). scusa se l'ho spiegato in maniera confusa ^^
non c' era condivisione del' ip in pratica ma ognuna aveva il suo.
non c' era condivisione del' ip in pratica ma ognuna aveva il suo.
71104
02-11-2007, 13:49
bisogna vedere che protezione ha la connessione di controllo e se in fase di start del download il server non chieda credenziali al client
post #75
(rispondevo giusto a quello infatti)
post #75
(rispondevo giusto a quello infatti)
nuovoUtente86
02-11-2007, 13:50
post #75
(rispondevo giusto a quello infatti)
però non si fa cenno alla eventuale crittografia utilizzata sul controllo
(rispondevo giusto a quello infatti)
però non si fa cenno alla eventuale crittografia utilizzata sul controllo
71104
02-11-2007, 13:54
però non si fa cenno alla eventuale crittografia utilizzata sul controllo
avevo dato per scontato che non si usasse SSL, ma anche se lo si usa certificare che il server sia quello serve a poco: è il client che bisogna autenticare, non il server. vero che SSL supporta anche l'autenticazione da parte del client ma a sto punto uso WebDAV... :mbe: con anche SSL :D
avevo dato per scontato che non si usasse SSL, ma anche se lo si usa certificare che il server sia quello serve a poco: è il client che bisogna autenticare, non il server. vero che SSL supporta anche l'autenticazione da parte del client ma a sto punto uso WebDAV... :mbe: con anche SSL :D
nuovoUtente86
02-11-2007, 14:02
be però se la connessione su cui si effettua l' autenticazione è sicura difficilmente 3 parti acquisiranno i dati necessari a prelevare aggratis il file dal server
jappilas
02-11-2007, 14:11
Infatti nel paragrafo non lo confondo.
Facciamo che nel esempio il tizio conosca che fino a quel punto c'era FTP.
Ora va meglio? Ma non attacchiamoci al pelo plz.sì ma fino a quel punto le informazioni erano scambiate prevalentemente tramite documenti in forma di file scaricati da server, o inviati per posta elettronica - non c' era http, ma non c' erano nemmeno gli ipertesti in linea, poi concretizzatisi come pagine html contenenti oggetti embedded e hyperlink (interni od esterni)
che mi risulti (ed è importante tenere presente che) l' html è fin dall' inizio andato di pari passo con http, e non si sarebbe mai passati attraverso richieste di singoli file per la ricezione dell' ipertesto e degli elementi collegati, visualizzati attraverso un' applicazione ad hoc e ricevuto tramite un protocollo ad hoc
Facciamo che nel esempio il tizio conosca che fino a quel punto c'era FTP.
Ora va meglio? Ma non attacchiamoci al pelo plz.sì ma fino a quel punto le informazioni erano scambiate prevalentemente tramite documenti in forma di file scaricati da server, o inviati per posta elettronica - non c' era http, ma non c' erano nemmeno gli ipertesti in linea, poi concretizzatisi come pagine html contenenti oggetti embedded e hyperlink (interni od esterni)
che mi risulti (ed è importante tenere presente che) l' html è fin dall' inizio andato di pari passo con http, e non si sarebbe mai passati attraverso richieste di singoli file per la ricezione dell' ipertesto e degli elementi collegati, visualizzati attraverso un' applicazione ad hoc e ricevuto tramite un protocollo ad hoc
71104
02-11-2007, 14:56
be però se la connessione su cui si effettua l' autenticazione è sicura difficilmente 3 parti acquisiranno i dati necessari a prelevare aggratis il file dal server infatti non potranno farlo leggendo quello che passa sulla connessione di controllo (non con gli odierni mezzi tecnologici; tra una ventina d'anni, forse...), ma potrebbero esistere altre... "clues", percui a seconda del contesto la third party potrebbe venire a sapere che in un dato momento quel server FTP non vede l'ora di sputare quel file su quella porta.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.