Prima di iniziare il video tutorial di oggi, voglio ringraziare tutti coloro che hanno contribuito alla popolarità del mio corso su YouTube. Quando l'ho iniziato circa 8 mesi fa, non mi aspettavo un tale successo: oggi le mie lezioni sono state viste da 312724 persone, ho 11208 iscritti. Non avrei mai immaginato che questo umile inizio avrebbe raggiunto tali altezze. Ma non perdiamo tempo e passiamo subito alla lezione di oggi. Oggi colmeremo le lacune che si sono verificate nelle ultime 7 videolezioni. Anche se oggi è solo il giorno 6, il giorno 3 è stato suddiviso in 3 lezioni video, quindi oggi guarderai effettivamente l'ottava lezione video.
Oggi tratteremo 3 argomenti importanti: DHCP, trasporto TCP e i numeri di porta più comuni. Abbiamo già parlato degli indirizzi IP e uno dei fattori più importanti nella configurazione dell'indirizzo IP è DHCP.
DHCP sta per Dynamic Host Configuration Protocol ed è un protocollo che aiuta a configurare dinamicamente gli indirizzi IP per gli host. Quindi abbiamo visto tutti questa finestra. Facendo clic sull'opzione "Ottieni automaticamente un indirizzo IP", il computer cerca un server DHCP configurato sulla stessa sottorete e invia diversi pacchetti e richieste per l'indirizzo IP. Il protocollo DHCP dispone di 6 messaggi, di cui 4 critici per l'assegnazione di un indirizzo IP.
Il primo messaggio è un messaggio DHCP DISCOVERY. Il messaggio di rilevamento DHCP è simile a un messaggio di benvenuto. Quando un nuovo dispositivo si unisce alla rete, chiede se è presente un server DHCP sulla rete.
Quella che vedi nella diapositiva sembra una richiesta broadcast in cui il dispositivo contatta tutti i dispositivi della rete alla ricerca di un server DHCP. Come ho detto, questa è una richiesta di trasmissione, quindi tutti i dispositivi sulla rete possono ascoltarla.
Se sulla rete è presente un server DHCP, invia un pacchetto: un'offerta DHCP OFFERTA. Proposta significa che il server DHCP, in risposta a una richiesta di rilevamento, invia una configurazione al client chiedendogli di accettare un indirizzo IP specifico.
Il server DHCP riserva un indirizzo IP, in questo caso 192.168.1.2, non lo fornisce, ma riserva questo indirizzo per il dispositivo. Allo stesso tempo il pacchetto di offerte contiene un proprio indirizzo IP del server DHCP.
Se su questa rete è presente più di un server DHCP, anche un altro server DHCP, dopo aver ricevuto la richiesta di trasmissione del client, gli offrirà il proprio indirizzo IP, ad esempio 192.168.1.50. Non è comune avere due diversi server DHCP configurati sulla stessa rete, ma a volte succede. Pertanto, quando un'offerta DHCP viene inviata a un client, riceve 2 offerte DHCP e deve ora decidere quale offerta DHCP desidera accettare.
Supponiamo che il cliente accetti la prima richiesta. Ciò significa che il client invia una richiesta DHCP REQUEST che dice letteralmente "Accetto l'indirizzo IP 192.168.1.2 offerto dal server DHCP 192.168.1.1."
Dopo aver ricevuto la richiesta, il server DHCP 192.168.1.1 risponde "okay, lo ammetto", cioè riconosce la richiesta e invia questo ACK DHCP al client. Ricordiamo però che un altro server DHCP ha riservato al client un indirizzo IP pari a 1.50. Una volta ricevuta la richiesta di trasmissione di un client, verrà a conoscenza dell'errore e reinserirà l'indirizzo IP nel pool in modo da poterlo assegnare a un altro client se riceve un'altra richiesta.
Questi sono i 4 messaggi critici che DHCP scambia durante l'assegnazione degli indirizzi IP. Successivamente, DHCP ha altri 2 messaggi di informazione. Un messaggio informativo viene emesso dal client se richiede più informazioni di quelle ricevute nella clausola DHCP OFFER nel secondo passaggio. Se il server non ha fornito informazioni sufficienti nell'offerta DHCP o se il client necessita di più informazioni di quelle contenute nel pacchetto offerta, richiede informazioni DHCP aggiuntive. C'è un altro messaggio che il client invia al server: questo è il DHCP RELEASE. Ti informa che il client desidera rilasciare il suo indirizzo IP esistente.
Tuttavia, ciò che accade più spesso è che l'utente si disconnette dalla rete prima che il client abbia il tempo di inviare un DHCP RELEASE al server. Questo accade quando spegni il computer, cosa che facciamo. In questo caso, il client di rete, o computer, semplicemente non ha il tempo di informare il server di rilasciare l'indirizzo utilizzato, quindi DHCP RELEASE non è un passaggio richiesto. I passaggi necessari per ottenere un indirizzo IP sono: rilevamento DHCP, offerta DHCP, richiesta DHCP e handshake DHCP.
In una delle prossime lezioni ti racconterò come configuriamo un server DHCP durante la creazione di un pool DNCP. Per pooling intendiamo che dici al server di assegnare indirizzi IP nell'intervallo da 192.168.1.1 a 192.168.1.254. Pertanto, il server DHCP creerà un pool, inserirà al suo interno 254 indirizzi IP e sarà in grado di assegnare indirizzi ai client sulla rete solo da questo pool. Quindi questa è qualcosa come un'impostazione amministrativa che l'utente può eseguire.
Ora diamo un'occhiata alla trasmissione TCP. Non so se conoscete il "telefono" raffigurato nella foto, ma da bambini usavamo questi barattoli di latta collegati da un filo per parlarci.
Sfortunatamente, la generazione di oggi non può permettersi questo “lusso”. Voglio dire, oggi i bambini stanno davanti alla TV dall'età di un anno, giocano alla PSP e forse questo è discutibile, ma penso che abbiamo avuto un'infanzia migliore, in realtà uscivamo e giocavamo e i bambini di oggi non possono essere allontanati dal divano .
Mio figlio ha solo un anno e già vedo che è dipendente dall'iPad, voglio dire è ancora molto piccolo ma penso che i bambini di oggi nascano già sapendo maneggiare i gadget elettronici. Quindi, volevo dire che da bambini, quando giocavamo, facevamo dei buchi nei barattoli di latta, e quando li legavamo con uno spago e dicevamo qualcosa in un barattolo, poi dall'altra parte la persona poteva sentire cosa veniva detto a lui, semplicemente avvicinando la lattina all'orecchio. Quindi è molto simile a una connessione di rete.
Oggi anche i trasferimenti TCP devono avere una connessione che deve essere stabilita prima che inizi il trasferimento dei dati vero e proprio. Come discusso nelle lezioni precedenti, TCP è una trasmissione orientata alla connessione mentre UDP è una trasmissione orientata alla connessione. Potresti dire che UDP è dove lancio la palla e sta a te vedere se riesci a prenderla. Che tu sia pronto o meno a farlo non è un mio problema, lo lascerò e basta.
TCP è più come parlare con un ragazzo e avvertirlo in anticipo che stai per lanciare una palla, così formi un legame, e poi lanci la palla in modo che il tuo partner sia più propenso a prenderla. Quindi TCP crea effettivamente la connessione e quindi inizia a eseguire la trasmissione vera e propria.
Diamo un'occhiata a come crea tale connessione. Questo protocollo utilizza un handshake a 3 vie per creare una connessione. Questo non è un termine molto tecnico, ma è stato a lungo utilizzato per descrivere una connessione TCP. Il dispositivo mittente avvia un handshake a 3 vie, con il client che invia un pacchetto con un flag SYN al server.
Diciamo che la ragazza in primo piano, di cui possiamo vedere il volto, è il dispositivo A, e la ragazza sullo sfondo, il cui volto non è visibile, è il dispositivo B. La ragazza A invia un pacchetto SYN alla ragazza B e lei dice: “fantastico, chi- allora vuole comunicare con me. Quindi devo rispondere che sono pronto a comunicare!” Come farlo? Si potrebbe semplicemente inviare indietro un altro pacchetto SYN e quindi un ACK che indichi la ricezione del pacchetto SYN originale. Ma invece di inviare ACK separatamente, il server forma un pacchetto comune contenente SYN e ACK e lo trasmette sulla rete.
Quindi a questo punto il dispositivo A ha inviato un pacchetto SYN e ha ricevuto in cambio un pacchetto SYN/ACK. Ora il dispositivo A deve inviare al dispositivo B un pacchetto ACK, cioè confermare di aver ricevuto il consenso dal dispositivo B per stabilire la comunicazione. Pertanto, entrambi i dispositivi hanno ricevuto pacchetti SYN e ACK e ora possiamo dire che la connessione è stata stabilita, ovvero è stato completato un handshake in 3 fasi utilizzando il protocollo TCP.
Successivamente esamineremo la tecnologia TCP Windowing. In poche parole, è un metodo utilizzato in TCP/IP per negoziare le capacità del mittente e del destinatario.
Diciamo che in Windows stiamo cercando di trasferire un file di grandi dimensioni, diciamo 2 GB, da un'unità all'altra. All'inizio del trasferimento, il sistema ci informerà che il trasferimento del file richiederà circa 1 anno. Ma pochi secondi dopo il sistema si correggerà e dirà: “oh, aspetta un attimo, penso che ci vorranno circa 6 mesi, non un anno”. Passerà ancora un po’ di tempo e Windows dirà: “Penso che potrei riuscire a trasferire il file tra 1 mese”. Seguirà il messaggio “1 giorno”, “6 ore”, “3 ore”, “1 ora”, “20 minuti”, “10 minuti”, “3 minuti”. Infatti, l'intero processo di trasferimento dei file richiederà solo 3 minuti. Come è successo? Inizialmente, quando il tuo dispositivo tenta di comunicare con un altro dispositivo, invia un pacchetto e attende conferma. Se il dispositivo attende a lungo la conferma, pensa: “se devo trasferire 2 GB di dati a questa velocità, ci vorranno circa 2 anni”. Dopo un po' di tempo, il tuo dispositivo riceve un ACK e pensa: "ok, ho inviato un pacchetto e ho ricevuto un ACK, quindi il destinatario può ricevere 1 pacchetto. Adesso proverò a mandargli 10 pacchetti invece di uno”. Il mittente invia 10 pacchetti e dopo un po' riceve una conferma ACK dal dispositivo ricevente, il che significa che il destinatario sta aspettando il successivo, l'undicesimo pacchetto. Il mittente pensa: “ottimo, visto che il destinatario ha gestito 11 pacchetti contemporaneamente, ora proverò a inviargli 10 pacchetti invece di dieci”. Invia 100 pacchetti e il destinatario risponde che li ha ricevuti e che ora sta aspettando 100 pacchetti. Pertanto, nel tempo, il numero di pacchetti trasmessi aumenta.
Questo è il motivo per cui si nota una rapida diminuzione del tempo di copia dei file rispetto a quanto dichiarato in origine: ciò è dovuto alla maggiore capacità di trasferire grandi quantità di dati. Tuttavia, arriva un punto in cui ulteriori aumenti del volume di trasmissione diventano impossibili. Supponiamo che tu abbia inviato 10000 pacchetti, ma il buffer del dispositivo del destinatario ne può accettare solo 9000. In questo caso, il ricevitore invia un ACK con il messaggio: "Ho ricevuto 9000 pacchetti e ora sono pronto a riceverne 9001". Da ciò il mittente deduce che il buffer del dispositivo ricevente ha una capacità di soli 9000 pacchetti, il che significa che d'ora in poi non invierò più di 9000 pacchetti alla volta. In questo caso, il mittente calcola rapidamente il tempo necessario per trasferire la quantità rimanente di dati in porzioni di 9000 pacchetti e fornisce 3 minuti. Questi tre minuti rappresentano il tempo di trasmissione effettivo. Questo è ciò che fa TCP Windowing.
Questo è uno di quei meccanismi di limitazione del traffico in cui il dispositivo di invio alla fine capisce qual è l'effettiva capacità della rete. Forse ti starai chiedendo perché non riescono a concordare in anticipo quale sia la capacità del dispositivo ricevente? Il fatto è che questo è tecnicamente impossibile perché sulla rete sono presenti diversi tipi di dispositivi. Diciamo che hai un iPad e ha una velocità di trasferimento/ricezione dati diversa rispetto a un iPhone, potresti avere diversi tipi di telefoni o forse hai un computer molto vecchio. Pertanto, ognuno ha una larghezza di banda di rete diversa.
Per questo motivo è stata sviluppata la tecnologia TCP Windowing, quando la trasmissione dei dati inizia a bassa velocità o con la trasmissione di un numero minimo di pacchetti, aumentando gradualmente la “finestra” di traffico. Invii un pacchetto, 5 pacchetti, 10 pacchetti, 1000 pacchetti, 10000 pacchetti e apri lentamente quella finestra sempre di più fino a quando "l'apertura" raggiunge il massimo volume possibile di traffico inviato in un determinato periodo di tempo. Pertanto, il concetto di Windowing è parte del funzionamento del protocollo TCP.
Successivamente esamineremo i numeri di porta più comuni. La situazione classica è quando hai 1 server principale, magari un data center. Include un file server, un server web, un server di posta e un server DHCP. Ora, se uno dei computer client contatta il data center, che si trova al centro dell'immagine, inizierà a inviare il traffico del file server ai dispositivi client. Questo traffico è mostrato in rosso e verrà trasmesso su una porta specifica per un'applicazione specifica da un server specifico.
Come faceva il server a sapere dove doveva andare un determinato traffico? Lo apprende dal numero della porta di destinazione. Se guardi il riquadro, vedrai che in ogni trasferimento di dati è menzionato il numero della porta di destinazione e il numero della porta di origine. Puoi vedere che il traffico blu e rosso, e il traffico blu è il traffico del server web, vanno entrambi allo stesso server fisico, su cui sono installati server diversi. Se si tratta di un data center, utilizza server virtuali. Allora come facevano a sapere che il traffico rosso sarebbe dovuto tornare al laptop sinistro con quell'indirizzo IP? Lo sanno grazie ai numeri di porta. Se fai riferimento all'articolo di Wikipedia "Elenco delle porte TCP e UDP", vedrai che elenca tutti i numeri di porta standard.
Se scorri verso il basso questa pagina puoi vedere quanto è grande questo elenco. Contiene circa 61 numeri. I numeri di porta da 000 a 1 sono conosciuti come i numeri di porta più comuni. Ad esempio, la porta 1024/TCP serve per inviare comandi ftp, la porta 21 è per ssh, la porta 22 è per Telnet, cioè per l'invio di messaggi non crittografati. La molto popolare porta 23 trasporta dati su HTTP, mentre la porta 80 trasporta dati crittografati su HTTPS, che è simile alla versione sicura di HTTP.
Alcune porte sono dedicate sia a TCP che a UDP e alcune eseguono attività diverse a seconda che la connessione sia TCP o UDP. Quindi, ufficialmente la porta TCP 80 viene utilizzata per HTTP e ufficiosamente la porta UDP 80 viene utilizzata per HTTP, ma con un protocollo HTTP diverso: QUIC.
Pertanto, i numeri di porta in TCP non hanno sempre lo stesso scopo di UDP. Non è necessario imparare a memoria questo elenco, è impossibile da ricordare, ma è necessario conoscere alcuni numeri di porta popolari e più comuni. Come ho detto, alcune di queste porte hanno uno scopo ufficiale, descritto negli standard, mentre altre hanno uno scopo non ufficiale, come nel caso di Chromium.
Pertanto, questa tabella elenca tutti i numeri di porta comuni e questi numeri vengono utilizzati per inviare e ricevere traffico quando si utilizzano applicazioni specifiche.
Ora diamo un'occhiata a come i dati si muovono attraverso la rete in base alle poche informazioni che conosciamo. Diciamo che il computer 10.1.1.10 vuole contattare questo computer, o questo server, che ha l'indirizzo 30.1.1.10. Sotto l'indirizzo IP di ciascun dispositivo c'è il suo indirizzo MAC. Faccio l'esempio di un indirizzo MAC con solo gli ultimi 4 caratteri, ma in pratica è un numero esadecimale a 48 bit con 12 caratteri. Poiché ciascuno di questi numeri è composto da 4 bit, 12 cifre esadecimali rappresentano un numero a 48 bit.
Come sappiamo, se questo dispositivo vuole contattare questo server, bisogna prima fare il primo passo del 3-way handshake, cioè inviare un pacchetto SYN. Quando viene effettuata questa richiesta, il computer 10.1.1.10 specificherà il numero di porta di origine, che Windows crea dinamicamente. Windows seleziona casualmente un numero di porta compreso tra 1 e 65,000. Ma poiché i numeri iniziali compresi tra 1 e 1024 sono ampiamente conosciuti, in questo caso il sistema considererà i numeri maggiori di 25000 e creerà una porta di origine casuale, ad esempio il numero 25113.
Successivamente, il sistema aggiungerà una porta di destinazione al pacchetto, in questo caso è la porta 21, perché l'applicazione che sta tentando di connettersi a questo server FTP sa che deve inviare traffico FTP.
Successivamente, il nostro computer dice: "Ok, il mio indirizzo IP è 10.1.1.10 e devo contattare l'indirizzo IP 30.1.1.10". Entrambi questi indirizzi sono inclusi anche nel pacchetto per formare una richiesta SYN e questo pacchetto non cambierà fino alla fine della connessione.
Voglio che tu capisca da questo video come i dati si muovono attraverso la rete. Quando il nostro computer che invia la richiesta vede l'indirizzo IP di origine e l'indirizzo IP di destinazione, capisce che l'indirizzo di destinazione non si trova su quella rete locale. Ho dimenticato di dire che questi sono tutti indirizzi IP /24. Quindi se guardi gli indirizzi IP /24, ti renderai conto che i computer 10.1.1.10 e 30.1.1.10 non sono sulla stessa rete. Pertanto, il computer che invia la richiesta capisce che per lasciare questa rete deve contattare il gateway 10.1.1.1, configurato su una delle interfacce del router. Sa che dovrebbe andare a 10.1.1.1 e conosce il suo indirizzo MAC 1111, ma non conosce l'indirizzo MAC del gateway 10.1.1.1. Cosa sta facendo? Invia una richiesta ARP broadcast che riceveranno tutti i dispositivi sulla rete, ma solo il router con indirizzo IP 10.1.1.1 risponderà.
Il router risponderà con il suo indirizzo MAC AAAA e anche gli indirizzi MAC di origine e di destinazione verranno inseriti in questo frame. Una volta che il frame è pronto, prima di lasciare la rete verrà eseguito un controllo dell'integrità dei dati CRC, che è un algoritmo per trovare un checksum per rilevare errori.
Cyclic Redundancy CRC significa che l'intero frame, dal SYN all'ultimo indirizzo MAC, viene eseguito attraverso un algoritmo di hashing, ad esempio MD5, risultando in un valore hash. Il valore hash, o checksum MD5, viene quindi posizionato all'inizio del frame.
L'ho etichettato FCS/CRC perché FCS è una sequenza di controllo dei frame, un valore CRC a quattro byte. Alcune persone usano la designazione FCS e altri usano la designazione CRC, quindi ho semplicemente incluso entrambe le designazioni. Ma fondamentalmente è solo un valore hash. È necessario per assicurarsi che tutti i dati ricevuti sulla rete non contengano errori. Pertanto, quando questo frame raggiunge il router, la prima cosa che farà il router sarà calcolare il checksum stesso e confrontarlo con il valore FCS o CRC contenuto nel frame ricevuto. In questo modo potrà verificare che i dati ricevuti in rete non contengano errori, dopodiché rimuoverà il checksum dal frame.
Successivamente, il router esaminerà l'indirizzo MAC e dirà: "Okay, indirizzo MAC AAAA significa che il frame è indirizzato a me" ed eliminerà la parte del frame contenente gli indirizzi MAC.
Guardando l'indirizzo IP di destinazione 30.1.1.10, capirà che questo pacchetto non è indirizzato a lui e deve passare oltre attraverso il router.
Ora il router “pensa” di dover vedere dove si trova la rete con l'indirizzo 30.1.1.10. Non abbiamo ancora trattato il concetto completo di routing, ma sappiamo che i router dispongono di una tabella di routing. Questa tabella contiene una voce per la rete con indirizzo 30.1.1.0. Come ricordi, questo non è l'indirizzo IP dell'host, ma l'identificatore di rete. Il router “penserà” di poter raggiungere l'indirizzo 30.1.1.0/24 passando attraverso il router 20.1.1.2.
Potresti chiedere, come fa a saperlo? Tieni presente che lo saprà dai protocolli di routing o dalle tue impostazioni se tu come amministratore hai configurato un percorso statico. Ma in ogni caso, la tabella di routing di questo router contiene la voce corretta, quindi sa che dovrebbe inviare questo pacchetto a 20.1.1.2. Supponendo che il router conosca già l'indirizzo MAC di destinazione, continueremo semplicemente a inoltrare il pacchetto. Se non conosce questo indirizzo, avvierà nuovamente ARP, riceverà l'indirizzo MAC 20.1.1.2 del router e il processo di invio del frame continuerà nuovamente.
Quindi presumiamo che conosca già l'indirizzo MAC, quindi avremo l'indirizzo MAC di origine BBB e l'indirizzo MAC di destinazione CCC. Il router calcola nuovamente l'FCS/CRC e lo posiziona all'inizio del frame.
Quindi invia questo frame sulla rete, il frame raggiunge il router 20.1.12, controlla il checksum, si assicura che i dati non siano danneggiati ed elimina FCS/CRC. Quindi "tronca" gli indirizzi MAC, guarda la destinazione e vede che è 30.1.1.10. Sa che questo indirizzo è collegato alla sua interfaccia. Lo stesso processo di formazione del frame viene ripetuto, il router aggiunge i valori dell'indirizzo MAC di origine e di destinazione, esegue l'hashing, allega l'hash al frame e lo invia attraverso la rete.
Il nostro server, dopo aver finalmente ricevuto la richiesta SYN ad esso indirizzata, controlla il checksum dell'hash e, se il pacchetto non contiene errori, cancella l'hash. Quindi rimuove gli indirizzi MAC, guarda l'indirizzo IP e si rende conto che questo pacchetto è indirizzato a lui.
Successivamente, tronca gli indirizzi IP relativi al terzo livello del modello OSI e esamina i numeri di porta.
Vede la porta 21, che significa traffico FTP, vede il SYN e quindi capisce che qualcuno sta cercando di comunicare con lui.
Ora, in base a ciò che abbiamo appreso sull'handshake, il server 30.1.1.10 creerà un pacchetto SYN/ACK e lo invierà al computer 10.1.1.10. Dopo aver ricevuto questo pacchetto, il dispositivo 10.1.1.10 creerà un ACK, lo passerà attraverso la rete allo stesso modo di un pacchetto SYN e, dopo che il server avrà ricevuto l'ACK, verrà stabilita la connessione.
Una cosa che dovresti sapere è che tutto questo avviene in meno di un secondo. Questo è un processo molto, molto veloce, che ho cercato di rallentare in modo che tutto ti sia chiaro.
Spero che troverai utile ciò che hai imparato in questo tutorial. Se avete domande scrivetemi a [email protected] o lascia domande sotto questo video.
A partire dalla prossima lezione selezionerò le 3 domande più interessanti da YouTube, che esaminerò alla fine di ogni video. D'ora in poi avrò una sezione "Domande principali", quindi pubblicherò una domanda insieme al tuo nome e risponderò in diretta. Penso che questo sarà vantaggioso.
Grazie per stare con noi. Ti piacciono i nostri articoli? Vuoi vedere contenuti più interessanti? Sostienici effettuando un ordine o raccomandando agli amici, Sconto del 30% per gli utenti Habr su un analogo unico di server entry-level, che è stato inventato da noi per te: (disponibile con RAID1 e RAID10, fino a 24 core e fino a 40 GB DDR4).
VPS (KVM) E5-2650 v4 (6 core) 10 GB DDR4 240 GB SSD 1 Gbps gratuito fino all'estate quando paghi per un periodo di sei mesi, puoi ordinare .
Dell R730xd 2 volte più economico? Solo qui In Olanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - da $99! Leggi
Fonte: habr.com