Web Version
Print Version
Esercitazioni (Risposte)
Esempi di configurazioni

Livebook: Guida ai protocolli Internet

Breve guida ai principali protocolli Internet: dal livello fisico, al network, dal trasporto ai vari protocolli applicativi. A cura di Arnaldo "Homer" Zitti.

Scheda Corso

ProgrammaGiorni0TargetSystem & Network Administrator Junior e tecnici informatici che intendono chiarire ed approfondire la propria conoscenza sui principali protocolli che stanno alla base di Internet.PrerequisitiConoscenza di base di Internet e dei sistemi operativi.ObiettivoMateriali

Programma

Networking e TCP/IP

Introduzione all'Internetworking.
I protocolli che stanno alla base di Internet: IP e TCP/UDP

Obiettivo:
Avere ben chiara la logica a livelli dei protocolli usati su Internet.

Introduzione a INTERNET

Introduzione a Internet e ai suoi utilizzi. Per principianti.

Internet e la famiglia dei protocolli TCP/IP

Visione d'insieme dei protocolli alla base di Internet: IP, TCP, UDP.

I protocolli di routing

Overview dei protocolli di routing: esterni (BGP) e interni (RIP, OSPF, EIGRP)


Protocolli a livello applicativo

Rassegna dei più comuni protocolli a livello applicativo.

Obiettivo:
Avere una idea di base della sintassi e della logica dei principali protocolli applicativi.

I protocolli HTTP e HTTPS

HyperText Transfer Protocol: sintassi, headers, URI e methods. Introduzione a HTTPS.

Il protocollo SMTP

Simple Mail Transfer Protocol: sintassi base

I protocolli POP3 e IMAP

Post Office Protocol e Interactive Mail Access Protocol: sintassi

Il protocollo DNS

Domain Name System: Logica e sintassi base.

I protocolli FTP e TFTP

File Transfer Protocol: sintassi e logica. Introduzione a TFTP (Trivial File Transfer Protocol)

Il protocollo Telnet

Introduzione al protocollo Telnet

Il protocollo CIFS/SMB

Common Internet File System / Server Message Block

Il protocollo NFS

Network File System: Introduzione

Il protocollo SNMP

Simple Network Management Protocol: logica, sintassi e MIB



Networking e TCP/IP


Introduzione a INTERNET

Introduzione a Internet e ai suoi utilizzi. Per principianti.

Internet: introduzione alla Rete delle Reti

Autore: homer - Ultimo Aggiornamento: 2003-09-13 22:47:58 - Data di creazione: 2003-09-13 22:47:58
Tipo Infobox: DESCRIPTION - Skill: 1- NOVICE

Cavi che percorrono incredibili distanze cablando il pianeta, un'infinità di computer interconnessi tra loro, il più grande contenitore di informazioni di ogni tipo, una miriade di possibilità di comunicazione: Internet.

CENNI STORICI  
Internet trova le sue radici in un progetto miltare risalente agli inizi della guerra fredda, intorno al 1962. Gli Stati Uniti formarono l'ARPA (Advanced Research Projects Agency) con lo scopo di gestire studi tecnologici per uso militare. L'obbiettivo degli USA era quello di creare un metodo che permettesse, anche in seguito ad un attacco nucleare, di mantenere la possibilità di comunicare con con le forze armate.

Il risultato degli studi in questo senso, fu la creazione di una rete a commutazione di pacchetto, in cui i dati trasmessi, suddivisi in piccole unità (datagrammi) indipendenti tra loro, potessero giungere a destinazione tramite differenti percorsi. La rete, doveva implementare un metodo, qualora non fosse possibile utilizzare un determinato percorso, che consettisse di trovarne uno alternativo per far giungere le informazioni a destinazione.

Questo network prese inizalmente il nome di ARPAnet, ed i primi collegamenti furono realizzati tra Università. Il protocollo in uso in quel tempo era NCP (Network Control Protocol). Nel 1972, ARPAnet comprendeva 32 nodi, i collegamenti erao a 50Kbps. Alcuni programmi per lo scambio di comunicazioni tra utenti (tipicamente tra professori universitari) cominciavano a diffondersi. Poco dopo l'ARPA veniva ribattezzata DARPA (Defence Advanced Research Projects Agentcy).

Nel 1973, iniziò lo sviluppo della suite di protocolli TCP/IP con il fine di interconnetere differenti tipi di reti.

L'utilizzo crescente per scopi pubblici di ArpaNET portò nel 1983, alla sudddivisione in ARPAnet e MILNET (Military Network) per evidente diversità di scopi. Conseguentemente alla crescita di ARPAnet fu necessario sviluppare un nuovo metodo per permettere la comuncazione tra i vari nodi. Nacque il DNS (Domanin Name Space) il quale permetteva un metodo automatico per indicare ai dati in transito l'indirizzo del destinario. In precedenza ogni host doveva possedere un file contentente tutti i nomi dei possibili host destinatari.

La NSF (National Science Foundation) posando le nuove linee T1 (a 1,544 Mbps) mise le basi per un ulteriore sviluppo di ARPAnet la quale prese il nome di NSFNET. Venne migliorato il protocollO TCP/IP e di pari passo ed introdotto NNTP (Network News Transfer Protocol). L'utenza in crescita, richiedeva ancora un incremento di banda. ANS (Advanced Network System) fu incaricata di posare nuove linee per la dorsale Internet di tipo T3 (a 45 Mbps).

Durante il corso dell'aggiornamento alle nuove linee il dipartimento della difesa abbandona definitivamente ARPAnet. Viene in seguito fondata InterNIC come organo di controllo dei servizi Internet e si fa strada la nuova tecnologia di dorsale ATM (Asynchronous Transfer Mode) con velicità di 145 Mbps. Nel 1996 NFS privatizza la dorsale e dà l'incarico ad alcune società di fornire l'accesso ad Internet.

Attualmente diversi provider indipendenti si occupano di gestire la maggior parte del traffico. L'evoluzione di software e protocolli così come l'incremento degli utenti è ancora costante. Tra le tappe future, visto lo scarseggiare di indirizzi di rete, l'adozione della nuova suite di protocolli IPv6 in sostituzione di IPv4.

UTILIZZARE INTERNET
Grazie allo sviluppo di Internet, il periodo attuale è stato definito era delle comunicazione globale. Comunicazione che puo' avvenire in tempo reale e non, per lavoro o per diletto e in diverse forme. Grazie alla Rete è possibile trovare, pubblicare e scambiare informazioni relative ai più disparati argomenti in svariati modi:

World Wide Web: è per molti sinonimo di Internet, in quanto rappresenta il servizio più conosciuto. La maggiorparte dei contenuti sulla Rete, viene offerta mediante questo tipo di media, le cui pagine  danno forma a molteplici tipologie di siti: Portali tecnico-informatici, di medicina, per la ricerca di lavoro, servizi di Home Banking, Virtual Shop, o Weblog sono solamente alcuni dei possibili contenuti. Il web è la più grande ragnatela globale di informazioni, organizzata in ipertesti, i quali possono essere collegati tra loro. La ricerca delle informazioni, avviene solitamente tramite i cosiddetti motori di ricerca (Google, Altavista ecc) i quali offrono una guida nell'enorme quantità di dati disponsibili.

Posta Elettronica: tra le applicazioni più diffuse vi è senz'altro l'E-Mail, usata ogni giorno da milioni di persone per lavoro, o semplicemente come mezzo di comunicazione in luogo delle tradizionali lettere cartacee. Grazie alla posta elettronica è possibile infatti inviare e ricevere quasi istantaneamente messaggi contenenti testi, immagini suoni o allegati di varia natura quali fogli elettronici, disegni Cad, programmi ed altro.

Mailing List: si basano sull'utilizzo della posta elettronica. Iscrivendosi ad una maling list di proprio interesse (ne esistono su svariati argomenti) si ricevono periodicamente email contenenti informazioni riguardanti l'argomento desiderato.

Newsgroup: una sorta di bacheca elettronica sulla quale postare e leggere messaggi inerenti ad argomenti di interesse comune. Tramite un newsgroup client è possbile sottoscrivere l'iscrizione al gruppo di proprio interesse e leggere o scrivere messaggi discutendo con gli altri partecipanti. I newsgroup, anche chiamati gruppi di discussione, sono disponibili collegandosi ad un news server e sono organizzati in modo gerarchico. Alcuni esempi di newsgroup sono it.lavoro.informatica in cui si discute di informatica (.informatica), in relazione ai rapporti di lavoro (.lavoro) ed in italiano (.it).

Transferimento di file: il quale permette di scaricare programmi, immagini, file musicali in MP3, Video MPEG da appositi server o siti in rete, oppure trasferire su server in Internet i propri file per esempio al fine di costruire un sito web.

Chat e Instant Messaging: Le chat nate grazie allo sviluppo del protocollo IRC nel 1985, permettono di comunicare in tempo reale, collegandosi ad un IRC server. Su un IRC Server gli utenti posson formare dei canali e riunirsi. L'evoluzione dei software di chat possono essere rappresentate da quelli Instant Messaging, in quali permettono di identificare l'utente in modo univoco e di recapitare i messaggi anche qualora il destinatario non fosse in quel momento collegato.

Stream Audio Video: La diffusione crescente della banda larga, permette un'utilizzo più multimediale della rete, quindi non solamente testo e immagini statiche ma anche video ed audio come per esempio la possibilità di effettuare videoconferenze oppure seguire progammi televisivi scelti dall'utente (Tv on demand) e utilizzare il telefono.

Internet è comunque un mondo in continuo movimento, sia per quanto riguarda i contenuti, che i media tramite i quali vi si accede.

Usare Internet: panoramica sui software ed i protocolli

Autore: carlo - ( Revisione: homer ) - Ultimo Aggiornamento: 2003-10-31 17:45:38 - Data di creazione: 2003-10-31 17:45:38
Tipo Infobox: DESCRIPTION - Skill: 1- NOVICE

Fruire dei contenuti della Rete, e comunicare tramite essa, è possibile grazie a diversi software e protocolli che permettono lo scambio di molteplici tipi di informazioni.

WEB  
Le pagine Web, scritte in linguaggio HTML (Hyper Text Markup Language), vengono visualizzate da un applicazione chiamata Web Browser o più semplicemente Browser, il quale avvalendosi del protocollo HTTP (Hyper Text Transfer Protocol) o HTTPS trasferisce i dati da un Web Server (un host in rete sul quale è in funzione un software che fornisce le pagine richieste) ai Web Browser, ovvero i client in funzione sui computer degli utenti.

Nella sua forma base, un Web Server è un computer generalmente online 24 ore su 24 (come ogni server su Internet), ha un indirizzo IP fisso a cui è associato un nome tipo www.dominio.com e, tramite un software dedicato (Apache, IIS, Zeus...) non fa altro che fornire file ai client che li richiedono.
Questi file sono tipicamente sia immagini (di solito in formato GIF e JPEG) e pagine HTML, che normali file ASCII contenenti il testo di un linguaggio di programmazione ipertestuale che permette di formattare testo, grafica e link all'interno di schermate visualizzabili dal browser. Il gran numero di server web, i quali contengono una enorme quantità di pagine html che a loro volta includono innumerevoli link ipertestuali che collegano altre pagine, costituiscono l'ossatura di questa ragnatela globale che collega logicamente pagine e server fisicamente dislocati in ogni parte del globo.

Tra i Web Browser più conosciuti è possibile annoverare tra i piu anziani, Netscape Navigator ed Explorer  mentre tra i più recenti troviamo nomi come Mozilla, Opera, Safari o Firebird. Browser che si sono evoluti nel tempo, passando da semplice supporto per la visualizzazione del testo, a quello per la grafica, all'utilizzo come client FTP ed alla gestione di stream audio e video.

E-MAIL
La scrittura, l'invio e la ricezione dei messaggi di posta elettronica E-Mail (Electronic Mail) avviene tramite un software chiamato Mail Client. L'utente destinatario del messaggio viene individuato tramite il suo E-Mail Address (Indirizzo di posta elettronica) scritto nella forma nome@dominio (Es. [email protected]).Il client di posta  grazie al protocollo SMTP (Simple Mail Transfer Protocol) lo inoltrerà ad un mail server il quale provvederà a recapitarlo a destinazione. Sempre grazie al client di posta, una volte connesso propria mailbox tramite i protocolli POP3 (Post Office Protocol versione 3) oppure IMAP (Internet Message Access Protocol), è possibile leggere i messaggi ricevuti.

Tra i client di posta elettronica abbiamo software quali Eudora, Outlook, Mozilla Mail, Kmail, Evolution, oppure il recente Thunderbird. La quasi totalità dei fornitori di caselle di posta, permette oggi di accedere alla propria mailbox anche tramite browser, grazie allo sviluppo di apposite interfacce web.  

NEWSGROUP  
La consultazione dei newsgroup avviene contattando un news server tramite un news client, scaricandone l'elenco e sottoscrivendo quelli di proprio interesse. Il protocollo utilizzato prende il nome di NNTP (Network News Protocol).  

I news client, possono essere incorporati all'interno di un client di posta come nel caso di Outlook, Mozilla o Thunderbird oppure come Knode o Free Agent sviluppati apossitamente per lo scopo. vengono utilizzati per visualizzare i messaggi sui newsgroup (Gruppi di discussione) la cui rete era originariamente chiamata Usenet.

FILE TRANSFER  
Sebbene l'utilizzo di Internet comporti praticamente sempre il trasferimento di informazioni e file anche senza che l'utente ne sia consapevole (HTTP per esempio), esistono software e protocolli specificatamente sviluppati per questo scopo, si tratta di FTP (File Transfer Protocol) e di TFTP (Trivial File Transfer Protocol).
Il primo più largamente usato, mentre il secondo utilizzato per compiti particolari quali il trasferimento di configurazioni e file su router o su stampanti in ambito LAN.

SESSIONI REMOTE  
Un possibilità forse poco utilizzata attualmente da un utente Internet è quella di instaurare una sessione di lavoro in remoto tramite Telnet, il quale è sia il nome del software lato client e server, sia il nome del protocollo che viene utilizzato per l'emulazione di terminale.

Il suo utilizzo riguarda ormai principalmente la connessione a server o router per da parte di un amministratore di sistema al fine di gestirne la configurazione. Preferito a Telnet per maggior sicurezza è SSH (Secure Shell) che permette di utilizzare un terminale remoto in modo protetto grazie alla crittografia.

CHAT e INSTANT MESSAGING, VIDEOCONFERENZA, TV ON DEMAND e TELEFONIA  
Tra le opportunità che la rete offre ai propri utenti c'è la comunicazione in tempo reale, possibile con limitate risorse in termini di banda per quanto riguarda Chat e Messengers, decisamente più avara di risorse per quanta riguarda la Videoconferenza, o la Tv on Demand o la telefonia.

Una sessione di chat si svolge collegandosi ad un IRC Server (a sua volta collegato in rete con altri server). Il protocollo utilizzato da questo servizio prende il nome di IRC (Internet Relay Chat). Tra i client più diffusi possiamo trovare mIRC, X-Chat, Bigfun, Pirch o KVirc. Anche in questo tipo di servizio si sono inseriti i browser che permettono di utilizzare chat appositamente create solitamente tramite tecnologie Java chiamate Web-Chat.
  
Tra i programmi di messaggistica, una sorta di evuluzione delle chat, i nomi più diffusi sono ICQ, AOL, MSN, Yahoo Messenger o C6.

Per l'utilizzo dei programmi di videoconferenza è necessario avere microfono, webcam e scheda audio ed una sufficiente ampiezza di banda al fine di ottenere una chiara comunicazione con gli altri partecipanti. Tra i software utilizzati in questo campo: CU-SeeMe, NetMeeting oppure GnomeMeeting su Linux.

Per quanto riguarda invece la Tv on demand vengono utilizzati hardware di tipo particolare come per esempio i decoder ed altri apparati dedicati i quali con l'ausilio di un televisore e grazie a collegamenti in fibra ottica o ADSL permettono la visualizzazione dei programmi scelti dall'utente.

La telefonia tramite Internet avviene grazie alla tecnologia Voice Over IP, la quale permette inviare su reti IP lo voce con pacchetti ad altissima priorità.

DNS  
Dietro le quinte, lavora il protocollo DNS (Domain Name System) il quale grazie ai DNS Server permette di associare ad un URL come per esempio www.coresis.com oppure irc.tin.it un indirizzo IP grazie al quale computer dell'utente può raggiungere la risorsa desiderata.

La posta elettronica

Autore: carlo - Ultimo Aggiornamento: 2003-10-31 17:46:03 - Data di creazione: 2003-10-31 17:46:03
Tipo Infobox: DESCRIPTION - Skill: 1- NOVICE

Come funziona e come si usa.

La posta elettronica permette, ad un utente connesso alla rete Internet, di inviare e ricevere messaggi in formato elettronico, scambiando così informazioni con altri utenti possessori di caselle di posta elettronica (e-mail).
Qualsiasi sistema che gestisce la posta Internet avrà un programma di mail installato. Tutti i programmi di mail hanno un insieme di comandi che vi consentono di inviare e ricevere posta, ma sono diversi nelle loro capacità di comporre, modificare e gestire i messaggi. Alcuni richiedono che componiate il messaggio come un file fuori dal programma di mail, e alcuni non vi permettono di modificarlo prima dell'invio. Altri, tuttavia, forniscono caratteristiche molto più amichevoli come l'editing a pieno schermo, cartelle elettroniche con nomi in cui memorizzare e organizzare i messaggi ricevuti, e varie utilità di ordinamento e ricerca per aiutarvi nella gestione dei vostri messaggi (come ad esempio Outlook o Eudora).
Il software di posta elettronica spesso contiene funzioni basate su quelle della posta tradizionale. Potete inviare un messaggio come copia per conoscenza semplice (carbon copy cc), trasferire ad altri un messaggio ricevuto (forwarding) e rispondere (reply). La funzione di risposta avrà un metodo per estrarre l'indirizzo del mittente, per aiutarvi a inviare un messaggio di risposta senza dover digitare l'indirizzo o l'argomento.
State attenti con questa funzione, dato che potreste aver ricevuto il  messaggio tramite una lista o un'altra persona, e la risposta potrebbe andare alla persona sbagliata. Ogni mailer gestisce la funzione di risposta in modo diverso; alcuni mailer risponderanno al mittente, altri risponderanno all'indirizzo indicato nel campo From:
Leggete la documentazione del programma per i dettagli di funzionamento.
Inoltre, molti programmi di mail vi permettono di scorrere rapidamente i messaggi esistenti per argomento e mittente, di stampare i messaggi e di metterli in una cartella "pattumiera" (trash) finché non uscite dal programma (invece di sbarazzarvene immediatamente).
La maggior parte dei sistemi di mail vi avvisa inoltre se avete della posta in attesa quando fate login.
Gli indirizzi di posta elettronica seguono questo schema: persona@dominio.
Il carattere @, detto familiarmente "chiocciolina", significa "at", in inglese "presso" , e divide l'identificazione del destinatario (user-id) dal dominio sul quale il destinatario stesso riceve la posta. Quindi: [email protected] è l'indirizzo del signor Pippo che riceve la posta sul dominio rete039.it, all'interno di questo "dominio" ci sono poi dei server specializzati che gestiscono la posta, nel caso specifico sono mail.rete039.it. Lo spazio server dedicato alla casella postale del signor Pippo è riservato e lui potrà accedervi utilizzando la password che gli è stata comunicata dal provider insieme all'indirizzo. I messaggi vengono registrati nella mail box del signor Pippo e potranno essere letti e trasferiti sul suo computer ogni volta che si attiva il collegamento. Quando si invia un messaggio è possibile trasmettere non solo un semplice testo ma anche testi elaborati, fogli elettronici, immagini, ecc. Più precisamente questo tipo di file possono essere inviati per mail come allegati al messaggio (in inglese: attachment).
Ma come funziona questo servizio?
Il sistema di posta elettronica è in realtà diviso in tre parti:
una che si occupa della consegna dei messaggi (protocollo SMTP),
una che mantiene i messaggi nella casella di posta del server e li presenta a richiesta al proprietario della casella, o mailbox, (protocolli POP3 e IMAP) e, infine,
un programma sul computer dell'utente che si occupa della spedizione e della lettura della posta dalla casella di posta elettronica (client).
Per fare un'analogia con la posta ordinaria (che, contro tutte le apparenze, funziona in modo molto simile) il client di posta corrisponde (a secondo dei casi) al mittente o al destinatario: se deve spedire qualcosa, cerca una buca delle lettere (server SMTP), vi infila la corrispondenza che verrà prelevata e portata a destinazione del sistema postale. Dal punto di vista di chi riceve, l'unica cosa da fare è controllare periodicamente la propria cassetta delle lettere (mailbox POP3 o IMAP) per vedere se vi è stato inserito qualcosa.

