Abans de començar el vídeo tutorial d'avui, vull donar les gràcies a tots els que han contribuït a la popularitat del meu curs a YouTube. Quan el vaig començar fa uns 8 mesos, no esperava tal èxit: avui les meves lliçons han estat vistes per 312724 persones, tinc 11208 subscriptors. Mai vaig somiar que aquest humil començament arribaria a tals cotes. Però no perdem el temps i anem directament a la lliçó d'avui. Avui omplirem els buits que es van produir en les últimes 7 lliçons de vídeo. Tot i que avui és només el dia 6, el dia 3 es va dividir en 3 lliçons de vídeo, així que avui veureu realment la vuitena lliçó de vídeo.
Avui tractarem 3 temes importants: DHCP, transport TCP i els números de port més comuns. Ja hem parlat de les adreces IP i un dels factors més importants en la configuració de les adreces IP és DHCP.
DHCP significa Dynamic Host Configuration Protocol i és un protocol que ajuda a configurar dinàmicament les adreces IP dels amfitrions. Així que tots hem vist aquesta finestra. Quan feu clic a l'opció "Obtenir una adreça IP automàticament", l'ordinador cerca un servidor DHCP que estigui configurat a la mateixa subxarxa i envia diversos paquets i peticions de l'adreça IP. El protocol DHCP té 6 missatges, dels quals 4 són crítics per assignar una adreça IP.
El primer missatge és un missatge DHCP DISCOVERY. El missatge de descobriment de DHCP és similar a un missatge de salutació. Quan un dispositiu nou s'uneix a la xarxa, pregunta si hi ha un servidor DHCP a la xarxa.
El que veieu a la diapositiva sembla una sol·licitud de difusió on el dispositiu contacta amb tots els dispositius de la xarxa buscant un servidor DHCP. Com he dit, aquesta és una sol·licitud de difusió, de manera que tots els dispositius de la xarxa la poden escoltar.
Si hi ha un servidor DHCP a la xarxa, envia un paquet: una oferta d'OFERTA DHCP. La proposta significa que el servidor DHCP, en resposta a una sol·licitud de descobriment, envia una configuració al client, demanant-li que accepti una adreça IP específica.
El servidor DHCP reserva una adreça IP, en aquest cas 192.168.1.2, no la proporciona, sinó que reserva aquesta adreça per al dispositiu. Al mateix temps, el paquet d'oferta conté la seva pròpia adreça IP del servidor DHCP.
Si hi ha més d'un servidor DHCP en aquesta xarxa, un altre servidor DHCP, en rebre la sol·licitud de difusió del client, també li oferirà la seva adreça IP, per exemple, 192.168.1.50. No és habitual tenir dos servidors DHCP diferents configurats a la mateixa xarxa, però de vegades passa. Així, quan s'envia una oferta DHCP a un client, aquest rep 2 ofertes DHCP i ara ha de decidir quina oferta DHCP vol acceptar.
Suposem que el client accepta la primera sol·licitud. Això significa que el client envia una sol·licitud DHCP REQUEST que literalment diu "Accepto l'adreça IP 192.168.1.2 que ofereix el servidor DHCP 192.168.1.1".
En rebre la sol·licitud, el servidor DHCP 192.168.1.1 respon "d'acord, ho admeto", és a dir, reconeix la sol·licitud i envia aquest ACK DHCP al client. Però recordem que un altre servidor DHCP ha reservat una adreça IP de 1.50 per al client. Un cop rep la sol·licitud d'emissió d'un client, sabrà de l'error i tornarà a posar aquesta adreça IP al grup perquè pugui assignar-la a un altre client si rep una altra sol·licitud.
Aquests són els 4 missatges crítics que intercanvia DHCP en assignar adreces IP. A continuació, DHCP té 2 missatges d'informació més. El client emet un missatge d'informació si requereix més informació de la que va rebre a la clàusula DHCP OFFER en el segon pas. Si el servidor no ha proporcionat prou informació a l'oferta de DHCP, o si el client necessita més informació que la que hi havia al paquet d'oferta, sol·licita informació addicional de DHCP. Hi ha un missatge més que el client envia al servidor: aquest és el DHCP RELEASE. Us informa que el client vol alliberar la seva adreça IP existent.
No obstant això, el que passa més sovint és que l'usuari es desconnecta de la xarxa abans que el client tingui temps d'enviar un DHCP RELEASE al servidor. Això passa quan apagueu l'ordinador, cosa que fem nosaltres. En aquest cas, el client de xarxa, o l'ordinador, simplement no té temps d'informar el servidor perquè alliberi l'adreça utilitzada, de manera que DHCP RELEASE no és un pas obligatori. Els passos necessaris per obtenir una adreça IP són: descobriment de DHCP, oferta de DHCP, sol·licitud de DHCP i encaix DHCP.
En una de les properes lliçons us explicaré com configurem un servidor DHCP quan creem un grup DNCP. Amb l'agrupació volem dir que dieu al servidor que assigni adreces IP en l'interval 192.168.1.1 a 192.168.1.254. Així, el servidor DHCP crearà un grup, hi col·locarà 254 adreces IP i només podrà assignar adreces als clients de la xarxa des d'aquest grup. Per tant, això és una cosa així com una configuració administrativa que l'usuari pot fer.
Vegem ara la transmissió TCP. No sé si coneixeu el "telèfon" que es mostra a la imatge, però quan érem nens solíem utilitzar aquestes llaunes connectades per una corda per parlar entre ells.
Malauradament, la generació actual no es pot permetre aquest "luxe". Vull dir que avui els nens estan davant de la televisió des d'un any, juguen a PSP i potser això és discutible, però crec que vam tenir la millor infància, de fet vam sortir a jugar i els nens d'avui no es poden allunyar del sofà. .
El meu fill només té un any i ja veig que és addicte a l'iPad, vull dir que encara és molt petit però crec que els nens d'avui ja neixen sabent manejar els aparells electrònics. Per tant, volia dir que de petits, quan jugàvem, fèiem forats a les llaunes, i quan les lligam amb un cordó i dèiem alguna cosa en una llauna, a l'altre extrem la persona sentia el que es deia. a ell, simplement posant-li la llauna a l'orella. Per tant, és molt semblant a una connexió de xarxa.
Avui dia, fins i tot les transferències TCP han de tenir una connexió que s'ha d'establir abans que comenci la transferència de dades real. Com hem comentat a les lliçons anteriors, TCP és una transmissió orientada a connexió mentre que UDP és una transmissió orientada a connexió. Es podria dir que l'UDP és on llenço la pilota i depèn de tu a veure si pots agafar-la. Tant si estàs preparat per fer-ho com si no és el meu problema, només el deixaré.
TCP s'assembla més a parlar amb un noi i avisar-lo per endavant que llançaràs una pilota, de manera que fas un vincle, i després llances la pilota perquè la teva parella tingui més probabilitats d'estar a punt per agafar-la. Així que TCP realment construeix la connexió i després comença a fer la transmissió real.
Vegem com crea aquesta connexió. Aquest protocol utilitza una encaixada de mans de 3 vies per crear una connexió. Aquest no és un terme molt tècnic, però fa temps que s'ha utilitzat per descriure una connexió TCP. El dispositiu d'enviament inicia una encaixada de mans de 3 vies, amb el client enviant un paquet amb un indicador SYN al servidor.
Suposem que la noia del primer pla, la cara de la qual podem veure, és l'aparell A, i la noia del fons, la cara de la qual no és visible, és l'aparell B. La noia A envia un paquet SYN a la noia B, i ella diu: “Genial, qui- llavors vol comunicar-se amb mi. Per tant, he de respondre que estic preparat per comunicar-me!” Com fer-ho? Es podria simplement enviar un altre paquet SYN i després un ACK que indica la recepció del paquet SYN original. Però en lloc d'enviar ACK per separat, el servidor forma un paquet comú que conté el SYN i l'ACK i el transmet per la xarxa.
Per tant, en aquest punt, el dispositiu A ha enviat un paquet SYN i ha rebut un paquet SYN/ACK. Ara el dispositiu A ha d'enviar al dispositiu B un paquet ACK, és a dir, confirmar que ha rebut el consentiment del dispositiu B per establir la comunicació. Així, ambdós dispositius van rebre paquets SYN i ACK, i ara podem dir que la connexió s'ha establert, és a dir, s'ha completat una encaixada de mans de 3 etapes mitjançant el protocol TCP.
A continuació, veurem la tecnologia de finestres TCP. En poques paraules, és un mètode utilitzat en TCP/IP per negociar les capacitats de l'emissor i el receptor.
Diguem que a Windows estem intentant transferir un fitxer gran, per exemple 2 GB de mida, d'una unitat a una altra. Al principi de la transferència, el sistema ens informarà que la transferència del fitxer trigarà aproximadament 1 any. Però uns segons després, el sistema es corregirà i dirà: "Oh, espera un minut, crec que trigarà uns 6 mesos, no un any". Passarà una mica més de temps i Windows dirà: "Crec que podria transferir el fitxer en 1 mes". A continuació apareixerà el missatge "1 dia", "6 hores", "3 hores", "1 hora", "20 minuts", "10 minuts", "3 minuts". De fet, tot el procés de transferència de fitxers només trigarà 3 minuts. Com va passar això? Inicialment, quan el vostre dispositiu intenta comunicar-se amb un altre dispositiu, envia un paquet i espera la confirmació. Si el dispositiu espera molt de temps per a la confirmació, pensa: "si he de transferir 2 GB de dades a aquesta velocitat, trigarà uns 2 anys". Després d'un temps, el vostre dispositiu rep un ACK i pensa: "d'acord, he enviat un paquet i he rebut un ACK, per tant, el destinatari pot rebre 1 paquet. Ara intentaré enviar-li 10 paquets en lloc d'un". El remitent envia 10 paquets i al cap d'un temps rep una confirmació ACK del dispositiu receptor, la qual cosa significa que el destinatari està esperant el següent, 11è paquet. El remitent pensa: "molt bé, com que el destinatari va gestionar 10 paquets alhora, ara intentaré enviar-li 100 paquets en lloc de deu". Envia 100 paquets i el destinatari respon que els ha rebut i que ara està esperant 101 paquets. Així, amb el temps, el nombre de paquets transmesos augmenta.
És per això que veieu una disminució ràpida del temps de còpia de fitxers en comparació amb el que es va indicar originalment; això es deu a l'augment de la capacitat de transferir grans quantitats de dades. No obstant això, arriba un moment en què els augments addicionals del volum de transmissió esdevenen impossibles. Suposem que heu enviat 10000 paquets, però la memòria intermèdia del dispositiu del receptor només en pot acceptar 9000. En aquest cas, el receptor envia un ACK amb el missatge: "He rebut 9000 paquets i ara estic preparat per rebre'n 9001". A partir d'això, el remitent conclou que la memòria intermèdia del dispositiu receptor té una capacitat de només 9000, la qual cosa significa que a partir d'ara no enviaré més de 9000 paquets alhora. En aquest cas, el remitent calcula ràpidament el temps que trigarà a transferir la quantitat de dades restants en porcions de 9000 paquets i li dóna 3 minuts. Aquests tres minuts són el temps real de transmissió. Això és el que fa TCP Windowing.
Aquest és un d'aquells mecanismes d'acceleració del trànsit on el dispositiu que envia finalment entén quina és la capacitat real de la xarxa. Potser us preguntareu per què no es poden posar d'acord per endavant sobre quina és la capacitat del dispositiu receptor? El cas és que això és tècnicament impossible perquè hi ha diferents tipus de dispositius a la xarxa. Suposem que teniu un iPad i té una velocitat de transferència/receptor de dades diferent a la d'un iPhone, és possible que tingueu diferents tipus de telèfons o potser teniu un ordinador molt antic. Per tant, tothom té una amplada de banda diferent.
És per això que es va desenvolupar la tecnologia TCP Windowing, quan la transmissió de dades comença a baixa velocitat o amb la transmissió d'un nombre mínim de paquets, augmentant progressivament la “finestra” de trànsit. Envieu un paquet, 5 paquets, 10 paquets, 1000 paquets, 10000 paquets i s'obre lentament aquesta finestra cada cop més fins que l'"obertura" assoleix el màxim volum possible de trànsit enviat en un període de temps concret. Així, el concepte de Windowing forma part del funcionament del protocol TCP.
A continuació, veurem els números de port més comuns. La situació clàssica és quan teniu 1 servidor principal, potser un centre de dades. Inclou un servidor de fitxers, un servidor web, un servidor de correu i un servidor DHCP. Ara, si un dels ordinadors client contacta amb el centre de dades, que es troba al centre de la imatge, començarà a enviar trànsit del servidor de fitxers als dispositius client. Aquest trànsit es mostra en vermell i es transmetrà en un port específic per a una aplicació específica des d'un servidor específic.
Com va saber el servidor on hauria d'anar determinat trànsit? Ho aprèn amb el número de port de destinació. Si mireu el marc, veureu que a cada transferència de dades hi ha una menció del número de port de destinació i el número de port d'origen. Podeu veure que el trànsit blau i vermell, i el trànsit blau és el trànsit del servidor web, tots dos van al mateix servidor físic, que té diferents servidors instal·lats. Si es tracta d'un centre de dades, fa servir servidors virtuals. Llavors, com van saber que el trànsit vermell havia de tornar a aquell portàtil esquerre amb aquesta adreça IP? Ho saben gràcies als números de port. Si consulteu l'article de la Viquipèdia "Llista de ports TCP i UDP", veureu que inclou tots els números de port estàndard.
Si us desplaceu cap avall d'aquesta pàgina podreu veure la gran quantitat d'aquesta llista. Conté aproximadament 61 números. Els números de port de l'000 al 1 es coneixen com els números de port més comuns. Per exemple, el port 1024/TCP és per enviar ordres ftp, el port 21 és per a ssh, el port 22 és per a Telnet, és a dir, per enviar missatges sense xifrar. El molt popular port 23 transporta dades a través d'HTTP, mentre que el port 80 transporta dades xifrades a través d'HTTPS, que és similar a la versió segura d'HTTP.
Alguns ports estan dedicats tant a TCP com a UDP, i alguns realitzen tasques diferents segons si la connexió és TCP o UDP. Per tant, oficialment s'utilitza el port TCP 80 per a HTTP i no oficialment el port UDP 80 s'utilitza per a HTTP, però amb un protocol HTTP diferent: QUIC.
Per tant, els números de port a TCP no sempre tenen la intenció de fer el mateix que a UDP. No cal que aprenguis aquesta llista de memòria, és impossible recordar-ho, però cal conèixer alguns números de port populars i més comuns. Com he dit, alguns d'aquests ports tenen una finalitat oficial, que es descriu als estàndards, i alguns tenen una finalitat no oficial, com és el cas de Chromium.
Per tant, aquesta taula enumera tots els números de ports comuns, i aquests números s'utilitzen per enviar i rebre trànsit quan s'utilitzen aplicacions específiques.
Vegem ara com es mouen les dades per la xarxa en funció de la poca informació que coneixem. Suposem que l'ordinador 10.1.1.10 vol contactar amb aquest ordinador, o amb aquest servidor, que té l'adreça 30.1.1.10. A sota de l'adreça IP de cada dispositiu hi ha la seva adreça MAC. Dono l'exemple d'una adreça MAC amb només els últims 4 caràcters, però a la pràctica és un nombre hexadecimal de 48 bits amb 12 caràcters. Com que cadascun d'aquests números consta de 4 bits, 12 dígits hexadecimals representen un nombre de 48 bits.
Com sabem, si aquest dispositiu vol posar-se en contacte amb aquest servidor, primer s'ha de fer el primer pas de l'enllaç de 3 vies, és a dir, enviar un paquet SYN. Quan es faci aquesta sol·licitud, l'ordinador 10.1.1.10 especificarà el número de port d'origen, que Windows crea dinàmicament. Windows selecciona aleatòriament un número de port entre 1 i 65,000. Però com que els números inicials de l'1 al 1024 són àmpliament coneguts, en aquest cas el sistema considerarà els nombres superiors a 25000 i crearà un port d'origen aleatori, per exemple, el número 25113.
A continuació, el sistema afegirà un port de destinació al paquet, en aquest cas és el port 21, perquè l'aplicació que està intentant connectar-se a aquest servidor FTP sap que ha d'enviar trànsit FTP.
A continuació, el nostre ordinador diu: "D'acord, la meva adreça IP és 10.1.1.10 i he de contactar amb l'adreça IP 30.1.1.10". Ambdues adreces també s'inclouen al paquet per formar una sol·licitud SYN, i aquest paquet no canviarà fins al final de la connexió.
Vull que entenguis amb aquest vídeo com es mouen les dades per la xarxa. Quan el nostre ordinador que envia la sol·licitud veu l'adreça IP d'origen i l'adreça IP de destinació, entén que l'adreça de destinació no es troba en aquesta xarxa local. Em vaig oblidar de dir que aquestes són totes adreces IP /24. Així, si mireu les adreces IP /24, us adonareu que els ordinadors 10.1.1.10 i 30.1.1.10 no estan a la mateixa xarxa. Així, l'ordinador que envia la sol·licitud entén que per sortir d'aquesta xarxa ha de contactar amb la passarel·la 10.1.1.1, que està configurada en una de les interfícies de l'encaminador. Sap que hauria d'anar a 10.1.1.1 i sap la seva adreça MAC de 1111, però no sap l'adreça MAC de la passarel·la 10.1.1.1. Què està fent? Envia una sol·licitud ARP de difusió que rebran tots els dispositius de la xarxa, però només hi respondrà l'encaminador amb l'adreça IP 10.1.1.1.
L'encaminador respondrà amb la seva adreça MAC AAAA, i les adreces MAC d'origen i de destinació també es col·locaran en aquest marc. Un cop la trama estigui a punt, es realitzarà una comprovació d'integritat de dades CRC, que és un algorisme per trobar una suma de verificació per detectar errors, abans de sortir de la xarxa.
CRC de redundància cíclica significa que tota aquesta trama, des del SYN fins a l'última adreça MAC, s'executa a través d'un algorisme hash, per exemple MD5, que resulta en un valor hash. El valor hash, o suma de comprovació MD5, es col·loca aleshores al principi del marc.
El vaig etiquetar FCS/CRC perquè FCS és una seqüència de verificació de trama, un valor CRC de quatre bytes. Algunes persones utilitzen la designació FCS i altres la designació CRC, així que només he inclòs les dues designacions. Però bàsicament només és un valor hash. Cal assegurar-se que totes les dades rebudes a la xarxa no continguin errors. Per tant, quan aquesta trama arriba a l'encaminador, el primer que farà l'encaminador és calcular la suma de comprovació i comparar-la amb el valor FCS o CRC que conté la trama rebuda. D'aquesta manera, pot comprovar que les dades rebudes a través de la xarxa no contenen errors, després del qual eliminarà la suma de comprovació de la trama.
A continuació, l'encaminador mirarà l'adreça MAC i dirà: "D'acord, l'adreça MAC AAAA significa que el marc s'adreça a mi" i suprimirà la part del marc que conté les adreces MAC.
Mirant l'adreça IP de destinació 30.1.1.10, entendrà que aquest paquet no s'adreça a ell i ha d'anar més enllà per l'encaminador.
Ara l'encaminador "pensa" que necessita veure on es troba la xarxa amb l'adreça 30.1.1.10. Encara no hem cobert el concepte complet d'encaminament, però sabem que els encaminadors tenen una taula d'encaminament. Aquesta taula té una entrada per a la xarxa amb l'adreça 30.1.1.0. Com recordeu, aquesta no és l'adreça IP de l'amfitrió, sinó l'identificador de xarxa. L'encaminador "pensarà" que pot arribar a l'adreça 30.1.1.0/24 passant pel router 20.1.1.2.
Podeu preguntar-vos, com ho sap ell? Tingueu en compte que ho sabrà ja sigui pels protocols d'encaminament o des de la vostra configuració si com a administrador heu configurat una ruta estàtica. Però en qualsevol cas, la taula d'encaminament d'aquest encaminador conté l'entrada correcta, de manera que sap que hauria d'enviar aquest paquet a 20.1.1.2. Suposant que l'encaminador ja coneix l'adreça MAC de destinació, simplement continuarem reenviant el paquet. Si no coneix aquesta adreça, tornarà a iniciar ARP, rebrà l'adreça MAC de l'encaminador 20.1.1.2 i el procés d'enviament de la trama continuarà de nou.
Per tant, suposem que ja coneix l'adreça MAC, llavors tindrem l'adreça MAC d'origen BBB i l'adreça MAC de destinació CCC. L'encaminador torna a calcular el FCS/CRC i el col·loca al principi de la trama.
Aleshores envia aquesta trama a través de la xarxa, la trama arriba a l'encaminador 20.1.12, comprova la suma de comprovació, s'assegura que les dades no estiguin malmeses i esborra el FCS/CRC. A continuació, "trunca" les adreces MAC, mira la destinació i veu que és 30.1.1.10. Ell sap que aquesta adreça està connectada a la seva interfície. Es repeteix el mateix procés de formació de trama, l'encaminador afegeix els valors de l'adreça MAC d'origen i de destinació, fa el hash, enllaça el hash a la trama i l'envia a través de la xarxa.
El nostre servidor, després d'haver rebut finalment la sol·licitud SYN adreçada a ell, comprova la suma de verificació hash, i si el paquet no conté errors, elimina el hash. Aleshores elimina les adreces MAC, mira l'adreça IP i s'adona que aquest paquet està dirigit a ell.
Després d'això, trunca les adreces IP relacionades amb la tercera capa del model OSI i mira els números de port.
Veu el port 21, que significa trànsit FTP, veu el SYN i, per tant, entén que algú està intentant comunicar-se amb ell.
Ara, basant-nos en el que hem après sobre l'encaixada de mans, el servidor 30.1.1.10 crearà un paquet SYN/ACK i l'enviarà de nou a l'ordinador 10.1.1.10. En rebre aquest paquet, el dispositiu 10.1.1.10 crearà un ACK, el passarà per la xarxa de la mateixa manera que un paquet SYN, i després que el servidor rebi l'ACK, s'establirà la connexió.
Una cosa que hauríeu de saber és que tot això passa en menys d'un segon. Aquest és un procés molt i molt ràpid, que he intentat frenar perquè tot us quedi clar.
Espero que trobeu útil el que heu après en aquest tutorial. Si teniu cap pregunta, si us plau, escriu-me a [protegit per correu electrònic] o deixa preguntes sota aquest vídeo.
A partir de la següent lliçó, seleccionaré les 3 preguntes més interessants de YouTube, que repassaré al final de cada vídeo. A partir d'ara tindré una secció "Preguntes principals", així que publicaré una pregunta juntament amb el teu nom i la respondré en directe. Crec que això serà beneficiós.
Gràcies per quedar-te amb nosaltres. T'agraden els nostres articles? Vols veure més contingut interessant? Doneu-nos suport fent una comanda o recomanant als amics, 30% de descompte per als usuaris d'Habr en un únic anàleg de servidors d'entrada, que hem inventat per a tu: (disponible amb RAID1 i RAID10, fins a 24 nuclis i fins a 40 GB DDR4).
VPS (KVM) E5-2650 v4 (6 nuclis) 10 GB DDR4 240 GB SSD 1 Gbps gratuït fins a l'estiu en pagar per un període de sis mesos, podeu demanar .
Dell R730xd 2 vegades més barat? Només aquí als Països Baixos! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB - a partir de 99 $! Llegeix sobre
Font: www.habr.com