Avant de commencer le didacticiel vidéo d'aujourd'hui, je tiens à remercier tous ceux qui ont contribué à la popularité de mon cours sur YouTube. Quand j'ai commencé il y a environ 8 mois, je ne m'attendais pas à un tel succès - pour aujourd'hui 312724 personnes ont vu mes leçons, j'ai 11208 abonnés. Je n'ai jamais rêvé que cette modeste entreprise atteindrait de tels sommets. Mais nous ne perdrons pas de temps et passerons immédiatement à la leçon d'aujourd'hui. Aujourd'hui, nous comblons les lacunes qui se sont produites dans les 7 derniers didacticiels vidéo. Bien qu'aujourd'hui ne soit que de 6 jours, le jour 3 a été divisé en 3 leçons vidéo, donc en fait aujourd'hui vous regardez la huitième leçon vidéo.
Aujourd'hui, nous traiterons de 3 sujets importants: DHCP, transmission TCP et les numéros de port les plus courants. Nous avons déjà parlé des adresses IP, et l'un des facteurs les plus importants dans la configuration d'une adresse IP est DHCP.
DHCP signifie «Dynamic Host Configuration Protocol», un protocole qui permet de configurer dynamiquement les adresses IP des hôtes. Nous avons donc tous vu cette fenêtre. Lorsque vous cliquez sur l'option «Obtenir l'adresse IP automatiquement», l'ordinateur recherche un serveur DHCP configuré sur le même sous-réseau et envoie divers paquets et demandes d'adresse IP. DHCP a 6 messages, dont 4 sont essentiels pour attribuer une adresse IP.
Le premier message est un message de découverte DHCP DISCOVERY. Le message de découverte DHCP est comme un message d'accueil. Lorsqu'un nouveau périphérique pénètre dans le réseau, il demande si un serveur DHCP est présent sur le réseau.
Ce que vous voyez sur la diapositive ressemble à une demande de diffusion, le code de l'appareil accède à tous les appareils du réseau à la recherche d'un serveur DHCP. Comme je l'ai dit, il s'agit d'une demande de diffusion, donc tous les périphériques réseau l'entendent.
S'il y a un serveur DHCP sur le réseau, il envoie un paquet - une phrase OFFRE DHCP. La proposition signifie que le serveur DHCP, en réponse à la demande de découverte, envoie la configuration au client, l'invitant à accepter une adresse IP spécifique.
Le serveur DHCP réserve l'adresse IP, dans ce cas 192.168.1.2, ne fournit pas, à savoir qu'il réserve cette adresse pour le périphérique. Dans le même temps, le package d'offre contient sa propre adresse IP du serveur DHCP.
Si ce réseau possède plusieurs serveurs DHCP, un autre serveur DHCP, après avoir reçu une demande de diffusion du client, lui offrira également son adresse IP, par exemple 192.168.1.50. Habituellement, deux serveurs DHCP différents ne sont pas configurés sur le même réseau, mais cela se produit parfois. Ainsi, lorsqu'une proposition DHCP est envoyée au client, il reçoit 2 propositions DHCP et doit maintenant décider quelle proposition DHCP il souhaite accepter.
Supposons que le client accepte la première application. Cela signifie que le client envoie une requête DHCP REQUEST qui dit littéralement: "J'accepte l'adresse IP 192.168.1.2 proposée par le serveur DHCP 192.168.1.1."
Dès réception de la demande, le serveur DHCP 192.168.1.1 répond: «OK, je l'admets», c'est-à-dire qu'il confirme la demande et envoie cette confirmation DHCP ACK au client. Mais nous nous souvenons qu'un autre serveur DHCP DHCP a réservé une adresse IP de 1,50 pour le client. Lors de la réception de la demande de diffusion du client, il apprend l’échec et remet cette adresse IP dans le pool afin qu’il puisse l’attribuer à un autre client s’il reçoit une autre demande.
Ce sont les 4 messages critiques que DHCP échange au début de l'attribution d'adresse IP. De plus, DHCP a 2 autres messages d'information. Un message d'information est émis par le client s'il a besoin de plus d'informations qu'il n'en a reçues dans la phrase DHCP OFFER à la deuxième étape. Si le serveur DHCP n'a pas fourni suffisamment d'informations dans la proposition DHCP ou si le client a besoin de plus d'informations que celles contenues dans le paquet de proposition, il demande des informations DHCP supplémentaires. Il y a un autre message que le client envoie au serveur - c'est la version de DHCP RELEASE. Il indique que le client souhaite libérer son adresse IP existante.
Cependant, il arrive le plus souvent que l'utilisateur se déconnecte du réseau avant que le client ne parvienne à envoyer DHCP RELEASE au serveur. Cela se produit lorsque vous éteignez l'ordinateur, que nous effectuons avec vous. Dans le même temps, le client réseau ou l'ordinateur n'a tout simplement pas le temps d'informer le serveur de la libération de l'adresse utilisée, donc DHCP RELEASE n'est pas une étape obligatoire. Les étapes requises pour obtenir une adresse IP sont les suivantes: découverte DHCP, offre DHCP, demande DHCP et confirmation DHCP.
Dans l'une des leçons suivantes, je vais vous expliquer comment nous configurons un serveur DHCP lors de la création d'un pool DNCP. Par pool, vous entendez informer le serveur de l'attribution d'adresses IP dans la plage de 192.168.1.1 à 192.168.1.254. Ainsi, le serveur DHCP créera un pool, y placera 254 adresses IP et ne pourra attribuer des adresses de clients réseau qu'à partir de ce pool. C'est donc quelque chose comme un paramètre administratif qu'un utilisateur peut faire.
Considérons maintenant la transmission de TCP. Je ne sais pas si vous connaissez le «téléphone» montré sur la photo, mais enfant, nous utilisions des canettes connectées avec un cordon pour nous parler.
Malheureusement, la génération actuelle ne peut pas se permettre un tel «luxe». Je veux dire, aujourd'hui, les enfants sont devant la télévision dès l'âge d'un an, ils jouent sur PSP, et c'est peut-être un point discutable, mais je pense que nous avons eu une meilleure enfance, nous sommes vraiment sortis et avons joué à des jeux, et vous ne pouvez pas arracher les enfants d'aujourd'hui du canapé.
Mon fils n'a qu'un an, et je vois déjà qu'il est accro à l'iPad, je veux dire qu'il est encore très petit, mais il me semble que les enfants d'aujourd'hui sont déjà nés avec une connaissance de la manipulation des gadgets électroniques. Donc, je voulais dire que dans l'enfance, quand nous jouions, nous déchirions des canettes, et quand ils les ont attachés avec une ficelle et ont dit quelque chose dans une boîte, à l'autre bout une personne pouvait entendre ce qu'ils disaient, en mettant simplement une canette dans son oreille . C'est donc très similaire à une connexion réseau.
Aujourd'hui, même pour la transmission TCP, une connexion doit être établie avant le début du transfert de données. Comme nous l'avons vu dans les leçons précédentes, TCP est une transmission qui se concentre sur le pré-établissement d'une connexion au réseau, tandis que UDP est une transmission sans avoir besoin d'établir une connexion. Vous pouvez dire que l'UDP, c'est quand je lance la balle, et cela dépend de vous si vous pouvez l'attraper. Êtes-vous prêt à le faire ou non, ce n'est pas mon problème, je vais juste y renoncer.
TCP ressemble plus à parler à un gars et à l'avertir à l'avance que vous allez lancer la balle, c'est-à-dire qu'une connexion est établie entre vous, et alors seulement vous lancez la balle, il est donc très probable que votre partenaire soit prêt à l'attraper. Ainsi, TCP établit réellement une connexion, puis commence à effectuer un véritable transfert.
Considérez comment cela crée une telle connexion. Pour créer une connexion, ce protocole utilise une négociation en 3 étapes. Ce terme n'est pas très technique, mais il est utilisé depuis longtemps pour décrire une connexion TCP. Une prise de contact en 3 étapes est initiée par le périphérique émetteur et le client envoie un paquet avec l'indicateur SYN au serveur.
Supposons que la fille au premier plan dont le visage que nous pouvons voir est le périphérique A, et la fille à l'arrière-plan dont le visage n'est pas visible est le périphérique B. La fille A envoie un paquet SYN à la fille B, et elle dit: «super, quelqu'un il veut me parler. Je dois donc répondre que je suis prêt à communiquer! » Comment faire On pourrait simplement renvoyer un autre paquet SYN, puis un accusé de réception ACK indiquant la réception du paquet SYN d'origine. Mais au lieu d'envoyer l'ACK séparément, le serveur forme un paquet commun qui contient le SYN et l'ACK et le transmet sur le réseau.
Donc, pour le moment, le périphérique A a envoyé un paquet SYN et a reçu un paquet SYN / ACK. Le périphérique A doit maintenant envoyer un ACK au périphérique B, c'est-à-dire confirmer qu'il a reçu le consentement du périphérique B pour établir la communication. Ainsi, les deux appareils ont reçu des paquets SYN et ACK, et maintenant nous pouvons dire que la connexion est établie, c'est-à-dire qu'une prise de contact en 3 étapes via TCP est implémentée.
De plus, nous considérerons la technologie TCP Windowing. En termes simples, il s'agit de la méthode utilisée par TCP / IP pour négocier les capacités de l'expéditeur et du récepteur.
Supposons que sous Windows, nous essayons de transférer un gros fichier, disons 2 Go, d'un disque à un autre. Au tout début du transfert, le système nous indiquera que le transfert de fichiers prendra environ 1 an. Mais quelques secondes plus tard, le système va récupérer et dire: "Oh, attendez une minute, je pense que cela ne prendra pas 6 mois, mais environ 6 mois." Un peu plus de temps passera et Windows dira: "Je pense que je pourrai peut-être transférer le fichier en 1 mois". Puis le message "1 jour", "6 heures", "3 heures", "1 heure", "20 minutes" "," 10 minutes "," 3 minutes. "En fait, tout le processus de transfert d'un fichier ne prendra que 3 minutes. Comment cela s'est-il passé? Initialement, lorsque votre appareil a essayé de contacter un autre appareil, il envoie un paquet et attend la confirmation. Si l'appareil attend confirmation pendant longtemps, il pense: "si je dois transférer 2 Go de données à cette vitesse, alors ce cela prend environ 2 ans. "Après un certain temps, votre appareil reçoit un ACK et pense:" OK, j'ai envoyé un paquet et reçu un ACK, par conséquent, le récepteur peut recevoir 1 paquet. Maintenant, je vais essayer de lui envoyer 10 paquets au lieu d'un. "L'expéditeur envoie 10 paquets et après un certain temps reçoit une confirmation ACK de l'appareil récepteur, ce qui signifie que le destinataire attend le 11ème paquet suivant. L'expéditeur pense: "excellent, puisque le destinataire a traité 10 paquets immédiatement, maintenant je vais essayer de lui envoyer 100 paquets au lieu de dix. " Il envoie 100 paquets, et le destinataire répond qu'il les a reçus et attend maintenant 101 paquets. Ainsi, au fil du temps, le nombre de paquets transmis augmente.
C'est pourquoi vous constatez une diminution rapide du temps de copie des fichiers par rapport à ce qui était indiqué à l'origine - cela est dû à une augmentation de la capacité de transférer une grande quantité de données. Cependant, il arrive un moment où une nouvelle augmentation du volume de transmission devient impossible. Supposons que vous ayez envoyé 10 000 paquets, mais que la mémoire tampon du périphérique du récepteur ne peut en recevoir que 9 000. Dans ce cas, le récepteur envoie un ACK avec le message: «J'ai reçu 9 000 paquets et je suis maintenant prêt à en recevoir 9001». À partir de cela, l'expéditeur conclut que le tampon de l'appareil récepteur a une capacité de seulement 9000, ce qui signifie qu'à partir de maintenant, je n'enverrai pas plus de 9000 paquets à la fois. Dans ce cas, l'expéditeur calcule rapidement le temps qu'il lui faudra pour transférer la quantité de données restante par portions de 9 000 paquets et donne 3 minutes. Ces trois minutes sont le temps de transmission réel. C'est ce que fait le fenêtrage TCP.
Il s'agit de l'un de ces mécanismes de contrôle du trafic où le dispositif de transmission au fil du temps comprend quelle est la bande passante réseau réelle. Vous vous demandez peut-être pourquoi ils ne peuvent pas s'entendre à l'avance sur la capacité de l'appareil récepteur? Le fait est que cela est techniquement impossible, car il existe différents types d'appareils sur le réseau. Supposons que vous ayez un iPad et que sa vitesse de transfert / réception de données soit différente de celle de l'iPhone, vous pouvez avoir différents types de téléphones ou peut-être un très vieil ordinateur. Par conséquent, tout le monde a une bande passante réseau différente.
Par conséquent, la technologie TCP Windowing a été développée lorsque le transfert de données commence à faible vitesse ou avec un nombre minimum de paquets, augmentant progressivement la fenêtre de trafic. Vous envoyez un paquet, 5 paquets, 10 paquets, 1000 paquets, 10000 paquets et ouvrez lentement cette fenêtre de plus en plus jusqu'à ce que «l'expansion» atteigne la valeur maximale possible d'envoi du volume de trafic dans une période de temps spécifique. Ainsi, le concept de fenêtrage fait partie du protocole TCP.
Ensuite, nous examinerons les numéros de port les plus courants. La situation classique est lorsque vous avez 1 serveur principal, il s'agit peut-être d'un centre de données. Il comprend un serveur de fichiers, un serveur Web, un serveur de messagerie et un serveur DHCP. Maintenant, si l'un des ordinateurs clients contacte le centre de données, qui se trouve au milieu de l'image, il commencera à envoyer le trafic du serveur de fichiers aux périphériques clients. Ce trafic est affiché en rouge et un port spécifique pour une application spécifique à partir d'un serveur spécifique sera utilisé pour le transmettre.
Comment le serveur a-t-il su où devait aller un certain trafic? Il le saura à partir du numéro de port de destination. Si vous regardez le cadre, vous verrez que dans chaque transfert de données, il y a une mention du numéro de port de destination et du port source. Vous voyez que le trafic bleu et rouge, et le trafic bleu est le trafic du serveur Web, les deux arrivent sur le même serveur physique, dans lequel différents serveurs sont installés. S'il s'agit d'un centre de données, il utilise des serveurs virtuels. Alors, comment savaient-ils que le trafic rouge était censé retourner sur cet ordinateur portable gauche avec cette adresse IP? Ils le savent grâce aux numéros de port. Si vous vous référez à l'article de Wikipedia «Liste des ports TCP et UDP», vous verrez qu'il répertorie tous les numéros de port standard.
Si vous faites défiler cette page, vous pouvez voir la taille de cette liste. Il contient environ 61 000 chambres. Les numéros de port de 1 à 1024 sont connus comme les numéros de port les plus courants. Par exemple, le port 21 / TCP est destiné à la transmission de commandes ftp, le port 22 pour ssh, le port 23 pour Telnet, c'est-à-dire pour la transmission de messages non chiffrés. Un port 80 très populaire est utilisé pour transmettre des données via HTTP, et le port 443 est utilisé pour transmettre des données chiffrées en utilisant HTTPS, qui est similaire à la version sécurisée de HTTP.
Certains ports sont conçus pour TCP et UDP en même temps, et certains effectuent des tâches différentes selon la connexion utilisée - TCP ou UDP. Ainsi, officiellement le port 80 TCP est utilisé pour HTTP, et officieusement le port 80 UDP est utilisé pour HTTP, mais en utilisant un protocole HTTP différent - QUIC.
Par conséquent, les numéros de port dans TCP ne sont pas toujours conçus pour les mêmes que dans UDP. Vous n'avez pas besoin d'apprendre cette liste par cœur, il est impossible de s'en souvenir, mais vous devez connaître certains numéros de port populaires et les plus courants. Comme je l'ai dit, certains de ces ports ont un objectif officiel, qui est décrit dans les normes, et certains ont un objectif officieux, comme c'est le cas pour le chrome.
Ainsi, ce tableau répertorie tous les numéros de port courants, et ces numéros sont utilisés pour envoyer et recevoir du trafic lors de l'utilisation d'applications spécifiques.
Voyons maintenant comment les données se déplacent sur le réseau en fonction du peu d'informations que nous connaissons. Supposons que l'ordinateur 10.1.1.10 veuille contacter cet ordinateur, ou ce serveur, qui a l'adresse 30.1.1.10. Sous l'adresse IP de chaque appareil se trouve son adresse MAC. Je donne comme exemple une adresse MAC avec seulement les 4 derniers caractères, mais en pratique c'est un nombre hexadécimal de 48 bits avec 12 caractères. Étant donné que chacun de ces nombres est composé de 4 bits, 12 chiffres hexadécimaux représentent un nombre de 48 bits.
Comme nous le savons, si cet appareil souhaite contacter ce serveur, la première étape de la négociation en 3 étapes doit être effectuée en premier, c'est-à-dire qu'un paquet SYN est envoyé. Lors de la création de cette demande, l'ordinateur 10.1.1.10 indiquera le numéro de port source, que Windows crée dynamiquement. Windows sélectionne au hasard un numéro de port compris entre 1 et 65 000. Mais comme les nombres initiaux compris entre 1 et 1024 sont largement connus, dans ce cas, le système considérera les nombres supérieurs à 25000 et créera un port source aléatoire, par exemple, sous le numéro 25113.
Ensuite, le système ajoutera le port de destination au package, dans ce cas le port 21, car l'application qui essaie de se connecter à ce serveur FTP sait qu'elle doit envoyer du trafic FTP.
De plus, notre ordinateur dit: "OK, mon adresse IP est 10.1.1.10, et je dois contacter l'adresse IP 30.1.1.10." Ces deux adresses sont également incluses dans le paquet, formant une demande SYN, et ce paquet ne sera modifié qu'à la fin de la connexion.
Je veux que vous compreniez dans cette vidéo comment les données se déplacent sur le réseau. Lorsque notre ordinateur envoyant la demande voit l'adresse IP source et l'adresse IP de destination, il comprend que l'adresse de destination ne se trouve pas dans ce réseau local. J'ai oublié de dire que ce sont toutes les adresses IP / 24. Donc, si vous regardez les adresses IP / 24, vous comprendrez que les ordinateurs 10.1.1.10 et 30.1.1.10 ne sont pas sur le même réseau. Ainsi, l'ordinateur émetteur de la requête comprend que pour sortir de ce réseau, il doit se tourner vers la passerelle 10.1.1.1, qui est configurée sur l'une des interfaces du routeur. Il sait qu'il doit aller à 10.1.1.1, et connaît son adresse MAC 1111, mais ne connaît pas l'adresse MAC de la passerelle 10.1.1.1. Que fait-il? Il envoie une demande ARP de diffusion que tous les appareils du réseau recevront, mais seul un routeur avec une adresse IP de 10.1.1.1 y répondra.
Le routeur répondra avec son adresse MAC AAAA, et les adresses MAC source et de destination seront également placées dans cette trame. Dès que la trame est prête, avant de quitter le réseau, une vérification d'intégrité des données CRC sera effectuée, qui est un algorithme pour trouver la somme de contrôle afin de détecter les erreurs.
Le code CRC redondant cyclique signifie que cette trame entière, de SYN à la dernière adresse MAC, est exécutée via un algorithme de hachage, par exemple MD5, résultant en une valeur de hachage. , MD5, .
FCS/CRC, FCS – , CRC. FCS, — CRC, . . , , , , . , , , , FCS CRC, . , , , , .
MAC- : «, MAC- AAAA , », , MAC-.
IP- 30.1.1.10, , .
«» , , 30.1.1.10. , , . 30.1.1.0. , IP- , . «» , 30.1.1.0/24, 20.1.1.2.
, ? , , , . , , , 20.1.1.2. , MAC- , . , ARP, MAC- 20.1.1.2, .
, , MAC-, MAC- BBB MAC- CCC. FCS/CRC .
, 20.1.12, , , , FCS/CRC. «» MAC-, , 30.1.1.10. , . , MAC- , , .
, - SYN-, , , . MAC-, IP- , .
IP-, OSI, .
21, FTP-, SYN , - .
, , , 30.1.1.10 SYN/ACK 10.1.1.10. , 10.1.1.10 ACK, , SYN, ACK .
, — . , , .
J'espère que ce que vous avez appris de ce tutoriel vous sera utile. Si vous avez des questions, écrivez-moi à imran.rafai@nwking.org ou postez des questions sous cette vidéo.À partir de la prochaine leçon, je sélectionnerai 3 des questions les plus intéressantes de YouTube, que je considérerai à la fin de chaque vidéo. À partir de maintenant, j'aurai la section «Meilleures questions», je vais donc poster la question avec votre nom et y répondre en direct. Je pense que cela en bénéficiera.Merci de rester avec nous. Aimez-vous nos articles? Vous voulez voir des matériaux plus intéressants? Soutenez-nous en passant une commande ou en le recommandant à vos amis, une
réduction de 30% pour les utilisateurs Habr sur un analogue unique de serveurs d'entrée de gamme que nous avons inventés pour vous: Toute la vérité sur VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbps à partir de 20 $ ou comment diviser le serveur? (les options sont disponibles avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).
VPS (KVM) E5-2650 v4 (6 cœurs) 10 Go DDR4 240 Go SSD 1 Gbit / s jusqu'à l'été gratuitement lorsque vous payez pour une période de six mois, vous pouvez commander
ici .
Dell R730xd 2 fois moins cher? Nous avons seulement
2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199 $ aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99 $! Pour en savoir plus sur la
création d'un bâtiment d'infrastructure. classe utilisant des serveurs Dell R730xd E5-2650 v4 coûtant 9 000 euros pour un sou?