Cosa sono gli URL

Autore: carlo - Ultimo Aggiornamento: 2003-11-03 14:19:42 - Data di creazione: 2003-11-03 14:19:42
Tipo Infobox: DESCRIPTION - Skill: 1- NOVICE

E' grazie agli URL (Uniform Resource Locator) che i navigatori possono accedere alle informazioni del World Wide Web.
Il problema è che non esiste un indice principale, un unico punto di riferimento, che racchiuda in se tutte le risorse e le informazioni disponibili su Internet, quindi per recuperare una specifica informazione si possono utilizzare diversi protocolli e metodi.

I protocolli in questione sono:
HTTP = HyperText Transfer Protocol. Protocollo di trasferimento di ipertesto, quello che viene più utilizzato nel WWW.
FTP = File Transfer Protocol. Protocollo di trasferimento di file.
GOPHER = Gopher. Progenitore dell'HTTP, ormai poco usato.
TELNET = Telnet. Protocollo per accedere, tramite interfaccia testuale, ad un host (computer) remoto.
NEWS = Network News Transfer Protocol. Protocollo di trasferimento delle news.

Ciascun tipo di protocollo ha un formato leggermente diverso per identificare univocamente la locazione di una risorsa.

HTTP e FTP
Questi due protocolli hanno lo stesso formato in quasi tutti i casi.
Locazione risorsa=//nome_server/percorso_documento
ad esempio per individuare, tramite protocollo HTTP, il file pippo.htm, contenuto nella directory mio sul server xxx.yyy.it si utilizzerà l'URL:
http://xxx.yyy.it/mio/pippo.htm.

Gopher
Il campo tipo è un singolo carattere che viene utilizzato dal protocollo Gopher per determinare il tipo di documento (quello predefinito è 1). Il resto del percorso è il documento o la stringa del selettore di risorse, come descritto nel protocollo Gopher.
Ad esempio, per accedere al documento principale sul server gopher.biz.com, si utilizza l'URL
gopher://gopher.biz.com/1

Telnet
Sulla maggior parte dei sistemi aprendo un URL di Telnet si lancia semplicemente un'applicazione esterna di telnet e ci si può connettere da lì.
Locazione risorsa=//nome_utente:password@nome_del_server
ad esempio per collegarsi a xxx.yyy.it come mariorossi si utilizza l'URL
telnet://[email protected]

News
Per la maggior parte dei programmi di ricerca si deve impostare una preferenza che indica quale server richiedere per gli URL di News. Ogni server ha i propri identificatori per ciascun articolo, quindi è meglio prima chiedere un elenco di articoli correnti omettendo le parole chiave primo e ultimo.
Locazione risorsa=gruppo di lettura delle news: primo articolo-ultimo articolo
Ad esempio per chiedere gli articoli in alt.flame si utilizza l'URL
news:alt.flame


Internet e la famiglia dei protocolli TCP/IP

Visione d'insieme dei protocolli alla base di Internet: IP, TCP, UDP.

Il modello ISO/OSI

Autore: Ariel - ( Revisione: homer ) - Ultimo Aggiornamento: 2003-09-02 12:33:29 - Data di creazione: 2003-09-02 12:33:29
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Verso la fine degli anni '70 la ISO (International Standard Organization) con lo scopo di uniformare la comunicazione anche tra reti progettate da case diverse, sviluppò un modello standardizzato, chiamato modello di riferimento OSI (Open System Interconnection).

Il modello di riferimento OSI descrive il modo in cui le informazioni vengono trasferite tra gli host in rete tramite 7 livelli (layer): Application, Presentation, Session, Transport, Network, Data Link, Physical.

- Application layer (livello applicazione): è il livello più vicino all'utente e si occupa di fornire i servizi di rete (ad esempio il traferimento di file o la posta elettronica). Tra i protocolli che fanno parte di questo livello abbiamo: SMTP (Simple Mail Transfer Protocol) il quale si occupa del trasferimento dei messaggi di posta elettronica, HTTP (Hypertext Transfer Protocol) per l'interconnessione con siti web, TELNET il quale svolge le operazioni necessarie a creare una sessione con un host remoto, FTP (File Transfer Protocol) che permette il traferimento dati attraverso la rete tra due host, POP3 (Post Office Protocol v3) per il download dei messaggi di posta, IMAP (Internet Mail Access Protocol) un protocollo relativo alla posta, ma più avanzato e complesso, NNTP (Network News Transfer Protocol) che permette di leggere e scrivere informazioni su Usenet;

- Presentation layer (livello presentazione): gestisce le conversioni tra formati di dati, cioè definisce una codifica indipendente dalla macchina utilizzata allo scopo di creare un formato standard comprensibile da tutti. Se necessario, sono utilizzate anche la funzioni di compressione e crittografia;

- Session layer (livello sessione): definisce le regole per aprire e chiudere una connessione logica riguardante il trasferimento dati tramite protocolli di connessione e comunicazione. In questo layer sono svolte anche funzioni di sicurezza al fine di garatire che due host siano autorizzati a comunicare tra loro. Tra i protocolli di questo layer troviamo NFS (Network File System), RPC (Remote Procedure Call), X Window;

- Transport layer (livello trasporto): assicura la corretta trasmissione dei dati segmentando il flusso proveniente dal livello superiore in porzioni di dimensione prevista dal supporto utilizzato dalla rete. Inoltre fornisce un riscontro delle trasmissioni e nel caso in cui si verifichino errori provvede a reinviare i dati. I protocolli caratteristici di questo layer sono TCP e UDP;

