Computer networks / reti di elaboratori by Andrea Mantoni Ultima modifica: %%mtime(%d %B %Y) = Introduzione = def. *Rete di elaboratori* = insieme di elaboratori *autonomi* e *interconnessi* OSS.: rete di elaboratori != *Sistema distribuito* = rete di elaboratori + SO distribuito In una rete gli elaboratori mantengono la loro indipendenza. Un sistema distribuito invece dà l'illusione di un unico elaboratore. classificazione: - per tecnologia trasmissiva: - *broadcast* = un unico canale di comunicazione condiviso, con *indirizzamento* - *PPP = Point-to-Point*, con routing + store&forward - per scala dimensionale: - locale/privata -> LAN = Local Area Network - metropolitana -> MAN = Metropolitan Area Network - geografica -> WAN = Wide Area Network == LAN = Local Area Network == caratteristiche: - dimensione: < 1-2 km - tecnologia trasmissiva: broadcast @ 10/100 Mbps - basso ritardo di propagazione - basso tasso di errore topologia: - *bus* = un solo elaboratore alla volta può trasmettere - *ring* = tutti possono sempre trasmettere in entrambi i casi è necessario un *arbitraggio*, che può essere: - ad allocazione statica (ad es. con time slots) - ad allocazione dinamica: - arbitraggio distribuito -> Ethernet / IEEE 802.3 - arbitraggio centralizzato == WAN = Wide Area Network == caratteristiche: - molto estesa - alto ritardo di propagazione - alto tasso di errore Mette in comunicazione gli elaboratori / *hosts / end systems* in LAN differenti mediante una *communication subnet / sottorete*, che può essere: - wired / cablata -> point-to-point costituita da: - trunks / linee di comunicazione - routers / switching elements - wireless -> broadcast (ad es. con onde radio o satellite) - mista def. Inter-net = insieme di più reti LAN collegate mediante *gateways / routers multiprotocollo*. = Software di rete = Il software di rete è organizzato a livelli. Ogni livello: - offre dei servizi ai livelli più alti (service provider) - ottiene dei servizi dai livelli più bassi (service user) - ha associati dei *protocolli* = insieme di regole e convensioni con il quale dialogano 2 *peer-entities* di 2 processi distinti - comunica _direttamente_ con i livelli adiacenti mediante le *interfacce* - comunica _indirettamente_ con le peer-entities mediante i protocolli funzionamento: ogni processo può operare in modalità *send o receive*. A seconda della modalità ogni livello aggiunge o rimuove degli *headers / trailers* al *messaggio*. Mediante questi headers avviene la comunicazione indiretta tre le peer entities. Un messaggio che contiene tutti gli headers fino al livello "n" è detto *n-PDU = Protocol Data Unit*. Quando questo passa al livello sottostante diventa un *(n-1)-SDU = Service Data Unit*, a cui vengono aggiunti (in modalità send) gli headers di livello n-1, detti *(n-1)-PCI = Protocol Control Information*. La comunicazione tra due livelli adiacenti invece avviene direttamente mediante le interfacce. Ogni interfaccia è caratterizzata da più *SAP = Service Access Point*, aventi un loro indirizzo. L'insieme dei SAP del livello "n" è detto "n-SAP". n-PDU livello n | - - - -o- - - - - -o- - - - - - -o- - - - - - - - - interfaccia (n-1)-SAP | (n-1)-PCI + (n-1)-SDU livello (n-1) Una interfaccia è caratterizzata da: - primitive di servizio - tipo di servizi offerti: - *connection-oriented* (con dialing e canale di comunicazione - tipo telefono) - *connection-less* (con indirizzamento - tipo posta) Nel primo caso si specifica l'indirizzo del destinatario _una sola volta_, e si apre quindi una *connessione* con esso. Nel 2° caso ogni messaggio è spedito individualmente, con il proprio indirizzo. - QoS = Quality of Service - reliable / affordable = assicura la consegna dei dati a destinazione - non-reliable ad es. servizio *datagram* = connectionless non-reliable == Architettura di rete == def.: *Architettura di rete* insieme dei livelli e dei protocolli del software di rete Oss.: non include / specifica: - le interfacce tra i livelli - la struttura interna dei livelli classificazione: - proprietaria (ad es. IBN SNA, Novell IPX) - di dominio pubblico: - standard de iure (ad es. IEEE xxx) - standard de facto (ad es. TCP/IP) === OSI reference model === OSS.: OSI reference model != architettura di rete TCP/IP OSI non definisce formalmente i protocolli, ma dà un modello. livelli: USER | 7. APPLICATION ---------- (6. PRESENTATION) ---------- (5. SESSION) ---------- 4. TRANSPORT ---------- 3. NETWORK ---------- ---------- 2. DATALINK ---------- ---------- 1. FISICO ---------- ---------- | HOST 1 ------------ ROUTER ---------- HOST 2 OSS.: il controllo di flusso e degli errori avviene a diversi livelli === Architettura TCP/IP === 7. APPLICATION (vari) ... (gestito dall'applicazione) 4. TRANSPORT (TCP/UDP) -> gestisce la connessione, ricostruisce il msg originale 3. INTERNET (IP) -> controlla il flusso, prepara i pacchetti ... (gestito dal SO) 1. FISICO Il livello internet offre solo servizi connectionless non affidabili. (I pacchetti IP viaggiano in maniera indipendente gli uni dagli altri.) Il livello transport superiore invece è di solito reliable e connection-oriented (TCP). Oppure può usare il protocollo non-reliable connectionless (UDP), e lasciare all'applicazione il compito di leggere e riordinare i pacchetti. == Livello 1 - Fisico == La trasmissione dei dati si ottiene variando dinamicamente qualche proprietà del *mezzo fisico* utilizzato: - mezzi elettrici - basati sul movimento di elettroni nei cavi - mezzi wireless - basati sul movimento di elettroni nell'aria - mezzi ottici - basati sul movimento di fotoni L'informazione trasmessa è detta *segnale* e può essere rappresentata come un funzione periodica "g(t)" di periodo "T". Il segnale può essere di due tipi: - *analogico* -> funzione continua, con molti valori - *digitale* -> funzione discontinua / onde quadre, pochi valori Fourier nell'800 dimostrò che: Una funzione periodica "g(t)" di periodo "T" può essere scomposta nella somma di un numero _infinito_ di funzioni sinusoidali aventi frequenze multiple di "f=1/T". g(t) = 1/2 c + SUM(n=1->inf) a_n sin(2 phi f t) + SUM(n=1->inf) b_n cos(2 phi f t) + Oss.: c, a_n, b_n sono costanti "f" è detta *frequenza fondamentale* Un segnale può essere dunque rappresentato con uno *spettro di frequenze* tutte comprese entro un certo intervallo/banda (*frequency band*). === Mezzi fisici === Ad ogni mezzo fisico/medium è associata una *banda passante / bandwidth*. proprietà: - inversamente proporzionale alla lunghezza del mezzo - può essere "tagliata" con dei *filtri low-pass e/o high-pass* problemi: - attenuazione - sfasamento / ritardo di propagazione - rumore Affinchè un segnale non venga alterato nella trasmissione è necessario che: signal frequency band E' CONTENUTA nella banda passante del mezzo fisico === Campionamento === Per la sua trasmissione un segnale deve essere campionato ad intervalli regolari "T". Nyquist dimostrò che un segnale di banda "h" richiede "2h" campionamenti al secondo per essere ricostruito. Il n° di bits necessari a descriverlo sarà: 2*h*log_2(V) bps Teo di Nyquist: in un mezzo fisico _ideale_: Max datarate = 2*h*log_2(V) bps h = banda passante del mezzo V = valori discreti che il mezzo può trasmettere OSS.: per aumentare il datarate se il mezzo lo consente si può aumentare "V". Nei mezzi fisici _reali_ sono presenti delle interferenze energetiche / *EMI = ElectroMagnetic Interference*, dette *rumore* di fondo*. def. *SNR = Signal/Noise Ratio* = rapporto tra l'energia del segnale e quella del rumore di fondo. si misura con una scala logaritmica: log_10(S/N) = 0,x dB Teo di Shannon: in un mezzo fisico _reale_: Max datarate = h*log_2(1+S/N) OSS.: più alto è il S/N ratio, più alto è il datarate (OSS.: "S" è proporzionale a "V")? in generale: il datarate è _sempre_ proporzionale alla banda passante del mezzo fisico. === Mezzi fisici più comuni === - *doppino intrecciato* = 2 conduttori di rame intrecciati - UTP = Unshielded Twisted Pair: Cat 3, Cat 5 (usati nelle LAN) - STP = Shielded Twisted Pair (ingombranti, poco usati) bandwidth: diversi Mbps fino a qualche km - *cavo coassiale* = 1 conduttore centrale in rame rivestito da 1 strato isolante e 1 calza metallica - baseband (50 ohm) (per 1 sola trasmissione digitale) - bandwidth: 1-2 Gbps fino a circa 1 km - broadband (75 ohm) (per + trasmissioni analogiche, usato per la TV via cavo) - bandwidth: 300 MHz fino a quasi 100 km - *fibre ottiche* = cilindro centrale in vetro (*core*) + strato esterno di vetro con indice di rifrazione diverso (*cladding*) - multimodali (+ segnali luminosi con diversi angoli) - monomodali (~= 1 guaina d'onda) vantaggi: - leggere - no disturbi elettromagnetici - sicurezza svantaggi: - collo di bottiglia: fotodiodi ricevitori - due fibre sono necessarie per una comunicazione two-way - costi delle giunzioni - *onde elettromagnatiche* nell'aria -> ampia banda passante, alto rumore, broadcast spettro elettromagnatico: - LF = Low Frequencies - 0-300kHz (bande marittime) - MF = Medium Frequencies / onde medie - 300kHz-3MHz (radio AM) - HF = High Frequencies - 3-30MHz (radio FM) - VHF, UHF = Very, Ultra High Frequencies - 30MHz-3GHz (TV) - SHF - 3-30GHz (Satelliti) - EHF - 30-300GHz (unused) - IR = Infra Red - 0.3-385THz - luce visibile - UV = Ultra Violet - X Rays / radiazioni ionizzanti - >3000THz Le onde di frequenza più bassa passano attraverso gli edifici, percorrono lunghe distanze, e sono riflesse dalla ionosfera. A frequenze più elevate le onde sono estremamente direzionali e vengono fermate dagli ostacoli. L'allocazione delle frequenze dipende dall'autorità statale. Per trasmisisoni di bassa potenza possono essere utilizzate le *bande ISM = Industrial, Scientific, Medical*: - banda 900MHz - larghezza 26MHz - banda 2.4GHz - larghezza 83MHz - banda 5.7GHz - larghezza 125MHz Per ovviare al rumore si utilizzano tecniche di *spread spectrum*: - *FHSS = Frequency Hopping SS* - *DSSS = Direct Sequence SS* (con ridondanza) === Il sistema telefonico === La *PSTN = Public Switched Telephone Network* è il mezzo più diffuso per comunicare nel mondo in tempo reale tra le persone. La subnet si basa su di una gerarchia di *centrali di commutazione*, messe in comunicazione mediante *trunks* (cavi coassiali, fibre ottiche). Ogni telefono è collegato alla centrale più vicina mediante il *local loop* (doppino telefonico). Il segnale (voce umana) viaggia in formato analogico nel local loop, quindi viene convertito in digitale dalla centrale e multiplexato assieme ai segnali delle altre conversazioni. tecniche di multiplexing: - *TDM = Time Division Multiplexing* (ad ogni segnale è assegnato un timeslot - la più usata) - *FDM = Frequency Division Multiplexing* (ad ogni segnale è assegnata una sottobanda - il segnale resta analogico) === Internetworking con il sistema telefonico === Per trasmettere i dati digitali prodotti da un computer sul local loop è necessario convertirli in un segnale analogico detto *portante / carrier wave* con un *modem* = MOulator/DEModulator. Per aumentare il datarate, si ricorre alla *modulazione di ampiezza/frequenza/fase* della portante, che consente di aumentare il numero di valori trasmissibili ("V" nel teo di Nyquist). Di solito si usa la *QAM = Quadrature Amplitude Modulation*, secondo i valori specificati da un *costellation pattern* standard. VARIANTE: *ADSL = Asymmetric Digital Subscriber Line* Per aumentare ulteriormente il datarate si possono rimuovere i *filtri passa-basso* a 3kHz nel local loop, e sfruttare così tutta la banda passante del mezzo. La banda inferiore ai 4kHz viene riservata per le chiamate vocali, quella superiore viene divisa in più sottobande da 4kHz ciascuna. Le sottobande vengono usate contemporaneamente per la trasmissione di più portanti modulate come sopra (tecnica *DMT = Discrete MultiTone*). A seconda della qualità del doppino e del SNR alcune sottobande possono essere temporaneamente inibite (con diminuzione del datarate). == Livello 2 - Datalink == Tipicamente implementato in hardware nella *NIC = Network Interface Card*. A volte può essere necessario implementare via software una *NIC virtuale* con il relativo livello datalink (ad es. per la virtualizzazione). Riceve in input un flusso di bits "grezzi" provenienti dal livello fisico. Offre i seguenti servizi: - *framing* = divisione del flusso di bits in *frames* - *gestione errori di trasmissione*, mediante l'aggiunta di *informazioni ridondanti* - *gestione flusso / congestione*, mediante lo scambio di *feedback* (gli *ack*) tra destinatario e mittente === Framing === tecniche: - spaziatura temporale -> inefficiente - *lenght counter* nell'header -> si può corrompere, poco affidabile - *fixed pattern flags* nell'header e nel trailer, che delimitano i confini -> problemi di ambiguità - *characher stuffing* inizio frame: DLE = Data Link Escape fine frame: DLE+ETX = End of TeXt - *bit stuffing* - violazioni della codifica -> richiede l'ausilio del livello 1 ad es.: *codifica Manchester* Ogni bit è codificato con una transizione di 2 valori di segnale: - 0 : -0.85V -> +0.85V - 1 : +0.85V -> -0.85V (l'inverso) pros: - è bilanciato - facilita la sincronizzazione - riduce gli errori cons: - richiede il doppio di banda === Gestione errori di trasmissione === Effettuato mediante l'aggiunta di *informazioni ridondanti* "r" al messaggio. def. "d", *distanza di Hamming* = il n° minimo di bits in cui differiscono tutte le parole di un codice / codewords - *EDC = Error Detection Code* = solo rilevamento: - *parity code* (r=d=1) - *CRC = Cyclic Redundancy Code / polinomial code* = rappresentano il messaggio come un polinomio, ed effettuano delle operazioni algebriche su di esso. - *ECC = Error Correction Code* = rilevamento + correzione: - algoritmi basati sulla *distanza di Hamming* (r=2d+1) PROBLEMA: *burst di errori* SOL.: trasmissione codeword in verticale / per colonne === Gestione flusso / congestione === Si basa sullo scambio di *feedback* (gli *ack*) tra destinatario e mittente. -> req. *canale half/full-duplex* -> se ciò non è possibile (*canale simplex*) si usa il *protocollo heaven* (senza ack) che però può portare a problemi di congestione e perdita dei dati. gli ack possono viaggiare: - autonomamente in *frames di ack vuoti* - a cavallo in un frame di dati (*piggybacking*) protocolli: - *heaven* (senza congestione) - *simplex stop-and-wait* (senza errori) - *simplex per canale rumoroso* (ack semplici) - *sliding window 1-bit* (ack + SEQ) - *sliding window + go-back-n (pipelining+cumulative ack+win size dest=1) - *sliding window + selective repeat (pipelining+cumulative ack+win size dest>1) protocolli (dettaglio): - *heaven* - *simplex stop-and-wait* = esplicita autorizzazione all'invio del prossimo frame Consente di risolvere il problema della congestione, ma NON quello degli errori/ritrasmissione. funzionamento: - il mittente, dopo aver trasmesso un frame dati si mette in attesa di un frame di ack prima del prossimo - il destinatario alla ricezione del frame di dati invia l'ack PROBLEMA: perdita del frame di ack -> attesa indefinita - *simplex per canale rumoroso / PAR = Positive Ack with Retrasmission* come prima, con in più: - un *timer* per la ricezione degli ack - *campo "SEQ"* nel frame per evitare il *problema dei doppioni* nel destinatario funzionamento: - il mittente ritrasmette lo stesso frame con lo stesso n° di seq. finchè non riceve un positive ack (o finchè non scade il timer). -> problema: se il timer è troppo breve 2 ack possono sovrapporsi - il ricevente invia un ack positivo _ogni volta_ che riceve un frame integro, MA passa al livello 3 solo quelli in ordine di sequenza. - *duplex sliding window* - si basano su piggybacking con timer la "finestra" è un buffer di frames da spedire o in attesa di conferma / ack. Ad ogni frame (di dati o di ack) è associato un n° di sequenza / indice nel campo "SEQ" ad "n" bit. funzionamento: - nel mittente la finestra scorre all'arrivo di un ack o all'arrivo di un nuovo frame dati dal livello 3 - nel destinatario solo i frames nella finestra vengono accettati e confermati. - *duplex sliding window 1-bit* come PAR, con in più l'uso del campo "SEQ" anche nei frames di ack. -> risolve il problema del timer troppo breve nel mittente -> nuovo problema: attese molto lunghe - *duplex go-back-n* si basa sul *cumulative ack* funzionamento: - il mittente ha la "finestra" di 1 bit: accetta solo i frames nella sequenza giusta. Se riceve un frame non nella giusta seq. ritrasmette l'ultimo ack e rifiuta il frame. - il destinatario può trasmettere più frames consecutivi (pipelining), ma ad un certo punto la sua finestra si "bloccherà" se non avrà ricevuto un n-ack (perchè l'n-frame è andato perso). Dovrà quindi tornare indietro e ritrasmettere tutti i frames dopo di "n" (go-back-n). - *duplex selective repeat* come prima, + finestra a "k" bit nel destinatario -> vengono accettati frames anche non in sequenza funzionamento: - il destinatario invia sempre un cumulative ack - il mittente si comporta come prima, solo che non dovrà ritrasmettere i frames perchè la finestra del destinatario farà un "salto" dei frames già ricevuti e bufferizzati dopo una ritrasmissione. VARIANTE: uso di *NAK = Negative AcKs* === Protocollo HDLC = High Level DataLink Control === Standard ISO / usato in 802.3. struttura del frame: 1. FLAG (8-bit) -> bit stuffing 2. Address (8-bit) (usato solo per l'indirizzamento multipunto?) 3. Control (8-bit) (SEQ, ACK, TYPE) -> protocollo duplex sliding window con 3-bit 4. Data (var-bit) 5. Checksum (16-bit) -> calcolato con CRC-CITT 6. FLAG (8-bit) -> bit stuffing === PPP = Point-to-Point Protocol === E' usato sia nei local loop che nei trunks. struttura del frame: 1. FLAG (8-bit) -> char stuffing 2. Address (8-bit) -> UNUSED 3. Control (8-bit) -> UNUSED 4. Protocol (8-bit) -> supporto protocolli livello network 5. Data (var-bit) 6. Checksum (16/32-bit) 7. FLAG (8-bit) -> char stuffing Il livello datalink in TCP/IP offre solo servizi _non affidabili_, quindi non vi è l'invio di ack/seq. == Sottolivello MAC = Medium Access Control == Solo per le reti broadcast -> mezzo trasmissivo condiviso / multi-access channel -> problema arbitraggio: - allocazione statica -> inefficiente per traffico bursty - allocazione dinamica -> ok === Modello a stazioni === definizioni: - Le *stazioni* che devono trasmettere hanno gli stessi privilegi. Ogni stazione può trasmettere _un solo frame alla volta_. - *collisione*: se 2 frames vengono mandati contemporaneamente sul medium si corrompono - *carrier sense*: prima di trasmettere le stazioni possono ascoltare il canale per vedere se è occupato - *tempo continuo* - *tempo slotted*: una nuova trasmissione può iniziare solo all'inizio di uno slot - *frame-time = frame lenght / bitrate*: tempo necessario alla trasmissione di un frame - *periodo di vulnerabilità*: tempo nel quale un frame è a rischio di collisioni -> scopo dei protocolli è minimizzarlo - *throughput*: quantità di pacchetti che arrivano a destinazione senza collisioni in un frame-time -> scopo dei protocolli è massimizzarlo === Protocollo Pure Aloha === regole: - Le stazioni trasmettono quando vogliono e subito (no carrier sense, continous time). - _Dopo_ la trasmissione ascoltano il canale per verificare l'incombenza di collisioni. - Al verificarsi di una collisione attendono per _tempo casuale_ e ritrasmettono. === Protocollo Slotted Aloha === Come prima, con in più: - Un dispositivo genera un segnale ad intervalli regolari = al frame-time - Slotted time -> periodo di vulnerabilità dimezzato! === Protocolli CSMA = Carrier Sense Multiple Access === Le stazioni effettuano il carrier sensing prima di trasmettere. con continous time: - *1-persistent* = trasmette _subito_ non appena il canale si libera (con probabilità = 1) - *non-persistent* = aspetta _tempo random_ dopo che il canale si libera con slotted time: - *p-persistent* = quando il canale è libero: - trasmette subito con probabilità "p" - attende il prossimo time-slot con probabilità "1-p" In tutti i casi, se si verifica una collisione attendono tempo random e ricominciano. PROBLEMA: dipendenza dal tempo di propagazione nel mezzo (ci vuole più tempo per rilevare le collisioni) === Protocolli CSMA+CD = CSMA + Collision Detector === Si alternano varie "fasi": 1. ascolto / carrier sensing 2. contesa - modellata come uno slotted Aloha con slot di durata "2T" = doppio del tempo di propagazione di un frame nel canale = tempo necessario per rilevare una collisione se durante questo periodo si verifica una collisione le stazioni coinvolte: - interrompono la trasmissione _immediatamente_ - attendono time slots casuali e ricominciano altrimenti la stazione può assumere di avere il controllo del medium ed inizia la fase di trasmissione vera e propria 3. trasmissione 4. inattività === Reti ad anello === Ogni NIC può operare in due modalità: - *listen-mode* = 1-bit delay tramite un buffer - *transmit-mode* -> l'anello è "aperto" OSS.: NO broadcast medium -> NO collisioni! Anche se le connessioni sono punto-a-punto una sola stazione alla volta può trasmettere sul ring. *Protocollo Token-Ring*: - una sequenza di bit detta "token" indica la disponibilità del mezzo - viene "messo in circolazione" sempre dall'ultima stazione che ha trasmetto PROBLEMA: *capacità del ring* >= bits del token (il token deve stare tutto sul ring) La capacità del ring dipende dal n° di stazioni e dalla lunghezza delle connessioni. Può essere necessario l'uso di un *monitor dell'anello* con un suo buffer. === Reti wireless WLAN === usano: - NIC half-duplex con _diverse portate_ / potenze di trasmissione - onde elettromagnetiche come mezzo trasmissivo -> mezzo broadcast con alto tasso di errore -> collisioni, interferenze topologie: - cella (con *base station / access point*) - *ad-hoc network* Poichè le stazioni hanno diverse portate si verificano dei problemi tipici: - *problema della stazione nascosta* (canale libero mittente !=> canale libero ricevente) Ogni stazione può rilevare la disponibilità del canale _solo alla sua portata_ e non nei pressi del ricevente. - *problema della stazione esposta* (canale occupato mittente !=> canale occupato ricevente) Le interferenze possono essere localizzate in certe zone. CSMA inefficace -> *Protocollo MACA = Multiple Access with Collision Avoidance* -> evita a priori il verificarsi di collisioni tra frames di dati Si basa sullo scambio di 2 frames di controllo: - *RTS = Request To Send* - *CTS = Clear To Send* (entrambi specificano la lunghezza dei dati da inviare) funzionamento: "A" = trasmettitore, "B" = ricevente Le stazioni alla portata di "A": - ricevono il suo RTS - devono rimanere in silenzio / listening finchè il CTS non raggiunge "A", poi possono trasmettere con "A" -> PROBLEMA: potrebbero non riceverlo se non sono alla portata di "B" -> SOLUZIONE: protocollo MACAW (vedi sotto) Le stazioni alla portata di "B": - ricevono il suo CTS - devono rimanere in silenzio / listening durante la trasmissione di dati A->B Le stazioni alla portata sia di "A" sia di "B" applicano entrambe le regole. Se si verificano collisioni tra frames RTS/CTS le stazioni attendono tempo casuale e riprovano. VARIANTE: *Protocollo MACAW = MACA for Wireless* come il MACA, con in più: - invio frame di ACK per segnalare la corretta ricezione dei dati - invio frame *DS = Data Send* per segnalare l'inizio dell'invio del frame di dati alle stazioni alla portata di "A" === Standard IEEE 802 per le LAN === 802.1 -> specifiche generali 802.2 -> *LLC = Logical Link Control* 802.3 -> Ethernet 802.3u -> Fast Ethernet 802.3z -> Gigabit Ethernet ... 802.5 -> Token Ring ... 802.11 -> WLAN ... 802.15 -> Bluetooth 802.16 -> WiMax OSS.: Lo standard propone la suddivisione del livello datalink in due sottolivelli: - LCC (up) - MAC (down) Esistono altri standard per le reti LAN non ancora approvati dallo IEEE: - HomePlug: = una serie di standard sulle reti powerline, che utilizzano i cavi della rete elettrica - HomePlug 1.0 (14 Mbit/s max) - HomePlug 1.0 Turbo (85 Mbit/s max) - HomePlug AV (200 Mbit/s max) - HPCC = HomePlug Command & Control, per il controllo remoto di dispositivi elettrici - HomePNA (reti su cavi coassiali o telefonici) - HomePNA 1.0 (1990) ... - HomePNA 3.1 (320 Mbit/s max) - ITU G.hn by the HomeGrid Forum (multi-wire standard = reti su cavi elettrici, telefonici o coassiali) === 802.2 LLC = Logical Link Control === Lo standard propone questo sottostrato superiore del livello datalink. comunica con: - sottolivelli MAC (sotto) - livello Network (sopra) Fornisce una _interfaccia unica_ ai vari sottolivelli MAC. (possono essercene uno per ogni tipo di NIC connessa all'elaboratore) Usa protocolli, interfacce e frames simili a HDLC. === Reti Token Ring 802.5 === caratteristiche: - datarate: 1, 4, 16 Mbps - cablaggio: 2 doppini STP/UTP cat 3, 4, 5 per stazione + 1 *wire center* che controlla e isola le parti dell'anello guaste - codifica: Manchester differenziale Ad una stazione viene assegnato il ruolo di *monitor*: - controlla il *THT = Token Holding Time* - controlla e rimuove i *frames orfani* = senza destinazione e i frames danneggiati dal ring === Reti Ethernet 802.3 === caratteristiche: - protocollo CSMA+CD - codifica dati Manchester - datarate: 10 Mbps - vari tipi di cablaggio: - *cavo Thick / 10Base5* = cavo coassiale baseband, max 500m + transceiver agganciato al cavo con un vampiro + transceiver drop cable alla interfaccia di rete - *cavo Thin / 10Base2* = cavo coassiale baseband, max 200m per segmento + giunzione passiva a "T" + transceiver integrato nell'interfaccia -> stazioni collegate "a cascata" -> problema interruzioni - *10Base-T* = doppino, max 100m per segmento + *HUB* = ripetitore multiporta che opera a livello 1 - gestione delle collisioni (solo con cavi Thick e Thin): - rilevate dal transceiver - invio *sequenza di jamming* / burst di rumore - attesa di un numero di time slots casuale prima di riprovare (scelto con il *binary backoff exponential algorithm*) === Fast Ethernet 802.3u === Si mantiene la compatibilità a livello logico dei protocolli, ma cambiano i cablaggi: - *10Base5/2* = cavi coassiali (non più supportati) - *100Base-T4* = 4 doppini di categoria 3 half duplex + codifica 8B/6T = 8 Bits in 6 Trits -> segnale ternario (0, 1, 2) velocità di segnalazione: 25 MHz - *100Base-Tx* = 2 doppini di classe 5 full duplex + codifica 4B/5B (con bit ridondanti) velocità di segnalazione: 125 MHz - *100Base-Fx* = 2 fibre ottiche multimodali full duplex + codifica 4B/5B velocità di segnalazione: 125 MHz target: datarate 100 Mbps soluzioni: se si aumenta la velocità di segnalazione si deve pure: - ridurre la lunghezza dei cavi -> si è scelto questo per 802.3u - aumentare la lunghezza minima dei frame -> scelta fatta per 802.3z === Reti WiFi 802.11 === caratteristiche: - banda ISM 2.4 GHz - tecniche trasmissive: FHSS, DSSS, *OFDM = Orthogonal Frequency Division Multiplexing* - datarate: 1, 2, 5.5, 11, 54 Mbps - codifica: @ 1/2 Mbps DSSS -> *sequenza di Barker*, con modulazione di fase @ 5.5/11 Mbps HR-DSSS -> *CCK = Complementary Code Keyring*, con modulazione di fase - protocolli arbitraggio: - *DCF = Distributed Coordination Function* -> CSMA/CA di tipo 1-persistent, con tempi di attesa prefissati: *DIFS/SIFS= Distributed / Short Inteframe Spacing* = MACA + carrier sense -> i frames di controllo vengono gestiti con un *NAV = Network Allocation Vector* - *PCF = Point Coordination Function* (centralizzato): - ogni stazione deve registrarsi presso un *AP = Access Point* - l'AP autorizza a turno le stazioni a trasmettere tra di loro I due protocolli possono coesistere grazie all'uso di *PIFS = PCF Interframe Spacing* t.c. DIFS < PIFS < SIFS. - servizi: - associazione / separazione da un AP - autenticazione - riservatezza (WEP, WPA) === 802.15 Bluetooth === caratteristiche: - ISM band from 2.4 GHz to 2.4835 GHz - per piccole distanze (~10m) [vs Wifi per grandi distanze] - packet-based protocol with a master-slave structure (up to 7 slaves supported) - progettato per dispositivi portatili (ad es. cellulari) -> energy efficient; - velocità supportate: 723,1 kb/s (<=v1.2), 3Mb/s (v2.0) [vs Wifi velocità più elevate] - max power output is 100 mW, 2.5 mW, and 1 mW for Class 1, Class 2, and Class 3 devices respectively (Class 1 is roughly the same level as mobile phones) i dispositivi bluetooth sono classificati secondo i seguenti *profili*, a seconda delle funzionalità che forniscono: - Generic Access Profile (GAP) - Service Discovery Application Profile (SDAP) - Cordless Telephony Profile (CTP) - Intercom Profile (IP) - Serial Port Profile (SPP) - Headset Profile (HSP) - Dial-up Networking Profile (DUNP) - Fax Profile - LAN Access Profile (LAP) - Generic Object Exchange Profile (GOEP) - Object Push Profile (OPP) - File Transfer Profile (FTP) - Synchronisation Profile (SP) === Bridge === Dispositivo che opera a livello datalink per mettere in comunicazione 2 LAN distinte. funzionamento: - per ogni LAN è presente una NIC ed un software compatibile - tutti i frames vengono "sbustati" fino al livello 2 / LCC e, solo se necessario, passano da un software all'altro - possono anche essere settati dei filtri sugli indirizzi LCC Lo standard 802.3 ne definisce due tipi: - *transparent bridge* (migliori e più usati) -> il bridge si costruisce delle *tabelle di instradamento* a runtime - *source-routing bridge* -> il mittente fornisce le info sull'instradamento nel campo "routing information". Tali info possono essere ottenute con un *discovery frame* che viene floodato da tutti i bridges nella rete == Livello 3 - Network == Si occupa del *routing / instradamento* dei pacchetti sulla *subnet di comunicazione*. La subnet è organizzata in maniera gerarchica per zone/regioni. Questo livello può operare in due modalità: - connection-oriented affordable, focus: i routers -> uso di *circuiti virtuali*, con negoziazione e pre-allocazione delle risorse - connectionless, not-affordable, focus: gli hosts -> uso di *tabelle di instradamento*, senza negoziazione === Routing === I *routers* sono dei dispositivi che operano fino al livello 3. Costituiscono il "cuore" della subnet di comunicazione. Sono collegati tra loro mediante diverse *linee*. 2 tipi: - *session routing* - *per-packet routing* algoritmi di routing: - statici / non-adattivi = one-shot, offline - dinamici / adattivi = online algoritmi di routing (dettaglio): - statici / non-adattivi = one-shot, offline - *flooding* = si instrada ogni pacchetto ricevuto su tutte le linee -> PROBLEMA: genera molti pacchetti inutili - *shortest path routing* = si conosce in anticipo la topologia della rete. Si associa ad ogni linea tra router un *peso*, e si applica l'algoritmo di Dijkstra -> 1 albero dei cammini minimi / *sink tree* per ogni router - *flow-based routing* = si conosce la topologia della rete ed il traffico. Si sceglie il routing che minimizza il *ritardo medio* della rete OSS.: se non si ha nessuna conoscenza della rete il flooding è l'unica scelta possibile - dinamici / adattivi = online - *distance vector routing* (utilizzato in IP) = i routers si _scambiano_ delle tabelle dette *vector* che contengono le info sulle _distanze_ tra i routers. Ogni router calcola il proprio vector mandando dei *pacchetti "ECHO"* ai router adiacenti ed aggiungendo le info che gli arrivano con gli altri vector. -> PROBLEMA: *count to infinity* = se una linea cade, le distanze verso il router isolato aumentano all'infinito - *link state routing* = i routers si scambiano dei pacchetti contenenti: - ID del router mittente - ID dei router adiacenti rilevati con le relative distanze - SEQ# - età ogni volta che muta la topologia della rete. Ogni router costruisce un *grafo della subnet* e calcola l'albero dei cammini minimi. Quando viene attivato avvia una *pacchetto "HELLO"*. OSS.: in entrambi i casi non è richiesta alcuna conoscenza della topologia della rete. Le info vengono scambiate in flooding tra i routers. === Congestion control === 2 approcci: - *open loop* = senza contro-reazione -> *traffic shaping* = si "forza" l'invio dei pacchetti ad un ritmo regolare - *closed loop* = con contro-reazione -> *choke packet* = si chiede di rallentare l'invio dei pacchetti se questi superano una certo limite approcci open loop: - *algoritmo leaky bucket* = i pacchetti in uscita vengono messi in un buffer (bucket) ed inviati ad un fissato datarate. Se il bucket si riempie i nuovi pacchetti vengono persi. - *algoritmo token bucket* = ad ogni host è associato un certo "credito" di tokens che aumenta con il passare del tempo e viene consumato all'arrivo di nuovi pacchetti. - *flow specification* = host e subnet si accordano in anticipo sulle caratteristiche del traffico. === Internetworking === L'inter-net-working richiede l'instradamento di pacchetti tra reti diverse mediante i *routers multiprotocollo*. I routers multiprotocollo possono essere organizzati in: - una rete - un *tunnel* = mette in comunicazione due reti = attraverso due reti != funzionalità: - conversione formato pacchetti e indirizzi - frammentazione e ricomposizione dei pacchetti === Internet === Internet è una collezione di *AS = Autonomous Systems* di varie estensioni: - *backbones* (continentali) - reti regionali - reti locali ma che utilizzano _tutte_ il *protocollo IP = Internet Protocol* di livello 3 (datagram, connectionless) struttura pacchetti IP (max tot 64 kByte): - HEADER (20->32 byte) - VERSION (4) - IHL = contatore lunghezza header - TYPE OF SERVICE - TOTAL LENGHT = contatore lunghezza intero pacchetto gestione della frammentazione: - IDENTIFICATION = ID del pacchetto originale - DF = Don't Fragment - MF = More Fragments (follows) - FRAGMENT OFFSET = ID del frammento - *TTL = Time To Live* = tempo max per la consegna del pacchetto - PROTOCOL = ID protocollo lv. transport di destinazione - HEADER CHECKSUM - SRC ADDRESS (32-bit) - DST ADDRESS (32-bit) - (routing) OPTIONS (1->3 bytes) - DATA (var-bit) === IPv4 Address === struttura *formato classful* (tot 4-bytes): - *network number* (1->3 bytes) -> assegnati dal NIC, universali - *host number* (1->3 bytes) -> assegnati dall'admin della rete, locali/privati Il numero di bytes del network number indica la *classe della rete*: + è alta la classe, - bytes servono ad identificare la rete e + bytes sono disponibili per gli hosts. notazioni: - *dot-decimal notation* = ognuno dei 4 bytes viene rappresentato come un intero (range 0-255), separato da un punto ".": aaa.bbb.ccc.ddd - *slash notation* = come la precedente + "/" + numero di bits riservati per il net number: aaa.bbb.ccc.ddd/e indirizzi speciali: 0.* .* .* = an host in this net 255.255.255.255 = broadcast on this net Y.255.255.255 = broadcast on net "Y" 127.* .* .* = loopback / localhost IANA Reserved Private Network Ranges: class A: 10.x.x.x class B: 172.16.x.x -> 172.31.x.x class C: 192.168.x.x PROBLEMA: poche classi / spreco di indirizzi IP pubblici SOLUZIONE: definizione di *subnetworks* ==== IPv4 Subnetting ==== SOL.1: *subnet mask* = parte dell'host number identifica una subnet: IPv4 Address = Network number + Subnet number + Host Number OSS.: La subnet mask ha validità _solo_ all'interno di una rete. Più reti possono avere lo stesso network number ma subnet number diverso. I routers interni devono avere delle entries apposite: - (this network #, this subnet #, host #) - (this network #, subnet #, 0) SOL.2: *CIDR = Classless Inter Domain Routing* si usa: 1 network mask \ 1 network number / VARIABILI pros: < spreco indirizzi IP > possibilità lottizzazione contro: routing più complesso SOL.3: *NAT = Network Address Translation* -> vedi paragrafo "NAT" === IP Routing === La routing table in ogni router contiene delle entries del tipo: - (0, host number, linea) per ogni host nella stessa rete del router - (network number, 0, linea) per ogni rete esterna conosciuta - (default router, 0, linea) per tutte le altre reti Quando arriva un pacchetto al router esso analizza _sempre e solo_ il network number per stabilire su quale linea in uscita instradarlo. === NAT === Il NAT opera una "traduzione" degli indirizzi nei pacchetti che transitano per il router su cui è in esecuzione. Il NAT può operare un 2 modalità: - *destination NAT* = cambia l'indirizzo _del destinatario_ - *source NAT* = cambia l'indirizzo _del mittente_ Il NAT considera 2 "lati": - *inside* = rete privata - *outside* = rete pubblica Il NAT considera 2 tipi di indirizzi: - *local* -> rete privata - *global* -> rete pubblica Il NAT utilizza al suo interno una *translation table* con static and dynamic entries: ( indirizzo inside local <-> indirizzo inside global ) A seconda del tipo di "traduzioni" effettuate distinguiamo i seguenti tipi di NAT: - *outbount* / unidirezionale (tradizionale) = source NAT pacchetti uscenti, destination NAT pacchetti entranti - PAT / NAPT / port nat - *inbound* / bidirezionale = destination NAT pacchetti entranti, source NAT pacchetti uscenti -> necessario per "rendere pubblico" un server nel lato inside - doppio / sovrapposto = destination NAT pacchetti uscenti, source NAT pacchetti entranti -> ~firewall (filtraggio indirizzi), ~tunelling == Livello 4 - Transport == E' il primo livello host-2-host: - "nasconde" la subnet sottostante - gestisce una _conversazione diretta_ tra host mittente e destinatario + orientato verso servizi affidabili connection-oriented -> possibilità di specificare il *QoS = Quality of Service* (deve essere negoziato) - orientato su servizi datagram servizi e protocolli ~= al lv.2 datalink: - segmenting - controllo degli errori - controllo di flusso complicazioni: - necessità _indirizzamento_ (ad es. port number) - apertura / attivazione della connessione - chiusura / rilascio della connessione === Attivazione della connessione === mediante *3-way handshaking*: 1. mitt -> conn.request(seq=x) -> dest 2. dest -> ack(ack=x, seq=y) -> mitt 3. mitt -> data(ack=y) -> dest === Chiusura della connessione === 2 modalità possibili: - asimmetrico (come il telefono) = la chiusura della connessione è _istantanea e bidirezionale_ -> perdita di dati possibile - simmetrico = 2 connessioni unidirezionali che devono essere rilasciate indipendentemente -> *rilascio concordato* -> *problema delle 2 armate 3 eserciti* -> protocollo *3-way handshaking con timeout*: 1. mitt -> disconnect_request -> dest 2. dest -> disconnect_accept -> mitt 3. mitt -> ack -> dest PROBLEMA: se tutte le "disconnect_request" si perdono si ha una *half-open connection* SOL.: - rilascio automatico di connessioni inattive - invio di *dummy TPDU* per "tenere viva" / keep-alive una connessione === Controllo di flusso === con sliding window =~ livello 2 datalink differenze con lv.2: - il lv. sottostante può offrire anche servizi affidabili > n° di connessioni > dimensione dei PDU *buffering*: - 1 pool di buffers _tutti uguali_ - 1 pool di buffers di dimensioni variabili - 1 array per ogni connessione Se si stà usando un servizio di lv.3 ed il mittente se che il destinatario ha spazio disponibile, il mittente può evitare il buffering. *upward multiplexing*: + connessioni \ 1 connessione transport / network PRO: risparmio di connessioni network *downward multiplexing*: 1 connessione \ + connessioni transport / network PRO: banda superiore === Livello Transport in Internet === 2 protocolli: - *TCP = Transmission Control Protocol* (connection-oriented, affidabile) - *UDP = User Data Protocol* (datagram) === TCP === indirizzamento: i SAP sono detti *sockets* IP address (32-bit) : port number (16-bit) 1 connessione di lv. transport è identificata da 2 sockets. protocollo sliding window go-back-n con timeout: - il lv. application sovrastante invia e riceve solo un _flusso di bytes_ - ogni byte è _numerato_ con un numero a 32-bit (sequence number) - il lv. transport divide questo flusso in *segments* = PDU lv.4 (max 64 kbytes) struttura: - SRC PORT (16-bit) - DST PORT (16-bit) - SEQ # (32-bit) - ACK # (32-bit) -> cumulative ack - HEADER LENGHT counter - FLAGS: URG, ACK, PSH, RTS, SYN, FIN - WINDOW SIZE - CHECKSUM (16-bit) - URGENT POINTER (16-bit) - OPTIONS (32-bit) - DATAS (var-bit) apertura connessione con 3-way handshaking: 1. connect_request: SYN=1, ACK=0, SEQ#=X 2. ack: SYN=1, ACK=1, SEQ#=Y, ACK#=X+1 3. data: SYN=0, ACK=1, SEQ#=X+1, ACK#=Y+1 chiusura della connessione: 1. FIN=1 2. ACK=1 gestione della congestione: 1. del destinatario -> con il campo WINDOW SIZE il destinatario segnala al mittente la dimensione della finestra = lo spazio libero nel suo buffer 2. della subnet -> mediante la *congestion window* gestita dal mittente sulla base degli ack ricevuti: - valore iniziale: window size = max segment size - ack in-time: crescita esponenziale fino al threshold, poi lineare - ack time-out: threshold = window size / 2 window size = max segment size (valore iniziale) === UDP === struttura segmenti: - SRC PORT (16-bit) - DST PORT (16-bit) - HEADER LENGHT (16-bit) - CHECKSUM (16-bit) -> opzionale - DATAS (var-bit) === Reserved IANA ports === La *IANA = Internet Assigned Numbers Authority* ha definito diversi gruppi di porte: - *Well Known Ports: 0–1023* They are used by system processes that provide widely-used types of network services. On Unix-like operating systems, a process must execute with superuser privileges to be able to bind a network socket to an IP address using one of the well-known ports. - *Registered Ports: 1024–49151* They are assigned by IANA for specific service upon application by a requesting entity. On most systems registered ports can be used by ordinary users. - *Dynamic, private or ephemeral ports: 49152–65535* They cannot be registered with IANA. It is used for custom or temporary purposes and for automatic allocation of ephemeral ports. Inoltre ha definito alcune porte standard: 80 -> HTTP (official) 8008 -> HTTP alternate (official) 8080 -> HTTP alternate / http_alt (official) — commonly used for Web proxy and caching server, or for running a Web server as a non-root user 8080 -> Apache Tomcat (unofficial) 443 -> HTTPS = Hypertext Transfer Protocol over SSL/TLS 4711 -> eMule optional HTTP interface (unofficial) 35021 -> utorrent optional HTTP interface (unofficial) 20 -> FTP (data transfer) 21 -> FTP (control/command) 22 -> SFTP = SSH File Transfer Protocol != SFTP = Simple File Transfer Protocol on port 115 (unsecure/obsolete) 989 -> FTPS = FTP over TLS/SSL (data only) 990 -> FTPS (control) 4993 -> home FTP Server HTTP Interface Default Port (unofficial) 1025/varing -> NFS = Network File System (the most popular file sharing protocol on Unix-like systems) (unofficial) 139, 445 -> SMB = Server Message Block aka CIFS = Common Internet File System (the most popular file sharing protocol on Windows systems) 548 -> AFP = Apple Filing Protocol (the most popular file sharing protocol on Mac systems) 9800 -> WebDAV = Web-based Distributed Authoring and Versioning 22 -> SSH = Secure Shell — used for secure logins, file transfers (scp, SFTP) and port forwarding 23 -> Telnet protocol — unencrypted text communications 119 -> NNTP = Network News Transfer Protocol 563 -> NNTPS = NNTP over TLS/SSL 109 -> POP2 = Post Office Protocol v2 - for email download 110 -> POP3 = Post Office Protocol v3 143 -> IMAP = Internet Message Access Protocol — management of email messages 220 -> IMAP, version 3 993 -> IMAPS = Internet Message Access Protocol over SSL (Official) 995 -> POP3S = Post Office Protocol 3 over TLS/SSL 25 -> SMTP = Simple Mail Transfer Protocol — used for e-mail routing between mail servers 587 -> SMTP = Simple Mail Transfer Protocol - used for client new message submission 194 -> IRC = Internet Relay Chat 113 -> ident—Authentication Service/Identification Protocol, used by IRC servers to identify users 1863 -> MSNP = Microsoft Notification Protocol, used by the .NET Messenger Service and a number of Instant Messaging clients 5190 -> ICQ and AOL Instant Messenger 52?? -> XMPP = eXtensible Messaging and Presence Protocol client connection 8000, 8001 -> commonly used for internet radio streams such as those using SHOUTcast (unofficial) 554 -> RTSP = Real Time Streaming Protocol 1755 -> Microsoft Media Services (MMS, ms-streaming) 389 -> LDAP = Lightweight Directory Access Protocol 636 -> LDAPS = Lightweight Directory Access Protocol over TLS/SSL 401 -> UPS Uninterruptible Power Supply 515 -> LPD/LPR = Line Printer Daemon 631 -> IPP = Internet Printing Protocol, CUPS = Common Unix Printing System 35 -> any private printer server protocol 3690 -> Subversion (SVN) version control system 9418 -> git, Git pack transfer service 53 -> DNS = Domain Name System 35 -> private printer server protocol 873 -> rsync file synchronisation protocol (Official USA only) 3306 -> MySQL database system (official) 5900 -> VNC 1194 -> OpenVPN ... http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers http://www.iana.org/assignments/port-numbers == Livello 5 - Application == Gira in user-space. protocolli applicativi: - privati - pubblici: - uso generico (ad es. DNS) - usi specifici (ad es. email, WWW, etc.) Quasi tutti i protocolli applicativi sono ASCII/plaintext-based, per inviare dati binari si deve usare una codifica come *base64* o *yEnc*. === DNS = Domain Name System === permette di mappare: indirizzi IP <-> *nomi logici DNS* -> spazio gerarchico organizzato in _domini multilivello_: host.subdomain.domain.top_level_domain *TLD = Top Level Domain*: - gTLD = generic TLD: - general: .biz, .com, .info, .name, .net, .org, .pro - sponsored: .aero, .asia, .cat, .coop, .edu, .gov, .int, .jobs, .mil, .mobi, .museum, .tel, .travel - ccTLD = country code TLD: - .us = United States - .uk = United Kingdom - .it = Italy - .ch = Switzerland - .de = Germany - .dk = Denmark - .cn = China - .tk = Tokelau - *pseudo-TLDs*: .bitnet, .csnet, .exit, .i2p, .local, .onion, .oz, .freenet, .uucp funzionamento: - l'OS fornisce un _DNS server locale_ - ogni applicazione interroga il server locale per il *resolving* - se il server locale ha un cached record con la risposta la restituisce, altrimenti interroga un server DNS di livello superiore (remoto) === Protocolli per posta elettronica === Consentono lo scambio di messaggi tra utenti. Ogni utente ha un indirizzo: username@domain struttura messaggio: To: dest1@domain, dest2@domain, ... \ From: scr@domain | Cc: | Bcc: | HEADER Subject: Foo | Sender: My name / <- EMPTY LINE Hello! \ ........ | BODY ... / . <- POINT funzionamento: utente1 -> MUA -(SMTP)-> MTA -(SMTP)-> ... -(SMTP)-> MTA -(POP3) -> MUA -> utente2 *MUA = Mail User Agent* (client di posta elettronica) *MTA = Mail Transport Agent* (server di posta elettronica) *SMTP = Simple Mail Transfer Protocol* (usato per uppare i messaggi da un MUA e per far comunicare gli MTA) *POP = Post Office Protocol* (usato per scaricare il messaggi da un MTA) Poichè il domain-name da solo non sarebbe sufficiente per trovare l'host che fa da server email, i DNS server sono configurati con dei _record speciali MX = Mail eXchange* che indicano quale host fa da server email in un dominio (ciò semplifica gli indirizzi email). ==== MIME ==== Il *MIME = Multipurpose Internet Mail Extensions* è un'estensione del protocollo classico per l'email che tra le altre cose consente l'invio di allegati binari. === Protocolli per il WWW = World Wide Web === Il WWW è un enorme *ipertesto* = un testo non lineare costituito da *pagine web + hyper-links*. *URL = Uniform Resource Locator* -> un sistema di indirizzamento per tutte le risorse accessibili sul web. E' costituito da 3 parti che specificano: 1. access mode = 1 protocollo (ad es. "http://") 2. l'host dove si trova la risorsa (ad es. "google.it") 3. l'identità della risorsa (ad es. "/path/resource.ext") === HTTP = HyperText Transfer Protocol === E' un protocollo plaintext, in cui i messaggi hanno la seguente sintassi: (client) request: METHOD /path/to/file.ext HTTP/1.1 <- REQUEST LINE User-Agent: Mozilla/5.0 (Windows;en-GB; rv:1.8.0.11) \ Accept: text/xml,text/html,text/plain,image/png | Accept-Language: en | HEADERS Accept-Encoding: gzip,deflate | Accept-Charset: ISO-8859-1,utf-8 / <- EMPTY LINE (CR+LF, "\r\n") ... \ ... | BODY (OPTIONAL) ... / Request methods più comuni: GET HEAD POST PUT DELETE (server) response: HTTP/1.1 STATUS <- STATUS LINE Date: Mon, 23 May 2005 22:38:34 GMT \ Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux) | Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT | HEADERS Content-Length: 438 | Content-Type: text/html; charset=UTF-8 / <- EMPTY LINE (CR+LF, "\r\n") ... \ ... | BODY (OPTIONAL) ... / Status codes più comuni: 200 OK -> The request succeeded, and the resulting resource (e.g. file or script output) is returned in the message body. 404 Not Found -> The requested resource doesn't exist. 301 Moved Permanently \ 302 Found | used for redirections, the client should request the url specified in the "Location" header instead 303 See Other (HTTP 1.1 only) / 400 Bad Request -> The request message is malformed. 401 Unauthorized -> il server richiede al client di autenticarsi per accedere alla risorsa 403 Forbidden -> accesso negato alla risorsa, anche con autenticazione 500 Server Error -> generic internal server error (retry later) 503 Service Unavailable -> the server is overloaded or down for maintenance. Generally, this is a temporary state. 100 Continue (HTTP 1.1 only) -> used for slow links/connections, the server confirms it has received the first part of the request and it is waiting the rest OSS.: solo il codice numerico è richiesto, la descrizione testuale è opzionale. = Fonti = Tanenbaum A. - Computer Networks (4e) (Prentice Hall) (2003) http://books.google.it/books?id=DYQoAQAAMAAJ Charles M. Kozierok - The TCP/IP Guide (No Starch Press) http://www.tcpipguide.com/buybook.htm?free