- Network layer (livello rete): si occupa di trovare il percorso migliore per il trasferimento dati tra host. Suddivide i dati in pacchetti che verranno poi instradati in un determinato percorso stabilito tramite degli algoritmi che analizzano le condizioni di traffico della rete. Tra i protocolli che sono coinvolti nelle funzioni svolte da questo livello abbiamo: IP (il quale si occupa dell'instradamento dei dati) e ICMP (si occupa della gestione degli errori ed il controllo dei messaggi) e protocolli di routing quali ad esempio RIP (Routing Information Protocol), IGP (Internet Gateway Protocol), oppure OSPF (Open Shortest Path First);

- Data link layer (livello collegamento dati): provvede ad organizzare i dati in blocchi di lunghezza predefinita chiamati frame ed effettua i primi controlli sulla validità tramite CRC (Cyclic Redundancy Check). Inoltre in questo strato sono definite le tecniche di sincronizzazione cioè le modalità per evitare che siano inviati dati ad una velocità incompatibile alla capacità di acquisizione del destinatario oppure che in una trasmissione bidirezionale i due nodi trasmettano contemporaneamente. Il Data link layer è suddiviso in due sottostrati: LLC (Logical Link Control) il quale si occupa del controllo errori e lavora a con il Network layer e MAC (Media Access Control) che fornisce l'accesso al mezzo trasmissimo (il cavo) e lavora quindi a stretto contatto con il Physical layer;

- Physical layer (livello fisico): gestisce l'interazione tra il computer e il mezzo trasmissivo e si occupa della conversione tra bit e segnali.

Le informazioni che vengono scambiate da un layer all'altro sono chiamate PDU (Protocol Data Unit). I dati del livello superiore vengono incpasulati come informazioni dallo strato inferiore.
Un esempio di processo:

1. I dati utente (Es. E-mail) vengono convertiti in un formato dati trattabile via rete;
2. I dati convertiti, a loro volta vengono trasformati in segmenti, quindi spediti tramite TCP o UDP ad un host remoto;
3. I segmenti vengono quindi incapsulati in pacchetti ai quale viene aggiunto l'indirizzo di partenza e di destinazione;
4. I pacchetti sono convertiti in frame a seconda del mezzo trasmissivo;
5. I frame sono convertiti in bit ed inviati via cavo.
Processo che dal punto di vista di Layer e PDU è il seguente:
[Dati] - in Application
[Dati] - in Presentation
[Dati] - in Session
[TCP o UDP Header][Dati] - in Transport (PDU = segmenti)
[IP Header][Dati] - in Network (PDU = pacchetti)
[LLC Header][Dati] - in Data Link (LLC) (PDU = frame)
[MAC Header][Dati] - in Data Link (MAC) (PDU = frame)
[010101] - in Physical (PDU = bits)

Una volta che i dati sono giunti a destinazione il processo viene ripetuto in senso inverso. Ogni layer estrae i dati che deve elaborare estrapolandoli dal relativo PDU.

Il modello TCP/IP

Autore: Ariel - ( Revisione: homer ) - Ultimo Aggiornamento: 2003-09-02 12:34:09 - Data di creazione: 2003-09-02 12:34:09
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Il modello TCP/IP, il quale prende il nome da i due protocolli principali di Internet progettati nel 1974 da Robert E. Kahn e Vinton G. Cerf a Berkeley, descrive il processo di trasmissione dati riassumendo i 7 livelli del modello ISO/OSI.

- Application (Applicazione): rappresenta i layer Application, Presentation e Session del modello OSI. Questo livello si occupa di fornire alle applicazioni (FTP, Telnet, Mail) i servizi di rete, compresi la rappresentazione dei dati, ed il mantenimento di sessioni;
- Transport (Trasporto): rappresenta l'omonimo layer del modello OSI. Questo livello si occupa del trasporto attraverso i protocolli TCP (Transmission Control Protocol) di tipo connection-oriented e UDP (User Datagram Protocol) di tipo connectionless permettendo quindi di stabilire comunicazioni tra due host;
- Internet (Internet): rappresenta il layer Network del modello OSI. Questo livello si occupa di indirizzare, suddividere e  instradare i pacchetti sulla rete. Il protocollo IP lavora in questo layer offrendo un metodo di indirizzamento ed un tipo di trasmissione connectionless;
- Network (Rete): rappresenta i layer Data Link e Phisical del modello OSI, lavora a stretto contatto con l'hardware. Questo livello si occupa di prelevare ed immetere i frame dati, diversi a seconda della tipologia di rete, sul cavo di rete e di controllarne la correttezza tramite un algoritmo CRC (cyclic redundancy check). Rispetto al modello ISO/OSI  non ci sono distinzioni tra schede di rete e driver con il vantaggio di poter implementare TCP/IP su ogni tipo di rete;

Un modello organizzato in questo modo presenta diversi vantaggi, infatti un nuovo protocollo in uno qualsiasi dei layer TCP/IP deve interagire solamente con quello adiacente a livello superiore od inferiore, semplificando e conseguentemente riducendo la possibilità di errori nello sviluppo e nella gestione.

Il protocollo IP

Autore: Ariel - ( Revisione: homer ) - Ultimo Aggiornamento: 2003-09-08 15:01:30 - Data di creazione: 2003-09-08 15:01:30
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Il protocollo IP si occupa di fornire un metodo di indirizzamento logico e di gestione frammentazione/riassemblaggio per la trasmissione dati tra gli host di una rete.

Il protocollo IP, descritto nella RFC 791, nasce negli anni '70 grazie a una serie di ricerche fatte dalle università americane su richiesta del ministro della difesa, allo scopo di realizzare una rete in grado di trasportare diversi tipi di informazioni. L'IP protocol definisce una tecnica di trasmissione dati non orientata alla connessione (connectionless) e senza riscontro (non c'è garanzia che i pacchetti giungano a destinazione e nella sequenza corretta). Esso prevede che le informazioni vengano strutturate in unità chiamate datagrammi IP (IP datagram), di lunghezza massima 65535 byte, suddivise in  due aree: il campo dati (data) che contiene il messaggio da inviare e l'intestazione (header) che contiene le informazioni necessarie per instradare il pacchetto.

HEADER IP
L'intestazione di un pacchetto IP è suddivisa nei seguenti campi:
Version: campo di 4 bit,  descrive la versione del protocollo;
IHL: campo di 4 bit, definisce la lunghezza dell'intestazione. Il campo IHL(Internet Header Lenght) viene sottratto da Packet Lenght per determinare l'inizio dei dati;
Service Type: campo di 8 bit, che definisce le caratteristiche del servizio in Precedence (importanza del pacchetto),
Delay, Throughput, Reliability (informazioni per il trasporto, servono a determinare il percorso che il pacchetto farà);
Packet Lenght: campo di 16 bit, definisce la lunghezza totale del pacchetto (Intestazione+Dati);
Packet Fragmentation: è formato da tre campi, identification di 16 bit , flags di 3 bit e fragment offset di 13 bit i quali permettono di suddividere il pacchetto in unità più piccole quando esso deve passare attraverso una rete che prevede frame di dimensioni minori, e di essere ricostruito all'uscita dalla rete;
Time-to-live (TTL): campo di 8 bit, definisce il tempo massimo di permanenza del pacchetto nella rete, ad ogni hop (router attraversato) il suo valore diminuisce di uno, una volta riaggiunto il valore zero il pacchetto viene scartato;
Protocol: campo di 8 bit, definisce il protocollo ad alto livello utilizzato per creare il messaggio contenuto nel campo dati (TCP, UDP, ICMP ecc);
Header Checksum: campo di 16 bit, definisce un checksum per il controllo della correttezza dei dati contenuti nell'intestazione del pacchetto;
Ip Address Source: campo di 32 bit, contiene l'indirizzo IP del mittente;
Ip Address Destination: campo di 32 bit, contiene l'indirizzo IP del destinatario;
Options: campo di dimensioni variabili, è opzionale, contiene informazioni sulle operazioni che devono essere effettuate durante il percorso;
Padding: campo di dimensioni variabili, è utilizzato per far raggiungere all'area d'intestazione una dimensione di 32 bit o un suo multiplo;
Data: i dati trasportati dal protocollo.

Indirizzi IP, classi e Subnetting

Autore: homer - Ultimo Aggiornamento: 2006-03-10 19:21:23 - Data di creazione: 2004-06-30 13:04:21
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

L'indirizzamento IP permette di identificare ogni host all'interno di una rete TCP/IP. Grazie all'utilizzo delle classi di indirizzi ed al subnetting è possibile organizzare e gestire in modo più efficiente il proprio network.

Un indirizzo IP, chiamato anche indirizzo logico, rappresenta un identificativo software per le interfacce di rete, esso viene utilizzato in combinazione con l'indirizzo fisico (MAC), il quale consente di determinare in modo univoco ogni interfaccia di un dispositivo di rete. Un IP Address è un numero di 32 bit suddiviso in quattro gruppi da 8 bit ciascuno, la forma con la quale viene solitamente rappresentato è detta decimale puntata (Dotted Decimal).

Essendo ogni numero rappresentato da 8 bit, può assumere un range di valori da 0 a 255. Utilizzando 32 bit per indirizzo è possibile avere 4.294.967.296 combinazioni di indirizzi differenti. In realtà esistono alcuni indirizzi particolari, di conseguenza non tutti i valori sono disponibili al fine di identificare un host nella rete.

Un esempio di Ip Address:
         Rete.         Rete.        Rete.          Host
          192.          168.              5.                2 : Rappresentazione decimale
11000000.10101000.00000101.000000010 : Rappresentazione binaria

Questo è un esempio di indirizzo (Classe C) in cui 192.168.5 identifica la rete di appartenenza dell'host 2.

INDIRIZZI SPECIALI: NETWORK, BROADCAST E LOOPBACK
Esistono alcuni particolari indirizzi di rete che non possono essere assegnati per l'identificazione di un host, tra questi abbiamo:  network e broadcast e loopback:
- Network: quando i bit dell'ottetto che rappresenta l'host hanno tutti valore 0, l'indirizzo è detto di rete o Network Address: 192.168.5.0 oppure in binario 11000000.10101000.00000101.00000000;  
- 0.0.0.0: quando tutti i bit hanno valore zero, identificano "questo host";  
- Broadcast: quando i bit del numero che rappresenta l'host hanno tutti valore 1, l'indirizzo è detto di broadcast o broadcast address, e rappresenta tutti gli host di quella rete. Inviare un pacchetto all'indirizzo 192.168.5.255 o in forma binaria 11000000.10101000.00000101.11111111 equivale a mandare un pacchetto a tutti gli host della rete 192.168.5;  
- Broadcast di rete: abbiamo questo tipo di indirizzo quando tutti i bit, sia della parte relativa all'host sia della parte relativa alla rete hanno valore 1. Inviare un pacchetto a 255.255.255.255 o in binario 11111111.11111111.11111111.11111111 significa inoltrarlo verso tutti gli host della rete corrente;  
- Loopback: è utilizzato per funzioni di test del protocollo TCP/IP, non genera traffico di rete e corrisponde all'indirizzo 127.0.0.1;

CLASSI DI INDIRIZZI
Per permettere una migliore organizzazione della rete, gli indirizzi disponibili sono stati suddivisi in classi in base alle dimensioni del network da gestire. In questo modo si verrando utilizzate le classi più adatte ad alla dimensioni della rete, con conseguente minore spreco di ip address. Sono disponibili cinque classi di indirizzi IP, di cui solo le prime tre possono essere utilizzate per assegnare indirizzi agli host.

Indirizzi di classe A
Il valore del primo ottetto è compreso tra 1 e 126 (I primi otto bit di questo indirizzo saranno: 0*****).  
E' rappresentata da indirizzi di tipo: Rete.Host.Host.Host ovvero 8 bit per la identificare la rete (di cui il primo fisso) e 24 per identificare gli host. Permette di ottenere 126 reti formate da 16.774.214 host ciascuna.

Indirizzi di classe B  
Il valore del primo ottetto è compreso tra 128 e 191 (I primi otto bit di questo indirizzo saranno: 10*****).  
E' rappresentata da indirizzi di tipo: Rete.Rete.Host.Host ovvero 16 bit per la identificare la rete(di cui i primi due fissi) e 16 per identificare gli host. E' possibile ottenere 16.384 reti formate da 65.534 host ciascuna.
  
Indirizzi di classe C  
Il valore del primo ottetto è compreso tra 192 e 223 (I primi otto bit di questo indirizzo saranno: 110*****).  
E' rappresentata da indirizzi di tipo: Rete.Rete.Rete.Host ovvero 24 bit per la identificare la rete (di cui i primi tre fissi) e 8 per identificare gli host. E' possibile ottenere 2.097.152 reti con 254 host ciascuna.

Indirizzi di classe D
Il valore del primo ottetto è compreso tra 224 e 239 (I primi otto bit di questo indirizzo saranno: 1110****).  
Sono indirizzi di rete riservati ai gruppi multicast e non assegnabili ai singoli host.

Indirizzi di classe E  
Il valore del primo ottetto è compreso tra 240 e 255 (I primi otto bit di questo indirizzo saranno: 1111****).  
Sono indirizzi riservati per usi futuri.

LE SUBNET MASK
Per il corretto funzionamento di una rete, ogni host deve poter distiguere quale parte dell'indirizzo identifica l'host e quale la rete. Questo può avvenire grazie all'ausilio delle subnet mask (Maschere di sottorete). Per quanto riguarda le classi A B C standard, cioè non ulteriormente suddivise, esistono delle subnet di default:  
- Classe A: Rete.Host.Host.Host ha come subnet 255.0.0.0;  
- Classe B: Rete.Rete.Host.Host ha come subnet 255.255.0.0;  
- Classe C: Rete.Rete.Rete.Host ha come subnet 255.255.255.0;  

Il processo di messa in AND
Per determinare se il destinatario dei propri pacchetti si trova sulla propria sottorete ogni host utilizza la propria maschera di sottorete durante un processo chiamato di messa in AND (ANDing process). Questo processo consiste nel confrontare il risultato dell'operazione di AND (matematica booleana) bit a bit tra il proprio indirizzo e la propria maschera subnet mask con quello tra l'indirizzo del destinatario e la propria subnet mask.  

Avendo un Host A con IP 192.168.0.5 con subnet 255.255.255.0 che vuole inviare dei pacchetti ad un Host B 192.168.0.25 con subnet 255.255.255.0, esso deve determinare se B è sulla stessa sua sottorete:  

Host A: 192.168.0.5  
11000000.10101000.00000101.000000010 : Ip address Host A  
11111111.11111111.11111111.000000000 : Subnet mask Host A  
  
11000000.10101000.00000101.000000000 : Risultato operazione AND bit a bit  

Host B: 192.168.0.25  
11000000.10101000.00000101.000011001 : Ip address Host B  
11111111.11111111.11111111.000000000 : Subnet mask Host B  

11000000.10101000.00000101.000000000 : Risultato operazione AND bit a bit  

Il risultato è identico, quindi, i due host possono inviarsi direttamente i pacchetti in quanto sulla stessa sottorete. Qualora il processo di AND avesse evidenziato valori diversi, i due host non avrebbero potuto comunicare direttamente, ma sarebbe stato necessario un router tra di essi.

NOTAZIONI  
Esistono due principali notazioni attraverso le quali è possibile indicare un indirizzo IP:  
- Indicando espressamente la subnet mask:  
  49.22.5.3 255.0.0.0 - Classe A;  
  172.16.20.5 255.255.0.0 - Classe B;  
  192.168.15.4 255.255.255.0 - Classe C;  
- Indicando i bit che compongono la subnet mask:  
  49.22.5.3/8 - Classe A;  
  172.16.20.5/16 - Classe B;  
  192.168.15.4/24 - Classe C;  
  
SUBNETTING
L'utilizzo della classe di rete corrispondente alle dimensioni che più si avvicinano a quella che si vuole gestire a volte non è sufficiente. Può essere necessario, dover suddividere la rete in ulteriori sottoreti. Per fare questo è possibile utilizzare la tecnica del subnetting.
Il subnetting di una rete comporta diversi vantaggi:  
- Minor spreco di indirizzi: in quanto è possibile scegliere il numero di host che faranno parte della sottorete;  
- Riduzione del traffico di rete: in quanto si riduce il dominio di broadcast (broadcast domain);  
- Miglioramento delle performance della rete: in conseguenza della riduzione del traffico;  
  
Il subnetting consiste nell'utilizzare alcuni bit "presi in prestito" (borrowed) dalla parte host dell'indirizzo di rete. E' possibile procedere alla suddivisione della rete in sottoreti più piccole tramite lo scheda seguente:  
- Determinare il numero di sottoreti necessarie.  
E' necessario tenere presente che il numero di subnet che si possono creare è dato da 2^x-2 dove x è rappresentato dai bit presi in prestito dalla parte host dell'indirizzo ai quali naturalmente bisogna levare l'indirizzo di broadcast quello di rete non assegnabili. Esempio: utilizzando prendendo in prestito 4 bit, sarà possibile creare 14 sottoreti;  
- Determinare il numero di host per ogni sottorete.  
Questo valore è dato da 2^y-2 dove y è il numero di bit rimasti per la rappresentazione degli host; Esempio: se i bit rimanenti sono 6 si potranno avere sottoreti formate da 62 host l'una;  
- Determinare le subnet valide.  
Questo valore è dato da 256-z, dove 256 dove z rappresenta il valore della subnetmask. Esempio: con una subnetmask di valore 224 avremmo avuto 256-224=32. Questo valore è il valore della prima subnet valida ed è anche la base per le successive, la cui progressione sarà: 32, 64, 96, 128, 160, 192;  
- Determinare gli host validi.  
Sono rappresentati da tutti i valori compresi tra le subnet create togliendo gli indirizzi di broadcast e network;  
- Determinare degli indirizzi di broadcast e network delle subnet.  
Sono gli indirizzi in cui rispettivamente i bit della parte host sono settati a 1(broadcast) e a 0(network);

ESEMPIO SUBNETTING DI UNA RETE DI CLASSE C  
Esaminiamo il caso di una rete con IP 192.168.5.0 che da suddividere in due sottoreti.  
- Deteriminare il numero di sottoreti necessarie.  
Volendo creare 2 sottoreti è necessario utilizzare 2 bit dalla parte host in quanto 2^2-2 = 2. Avremmo quindi una subnetmask di questo tipo 255.255.255.192. E' possibile notare che in binario 192 equivale a 11000000, i primi due bit vengono utilizzati per le subnet ed i restanti 6 per gli host;  
- Determinare il numero di host per ogni sottorete.  
I bit rimasti per gli host sono 6 quindi, abbiamo 2^6-2=62 indirizzi di host validi per sottorete;  
- Determinare le subnet valide.  
Le subnet che si andranno a creare sono due con base data da 256-192=64. Questo significa che la progressione delle subnet valide sarà 64 e 128 ovvero 192.168.5.64 e 192.168.5.128.  
- Determinare gli host validi.  
Gli host validi sono rappresentati dai valori compresi tra le subnet esclusi gli indirizzi di broadcast e di network. Avremo quindi gli indirizzi da 192.168.5.65 a 192.168.5.126 per la prima subnet e 192.168.5.129 a 192.168.5.190 per la seconda;    
- Determinare gli indirizzi di broadcast e network delle subnet.  
Gli indirizzi di rete (bit della parte host settati a zero) saranno 192.168.5.64 per la prima subnet e 192.168.5.128 per la seconda, mentre gli indirizzi di broadcast (bit parte host settati a 1) saranno rispettivamente 192.168.5.127 e 192.168.5.191.

Tabella di riepilogo  
Rete di partenza: 192.168.5.0 255.255.255.0 suddivisa in due sottoreti tramite la subnet 255.255.255.192:  
Subnet 1: 192.168.5.64 in binario 11000000.10101000.00000101.01000000  
Primo indirizzo valido: 192.168.5.65 in binario 11000000.10101000.00000101.01000001  
Ultimo indirizzo valido: 192.168.5.126 in binario 11000000.10101000.00000101.01111110  
Broadcast: 192.168.5.127 in binario 11000000.10101000.00000101.01111111  
Subnet 2: 192.168.5.128 in binario 11000000.10101000.00000101.10000000  
Primo indirizzo valido: 192.168.5.129  in binario 11000000.10101000.00000101.10000001  
Ultimo indirizzo valido: 192.168.5.190 in binario 11000000.10101000.00000101.10111110  
Broadcast: 192.168.5.191 in binario 11000000.10101000.00000101.10111111  
  
Questo procedimento è lo stesso da applicare anche per il subnetting delle classi A e B, con la differenza di poter creare un maggior numero di subnet.

  
INDIRIZZI IP PRIVATI
Alcune classi di indirizzi, definite nella RFC 1918, vengono chiamati privati e sono utilizzati per le reti locali non connesse ad internet:  
Da 10.0.0.0.0 a 10.255.255.255.255  
Da 172.16.0.0 a 172.31.255.255  
Da 192.168.0.0 a 192.168.255.255  

Questi indirizzi non possono essere utilizzati in Internet, e sono riservati per utilizzi in reti interne. Qualora però un host all'interno di un lan si connetta ad internet il suo indirizzo verrà riscritto tramite NAT (Network Address Traslation) da un router od una macchina che fa da gateway verso Internet.

Porte & Socket

Autore: homer - Ultimo Aggiornamento: 2003-12-18 15:50:21 - Data di creazione: 2003-12-18 15:50:21
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Le porte ed i socket permettono di individuare e gestire quali sono gli host in comunicazione tra loro e tramite quale protocollo.

LE PORTE  
Ogni processo locale che comunica con uno remoto viene identificato in una connessione TCP/IP tramite una porta.
Una porta è rappresentata, all'interno di un pacchetto TCP o UDP, da un campo a 16 bit che può assumere un valore tra 0 e 65535.

E' possibile suddivere i tipi di porte in tre categorie:  
Well Known Ports: il cui valore va da 0 a 1023 sono assegnate a specifici protocolli dalla Internet Assigned Number Authority (IANA);  
Registered Ports: il cui valore va da 49151, sono registrate a nome delle società che hanno sviluppato specifiche applicazioni;  
Dynamic and/or Private Ports: il cui valore va da 49152 a 65535, non sono gestite da nessun organo di controllo, e vengono assegnate dinamicamenete, dal sistema operativo, quando un client si connette ad un host remoto;

I SOCKET  
La combinazione tra indirizzo IP, protocollo di trasporto e numero di porta prende il nome di Socket. Le condizioni per instaurare una connessione TCP sono due:  
- apertura passiva lato server, la quale indica al sistema operativo su quale porta vengono accettate le connessioni;  
- apertura attiva lato client, che richiede al sistema operativo l'assegnamento di una porta per connettersi all'host remoto;

WELL KNOWN PORTS  
Sebbene generalmente un'applicazione utilizzi solamente un protocollo tra TCP e UDP, vi sono dei casi come per esempio il protocollo DNS o altri in cui vengono utilizzati entrambi i protocolli. In quest'ultimo caso si avrà il medesimo numero di sia per quanto riguarda  TCP che per quanto riguarda UDP. Di seguito alcune tra le Well Known Port (porte note) più comuni:

Porte TCP  
  7 ECHO - Servizio Echo;      
 20 FTP DATA - File Transfer Protocol Dati;      
 21 FTP - File Transfer Protocol Controllo;  
 22 SSH - Secure Shell Remote Login Protocol      
 23 TELNET - Telnet Protocol;      
 25 SMTP - Simple Mail Transfer Protocol;      
 53 DNS - Server dei nomi di dominio;  
 67 BOOTPS - (Dhcp) Bootstrap Protocol Server;      
 68 BOOTPC - (Dhcp) Bootstrap Protocol Client;      
 80 HTTP - Hypertext Transmission Protocol;      
110 POP3 - Post Office Protocol 3;      
111 SUNRPC - Sun RPC Portmap;      
113 AUTH - Servizio autenticazione;      
119 NNTP - Network News Transfer Protocol;      
137 NETBIOS-NS - NETBIOS Name Service    
138 NETBIOS-DGM  - NETBIOS Datagram Service  
139 NETBIOS-SSN - NETBIOS Session Service  
143 IMAP - Internet Mail Access Protocol;      
389 LDAP - Lightweight Directory Access Protocol;  
443 HTTPS - http protocol over TLS/SSL;  
515 PRINTER - Spooler;      

Porte UDP  
  7 ECHO - Servizio Echo;      
 53 DNS - Server dei nomi di dominio;  
 67 BOOTPS - (Dhcp) Bootstrap Protocol Server;      
 68 BOOTPC - (Dhcp) Bootstrap Protocol Client;      
 69 TFTP - Trivial File Transfer Protocol;  
111 SUNRPC - Sun RPC Portmap;      
123 NTP- Network Time Protocol;      
137 NETBIOS-NS - NETBIOS Name Service;    
138 NETBIOS-DGM  - NETBIOS Datagram Service;  
139 NETBIOS-SSN - NETBIOS Session Service;  
161 SNMP - Simple Network Management Protocol (SNMP);
162 SNMP - TRAP Simple Network Management Protocol Trap;      
515 PRINTER - Spooler;  

Il protocollo UDP

Autore: homer - Ultimo Aggiornamento: 2003-09-02 12:34:47 - Data di creazione: 2003-09-02 12:34:47
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

E' un protocollo di trasporto di tipo connectionless, per la trasmissione dati tra due host.

UDP (User Datagram Protocol) viene descritto nella RFC 768. E' un protocollo non orientato alla connessione, utilizzato quando l'affidabilità, il cui controllo viene richiesto ai protocolli applicativi che ne fanno uso, non è il target primario. I vantaggi nell'utilizzo di UDP sono infatti la velocità, e la minore congestione di rete rispetto a TCP (non ci sono pacchetti di conferma) e la possibilità di trasmettere in multicast (invio di un pacchetto ad un gruppo di host) e broadcast (invio di un pacchetto a tutti gli host di un segmento di rete).
  
HEADER UDP  
Il formato di un pacchetto UDP non è molto complesso e comprende i seguenti campi:  
Source Port: campo di 16 bit (facoltativo), contiene la porta UDP di origine dell'host sorgente;  
Destination Port: campo di 16 bit, contiene la porta UDP di destinazione del pacchetto sull'host remoto;  
Lenght: campo di 16 bit, contiene la lunghezza in byte dell'intestazione UDP e dei dati;  
Checksum: campo di 16 bit, è utilizzato per verificare l'integrità dei dati trasportati;  
Data: campo di lunghezza variabile contenente i dati;
  
TRASMISSIONE UDP  
La trasmissione di un pacchetto UDP avviene incapsulandolo all'interno di un pacchetto IP. Giunto a destinazione, il pacchetto viene inviato alla porta di destinazione indicata nell'intestazione UDP. Qualora la porta non fosse disponibile, viene inviato un paccheto ICMP (Internet Control Message Protocol) all'host mittente con messaggio di port unreachable (porta irraggiungibile).
  
Attraverso un network sniffer è possibile visualizzare i vari campi di un pacchetto UDP. Un esempio:  
Source IP: 192.168.0.97  Target IP: 195.130.224.18 UDP  Length: 27
Essendo UDP incapsulato in IP vediamo prima l'intestazione IP con gli indirizzi sorgente e destinazione e la dimensione  
Source Port: 33997  Target Port: 53  Leng: 35  ChkSum: 2342  
Nell'header UDP troviamo la porta sorgente (33997) e la porta destinazione (53 - richiesta DNS) la dimensione (35) ed il checksum (2342)  
00000000: 1A B4 01 00 00 01 00 00 00 00 00 00 09 6C 6F 63  
...

Infine troviamo il campo dati

UDP viene utilizzato da protocolli come TFTP (Trivial File Transfer Protocol), SNMP (Simple Network Managment Protocol), DNS (Domain Name Server), per l'invio di stream audio, ed è ampiamente usato nelle applicazioni videoludiche.

Il protocollo TCP

Autore: Ariel - ( Revisione: homer ) - Ultimo Aggiornamento: 2003-09-02 10:20:31 - Data di creazione: 2003-09-02 10:20:31
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

E' un protocollo di trasporto di tipo connection-oriented per la trasmissione dati tra due host.

Il protocollo TCP ha il compito di fornire alle applicazioni un servizio affidabile per il trasferimento dei dati attraverso la rete. Questo protocollo offre un servizio orientato alla connessione (connection-oriented), esso garantisce la consegna e l'ordinamento corretto dei dati grazie all'utilizzo di sequence number e conferme di consegna. Tra gli host impegnati nella comunicazione viene simulato un colloquio diretto attraverso un canale che consente lo scambio interattivo delle informazioni (full-duplex). I dati vengono presentati e ricevuti da TCP ai protocolli superiori come un'unica sequenza (byte-stream). In questo modo è il TCP ad occuparsi di segmentarli lasciando ai protocolli superiori solo il compito di prepararli. Le informazioni contenute in un segmento sono suddivise in due parti: l'intestazione (header) e i dati (data). Il Transmission Control Protocol è utilizzato da diversi protocolli a livello applicativo quali FTP, Telnet, SMTP, POP3 ed altri.

HEADER TCP
L'intestazione di un pacchetto TCP è formata dai seguenti campi:
Source Port: campo di 16 bit, contiene il numero porta utilizzata dall'host mittente;
Destination Port: campo di 16 bit, contiene il numero della porta utilizzata dall'host destinatario;
Sequence Number: campo di 32 bit, definisce l'ordine in cui i segmenti devono essere riassemblati. E' utilizzato anche nella fase di connessione (handshake);
Acknowledgment Number: campo di 16 bit, contiene il prossimo numero di sequenza che l'host destinatario si aspetta di ricevere dall'host mittente. Esprime il numero di segmenti ricevuti correttamente fino a quel momento;
Data Offset: campo di 4 bit, definisce la lunghezza in parole a 32 bit dell'intestazione TCP. Indica dove inziano i dati;
Reserved: campo di 6 bit, riservato per futuri utilizzi;
Urgent Controlo Bit: campo di 6 bit, contiene a sua volta 6 flag da un bit:
 - URG se è attivo indica che il campo Urgent Pointer è significativo e deve essere letto;
 - ACK se attivo indica che il campo Acknowledgement Number è significativo è deve essere letto;
 - PSH se attivo significa che il pacchetto deve essere inviato immediatamente, invece di attendere il riempimento del buffer;
 - RST viene utilizzato per indicare che la connessione deve essere reinizializzata, solitamente a seguito di problemi;
 - SYN viene utilizzato per stabilire una sessione, indica al destinatario di leggere il campo Sequence number e sincronizzare il proprio con esso;
 - FIN indica che l'host mittente non ha più dati da spedire, e vuole terminare la connessione;
Windows Size: campo di 16 bit, contiene la dimensione del buffer di dati che il mittente può accettare;
Checksum: campo di 16 bit, stabilisce la correttezza delle informazioni (Intestazione+Dati);
Urgent Pointer: campo di 16 bit, indica quale porzione dati è urgente;
Options: campo di dimensione varabile, contiene le opzioni per la comunicazione;
Padding: campo di dimensioni variabili, è utilizzato per far raggiungere all'area d'intestazione una dimensione di 32 bit o un suo multiplo;
Data: i dati trasportati dal protocollo;

I FLAG TCP
Durante una sessione TCP è di fondamentale importanza lo stato dei flag del campo Urgent Control Bit che possono assumere combinazioni differenti:
SYN: è presente nel primo pacchetto di un host che intende stabilire la connessione con un altro;
SYN | ACK: è la risposta di un host contattato che accetta la connessione;
ACK: a connessione stabilita ogni pacchetto è confermato tramite i flag ACK attivo;
FIN: è inviato da un host che intende chiudere una sessione;
FIN | ACK: è la risposta di un host che conferma la chiusura di una connessione;
RST: viene inviato da un host che riceve un pacchetto inatteso e che quindi non accetta la connessione;

STATI DI UNA SESSIONE TCP
Una sessione TCP attraversa diversi stati in seguito al verificarsi di determinati eventi:
LISTEN: host in attesa di connessione;

SYN-SENT: host che ha inviato una richiesta di connessione ed è in attesa di risposta;
SYN-RECEIVED: host in attesa di conferma per la richiesta di connessione dopo aver ricevuto ed inviato una richiesta di conferma;
ESTABLISHED: host con una connessione aperta durante la quale i dati sono inviati e ricevuti;
FIN-WAIT1: host in attesa di una richiesta di termine della sessione o di conferma di richiesta di termine della connessione;
FIN-WAIT2: host in attesa di una richiesta di termine della sessione da parte di un host remoto;
CLOSE-WAIT: host in attesa di terminare la sessione;
CLOSING: host in attesa della conferma della richiesta di termine di connessione;
LAST-ACK: host in attesa della conferma dellle richiesta di termine della connessione già inviata all'host remoto;
TIME-WAIT: host in attesa (per un determinato lasso di tempo) per garantire che l'host remoto abbia ricevuto la conferma della richiesta di termine della connessione;
CLOSED: non esiste connessione tra host;

SESSIONE TCP
Il presupposto per instaurare una connessione è l'esistenza di un server con un socket attivo in stato di listen (apertura passiva). Inizialmente il client ed il server sono in stato closed. Successivamente una sessione TCP attraversa i seguenti passaggi:
- Instaurazione della connessione
1. Il client esegue una procedura chiamata apertura attiva creando un socket, ed inviando un segmento TCP con il flag SYN (synchronize) settato ed un sequence number (random) seq=x;
[Host A (Stato Syn Sent)] SEQ=100 SYN --> [Host B (Stato LISTEN)]
2. Il server risponde con il flag SYN e ACK (risposta di conferma) attivi, inviando un sequence number  settato a seq=y e ACK x+1 oppure se non accetta la connessione risponde inviando un pacchetto con flag RST attivo;

[Host A (Stato ESTABLISHED)] <-- SEQ=300 ACK=101 SYN,ACK [Host B (Stato Syn Received)]
3. Il client riceve il segmento dal server e ne invia uno con il flag ACK settato: ACK x+1. Durante questa fase gli host impostano la dimensione massima del buffer di trasmissione (Window Size). La procedura three-way handshake è terminata ed inizia il trasferimento dati;
[Host A (Stato ESTABLISHED)] SEQ=101 ACK=301 ACK --> [Host B (Stato ESTABLISHED)]
- Scambio dati
4. I Dati vengono scambiati tra i due host.
[Host A (Stato ESTABLISHED)] SEQ=101 ACK=301 ACK (Dati) --> [Host B (Stato ESTABLISHED)]
- Termine della connessione
5. Per rilasciare la connessione il client invia un segmento contenente il flag FIN settato;
[Host A (Stato FIN-WAIT-1)] SEQ=500 ACK=700 FIN,ACK --> [Host B (Stato CLOSE-WAIT)]
6. Il server lo riceve e invia un segmento di conferma con il successivo numero sequenziale atteso ACK y+1;
[Host A (Stato FIN-WAIT-2)] <-- SEQ=700 ACK=501 ACK [Host B (Stato CLOSE-WAIT)]
7. Il server invia la richiesta di fine connessione e la conferma con il flag FIN;
[Host A (Stato TIME-WAIT)] <-- SEQ=700 ACK=501 FIN,ACK [Host B (Stato LAST-ACK)]
8. Il client conferma la ricezione, ed il server chiude la connessione;
[Host A (Stato TIME-WAIT)] SEQ=501 ACK=701 ACK --> [Host B (Stato CLOSED]
9. La connessione viene chiusa anche dal lato client;
[Host A (Stato CLOSED)]

FINESTRE SCORREVOLI e TIMEOUT
Il meccanismo delle finestre scorrevoli (Sliding Windows) viene utilizzato dal TCP/IP per migliorare le performance di una trasmissione. La dimensione della finestra di trasmissione, contenuto nel campo Windows Size, viene scambiata tra i due host nella fase di handshaking (può comunque variare in seguito durante la sessione).
Questa dimensione indica il numero massimo di segmenti che si possono inviare ogni volta. Il meccanismo dei timeout permette invece di rispedire un pacchetto, qualora scaduto un determinato periodo di tempo (timeout appunto) non sia stata ricevuta la conferma da parte dell'host remoto.

Poniamo che a seguito dell'handshake si abbia una finestra di partenza di 6 segmenti:
1. L'host mittente invia i 6 segmenti al all'host destinatario.
Host A [(1)(2)(3)(4)(5)(6)]7 8 9 10 11 12  - Host B [ ]
Host A (1)(2)(3)(4)(5)(6) --> Host B
2. Se l'host destinatario riceve solamente i segmenti 1 e 2, invia una conferma indicando che si aspetta il segmento 3, inidicando quindi che i segementi 1 e 2 sono stati ricevuti. A questo punto la finestra si sposta di due segmenti in modo da poter trasmettere i segmenti 7 ed 8.
Se non viene confermata la ricezione dei segmenti da 3 a 6 inviati precedentemente, il timer di ritrasmissione raggiunge lo zero e vengono quindi rispediti ma con il tempo di timeout raddoppiato.
Host A 1 2 [(3)(4)(5)(6)(7)(8)] 9 10 11 12  - 1 2 [ ]
Host A (7)(8) --> Host B
3. L'host destinatario invia un pacchetto di conferma in cui si aspetta di ricevere il segmento 8, indicando quindi di aver ricevuto i segmenti fino al 7. La finestra a questo punto scorre oltre il segmento 7, e si devono inviare i segmenti da 8 a 12 e cosi via.
Host A 1 2 3 4 5 6 7 [(8)(9)(10)(11)(12)] - Host B 1 2 3 4 5 6 7 []
Host A (8)(9)(10)(11)(12) --> Host B

Grazie a queste tecniche si ha un miglioramento delle prestazioni in quanto, l'host destinatario può inviare le conferme di ricezione di più segmenti (contigui) contemporaneamente riducendo quindi il traffico di rete. Naturalmente una finestra troppo grande potrebbe portare a perdere troppi segmenti e quindi a peggiorare la trasmissione.

Request For Comments (RFC)

Autore: homer - Ultimo Aggiornamento: 2003-09-02 12:38:45 - Data di creazione: 2003-09-02 12:38:45
Tipo Infobox: TIPS - Skill: 2- JUNIOR

Ogni standard riguardante la suite di protocolli TCP/IP viene pubblicato sotto forma di Request For Comments, un documento che ne illustra le specifiche tecniche.

Le Request For Comments, meglio conosciute come RFC, sono mantenute dalla IAB (Internet Architecture Board) e  pubblicate al fine di far conoscere, studiare e migliorare (commentare) le specifiche riguardanti la suite TCP/IP. E' bene ricordare che nonostante gli standard TCP/IP vengano pubblicati sotto forma di RFC non tutte le RFC rapprentano degli standard. A volte infatti, si tratta di specifiche in corso di studio o di test che in alcuni casi diventano standard in altri vengono scartate.

I test delle RFC non hanno un formato predefinito, possono essere redatte da chiunque intenda proporre una specifica riguardante TCP/IP e successivamente verrano vagliate da una commissione tecnica quale IETF (Internet Engineering Task Force) oppure IRTF (Internet Research Task Force). Come nota di cronaca, è necessario dire che state pubblicate anche RFC ironiche.

Una volta vagliata una RFC viene classificata:
- Required: obbligatorio implementarle su tutti gli host ed i gateway TCP/IP;
- Recommended: non sono obbiglatorie ma è raccomandato implementarle su ogni host e gateway;
- Elective: non è obbligatorio implementarla, anche se è completamente definita;
- Limited use: non è destinata ad un impiego generale;
- Not Recomended: si consiglia di non implementarla;

Prima di diventare standard, una RFC passa attraverso un processo chiamato di "maturazione":
Internet Standard: RFC che ha acquisito la necessaria maturità tecnica;
Draft Standard: implementazione base per lo sviluppo dello standard finale, in questa fase sono richiesti soprattutto test e commenti;
Proposed Standard: protocolli destinati a diventare standard previo processo e sperimentazione ulteriore;
Experimental Protocol: protocolli non destinati ad un utilizzo operativo ma destinati alla sperimentazione;
Informational Protocol: protocolli sviluppati da rivenditori od organizzazioni autorevoli al di fuori degli organi ufficiali Internet;
Historic Protocol: si tratta di protocolli abbandonati o diventati obsoleti che difficilmente diverrano standard;

Ogni RFC pubblicata riceve un numero di documento, in caso di aggiornamento verrà pubblicata una nuova RFC alla quale verrà assegnato anche un nuovo numero identificativo.


I protocolli di routing

Overview dei protocolli di routing: esterni (BGP) e interni (RIP, OSPF, EIGRP)

Overview sui protocolli di routing

Autore: al - Ultimo Aggiornamento: 2003-10-23 18:56:46 - Data di creazione: 2003-10-23 18:56:46
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Internet viene comunemente definita come "la madre delle reti", un'enorme rete globale composta da migliaia di network autonomi di stati, enti e società diversi che comunicano e si "capiscono" fra di loro grazie a dei protocolli comuni e predefiniti.
Fra le caratteristiche di Internet viene spesso anche citata la sua capacità di adattarsi a temporanei malfunzionamenti, permettendo ai pacchetti che la attraversano di arrivare a destinazione tramite vie alternative a quelle normalmente utilizzate.
Tutti gli host in Internet (i computer degli utenti, i server con cui comunicano) hanno un loro indirizzo IP e possono comunicare con host di reti IP diverse (in senso stretto, identificate da una maschera di sottorete) tramite dei router: host particolari esclusivamente dedicati a smistare e indirizzare, in base alle tabelle di routing con cui sono configurati, i pacchetti che attraversano le loro interfacce.
Le tabelle di routing di un router possono essere basate su rotte statiche, configurate manualmente e fisse, oppure su rotte dinamiche, che si adattano a condizioni di rete diverse (interruzione o intasamento di una linea ecc.).

Questo è possibile tramite i protocolli di routing (routing protocols, in contrapposizione ai normali routed protocols che sono quelli utilizzati dagli applicativi a disposizione degli utenti) che permettono ai router di cui è composta la rete di comunicare fra loro e scegliere la via migliore per scambiarsi dati.
Una prima distinizione di questi protocolli viene fatta in relazione agli ambiti di utilizzo:
- Exterior Gateway Protocols (EGP), sono quelli che gestiscono la comunicazione fra i vari network di cui Internet è composta. Queste reti, gestite da organismi autonomi (carrier, provider, aziende, enti pubblici...) vengono comunemente definite Autonomous Systems (AS), hanno un numero progressivo (da 1 a, ormai, varie migliaia, in costante crescita),  e comunicano fra loro di fatto con un unico protocollo, il BGP4, che costituisce la vera spina dorsale di Internet e ne permette la stessa esistenza come network globale.
- Interior Gateway Protocols (IGP), sono i protocolli di routing che vengono utilizzati all'interno di un Autonomous System, servono per gestire il flusso di pacchetti fra i router dello stesso AS, quindi del network di un singolo ente. Esistono diversi protocolli di questo tipo (I più utilizzati sono OSPF e EIGRP, ma esistono anche RIP, IGRP e IS-IS) e fondamentalmente la loro scelta dipende dai network administrator di un AS e non influisce sui rapporti con altri AS (sempre gestiti dai router "esterni" che parlano BGP4).

Sembra paradossale, ma in realtà è logico necessario, tutti questi protocolli di routing, che di fatto su Internet servono per instradare pacchetti su una rete IP (Internet Protocol) si appoggiano sul protocollo IP stesso e, visti in termini di livelli ISO/OSI, operano a livello di rete, di trasporto o anche applicativo, scambiandosi dati sui link che essi stessi determinano.

Le caratteristiche alla base di un buon protocollo di routing (che in alcuni casi vengono supportati meglio di altri) sono:
- Dinamicità e possibilità di scegliere automaticamente rotte alternative nel momento in cui la rotta principale non è più disponibile.
- Scalabilità e capacità di gestire tabelle di routing per reti di complessità crescente.
- Coerenza fra le tabelle di routing dei diversi router che parlano lo stesso protocollo e concordano a definire rotte funzionanti.
- Rapidità nell'adattamento a variazioni sulla struttura della rete e nel definire rotte alternative (convergenza).

Su un router possono coesistere rotte statiche, configurate "manualmente" e protocolli di routing diversi che concorrono a definire una tabella di routing univoca in base alla "distanza amministrativa" (AD) assegnata ai diversi protocolli (più è basso questo valore più la rotta viene considerata attendibile):
- Le reti appartenenti ad interfacce direttamente connesse hanno una distanza amministrativa pari a 0;
- Rotte statiche che puntano ad host esterni hanno AD 1
- Il BGP ha AD 20, EIGRP 90, OSPF 110, RIP 120 e via andando.
In genere protocolli di routing con metriche (metodi per valutare le rotte migliori) complesse e sofisticate hanno AD inferiore e quindi più attendibili.


Protocolli a livello applicativo


I protocolli HTTP e HTTPS

HyperText Transfer Protocol: sintassi, headers, URI e methods. Introduzione a HTTPS.

Introduzione al protocollo HTTP

Autore: al - Ultimo Aggiornamento: 2003-02-03 12:01:44 - Data di creazione: 2003-02-03 12:01:44
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Il protocollo HTTP (Hyper Text Transfer Protocol) viene usato da tutti i client e server web e gestisce il modo con cui questi si scambiano pagine HTML o altri file.

Il client web (cioè un browser come Microsoft Internet Explorer, Netscape Navigator, Opera ecc.) utilizza l'HTTP per richiedere file al server web. In primo luogo vengono richieste pagine HTML, che dopo essere state ricevute, vengono processate dal browser che provvede a fare richiesta di eventuali nuovi file richiamati nel codice HTML (immagini, fogli di stile css, script esterni ecc.) e a visualizzare il tutto sul monitor dell'utente.
Ogni richiesta http consta di:
- Metodo (GET, HEAD, PUT ...)
- URI (Uniform Resource Identifier) Il path o indirizzo completo della risorsa richiesta.
- Versione del protocollo (HTTP/1.0 o HTTP/1.1)
Un esempio tipico di una richiesta HTTP è:
GET / HTTP/1.0

Alla richiesta possono seguire degli HTTP headers come Accept-Language, Date, Expires e vari altri (possono essere arbitrariamente definiti fra broswer e server).

Esistono attualmente 3 specifiche del protocollo HTTP:
HTTP/0.9 - Di fatto non è più utilizzato da nessuna parte
HTTP/1.0 - Ancora abbastanza utilizzato e supportato da ogni browser e web server
HTTP/1.1 - Introduce nuovi metodi (OPTIONS, TRACE, DELETE, PUT, CONNECT) e la gestione di Virtual Host. E' supportato da tutti i browser e server non troppo vecchi ed è utilizzato nella maggior parte dei casi.

I metodi HTTP

Autore: al - Ultimo Aggiornamento: 2003-02-03 12:05:32 - Data di creazione: 2003-02-03 12:05:32
Tipo Infobox: DESCRIPTION - Skill: 4- ADVANCED

Un metodo HTTP può considerarsi un comando proprio del protocollo HTTP che il client richiede al server.
Ne esistono vari, ma di fatto i più utilizzati sono GET (per richiedere un file) e POST (per inviare informazioni al server).

GET - Richiede un file al server. La risposta è composta da vari header separati con due Carriage Return dalla risorsa effettivamente richiesta (il file HTML che contiene l'home page del sito). All'inizio della risposta viene specificato il protocollo usato (HTTP/1.1) e lo Status Code che indica l'esito della richiesta fatta (200 OK vuol dire che la richiesta ha avuto successo e il server ha fornito i dati chiesti).
GET / HTTP/1.0
HTTP/1.1 200 OK
Date: Wed, 23 Oct 2002 08:18:47 GMT
Server: Apache/1.3.26 (Unix) PHP/4.2.3
X-Powered-By: PHP/4.2.3
Set-Cookie: PHPSESSID=8fd7c6a69c84da8276187e18a3067b85; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html

[Contenuto della pagina HTML..]


HEAD - Richiede solo l'header, senza la risorsa (il file HTML, l'immagine, ecc.). Di fatto viene usato soprattutto per diagnostica.
HEAD / HTTP/1.0
HTTP/1.1 200 OK
Date: Wed, 23 Oct 2002 08:31:36 GMT
Server: Apache/1.3.26 (Unix) PHP/4.2.3
X-Powered-By: PHP/4.2.3
Set-Cookie: PHPSESSID=d0226985ad2282fd9e2d9f6fb868b92a; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Content-Type: text/html


POST - Invia informazioni all'URI specificato. Le informazioni sono presenti in coppie attributo=valore&attributo=valore e vengono processate dal server sulla base di come è configurato e di come è fatto il file a cui vengono postate.
Viene qui riportato il POST di un browser reale, con tutti gli header inviati dal browser stesso e l'inizio delle coppie attributo=valore.
POST /modify/modify.php HTTP/1.1
Host: openskills.info
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Cookie: PHPSESSID=fdcb56ecb694a7564dc814b422dd2a7d
Referer: http://openskills.info/modify/modify.php?table=box&IDbox=357&boxtype=infobox&LANGUAGE=ita
Content-Type: application/x-www-form-urlencoded
Content-Length: 2431

IDbox=357&box_title=I+metodi+HTTP&[attributi=valori]


HTTP/1.1 200 OK
Date: Wed, 23 Oct 2002 08:38:51 GMT
Server: Apache/1.3.26 (Unix) PHP/4.2.3
X-Powered-By: PHP/4.2.3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Keep-Alive: timeout=25, max=85
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html

[HTML della pagina di risposta]


I metodi finora elencati sono comuni sia al protocollo HTTP/1.0 che all'HTTP/1.1, quelli che seguono invece sono esclusivi del HTTP/1.1 e, spesso, non vengono permessi dai server.
Nella configurazione di default di Apache, per esempio, sono disattivati.
Se si prova ad utilizzarli su server che non li permettono si ottiene uno Status code: 405 Method not allowed.
Quando si usa il protocollo HTTP/1.1 è necessario specificare l'host a cui si intende fare la richiesta.

OPTIONS - Richiede l'elenco dei metodi permessi dal server.
OPTIONS * HTTP/1.1
Host: openskills.info


TRACE - Traccia una richiesta, visualizzando come viene trattata dal server.
TRACE * HTTP/1.1
Host: openskills.info


DELETE - Cancella una risorsa (file) sul server. L'utente con cui gira il web server deve poter avere permessi in scrittura sul file indicato e il server deve essere configurato per poterlo fare.
DELETE /info.html HTTP/1.1
Host: openskills.info


PUT - Uploada un file sul server, creandolo o riscrivendolo, con il nome indicato e i contenuti specificati nella parte che segue gli header.
PUT /info.html HTTP/1.1
Host: openskills.info

[Contenuto file]

Gli header HTTP

Autore: Eberk - ( Revisione: al ) - Ultimo Aggiornamento: 2003-02-03 12:25:30 - Data di creazione: 2003-02-03 12:25:30
Tipo Infobox: DESCRIPTION - Skill: 4- ADVANCED

Gli header HTTP vengono trasferiti fra client e server e generalmente contengono meta-informazioni sul contenuto effettivo della risorsa (file) trasferita.
Il loro formato è:
NomeHeader: Valore (CRLF)
in una richiesta o una risposta HTTP possono esistere un numero arbitrario di header, il loro ordine non è importante ma è raccomandato un ordine sulla base delle categorie sotto indicate.

Esistono 4 categorie di header, di queste citiamo solo le voci più significative:

1 - GENERAL HEADERS
Contengono informazioni generali non relative al server, al client, al dato trasferito o al protocollo HTTP.
Cache-Control: direttive - Definisce le direttive sia associate a richieste che a risposte (separate da virgola) a cui devono obbedire tutti i sistemi di caching fra client e server. Quando sul proprio browser si cambiano le impostazioni relative alla cache, di fatto si modificano le direttive gestite con questo header.
Date: data_rfc-1123 - (es: Wed, 23 Oct 2002 18:59:12 GMT) La data è quella in cui il messaggio viene originato.
Pragma: no-cache - Il contenuto richiesto non deve essere messo in alcuna cache (del browser, di un proxy ecc.). Fondamentale per pagine dinamiche che devono essere sempre aggiornate.
Via: protocollo host_ricevente [commento] - Va aggiunto da proxy o gateway per indicare i protocolli e gli host intermedi fra client e server attraverso i quali è passata la richiesta.
Upgrade: protocollo/versione - Permette al client di specificare che supporta una versione di protocollo superiore a quella che si sta utilizzando (tipicamente HTTP/1.1 rispetto a HTTP/1.0) e al server di indicare su quale protocollo ha switchato.

2 - REQUEST HEADERS
Sono riservati alla richieste che il client esegue e contengono informazioni riguardo la richiesta stessa o il client.
Accept: tipo/sottotipo [;q=valore] - Indica quali tipi di file sono accettati dal client, in formato MIME (es: text/html). Con il parametro q (valori da 0 a 1) si definisce la preferenza relativa al tipo indicato (es: Accept: text/plain; q=0.5, text/html; q=0.8).
Accept-Charset: charset [;q=valore] - Indica i charset (set di caratteri per le diverse lingue) il client accetta e in che ordine.
Accept-Encoding: encoding-type [;q=valore] - Indica il tipo di encoding che il client può accettare (es: Accept-Encoding: gzip, default, compress;q=0.9).
Accept-Language: lingua [;q=valore] - Indica la lingua che il client preferisce e quali può comunque accettare (es: Accept-Language: en-us, en;q=0.5).
Authorization: credenziali - Quando l'utente si è autenticato e accede a pagine protette, il client con questo header fornisce le credenziali richeste ed evita ultetiori richieste di autenticazione da sottoporre all'utente.

3 - RESPONSE HEADERS
Sono riservati alle risposte del server e contengono info sul server stesso o sulla risorsa richiesta. Fra questi:
Age: secondi - Tempo stimato da quando è stata generata la risposta sul server.
Server string - Contiene informazioni sulla versione del software utilizzata dal server

4 -ENTITY HEADERS
Contengono meta-informazioni sull'entità (file) trasferito.
Content-Encoding: encoding - Indica quali tipi di encoding (es: gzip) sono stati fatte sul contenuto del messaggio, per permettere al client di decodificarlo.
Content-Language: lingue - Indica la lingua presunta dell'utente che riceve il file, si basa sull'analogo Request header Accept-Languages.
Content-Lenght: bytes - Indica la lunghezza in byte del file servito.
Expires: data - Indica la data dopo la quale il file servito è da considerare obsoleto. Va considerata da tutti i meccanismi di cache coinvolti nella richiesta.
Last-Modified: data - Indica la data di ultima modifica del file.

Status codes del protocollo HTTP

Autore: Eberk - Ultimo Aggiornamento: 2003-02-03 12:32:57 - Data di creazione: 2003-02-03 12:32:57
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE

I server HTTP rispondono utilizzando linee di status che informano il client sull'esito della richiesta.
Gli status contengono 3 campi: versione del protocollo HTTP, status code e descrizione.
Lo status code è dato da un numero a 3 cifre con i seguenti significati:
1XX - Informational
2XX - Client request successful
3XX - Client request redirected, futher action necessary
4XX - Client request incomplete
5XX - Server errors

1xx - INFORMATIONAL
Questa classe di status consiste solo nella status line e in headers opzionali. HTTP/1.0 non definisce nessuno status code 1XX.
100 Continue - Il client può continuare con la sua richiesta. Questa risposta intermedia è inviata al client dal server per informarlo che la parte iniziale della sua richiesta non è stata respinta. Il client ora può completarla o ignorare la risposta se la richiesta è gia stata inviata per intero. Quando la richiesta è stata completamente inviata il server invierà una risposta finale.
101 Switching Protocols - Il server riceve una richiesta per il cambiamento del protocollo per quella connessione.

2xx - SUCCESSFUL CLIENT REQUEST
I seguenti status code indicano che la richiesta da parte del client è stata ricevuta, capita e accettata.
200 OK - La richiesta è stata accolta, il server risponde con i dati richiesti. E' la risposta normale per un file correttamente trasferito.
201 Created - La richiesta è stata effettuata ed una nuova risorsa è stata creata. L'URI rinviato nella risposta fa riferimento alla nuova risorsa creata.
202 Accepted - La richiesta è stata accettata ma non ancora processata.
203 Non-Authorative Information - L'insieme delle informazioni rimandate contenute nell'entity-header non è l'insieme di informazioni mandate dal server di origine ma provengono da una copia fatta in locale o da terzi.
204 No Content - Il server ha effettuato la richiesta ma non si necessita il rinvio dell'entity-body. A questa risposta il browser non dovrebbe aggiornare il documento visualizzato.
205 Reset Content - Il browser alla ricezione di questo status code dovrebbe resettare il contenuto del form che ha causato l'invio della richiesta.
206 Partial Content - Il server ha effettuato un GET parziale della risorsa. Questo succede quando risponde a una richiesta contenente un Range header.

3xx - CLIENT REQUEST REDIRECTED
Questa classe di status indica che si necessita di un'ulteriore azione per far si che la richiesta sia correttamente effettuata.
300 Multiple Choices L'URI richiesto corrisponde a piu documenti (per esempio un documento disponibile in piu lingue).
301 Moved Permanently - La risorsa richiesta è stata assegnata definitivamente ad un nuovo URI.
302 Moved Temporarily - La risorsa richiesta è stata assegnata temporaneamente ad un nuovo URI. Il client può usare il nuovo URI per le attuali richieste, ma in futuro (quando non vi sarà piu redirezione) dovrà usare il vecchio URI.
303 See Other - La risorsa richiesta si trova in un altro URI specificato nel Location header.
304 Not Modified - Il Client ha effettuato una richiesta GET condizionale usando l'If-Modified-Since header, ma la risorsa non è stata ancora modificata. La risorsa non viene mandata in quanto il client la possiede gia in locale.
305 Use Proxy - La risorsa richiesta deve passare per un proxy il cui l'URI è dato nel Location field.

4xx - CLIENT REQUEST ERRORS
La classe di status 4XX è riservata ai casi in cui il client commette degli errori.
400 Bad Request - Richiesta non capita dal server causa sintassi errata.
401 Authorization Required - Questo risultato è dato dal WWW-Authenticate header per indicare che la richiesta era sprovvista dell'autorizzazione che quella determinata risorsa richiede.
402 Payment Required - Questo codice è riservato ad usi futuri.
403 Forbidden - Il server capisce la richiesta ma si rifiuta di compierla. La richiesta non dovrebbe essere ripetuta.
404 Not Found - Il server non ha trovato nulla che corrisponda all'URI richiesto. Dopo il codice 200, questo è tipicamente quello più riscontrato nei log dei server web.
405 Method Not Allowed - Il metodo specificato nella request line non è disponibile per l'URI richiesto
406 Not Acceptable (encoding) - La risorsa identificata tramite richiesta può solo generare una risposta che ha caratteristiche incompatibili con gli accept headers contenuti nella richiesta.
407 Proxy Authentication Required - Questo codice indica che il client deve prima autenticarsi con il proxy, usando l'header Proxy-Authenticate.
408 Request Timed Out - Il client non ha fornito una richiesta nel tempo massimo di attesa del server.
409 Conflict - La richiesta non puo essere completata causa conflitto con il corrente stato della risorsa.
410 Gone - La risorsa richiesta non è piu disponibile sul server e il server non conosce indirizzi su cui ridirezionare.
411 Length Required - Il server si rifiuta di accettare la richiesta in quanto il client non ha definito il Content-Length.
412 Precondition Failed - Una o piu condizioni specificate negli IF request headers è risultata falsa al momento del test del server.
413 Request Entity Too Large - La richiesta è piu grande rispetto a quello che il server può processare.
414 Request URI Too Long - L'URI richiesto è troppo lungo per essere interpretato dal server.
415 Unsupported Media Type - Il corpo della richiesta è in un formato non supportato.

5xx - SERVER ERRORS
Questa classe di status è riservata ai casi in cui il server commette un errore o non è in grado di performare la richiesta. In genere richiede un intervento sistemistico sul server.
500 Internal Server Error - Il server è in una situazione inaspettata e non può rispondere alle richieste.
501 Not Implemented - Il server non è implementato per rispondere correttamente alla richiesta effettuata.
502 Bad Gateway - Il server collegato ad un gateway o ad un proxy, riceve una risposta non valida da questo.
503 Service Unavailable - Il server non può rispondere causa temporaneo overload.
504 Gateway Timeout - Il server collegato ad un gateway o ad un proxy, non riceve una risposta da questo nel tempo di attesa massimo impostato.
505 HTTP Version Not Supported - Il server non supporta la versione del protocollo HTTP utilizzato per fare la richiesta.

Elementi del protocollo HTTP

HTTP è il protocollo usato per trasferire file fra client e server Web.
La versione maggiormente diffusa e utilizzata è la 1.1

Ogni richiesta HTTP da client a server è composta da:
- Metodo (GET, POST, HEAD...)
- Nome file (file.html) Il file richiesto, completo di path.
- Versione del protocollo utilizzata (1.1)
- Header che forniscono informazioni sul client e sul modo con cui trattare i file.

Una risposta HTTP da parte del server è composta da:
- Versione del protocollo utilizzata (1.1)
- Status Code (200, 403, 404...) Codice di risposta, che indica se la richiesta è stata esaudita con successo o se ci sono errori
- Header con informazioni sul file servito
- Dati con il contenuti del file fornito.

Gli Header di una richiesta lato client includono informazioni quali:
Host: openskills.info
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain... [...]
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Cookie: PHPSESSID=fdcb56ecb694a7564dc814b422dd2a7d
Referer: http://openskills.info/modify/modify.php?table=box&IDbox=357
Content-Type: application/x-www-form-urlencoded
Content-Length: 2431


Le risposte del server contengono header (in parte diversi) come:
Date: Wed, 23 Oct 2002 08:38:51 GMT
Server: Apache/1.3.26 (Unix) PHP/4.2.3
X-Powered-By: PHP/4.2.3
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Keep-Alive: timeout=25, max=85
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html


Il protocollo SMTP

Simple Mail Transfer Protocol: sintassi base

Protocollo SMTP Overview

Autore: homer - Ultimo Aggiornamento: 2004-06-04 11:50:33 - Data di creazione: 2004-06-04 11:50:33
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Simple Mail Transfer Protocol (SMTP) è il protocollo utilizzato per trasmettere messaggi di posta elettronica tra due host.

SMTP utilizza il protocollo di trasporto TCP, ed in particolare un SMTP server rimane costantemente in ascolto sulla porta 25. Il server SMTP si occupa poi di trasferire i messaggi nelle caselle di posta (mailbox) dei destinatari, oppure qualora non fosse il diretto responsabile di queste, inoltrarli (operazione di relay) al server che provvederà a farlo. La sintassi dei comandi è case-insensitive, ed è composta da istruzioni seguite da uno o più parametri terminate da un CRLF (Invio).

Il protocollo è descritto nella RFC 821, ma lavora in stretta collaborazione con altri standard come la RFC 822 che descrive la sintassi degli headers della mail, la RFC 1049 che definisce le strutture dati per interpretare correttamente il contenuto delle mail e la RFC 974 che si occupa del routing delle mail tramite DNS.

Lo standard definito dalla RFC 821, aveva diversi limiti riguardanti per esempio la dimensioni dei messaggi oppure la trasmissione di mail non in inglese o diverse dal semplice plain text. Per ovviare a questa restrizione è stato necessario estendere il protocollo tramite la RFC 1425 riguardante le SMTP Service Extensions.

I principali comandi SMTP:
HELO: Identifica il client SMTP al server SMTP;
EHLO: E' possibile usare anche questo comando per identificarsi, se il server supporta le SMTP Service Extensions riponderà in modo positivo altrimenti con un errore di tipo 500 (Syntax Error);
MAIL FROM: <indirizzo mittente>: Indicata la mailbox del mittente del messaggio;
RCPT TO: <indirizzo destinatario> : Indica la mailbox del desinatario (Recipient). E' possibile specificare attraverso molteplici RCPT TO diversi destinatari;
DATA: Indica al server che quanto digitato successivamente saranno i dati del messaggio di posta;
RSET: Annulla i comandi (Reset) precedentemente inviati nella sessione SMTP corrente;
VRFY <stringa>: Chiede al server se la stringa di testo immessa rappresenta un
nome utente presente ed in tal caso visualizza l'intero indirizzo;
HELP: Visualizza i comandi disponibili sul server;
NOOP: Non esegue nessuna operazione restituisce solo un messaggio 250 (Ok) se il server risponde;
QUIT: Termina la sessione SMTP corrente;

Una sessione SMTP attraversa almeno sei fasi:
1. Il client SMTP contatta il server sulla porta TCP 25. Se questo è in ascolto e la connessione è accettata risponde con un messaggio 220 (Ready);
2. Il client chiede di stabilire la sessione SMTP inviando il comando HELO seguito dal FQDN (Fully Qualified Domani Name). Se il server accetta rispondo con un messaggio 250 (Ok);
3. Il client indica il proprio indirizzo tramite il comando MAIL FROM: <indirizzo mittente>. Il server risponde con 250 (Ok) per ogni destinatario accettato;
4. Successivamente il client indica al server i destinatari del messaggio tramite RCPT TO: <indirizzo destinatario> ed il server risponde per ogni destinatario accettato un codice 250 (Ok);
5. Il client comunica al server l'intenzione di scrivere il corpo del messaggio con DATA. Il server risponde con un codice 354 e indica come marcare il termine del messaggio. I campi come Date, Subject, To, Cc, From vanno inseriti tra i dati della mail;
6. Completato il messaggio da scrivere tramite . il server memorizza la mail. A questo punto è possibile, scrivere un nuovo messaggio oppure inviare il comando QUIT, dopo il quale il server invia i messaggi e risponde con un codice 221 (Closing) e la connessione TCP viene terminata;

Esempio di una sessione SMTP da linea di comando:
homer@Joker:~$ telnet smtp.springmail.it 25
Trying 195.130.225.171...
Connected to smtp.springmail.it.
Escape character is '^]'.
220 mail.springmail.it ESMTP Service (6.5.032) ready
Tramite il programma telnet viene contattato il server SMTP sulla pora TCP 25
E' possibile notare dal messaggio ESMTP Service che il server supporta le SMTP Service Extensions

HELO
250 mail.springmail.it Missing required domain name in HELO, defaulted to your IP address [62.10.125.229]
Il client si identifica tramite il comando helo (non iniviando un nome di dominio, viene utilizzato l'indirizzo IP)
L'autenticazione avviene con HELO anziché EHLO e quindi il client non usufruisce delle SMTP Service Extensions qui supportate

HELP
214-Valid SMTP commands:
214-  HELO, EHLO, NOOP, RSET, QUIT, STARTTLS
214-  MAIL, RCPT, DATA, VRFY, EXPN, HELP, ETRN
214-For more info, use HELP <valid SMTP command>
214 end of help
HELP QUIT
214-Syntax: QUIT
214-Purpose: request closing of the connection
214 end of help
Il client richiede una lista dei comandi disponibili tramite help e successivamente un aiuto per il comando QUIT
MAIL FROM:<[email protected]>
250 MAIL FROM:<[email protected]> OK
RCPT TO:<[email protected]>
250 RCPT TO:<[email protected]> OK
DATA
Inizia l'inserimento del corpo della mail
354 Start mail input; end with <CRLF>.<CRLF>
From:Homer
To:Arnaldo
Subject:Il protocollo SMTP

Ciao,
questa mail serve per illustrare
il protocollo SMTP
---
Arnaldo aka [Homer]
.

250  Mail accepted
Il comando "." punto termina l'inserimento del messaggio; Il server SMTP lo accetta
QUIT
221 mail.springmail.it QUIT
Connection closed by foreign host.
La connessione TCP termina e si ritorna al prompt
homer@Joker:~$


Il client di posta elettronica (Kmail, Outlook o Eudora) si occupa solitamente di comunicare con il server al posto nostro in base alla propria configurazione.


I protocolli POP3 e IMAP

Post Office Protocol e Interactive Mail Access Protocol: sintassi

Protocollo POP3 Overview

Autore: homer - Ultimo Aggiornamento: 2003-08-12 23:01:03 - Data di creazione: 2003-08-12 23:01:03
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE

Post Office Protocol 3 (POP3) è attualmente il protocollo più utilizzato per il download della posta elettronica.

Il protocollo POP3 descritto nella RFC 1939, fornisce le funzioni base per scaricare e cancellare la posta da un mail server. Per eseguire il processo di download viene instaurata una connessione di tipo TCP tra il client ed il server POP3 in ascolto di default sulla porta 110.

Una sessione POP3 consiste in una serie di comandi di tipo case-insesitive scambiati tra client e server seguiti da uno o più argomenti e conclusi con un CRLF (INVIO).

La sessione passa attraversi diversi stati:

AUTHORIZATION state: ci troviamo in questo stato in seguito all'avvenuta connessione TCP. Il server mostra il messaggio di greeting (Saluto) ed il client deve autenticarsi ed ottenere quindi l'autorizzazione per gestire la posta;

TRANSACTION state: ad autenticazione avvenuta si passa in stato fase dove è possibile inviare i comandi al server per gestire i messaggi di posta;

UPDATE state: dopo aver inviato il comando QUIT si passa nella fase di aggiornamento. Vengono eseguiti i comandi di cancellazione precedentemente memorizzati e successivamente la connessione TCP termina;

E' possibile che su un server POP3 sia impostato un tempo di inattività, trascorso il quale si viene automaticamente disconnessi senza passare in UPDATE state. Questo significa che la connessione TCP termina e gli eventuali comandi di cancellazione impartiti al server non saranno presi in considerazione.

Una tipica sessione POP3 è caratterizzata dalle seguenti fasi:

1. Il client POP3 si connette al server POP3 costantemente in ascolto sulla porta 110in attesa di connessioni.

2. Una volta connessi il server invia un messaggio di saluto al client solitamente indicando il nome e/o la versione del software server.

3. Si passa quindi alla fase di autenticazione dove il client deve inviare al server POP3 i comandi USER <nomeutente> e PASS <password>. Una volta che il client è stato autenticato è possibile eseguire le operazioni come leggere, cancellare un messaggio ecc.

4. E' possibile inviare i comandi al pop server il quale risponde con +OK in caso di comando eseguito correttamente, e con -ERR nel caso in cui non riesca ad interpretare il comando.

5. La sessione viene terminata con il comando QUIT.

I principali comandi utilizzati dal protocollo POP3 sono i seguenti:

USER <nomeutente>: Identifica l'utente che si connette al server;
PASS <password>: Invia in chiaro la password dell'utente che si sta autenticando;
STAT: Restituisce il numero di messaggi presenti e lo spazio da essi occupato;
LIST <numero messaggio>: Senza parametri indica la dimensione di ogni messaggio, altrimenti solo quella del messaggio indicato;
RETR <numero messaggio>: Visualizza il messaggio indicato;
TOP <numero messaggio>: Visualizza un numero predefinito di linee dalla testa del messaggio;
DELE <numero messaggio>: Cancella dal server il messaggio indicato;
NOOP: Non esegue nessuna operazione restituisce solo un messaggio +OK se il server risponde;
RSET: Cancella le operazioni di cancellazione DELE in precedenza inviate al server;
QUIT: Termina la sessione POP3 corrente e si disconnette dal server;

Un esempio di sessione POP3 da linea di comando:
homer@Joker:~$ telnet pop.springmail.com 110
Collegamento al pop server di nome pop.springmail.com tramite il programma telnet sulla porta 110
Trying 213.92.5.75...
Connected to pop.springmail.com.
Escape character is '^]'.
+OK ifm-pop (version 4.0.0) at all-1.inet.it starting.
Il server risponde, ed è pronto per l'autenticazione, ora siamo in AUTHORIZATION state
USER [email protected]
+OK Password required for [email protected].
Viene inviato il nome utente in questo caso rappresentato dall'intero indirizzo [email protected] Il server risponde +OK, ovvero che ha accettato l'utente e richiede la password
PASS hmj2001np
+OK [email protected] has 1 visible message (0 hidden) in 1173 octets.
Viene inviata la password ed il processo di autenticazione termina con successo. Ci troviamo ora in TRANSACTION state
STATS
-ERR Unknown command: "stats".
Inviando un comando errato, STATS anziché STAT, la risposta è un -ERR
STAT
+OK 1 1256
Stat viene eseguito con successo (+OK) ed indica che c'è un messaggio di 1256 byte
LIST
+OK 1 visible messages (1256 octets)
1 1256
.
LIST visualizza tutti i messaggi, è presente un solo messaggio
RETR 1
+OK 1256 octets
Return-Path:
Received: from  [::ffff:193.70.193.55] by hal-5.inet.it via I-SMTP-4.3.7-430
id ::ffff:193.70.193.55+8UyItiMrJDJ; Wed, 02 Apr 2003 22:47:27 +0200
Received: from email.it (62.10.125.8) by mail1c.webmessenger.it (6.7.016) (authenticated as [email protected])
id 3E8868D4001242B0 for [email protected]; Wed, 2 Apr 2003 22:47:24 +0200
Message-ID:
Date: Wed, 02 Apr 2003 22:47:21 +0200
From: Arnaldo Zitti
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To:  [email protected]
Subject: Il protocollo POP3
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-UIDL: A0Y7UQ00N4rWVMr9ot4i
Salve,
questo è un messaggio di prova, come sample per
l'INFOBOX sul POP3 su OpenSkills.
--
Arnaldo aka [Homer]
.
Il comando RETR visualizza l'intero messaggio
DELE 1
+OK Message 1 has been deleted.
.
Viene cancellato il messaggio 1 con il comando DELE ed il server ne da conferma
In realtà il messaggio non viene cancellato ora, ma solo in UPDATE state

QUIT
+OK Pop server at all-1.inet.it signing off.
Una volta dato il comando QUIT si entra in UPDATE state, ed i messaggi verrano realmente cancellati
Connection closed by foreign host.
homer@Joker:~$
La connessione TCP è terminata e si ritorna al prompt


Durante una sessione POP3 tramite un client di posta eletronica come KMail, Outlook Express, Eudora od altri, è il client stesso che in base ai parametri di configurazione dell'account si occupa per noi di scambiare i messaggi con il server.

Protocollo IMAP Overview

Autore: homer - Ultimo Aggiornamento: 2003-07-15 20:50:55 - Data di creazione: 2003-07-15 20:50:55
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE

Internet Mail Access Control (IMAP) e' un protocollo per la gestione della posta elettronica che permette di compiere le elaborazioni direttamente sul server remoto.


Il protocollo IMAP giunto alla versione 4, descritto nella RFC 2060, è nato come candidato per la sostituzione del protocollo POP3 e presenta infatti una maggiore flessibilita', ed un sistema di gestione piu' esteso e complesso. IMAP si basa sul concetto di elaborare tutta la posta su un server remoto e centralizzato, in modo di avere a disposizione l'intero insieme dei propri messaggi da qualsiasi macchina ci si connetta, al contrario di quanto accade tramite POP3, il quale  scarica in locale i messaggi degli utenti.

Le funzionalita' offerte da IMAP sono:  
- Accesso e gestione dei messaggi di posta direttamente sul server;
- Possibilità di creare, cancellare e rinominare mailbox;  
- Supporto della modalità di lavoro offline per i client e successiva sincronizzazione quando possibile;
- Ricerca e selezione dei messaggi in base ad attributi quali testo o contenuto MIME;

Una sessione IMAP consiste in una serie di comandi inviati dal client al server, il quale resta in ascolto sulla porta TCP 143, e terminati da CRLF (Invio). Ogni comando deve avere un identificatore, ovvero un prefisso alfanumerico (Es. A0001) chiamato tag che lo precede il cui compito è quello di far corrispondere le risposte dels server alle rispettive domande del client.

Una sessione IMAP consiste nelle seguenti fasi:  
1 - Enstaurazione della connessione da parte del client con l'IMAP server (in ascolto sulla porta 143);  
2 - Risposta del server con il messaggio di benvenuto;  
3 - Autenticazione e successiva gestione delle mail da parte del client;  
4 - Termine della connessione al seguito della richiesta da parte client o per via della scadenza del tempo di timeout;

ATTRIBUTI DEI MESSAGGI IMAP
Avendo la possibilita' di gestire la posta in modo centralizzato sul server, e potendo accedere quindi da diversi client, IMAP implementa una sistema di attributi in grado di indicare lo stato corrente di un messaggio. Per ogni messaggio vengono definiti uno o piu' flag, i quali iniziano con il carattere "\", che ne indicano lo stato:  
- \Seen: indica che il messaggio e' stato letto;
- \Answered: indica che e' stata inviato un messagio di reply a al messaggio;
- \Flagged: indica che sul messaggio e' stato impostato un flag urgent o Special Attention;
- \Deleted: indica che il messaggio e' stato marcato per la cancellazione;
- \Draft: indica che il messaggio non e' completo ed e' quindi marcato come bozza;
- \Recent: indica che il messaggio e' appena giunto nella mailbox;

STATI DI UNA SESSIONE IMAP
Una sessione IMAP puo' attraversare quattro stati:  
- Non-Authenticated State;  
- Authenticated State;  
- Selected State;  
- Logout State;  
In relazione allo stato della sessione, sono disponibili determinati comandi per l'elaborazione dei messaggi.

Comandi in Non-Authenticated State
In Non-Authenticated State, si trovano gli utenti che sono collegati al server ma che si devono ancora autenticare per avere la possibiilta' di gestire la propria posta. I comandi disponibili in questo stato sono:  
AUTHENTICATE: indica il metodo di autenticazione da utilizzare;
LOGIN <utente> <password>: invia al server il nome utente e la password per autenticarsi;

Comandi in Authenticated State
Una volta forniti i corretti valori di login e password si passa in Authenticated State. Le operazioni possibili in questo stato sono: scegliere, esaminare, creare, cancellare, rinominare una mailbox, controllarne lo stato e gestire le sottoscrizioni ad altre caselle. I comandi utilizzati sono:  
Select <mailbox>: seleziona la mailbox con cui lavorare;
Examine <mailbox>: seleziona la mailbox ma con accesso in sola lettura;
Create <mailbox>: crea una nuova mailbox;
Delete <mailbox>: cancella una mailbox;
Rename <vecchio-nome-mailbox> <nuovo-nome-mailbox>: rinomina una mailbox;
Subscribe <mailbox>: aggiungela mailbox alla lista delle caselle attive da visualizzare in un client IMAP;
Unsubscribe <mailbox>: elimina la mailbox alla lista delle caselle attive da visualizzare in un client IMAP ;
List <riferimento> <mailbox>: restituisce un sottoinsieme dei nomi disponibili al client;  
LSUB <riferimento> <mailbox>: restituisce un sottoinsieme delle casella sottoscritte dall'utente;  
Status <mailbox> <stato>: indica lo stato della mailbox;  
Append <mailbox> <messaggio>: aggiunge un messaggio alla mailbox selezionata;

Comandi Selected State
In selected state, ovvero quando si e' scelto su quale casella elaborare sono disponibili i comandi per la gestione dei messaggi:  
Check: funzione di manutenzione del server IMAP;
Close: riporta in Authenticated State e rimuove i messaggi con flag \Delete attivo;
Expunge: rimane nello stato Selected e rimuove i messaggi con flag \Delete attivo;
Search [setcaratteri] <parametri>: cerca i messaggi che soddisfano i parametri di ricerca indicati;
Fetch <messaggi> <dati>: visualizza determiniti dati di un messaggio (Es. Subject, data, testo ecc);
Store <messaggi> <valore-dati>: cambia i dati che si voglio modificare nel messaggio. Viene solitamente usato per cambiare i flag di stato;
Copy <messaggi> <mailbox>: copia i dati nella casella specificata;
Uid <comando> <argomenti>: esegue i comandi impartiti in base al numero Uid (Unique Identifier) anzichè il numero messaggio;

Comandi Logout State
Una volta che il client effettua una richiesta di chiusura della connessione, si passa in logout state, successivamente appena pronto il server terminare il collegamento.

Comandi disponibili in ogni stato
Alcuni comandi non sono associati ad un particolare stato del server e quindi sono sempre disponibili:  
CAPABILITY: indica le funzioni supportate dal server;
NOOP: non esegue nulla, risponde in modo positivo se il server è attivo. Utilizzato per evitare la disconnessione causa timeout;
LOGOUT: indica al server che il client vuole terminare la connessione;

Un esempio di sessione IMAP tramite telnet:  

[homer@Enigma homer]# telnet imap.joker.net 143
* OK [CAPABILITY IMAP4REV1 LOGIN-REFERRALS STARTTLS AUTH=LOGIN] joker.net IMAP4rev1 2001.315 at Sun, 13 Jul 2003 22:09:17 +0200 (CEST)  
Il server risponde e visualizza la versione del protocollo. Siamo in Non-Authenticated State.  
a100 LOGIN homer onslls  
a100 OK [CAPABILITY IMAP4REV1 IDLE NAMESPACE MAILBOX-REFERRALS SCAN SORT THREAD=REFERENCES THREAD=ORDEREDSUBJECT MULTIAPPEND] User homer authenticated  
Viene eseguito il login e l'utente è accettato. Siamo in Authenticated State.  
a101 select inbox  
Viene selezionata la mailbox inbox (la posta in arrivo). Siamo in Selected State.  
* 2 EXISTS  
* NO Trying to get mailbox lock from process 925  
* 0 RECENT  
* OK [UIDVALIDITY 1058126897] UID validity status  
* OK [UIDNEXT 3] Predicted next UID  
* FLAGS (NonJunk \Answered \Flagged \Deleted \Draft \Seen)  
* OK [PERMANENTFLAGS (NonJunk \* \Answered \Flagged \Deleted \Draft \Seen)] Permanent flags  
* OK [UNSEEN 1] first unseen message in /var/spool/mail/homer  
a101 OK [READ-WRITE] SELECT completed  
La prima voce 2 EXISTS indica che sono presenti due messaggi  
a102 fetch 1:2 (flags body[header.fields (subject)])  
Viene effettuata una richiesta di visualizzazione dei subject delle due mail presenti...  
* 1 FETCH (FLAGS (\Seen NonJunk) BODY[HEADER.FIELDS ("SUBJECT")] {37}  
Subject: Protocollo IMAP Overview  
)  
* 2 FETCH (FLAGS (\Seen NonJunk) BODY[HEADER.FIELDS ("SUBJECT")] {20}  
Subject: Prova 2  
)  
a102 OK FETCH completed  
a103 FETCH 1 (body[text])  
Richiesta del corpo del messaggio 1  
* 1 FETCH (BODY[TEXT] {105}  
Messaggio di prova,  
relativo all'Infobox sul protocollo IMAP per Openskills  
--  
Arnaldo aka Homer  
)  
a104 STORE 1 +FLAGS (\Deleted)  
Il messaggio 1 viene marcato con il flag \Deleted ovvero da cancellare  
* 1 FETCH (FLAGS (\Seen \Deleted NonJunk))  
a104 OK STORE completed  
a105 EXPUNGE  
Vengono cancellati i messaggi con il flag \Deleted attivo (in questo caso il messaggio 1)   
* 1 EXPUNGE  
* 1 EXISTS  
* 0 RECENT  
a105 OK Expunged 1 messages  
a106 LOGOUT  
Una volta lanciato il comando logout si entra in Logout State  
* BYE joker.net IMAP4rev1 server terminating connection  
a106 OK LOGOUT completed
  
Il server invia il messaggio BYE e termina la connessione

Come per gli altri protocolli a livello applicativo, un client di posta che supporta IMAP si occuperà per l'utente di scambiare i messaggi con il server.


Il protocollo DNS

Domain Name System: Logica e sintassi base.

Overview DNS

Autore: lorenz - Ultimo Aggiornamento: 2003-05-12 10:25:19 - Data di creazione: 2003-05-12 10:25:19
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

DNS, acronimo di Domain Name System, strutturato come un database si occupa della risoluzione dei nomi di dominio (es. www.esempio.com) nei loro corrispettivi indirizzi numerici (es. 10.11.12.13) e viceversa, delle informazioni relative all'instradamento della posta e di ulteriori dati relativi a diverse applicazioni internet.

La struttura dei nomi di dominio è gerarchica, ad albero in cui la radice indica il dominio principale ed è rappresentata da un punto alla fine del nome (es. www.example.com.).

Nella maggior parte dei casi il punto finale viene omesso a parte quando ci si appresta a editare i file delle zone, in cui è importante specificarlo per far capire al server i limiti della zona su cui ha autorità.

I dati che un DNS gestisce sono identificati in nomi di dominio e organizzati in una struttura ad albero. Ogni nodo dell'albero corrisponde a un dominio e ne viene assegnato un nome. Un nome di dominio pienamente qualificato (FQDN, Fully Qualified Domain Name) nasce dall'unione di tutti i nomi dei nodi (detti "etichette") che lo compongono, separati da un punto, a partire dal nome della macchina per arrivare al punto finale del dominio radice.

Ad esempio pc01.esempio.com è composto dal dominio com, il quale è il dominio principale (TLD, Top Level Domain), dal dominio esempio che è un sottodominio o dominio secondario di com e  per finire da pc01 che altri non è che il nome della macchina.

Per fini amministrativi ad ogni nodo che compone un nome di dominio corrisponde una zona.
Per il DNS i file delle zone contengono i riferimenti ai domini di cui il server ha competenza o eventualmente contengono i riferimenti ad altre zone a cui il server demanda il compito di risoluzione dei nomi. Queste zone a loro volta saranno competenti per tutti i loro sotto-domini.

Il DNS utilizza principalmente il protocollo UDP  per la gestione delle richieste fuorchè nei casi in cui i dati superano il limite di 512 bytes imposto dal protocollo UDP (ad esempio per un "zone transfer") in tal caso utilizza TCP. La porta utilizzata dal servizio è la 53 sia in UDP che in TCP.

Un server DNS può essere di vari tipi:
- Authoritative Server: Un DNS autoritativo per una determinata zona contiene tutti i dati relativi alle zone di sua competenza. Per un servizio quanto più invulnerabile ai fallimenti è generalmente consigliato "appoggiare" (ridondanza) le zone ad uno o più server secondari (detti slave). Il server che mantiene le copie principali dei file delle zone è detto master o primary server. Il secondary o slave server aggiorna i suoi file di zona da un'altro server attraverso una procedura detta zone transfer. Il file di zona contiene un numero seriale che va incrementato ogni volta che il file subisce una modifica in questo modo i server slave riconosceranno i cambiamenti. Generalmente li trasferisce dal primary server ma questo non è obbligatorio, se ne deduce che un server slave può essere master per un'altro/i.
- Caching Only Server: Detto anche Recursive Server effettua dei recursive lookups per conto dei client locali e inoltre mantiene una cache delle ultime richieste effettuate di modo che alla replicazione delle richieste non debba più rivolgersi all'esterno per la risoluzione. Questo ha un effetto di minor occupazione di banda e quindi anche di una maggiore velocità nelle risposte. Essendo questo tipo di DNS completamente indipendente dagli altri si appresta all'implementazione in reti protette da firewall.

Record di risorse e file delle zone

Autore: lorenz - Ultimo Aggiornamento: 2003-10-23 19:02:40 - Data di creazione: 2003-10-23 19:02:40
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Per comprendere il funzionamento del DNS è necessario comprendere il significato di un record di risorsa e il funzionamento del database delle zone.

I record risorse DNS sono voci memorizzate all'interno dei file che compongono un database DNS.
Il database DNS è un set di file di testo (ASCII), detti anche file delle zone, che contiene le informazioni sulle macchine che compongono un determinato dominio.

Le informazioni vengono associate ad un dominio aggiungendo record di risorse al database DNS di un nameserver primario. Il database corrispondente ad un determinato dominio contiene le informazioni sul dominio di cui il nameserver è autoritario o eventualmente i riferimenti che indirizzano ad un altro nameserver che avrà autorità per il dominio richiesto.
Ecco perchè quando si parla di database DNS se ne parla in termini di database "distribuito". Non esiste un nameserver  principale contenente tutte le informazioni su tutti i domini esistenti, ogni DNS ha autorità (contiene i dati) solo per il dominio di sua competenza e la risoluzione dei nomi esterni al suo viene delegata ad altri server.

Un database elementare conterrà almeno tre file:
db.network (ad esempio db.10.11.12)
db.domain (ad esempio db.esempio)
db.127.0.0
Da ricordare: tutti i file descritti possono avere nomi arbitrari, andranno poi specificati nel file di configurazione.
Il primo file conterrà le informazioni necessarie per risolvere gli indirizzi numerici IP (ad esempio 10.11.12.13) in nomi di host (ad esempio miohost.esempio.com)
Il secondo file conterrà invece le informazioni necessarie ad eseguire il procedimento opposto, da un nome di host al suo corrispettivo IP numerico.
Il terzo file infine conterrà una corrispondenza per l'host locale.

Ciascun file di zona ha 3 sezioni principali:
Start of Authority (SOA), nameserver (NS) e la sezione database contenente le informazioni sugli host.
La sintassi può essere rappresentata così:
[TTL][class] type data
[class][TTL] type data

I due campi TTL e class sono campi opzionali che corrispondono alla durata Time-To-Live e alla classe del record di risorsa. Il Time-To-Live indica quanto tempo il nameserver attende prima di effettuare un refresh del record. Può essere omesso in tal caso il valore di default è di tre ore.
Il campo della classe indica a quale classe di dati appartiene il record. Si usa una sola classe per tutti i record che è IN e sta a significare che si tratta di dati Internet.
Il campo type è obbligatorio e descrive il tipo di record risorsa.

Vediamo alcuni dei principali tipi e il loro significato:
SOA: Start of Authority, posizionato all'inizio di ogni file di zona indica l'inizio di una zona autoritativa per il nameserver.
NS:  Name Server, indica il o i server che hanno autorità per una determinata zona.
A: Address, indica l'indirizzo di un host. E' utilizzato per tradurre un nome host nel suo corrispettivo numerico.
PTR: Record Puntatore, si trova solo nei file come da esempio, db.network o db.127.0.0, serve per convertire un indirizzo ip nel suo nome di domino.
CNAME:Canonical Name, questo record è importante per assegnare un alias ad un host. Per esempio se una macchina su una rete interna si chiama miohost.esempio.com e fornisce servizi di web (www) e ftp è utile che possa essere chiamato www.esempio.com o ftp.esempio.com.
MX: Mail Exchange, questo record serve a specificare gli host che si occuperanno di instradare la posta e la loro priorità. La priorità indica l'host che si occuperà per primo dell'instradamento della posta ed è rappresentata da un numero che segue immediatamente dopo il record MX, un numero piccolo indica il server che ha la priorità.


I protocolli FTP e TFTP

File Transfer Protocol: sintassi e logica. Introduzione a TFTP (Trivial File Transfer Protocol)

Protocollo FTP Overview

Autore: homer - Ultimo Aggiornamento: 2003-05-23 20:50:36 - Data di creazione: 2003-05-23 20:50:36
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

FTP (File Transfer Protocol) è il protocollo generalmente utilizzato per trasferire dati tra due host.

Il protocollo di trasferimento dati FTP viene descritto nella RFC 959, l'obbiettivo per cui è stato sviluppato è il trasferimento affidabile ed efficiente dei dati, per questo motivo si basa TCP. In particolare un FTP Server rimane in attesa di connessioni sulla porta 21, i comandi utilizzati sono di tipo case-insensistive, possono essere seguiti da argomenti e sono terminati da un CRLF (Invio).
  
FTP utilizza due processi distinti per compiere il proprio compito:  
PI (Protocol Interpreter) attraverso cui il client invia i comandi e riceve le risposte dal server;  
DTP (Data Transfer Process) attraverso il quale il client ed il server si scambiano i dati;  
  
Il Data Transfer Process può essere di due tipi Active MODE (default) o Passive MODE. Nella modalità Active Mode il client contatta il server il quale da inizio alla connessione (sulla porta 20) per trasmettere i dati con il client. In Passive MODE è prerogativa del client anche dare il via alla connessione per il trasferimento dei dati.
  
Le fasi di una sessione FTP sono:  
FASE 1: Il client contatta il server sulla porta 21 utilizzando il processo PI;  
FASE 2: Autenticazione del client;  
FASE 3: Trasferimento dati attraverso tramite il DTP;  
FASE 4: Termine della sessione TCP;  
  
CODICI DI RISPOSTA  
Ad ogni comando inserito il server risponde inviando un codice che identifica la riuscita o meno dell'operazione richiesta. I codici sono numerici e composti da tre caratteri xyz, ognuno dei quali identifica in modo sempre più dettagliato lo stato delle operazioni. In particolare avremo in x il valore più significativo in y un maggiore dettaglio in relazione a x così di seguito per z.
  
Per quanto riguarda il codice di risposta più significativo, ovvero il primo dei tre caratteri abbiamo:  
1yz: Risposta preliminare positiva. Indica che il comando è stato accettato e che si avrà un ulteriore risposta prima del comando successivo;  
2yz: Comando terminato con successo;  
3yz: Risposta intermedia positiva. Comando eseguito correttamente e in attesa di ulteriori informazioni per completare l'operazione;  
4yz: Il comando non è stato eseguito correttamente;  
5yz: Comando che il server non ha potuto eseguire;  
    
FTP ANONIMO  
Il protocollo FTP permette anche la possibilità di sessioni FTP anonime, situazione tipica di un file server pubblico dove per esempio viene reso disponibile software per il download. In questo caso al client, a cui viene richiesto username anonymous e come password il proprio indirizzo email, viene permesso l'accesso in sola lettura.
    
PRINCIPALI COMANDI FTP  
Accesso  
OPEN <host>: Apre una connessione verso un determinato host;  
USER <nomeutente>: Identifica l'utente che accede al server FTP;  
PASS <password>: Invio della password (di default in chiaro);  
QUIT: Termina la sessione client-server;  
Parametri di trasferimento  
PORT <indirizzo-e-porta>: Definisce su quale porta lato client deve essere stabilita la connessione dati ;  
PASV: Attiva o disattiva la modalità Passive MODE;  
Trasferimento  
TYPE: Indica il tipo di trasferimento dei dati;  
ASCII: Tipo di trasferimento per il file di testo;  
BINARY: Tipo di trasferimento per i file non di testo: eseguibili, grafici ecc.;  
GET <file-remoto> <file-locale>: Trasferimento di un file dal server al client;  
MGET <file-remoto> <file-locale>: Trasferimento multiplo di file dal server al client;  
PUT <file-remoto> <file-locale>: Trasferimento di un file dal client al server;  
MPUT <file-remoto> <file-locale>: Trasferimento multiplo di file dal client al server;  
PROMPT: Abilita/disabilita la conferma per ogni file durante il trasferimenti multipli;  
Gestione File  
DELETE: Cancella un file sul server;  
MDELETE: Effettua una cancellazione multipla;  
LCD: Cambia la directory sul client;  
CD: Cambia la directory sul server;  
CDUP: Cambia la directory spostandosi in quella di livello superiore;  
PWD: Visualizza la directory in cui ci si trova al momento;  
MKDIR: Crea una nuova directory sul server;  
RMDIR: Rimuove una directory sul server;  
LS o DIR: Visualizza l'elenco dei file presenti sul server;  
RENAME <file-1> <file-2>: rinomina un file;  
Aiuto  
HELP o ?: Visualizza i comandi disponibili sul client FTP;  
!: Esce alla shell di sistema mantenendo in esecuzione il client FTP in cui si può rientrare con EXIT;  
STATUS: Visualizza le informazioni sulla sessione corrente;  
VERBOSE: Visualizza una quantità maggiore o minore di informazioni in relazione alle operazioni eseguite;
    
Una sessione di esempio:  
homer@Joker:~$ ftp  
Connessione al serever tramite un client FTP a linea di comamndo, ma è possibile utilizzare anche Telnet  
ftp> open ftp.joker.net  
Connected to ftp.joker.net.  
220 ProFTPD 1.2.5 Server (ProFTPD Joker Installation) [Joker.Net]  
Il server risponde e visualizza il proprio banner. Il codice di risposta è di tipo 2xx ovvero di comando completato con successo  
Name (ftp.joker.net:homer): homerweb  
331 Password required for homerweb.  
Qui è possibile notare che il codice di risposta è 3xx ovvero, che il comando è stato eseguito con successo ma mancano altre informazioni... ovvero la password che verrà inserita successivamente  
Password: h03hwp  
Remote system type is UNIX.  
Using binary mode to transfer files.  
ftp> type ascii  
200 Type set to A.  
Settaggio del tipo di trasferimento dati su ASCII  
ftp> help pwd  
pwd     print working directory on remote machine  
Tramite il comando help è possibile visualizzare l'aiuto su un determinato comando  
ftp> ls  
200 PORT command successful.  
150 Opening ASCII mode data connection for file list.  
drwxr-xr-x  4 homerweb users   4096 May  7 09:36 arnaldotest  
drwxr-xr-x  2 homerweb users   4096 May 18 20:28 arnaldoweb2003  
226 Transfer complete.  
ftp> cd arnaldotest  
250 CWD command successful.  
ftp> pwd  
257 "/arnaldotest" is current directory.  
Verifica della directory in cui ci si trova tramite il comando PWD  
ftp> ls  
200 PORT command successful.  
150 Opening ASCII mode data connection for file list.  
-rw-r--r--  1 homerweb users   1015 Mar 19 13:39 leggimi.txt  
-rw-r--r--  1 homerweb users   1793 Mar 19 13:38 guestbook_read.php  
-rw-r--r--  1 homerweb users   3293 Mar 19 13:38 guestbook_write.php  
226 Transfer complete.  
ftp> get testphp.php  
local: testphp.php remote: testphp.php  
200 PORT command successful.  
150 Opening ASCII mode data connection for testphp.php (1391 bytes).  
E' possibile notare il codice 1xx ovvero risposta preliminare positiva, si avrà una risposta di successo o di insuccesso solamente ad operazione terminata  
226 Transfer complete.  
1439 bytes received in 0.0649 secs (22 Kbytes/sec)  
Trasferimento dal SERVER al CLIENT del file testphp.php   
ftp> put dati.txt  
local: dati.txt remote: dati.txt  
200 PORT command successful.  
150 Opening ASCII mode data connection for dati.txt.  
226 Transfer complete.  
41 bytes sent in 0.00116 secs (35 Kbytes/sec)  
Trasferimento dal CLIENT al SERVER del file dati.txt  
ftp> quit  
221 Goodbye.  
homer@Joker:~$
  
Uscita, ritorno al prompt di sistema e termine della connessione TCP
    
Per FTP, come per altri protocolli, sono stati sviluppati client di tipo grafico per facilitare il trasferimento di file da parte degli utenti. File Transfer Protocol è supportato anche sui comuni browser web.

Protocollo TFTP Overview

Autore: homer - Ultimo Aggiornamento: 2003-10-03 08:57:54 - Data di creazione: 2003-10-03 08:57:54
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

TFTP è un protocollo molto semplice utilizzato per trasferire file tra due host utilizzando UDP.

TFTP (Trivial File Transfer Protocol) è definito nella RFC 1350, ed è stato progettato per trasferire file utilizzando come protocollo di trasporto UDP (User Datagram Protocol). La porta sulla quale è in ascolto un TFTP server è la 69. Essendo molto semplice e con meno funzioni rispetto a FTP, non può leggere directory e non è provvisto di autenticazione, il suo utilizzo è limitato. TFTP viene solitamente usato per trasferire file tra un computer ed un altro dispositivo come router o switch in ambito LAN.

I dati trasmessi tramite TFTP sono rappresentati da pacchetti con una lunghezza fissa di 512 byte. Un pacchetto avente una dimensione inferiore rappresenta l'ultimo pacchetto trasmesso. I pacchetti dati inviati vengono memorizzati in un buffer fino alla ricezione della avvenuta accettazione da parte dell'host remoto. In caso di mancata conferma della ricezione entro un determinato tempo di un pacchetto, quest'ultimo viene ritrasmesso. La modalità di trasferimento dati di TFTP è di due tipi:  
- NETASCII per i file di testo;  
- OCTET per i file binari.

I pacchetti utilizzati durante una sessione TFTP sono di cinque tipi:  
- RR: Read Request (Richiesta di lettura);  
- WR: Write Request (Richiesta di scrittura);  
- DATA: Dati;  
- ACK: Acknowledgment (Accettazione);  
- ERR: Errore;  

Le fasi di una sessione TFTP:  
1. Il client contatta il server inviando una pacchetto di tipo RR (richiesta di lettura) o WR (richiesta di scrittura);  
2. Il server, se accetta la connessione, risponde inviando/ricevendo pacchetti DATA di 512 byte. Per ogni pacchetto inviato/ricevuto regolarmente viene inviato/ricevuto un ACK altrimenti un ERROR;
3. I pacchetti vengono trasferiti finchè la loro lunghezza non è inferiore a 512 byte;  
4. Termine della connessione;  
  
Esempi:  
Un caso frequente di utilizzo di TFTP, la copia di un file di configurazione da un TFTP server ad un router Cisco:  
Router-GW1# copy tftp run  
Address or name of remote host []? 192.168.0.120  
Indicazione del TFTP server   
Source filename []? cisco2500-config  
Indicazione del file da trasferire  
Destination filename [running-config]? (invio)  
Accessing tftp://192.168.0.120/cisco2500-config...  
Loading cisco2500-config from 192.168.0.120 (via Ethernet0):  
!!  
[OK - 487/4096 bytes]  
487 bytes copied in 5.400 secs (97 bytes/sec)  
Router-GW1#

  
Trasferimento dati tra due computer:  
F:\Arnaldo>tftp joker get prova.txt  
Il client richiede (GET) al TFTP server joker il file prova.txt  
Trasferimento effettuato: 14 byte in 2 secondi, 7 byte/s

  
Il protocollo TFTP viene utilizzato nell'ambito di soluzioni diskless dagli host BOOTP, il suo compito è quello di scaricare il sistema operativo per i client.


Il protocollo Telnet

Introduzione al protocollo Telnet

Protocollo Telnet Overview

Autore: homer - Ultimo Aggiornamento: 2003-08-04 19:58:32 - Data di creazione: 2003-08-04 19:58:32
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE

Telnet fornisce un metodo di comunicazione standard e bidirezionale, attraverso il quale due host possono comunicare.

Il protocollo Telnet, descritto nelle RFC 854 e 855, permette a due host di comunicare tra loro. Grazie a questo protocollo è possibile impartire comandi al server remoto come se si fosse localamente collegati a quest'ultimo. Una sessione telnet, utilizza il protocollo TCP per la comunicazione e necessita di un Telnet Server in ascolto sulla porta 23.
  
Le funzioni fornite a due host che comunicano tramite una sessione telnet sono:  
- Network Virtual Terminal (NVT);  
- Negoziazione delle opzioni;  
- Viste simmetriche di terminali e processi;  
  
Network Virtual Terminal
NVT, come indica il nome, è un ambiente virtuale creato ai due estremi della connessione, dove operano rispettivamente il client ed il server Telnet. Le funzioni disponibili per la connessione sono negoziate tra i due host partendo da un insieme minimo, il quale deve essere necessariamente disponibile. In questo modo è possibile offrire un ambiente identico per i due host che instaurano la connessione in base alle caratteristiche comuni disponibili per ciascuno e preventivamente negoziate. Grazie a NVT, non è quindi necessario utilizzare software specifici sia dal lato client che da quello server.    
  
Negoziazione delle opzioni
In quanto non tutti i client ed i server Telnet supportano le medesime funzioni, è stato implementato un meccanismo di negoziazione delle opzioni grazie al quale, una sessione può avvenire utilizzando le caratteristiche comuni ai due host. Le opzioni di base disponibili possono poi essere successivamente ampliate.  
La negoziazione, che avviene solitamente all'inizio di una connessione, utilizza quattro tipi di richieste:  
- DO <codice opzione>: Richiede all'NVT ricevente di implementare l'opzione richiesta;  
- DON'T <codice opzione>: Richiede all'NVT ricevente di cessare l'utilizzo dell'opzione richiesta;  
- WILL <codice opzione>: Propone all'NVT ricevente di implementare l'opzione indicata;  
- WON'T <codice opzione>: Propone all'NVT ricevente di cessare l'utilizzo dell'opzione indicata;  
  
Viste simmetriche di terminali e processi
La capacità di negoziare le opzioni, essendo simmetrica può dare origine ad un ciclo infinto di richieste qualora uno dei due host interpretasse erronamente le richieste. Telnet prevede delle funzioni per evitare questo tipo di problema:  
- La richiesta di definizione di un'opzione può essere inviata ad un NVT solo se viene richiesto un cambiamento dello stato delle opzioni;  
- Se un NVT riceve una richiesta di definizione di un'opzione già definita non deve inviare nessun messaggio di accettazione al fine di evitare la possibile nascita di un loop senza fine;  
- E' possibile definire una nuova opzione anche quando il flusso dati della sessione è in corso. L'opzione sarà attiva dalla sua definizione in avanti;
  
Funzioni di controllo standard
Essendo tra gli obbiettivi del protocollo quello di definire uno metodo standard per la comunicazione, indipendentemente dal sistema su cui è in funzione il terminale, sono stati definite alcune funzioni di controllo standard:  
- Interrupt Process (IP): sospende un processo in corso su un server Telnet;  
- Break (BRK): indica che è stato premuto il tasto break;  
- Abort Output (AO): porta a termine il processo in esecuzione senza visualizzare l'output sul terminale utente;  
- Are You There (AYT): permette di sapere se l'host remoto è ancora online;  
- Erase Character (EC): permette di correggere i caratteri di una stringa di testo prima di inviarla al server;  
- Erase Line (EL): permette di cancellare una riga completa dall'input dei comandi;  
- Synchronize (SYNCH): permette di riprendere il controllo della sessione in caso di problemi;
  
Caratteri di Escape  
Ogni comando inviato da un client ad un server Telnet è composto da due parti: il codice di Escape detto anche IAC (Interpret As Command) ed il codice del comando. I codici di Escape hanno lo scopo di distinguere i comandi dai dati durante la sessione Telnet tra due host.
  
Alcuni dei principali comandi telnet:  
close: chiude la sessione corrente;  
display: visualizza i parametri operativi della sessione;  
open <host> <porta> : indica a quale server e su quale porta deve avvenire il collegamento;        
quit: esce dal client telnet;  
send <codice>: invia dei caratteri speciali al server;  
set <parametro>: imposta i parametri operativi;  
unset <parametro>: elimina l'impostazione di un parametro operativo;  
status: visualizza lo stato della connessione;  
?: visualizza l'help in linea;  
  
Un classico utilizzo: l'accesso ad una shell di un host in rete. Un esempio:  
homer@Apollo13:~$ telnet  
telnet> open 192.168.0.1  
Avvio del client e connessione all'host 192.168.0.1  
Trying 192.168.0.1...  

Welcome to Joker Linux Slackware Box!!!  

Joker login: homer  
Password: du367fh34r  
L'host risponde quindi passa alla fase di autenticazione...  
Linux 2.4.18.  
Last login: Wed Jul 23 09:35:32 +0200 2003 on pts/0 from 192.168.0.100.  
No mail.  
homer@Joker:~$
  
Connessione avvenuta con successo. A questo punto è possibile impartire comandi come da locale. (Esiste anche la possibilità di implementare un telnet server con accesso anonimo)
  
Essendo Telnet un protocollo flessibile, può essere utilizzato per diversi molti altri compiti come per esempio: effettuare sessioni POP3, IMAP, SMTP, oppure collegarsi alla console di router.


Il protocollo CIFS/SMB

Common Internet File System / Server Message Block

Fondamenti di NetBios

Autore: al - Ultimo Aggiornamento: 2006-02-28 14:31:06 - Data di creazione: 2003-03-24 17:12:34
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE

Quando si parla di NetBios, NetBEUI e SMB si rischia spesso di far confusione fra protocolli, livelli di applicazione, definizione e contesti. Non è un caso, questi sono argomenti di fatto anomali, nel mondo del networking, che si trascinano dietro due decenni di utilizzi in rete e relative implementazioni.
Cerchiamo di chiarire le cose a grandi linee, in modo da poter meglio individuare gli argomenti che ci interessano e contestualizzarli correttamente.

NetBios strettamente parlando più che un protocollo è un interfaccia di programmazione (API) fatta sviluppare da IBM nel 1983 per permettere a delle applicazioni di comunicare scambiandosi file e messaggi sui PC network del tempo, che avevano un basso numero di host e non prevedevano ancora l'uso del protocollo IP (già presente ma usato più su WAN che in LAN) per le comunicazioni di rete.
Con l'introduzione di Token Ring, IBM nel 1985 definì delle estensioni a NetBios (NetBIOS Extended User Interface NetBEUI) che permettevano di appoggiarsi ad un data-link 802.2 (Token Ring o Ethernet).
Microsoft ha iniziato ad usare NetBEUI come protocollo di rete su Windows for Workgroup (Windows 3.1) e poi su tutte le versioni successive ma, al contempo, con la diffusione di Novell IPX e di IP, si è iniziato a veicolare NetBios anche su IPX e IP, oltre che su altri protocolli.
E' quindi possibile trovare NetBios (tipicamente proposto come protocollo a livello di sessione) nella sua incarnazione originaria, come NetBIOS Frames Protocol (NBF) detto anche semplicemente NetBios o NetBEUI, che copre i livelli di network e trasporto, oppure incapsulato su IPX o TCP/IP con questi ultimi a gestire il network e transport layer e NetBios posizionato come session layer.
Il protocollo Server Message Block (SMB) e il suo derivato Common Internet File System (CIFS) agiscono a livello applicativo, direttamente su NetBEUI, NetBios su IPX o NetBios su IP (chiamato anche NBT o NetBT), CIFS, invece, nelle sue recenti versioni può anche essere trasportato direttamente dal TCP/IP, senza layer NetBios intermedio.

Caratteristiche di NetBios
L'indirizzamento di NetBios è flat, basato sul semplice nome di un host (generalmente fino a 15 caratteri) e senza elementi gerarchici (come il DNS) che di fatto lo rendono inadatto per gestire il routing fra network diversi. Il nome NetBios è lo stesso che viene utilizzato dai procotolli superiori come SMB/CIFS.  
Per impedire che due host nella stessa rete abbiamo lo stesso nome viene utilizzato il protocollo Name Management Protocol (NMP), tramite il quale, a colpi di broadcast, un host annuncia la sua presenza in rete e avverte quando un nuovo host con lo stesso nome prova ad apparire.
Nella comunicazione fra host si usano lo User Datagram Protocol (UDP, diverso dall'UDP usato su IP), unreliable e basato su datagrammi fino a 512 byte e il Session Management Protocol (SMP), bidirenzionale, reliable e basato su sessioni che vengono stabilite fra due host. Meccanismi di controllo e di monitoring vengono gestiti dal Diagnostic and Monitoring Protocol (DMP).
Attualmente la forma maggiormente utilizzata è quella di NetBios incapsulato su TCP/IP (NetBios over TCP/IP o NBT). Questo standard è definito nelle RFC 1001 e RFC 1002 dove si affrontano le problematiche relative all'associazione di un nome di host ad un indirizzo IP (broadcast o server di nomi centralizzato) e i metodi di comunicazione (a datagrammi o a sessioni).
Le porte utilizzate per questi servizi sono:
netbios-ns      137/udp                         # NETBIOS Name Service
netbios-dgm     138/udp                         # NETBIOS Datagram Service
netbios-ssn     139/tcp                         # NETBIOS Session Service

Gestione dei nomi su NetBios
I nomi di host di NetBios su TCP/IP (che coincidono con i nomi SMB) possono essere registrati (annunciati) e risolti (trovati) sul network locale sia tramite broadcast che tramite un server di nomi centralizzato (NBNS NetBios Name Server, su sistemi Windows l'implementazione di un NBNS è il WINS server) che risulta, soprattutto su reti affollate, molto più efficace.
A seconda di come un host è configurato per gestire i nomi assume un tipo di nodo diverso:
b-node - Host che usa solo broadcast per la risoluzione e la registrazione degli host name.
p-node - Host che usa un server centrale (comunicazione point-to-point) per risoluzione e registrazione
m-node - Host che usa broadcast per la registrazione e la risoluzione, inoltre se porta a termine con successo una registrazione lo notifica ad un server NBNS, che viene usato anche quando la risoluzione via broadcast non ha successo.
h-node (hybrid) - Host che usa un server NBNS per risoluzione e registrazione dei nomi e, nel caso in cui il server NBNS non sia disponibile utilizza i broadcast. Questa modalità è stata introdotta da Microsoft, non appare nelle RFC 1001 e 1002.
Il tipo di nodo, su Windows, è visibile nell'output del comando ipconfig /all dove si parla di NodeType

I nomi possono essere lunghi 15 caratteri (byte) e contenere caratteri alfanumerici standard ( a-z, A-Z, 0-9, ! @ # $ % ^ & ( ) - ' ). Il sedicesimo e ultimo byte indica il tipo di risorsa, a seconda del valore esadecimale indicato corrisponde una diversa risorsa, alcuni esempi:
00 - Normale workstation
03 - Servizio di messaggistica (WinPopup)
1B - Domain Master Browser
20 - Fileserver
NetBios inoltre prevede il concetto di gruppo (i Workgroup in ambiente Windows).

Principi di SMB
SMB è un protocollo di livello applicativo utilizzato per la condivisione di directory fra computer, la stampa via rete e lo scambio di file e messaggi. Si basa su una struttura client-server ed ha una logica di tipo request-response. Dalla sua introduzione originaria ha subito varie modifiche e varianti che modificano e aggiungono nuovi SMB (Server Message Blocks, di fatto i "comandi" utilizzabili). Su Windows 95 e NT per esempio viene utilizzata la variante NT LM 0.12, che viene supportata, fra gli altri, anche da Samba, un implementazione OpenSource del protocollo che è utilizzabile su gran parte degli Unix in circolazione.

L'implementazione Windows di SMB

Autore: al - Ultimo Aggiornamento: 2003-03-25 16:09:46 - Data di creazione: 2003-03-25 16:09:46
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

Microsoft utilizza NetBios e SMB come protocolli di rete per condividere risorse su Windows fin da Windows 3.1. Rispetto alle versioni esistenti di questi protocolli ha introdotto alcune estensioni proprietarie:

- Domini Windows
- Browsing
- Server WINS

I Domini Windows
Fondamentalmente un dominio Windows è un workgroup con un server che agisce come Domain Controller con funzioni di autenticazione centralizzata per l'accesso alle risorse (file, stampanti, login sul sistema...) da parte tutti gli host che fanno parte del dominio.
Vengono usati protocolli differenti per Windows 95/98, Windows NT e Windows 2000 (dove il concetto di dominio viene ulteriormente allargato con le Active Directory).
Il Primary Domain Controller (PDC) è il server che mantiene un database di tutte le password (SAM): quando un client cerca di accedere alle risorse di un server, quest'ultimo verifica sul PDC se login e password fornite sono valide. Se questo accade al client viene permesso l'accesso alle risorse richieste e fornito un token di autenticazione con cui automaticamente riesce ad accedere ad altre risorse in rete accessibili dalla stessa login.
Il database delle password viene automaticamente copiato ad uno o più Backup Domain Controller (BDC) che possono  essere utilizzati per autenticare i clinet nel caso in cui i PDC risulti inaccessibile.

Browsing
Per rendere più rapida l'individuazione degli host e delle risorse in una rete locale, Microsoft ha introdotto il Local Master Browser un computer che ha il ruolo di mantenere la lista degli host in rete (browse list) e che fa da riferimento per tutte le richieste e gli aggiornamenti da parte delle altre macchine in rete.
Praticamente ogni macchina Windows può agire da Local Master Browser o da Backup Browser (host che riceve la browse list da un Master Browser e viene utilizzata in caso di inagibilità di quest'ultimo). Queste funzionalità vengono definite automaticamente dagli host NetBios in una rete locale tramite una procedura chiamata elezione in cui tutti gli host partecipano tramite broadcast. A seconda del sistema operativo, della versione di protocollo utilizzata, del tempo di uptime nella rete e del nome dell'host viene automaticamente deciso chi deve operare come Master Browser e questo rimane tale fino a quando resta connesso o un nuovo host con migliori credenziali si aggiunge alla rete.
Quando si clicca, in Windows, su Risorse di Rete di fatto si ottiene dal Master Browser la browse list degli host in rete (notare che questa potrebbe essere non perfettamente aggiornata, con alcuni host che risultano presenti anche se magari sono spenti o disconnessi e non hanno avuto modo di comunicarlo al Master Browser), quando si clicca sul singolo host si ottiene l'elenco delle sue risorse condivise.

Server WINS
Il Windows Internet Name Service (WINS) è l'implementazione Microsoft di un NetBios Name Server (NBNS) che ha la funzione di mantenere la lista dei nomi NetBios degli host in rete e dei relativi indirizzi IP. Ovviamente questo serve quando si usa NetBios over TCP/IP ed è una soluzione consigliabile quando si ha una rete medio grande o si devono connettere workgroup presenti su network IP differenti.
Anche in questo caso, oltre ad un Primary Wins Server possono esistere uno o pià Secondary Wins Server con funzioni di ridondanza e backup.


Il protocollo NFS

Network File System: Introduzione

Overview NFS

Autore: neo - Ultimo Aggiornamento: 2003-03-27 12:15:05 - Data di creazione: 2003-03-27 12:15:05
Tipo Infobox: DESCRIPTION - Skill: 2- JUNIOR

NFS è l'acronimo di NETWORK FILE SYSTEM, è un protocollo sviluppato originariamente da SUN nei primi anni 80, per poter shareare o meglio esportare directory o interi filesystem a più client.

NFS si appoggia alla classica struttare server/client dove il server è il sistema che realmente possiede le risorse che esporterà e il cliente tramite un client NFS e il protocollo NFS potrà montare le risorse remote e utilizzare tali risorse come se fossero in locale.

Nel corso della storia dell'evoluzione di ambienti Unix e Unix-like l'uso di NFS si è trasformato (attualmente vengono utilizzate due versioni NFSv2 e NFSv3) e il suo reale impiego è cambiato.
Nato come supporto per workstation diskless ora viene utilizzato in ambienti distribuiti per propagare o per rendere disponibile a tutti i sistemi una risorsa.
Il classico esempio è la DocumenRoot di un server web che viene esportata a tutti i serverweb di una farm.

In questi ultimi anni NFS è stato affiancato da altri protocolli per lo sharing di risorse ma viene tuttora comunemente utilizzato sia in ambiente Unix che misto proprio per il fatto che è un protocollo supportato dalla maggior parte dei sistemi operativi, nonostante la pericolosità derivate dall'insicurezza intrinsica del protocollo.
Di fatto NFS si appoggia a RPC per rafforzare il rapporto client e server con tutti i problemi del caso legato a questa procedura (i bachi di RPC sono molto famosi ed utilizzati per accedere alle macchine altrui).
NFS risulta essere una soluzione vincente in una intranet o in una struttura dove le risorse non possono essere montate da sistemi esterni per ovvi motivi di sicurezza.

Di seguito sono riportati le principali differenze fra i protocolli NFSv2 e NFSv3:

- Il limite della dimensione del file.
Nella vesione v2 è limitato a 2 Gb mentre nella versione v3 supporta file molto più grandi.

- Il protocollo nfsv2 prevede 8k come dimensione massima del blocco dati in lettura e scrittura.
Il limite teorico del protocollo nfsv3 è superiore a 64k ma attualmente i parametri di default del kernel prevedono ancora blocchi da 8k. In alcune kernel patch è previsto l'incremento fino a 32k.  

- Nfsv2 prevede che ogni richiesta di scrittura del client venga eseguita prima che il server stesso risponda al client. Nfsv3 invece prevede che il server invii lo status della richiesta di scrittura finchè tutti i dati non verranno scritti su disco, quindi maggior controllo sulla richiesta di scrittura dati da remoto.

Attualmente è in via di sviluppo il protocollo NFSv4 da parte della IETF (Internet Engineering Task Force), la quale a reso pubblica tutta la documentazione relativa a questo nuovo protocollo al seguente indirizzo: http://www.ietf.org/ids.by.wg/nfsv4.html.

Maggiori informazioni sull'implementazione di NFS con linux si possono traovare al seguente indirizzo: http://nfs.sourceforge.net/.

Dettagli tecnici sul protocollo sono reperibili tramite le relative RFC:
- NFSv2 RFC n° 1094   http://www.ietf.org/rfc/rfc1094.txt
- NFSv3 RFC n° 1813   http://www.ietf.org/rfc/rfc1813.txt
- NFSv4 RFC n° 3010   http://www.ietf.org/rfc/rfc3010.txt


Il protocollo SNMP

Simple Network Management Protocol: logica, sintassi e MIB

Protocollo SNMP Overview

Autore: homer - Ultimo Aggiornamento: 2003-08-19 11:34:30 - Data di creazione: 2003-08-19 11:34:30
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE

SNMP è un protocollo utilizzato per la gestione dell'infrastruttura di rete.

Simple Network Managment Protocol (SNMP), permette il monitoraggio (statistiche sullo stato dei sistemi) ed il controllo (modifica delle impostazioni) di dispositivi di rete quali Server, Router, Switch, Hub ecc. Grazie ad SNMP è possibile sapere throughput, il carico, dati sulle interfacce di rete, e prestazioni di un sistema. E' generalmente utilizzato su reti TCP/IP ma può essere implementato anche su reti IPX o AppleTalk.

SNMP è passato attraverso alcune revisioni fino all'attuale versione 3:  
- SNMPv1: descritto nelle RFC 1155-1157 rappresenta la prima versione, utilizza l'invio dei nomi di community (utilizzati come password) in chiaro;  
- SNMPv2: descritto nelle RFC 1441-1452 in cui sono state aggiiunte nuove funzionalità tra cui la crittografia tramite MD5;  
- SNMPv3: descritto nelle RFC 2571-2575 è lo standard finale, ma al momento raramente utilizzato;  

SNMP FRAMEWORK  
Sostanzialmente un framework SNMP è composto da una o più Stazioni di Gestione (Management Station) e dagli agenti SNMP (SNMP Agent) in funzione sui device di rete. Le Management Station interrogano gli agent i quali inviano le informazioni richieste sul device. Solitamente gli agent SNMP di un apparato di rete sono implementati nel firmware dello stesso, mentre per quanto riguarda i server, si tratta di servizi software. Gli oggetti gestiti dagli agent, sono raccolti, in ogni device, in un database chiamato MIB (Management Information Base) secondo la struttura definita nella SMI (Structure Management Information).

Esiste un caso particolare dove l'apparato di rete non viene interrogato, ma è esso stesso a generare il messaggio ed inviarlo alle Management Station.  E' infatti possibile configurare gli agent in modo da inviare un particolare messaggio al verificarsi di determinati eventi ovvero impostare le cosidette trap. Grazie all'impostazione delle trap è possibile ad esempio sapere quando un'interfaccia di rete smette di funzionare, in quanto al verificarsi del guasto, l'agent SNMP che esegue il monitoraggio dell'apparato invia alla Management Station un messaggio che identifica il problema.

SNMP utilizza come protocollo di trasmissione UDP in modo da ottenere migliori performance e minore overhead della rete. In particolare viene utilizzata la porta UDP 161 per le interrogazioni e le risposte, e la porta UDP 162 come destinazione dei messaggi trap SNMP generate dagli agent SNMP.

SNMP COMMUNITY  
L'insieme degli apparati di rete gestiti da SNMP appartengono ad una comunità (community). La comunità rappresenta un identificativo che permette di garantire la sicurezza delle interrogazioni SNMP. Un agent SNMP risponde solo alla richieste di informazioni effettuate da una Management Station appartenente alla stessa comunità.  
I nomi di comunità sono formati da 32 caratteri e sono di tipo case sensitive.

Esistono tre tipi di comunità:  
- monitor: permette di lavorare in sola lettura, quindi di effettuare solamente interrogazioni agli agent (il cui nome di comunità deve corrisponde a quello della management station che ne ha fatto la richiesta) ;
- control: permette tramite gli agent SNMP di effettuare delle operazioni in lettura/scrittura sul dispositivo, quindi di variarne delle impostazioni sempre previo controllo di sicurezza;
- trap: permette ad un agent di inviare un messaggio trap SNMP alla management station secondo la propria configurazione.

Spesso i nomi di community di default predefiniti sono public per le comunità di sola lettura e write o private per quelle in lettura/scrittura. Ovviamente è bene modifcare queste impostazioni di default per motivi di sicurezza.

MESSAGGI SNMP  
SNMP utilizza sei tipi di messaggi di base per svolgere il proprio lavoro. Ogni messaggio è definito in PDU (Protocol Data Unit) separate, e precisamente:  
- GetRequest: è utilizzata per interrogare un MIB su un agent SNMP;  
- GetNextRequest: è utilizzata per leggere in modo sequenziale un MIB;  
- GetBulk: permette di leggere un MIB con un unica richiesta anzichè utilizzare più messaggi GetNextRequest;  
- SetRequest: modifica il valore all'interno di un MIB acceddibile in lettura/scrittura;  
- GetResponse: identifica la risposta da parte di un agent SNMP ad un'interrogazione di una management station;  
- Trap: permette all'agent di inviare un messaggio al verificarsi di un determinato evento;  
  Alcune trap sono predefinite:  
   - coldStart: generata quando l'agente SNMP si reinizializza e la configurazione è stata cambiata (Es. reboot del sistema);  
   - warmStart: generata quando l'agente SNMP si reinizializza ma senza cambiamenti nella configurazione;  
   - linkDown: generata quando il collegamento con l'agent non funziona correttamente;  
   - linkUp: generata quando il collegamento con l'agent viene ripristinato;  
   - authenticationFailure: generata da un'autenticazione con l'agent non andata a buon fine (Es. nome di comunità errato);  
   - egpNeighborLoss: generata da problemi di EGP (Exterior Gateway Protocol - utilizzato dai router);  
   - enterpriseSpecific: evento definito dal produttore del device;  

STRUCTURE MANAGEMENT INFORMATION (SMI)  
Structure Mangement Information definisce in modo standard come devono essere strutturate le informazioni e la loro gerarchia per essere inserite nel database MIB e quindi gestite da una manager SNMP.
La gerarchia degli oggetti, è ad albero:  

            [root]  
[ccit(0)][iso(1)][joint-iso-ccitt(2)]  
            [org(3)]  
            [dod(6)]  
            [internet(1)]  
[directory(1)][management(2)][experimental(3)][private(4)]  
                     [mib(II)]                                          [enterprise(1)]  
   [System(1)][Interfaces(2)][Address Translation(3)][Ip(4)][Icmp(5)][Tcp(6)][Udp(7)][Egp(8)][Snmp(9)]  

Ogni oggetto della gerarchia viene identificato in modo univoco, attraverso il suo percorso nell'albero, la variable Hostname per esempio è identificata da  iso.org.dod.internet.management.mib.system.sysdescr oppure 1.3.6.1.2.1.1.1.

Gli oggetti sono definiti tramite la sinstassi ASN.1 (Abstract Syntax Notation One), la quale permette di non avere ambiguità tra funzioni e proprietà dell'oggetto definito.

MANAGEMENT INFORMATION BASE (MIB)  
La management Information Base, è una base di dati contenente tutte le informazioni gestite dall'agent SNMP che è in funzione sulla device monitorata. Gli oggetti all'interno di una MIB vengono definiti in base alle strutture SMI. Attualmente lo standard utilizzato è la MIB-II.

All'interno di ogni MIB gli oggetti sono suddivisi in categorie, in particolare:  
- System: contiene informazioni di carattere generale sul device di rete;  
- Interfaces: contiene le informazioni relative alle interfacce di rete;  
- Address Translation: contiene informazioni relative alla conversioni degli indirizzi (Es. da logico a fisico), esiste per compatibilà con MIB-I;  
- Ip: contiene informazioni relative al protocollo IP;  
- Icmp: contiene informazioni relative al protocollo ICMP;  
- Tcp: contiene informazioni relative al protocollo TCP. Gli oggetti di questo gruppo esistono solo per la durate della sessione TCP;  
- Udp: contiene informazioni relative al protocollo UDP;  
- Egp: contiene informazioni relative al protocollo EGP (protocollo utilizzato da un router per scambiare informazioni tra Autonomous System);  
- Transmission: sperimentale, contiene informazione sui mezzi trasmissione utilizzato da ogni interfaccia di rete ;  
- Snmp: contiene informazioni relative al protocollo SNMP.

Privacy Policy