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 je l'ai commencé il y a environ 8 mois, je ne m'attendais pas à un tel succès - aujourd'hui mes cours ont été vus par 312724 11208 personnes, j'ai 7 6 abonnés. Je n’aurais jamais imaginé que ce modeste début atteindrait de tels sommets. Mais ne perdons pas de temps et passons directement à la leçon d'aujourd'hui. Aujourd'hui, nous allons combler les lacunes survenues dans les 3 dernières leçons vidéo. Bien qu'aujourd'hui ne soit que le sixième jour, le troisième jour a été divisé en 3 leçons vidéo. Aujourd'hui, vous allez donc réellement regarder la huitième leçon vidéo.
Aujourd'hui, nous aborderons 3 sujets importants : DHCP, le transport 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 des adresses IP est DHCP.
DHCP signifie Dynamic Host Configuration Protocol et c'est 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 une 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. Le protocole DHCP comporte 6 messages, dont 4 sont critiques pour l'attribution d'une adresse IP.
Le premier message est un message DHCP DISCOVERY. Le message de découverte DHCP est similaire à un message de bienvenue. Lorsqu'un nouvel appareil rejoint le réseau, il demande s'il existe un serveur DHCP sur le réseau.
Ce que vous voyez sur la diapositive ressemble à une demande de diffusion dans laquelle l'appareil contacte 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 appareils du réseau peuvent l'entendre.
S'il y a un serveur DHCP sur le réseau, il envoie un paquet - une offre DHCP OFFER. La proposition signifie que le serveur DHCP, en réponse à une demande de découverte, envoie une configuration au client, lui demandant d'accepter une adresse IP spécifique.
Le serveur DHCP réserve une adresse IP, dans ce cas 192.168.1.2, ne la fournit pas, mais réserve plutôt cette adresse à l'appareil. En même temps, l'offre contient sa propre adresse IP du serveur DHCP.
S'il y a plus d'un serveur DHCP sur ce réseau, un autre serveur DHCP, dès réception de la demande de diffusion du client, lui proposera également son adresse IP, par exemple 192.168.1.50. Il n'est pas courant d'avoir deux serveurs DHCP différents configurés sur le même réseau, mais cela arrive parfois. Ainsi lorsqu'une offre DHCP est envoyée à un client, celui-ci reçoit 2 offres DHCP et doit maintenant décider quelle offre DHCP il souhaite accepter.
Supposons que le client accepte la première candidature. 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 « d'accord, je l'admets », c'est-à-dire qu'il accuse réception de la demande et envoie cet ACK DHCP au client. Mais on rappelle qu'un autre serveur DHCP a réservé une adresse IP de 1.50 pour le client. Une fois qu'il aura reçu la demande de diffusion d'un client, il sera informé de l'échec et remettra cette adresse IP dans le pool afin de pouvoir l'attribuer à un autre client s'il reçoit une autre demande.
Ce sont les 4 messages critiques que DHCP échange lors de l'attribution d'adresses IP. Ensuite, DHCP a 2 messages d'information supplémentaires. Un message d'information est émis par le client s'il nécessite plus d'informations que celles reçues dans la clause DHCP OFFER lors de la deuxième étape. Si le serveur n'a pas fourni suffisamment d'informations dans l'offre DHCP, ou si le client a besoin de plus d'informations que celles contenues dans le paquet d'offre, il demande des informations DHCP supplémentaires. Il y a un autre message que le client envoie au serveur : il s'agit de la version DHCP. Il vous informe que le client souhaite libérer son adresse IP existante.
Cependant, ce qui arrive le plus souvent, c'est que l'utilisateur se déconnecte du réseau avant que le client n'ait le temps d'envoyer un DHCP RELEASE au serveur. Cela se produit lorsque vous éteignez l'ordinateur, ce que nous faisons. Dans ce cas, le client du réseau, ou l'ordinateur, n'a tout simplement pas le temps d'informer le serveur de libérer l'adresse utilisée, donc DHCP RELEASE n'est pas une étape obligatoire. Les étapes requises pour obtenir une adresse IP sont : la découverte DHCP, l'offre DHCP, la demande DHCP et la prise de contact DHCP.
Dans l'une des prochaines leçons, je vous expliquerai comment configurer un serveur DHCP lors de la création d'un pool DNCP. Par pooling, nous entendons que vous demandez au serveur d'attribuer des adresses IP comprises entre 192.168.1.1 et 192.168.1.254. Ainsi, le serveur DHCP créera un pool, y placera 254 adresses IP et pourra attribuer des adresses aux clients du réseau uniquement à partir de ce pool. C'est donc quelque chose comme un paramètre administratif que l'utilisateur peut effectuer.
Examinons maintenant la transmission TCP. Je ne sais pas si vous connaissez le "téléphone" représenté sur la photo, mais quand nous étions enfants, nous utilisions ces boîtes de conserve reliées par une ficelle pour nous parler.
Malheureusement, la génération actuelle ne peut pas se permettre un tel « luxe ». Je veux dire qu'aujourd'hui, les enfants sont devant la télévision dès l'âge d'un an, ils jouent à la PSP et c'est peut-être discutable, mais je pense que nous avons eu la meilleure enfance, nous sommes en fait allés dehors et avons joué à des jeux et les enfants d'aujourd'hui ne peuvent pas être éloignés 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 jeune mais je pense que les enfants d'aujourd'hui naissent déjà en sachant manier les gadgets électroniques. Donc, je voulais dire que lorsque nous étions enfants, lorsque nous jouions, nous faisions des trous dans les boîtes de conserve, et lorsque nous les attachions avec une ficelle et disions quelque chose dans une boîte, alors à l'autre bout du fil, la personne pouvait entendre ce qui se disait. à lui, simplement en mettant la canette à son oreille. C'est donc très similaire à une connexion réseau.
Aujourd'hui, même les transferts TCP doivent avoir une connexion qui doit être établie avant le début du transfert de données proprement dit. Comme nous l'avons vu dans les leçons précédentes, TCP est une transmission orientée connexion tandis qu'UDP est une transmission orientée connexion. On pourrait dire que UDP est l'endroit où je lance la balle et c'est à vous de voir si vous pouvez l'attraper. Que tu sois prêt à le faire ou non, ce n'est pas mon problème, je vais juste le quitter.
TCP, c'est plutôt si vous parlez à un gars et l'avertissez à l'avance que vous allez lancer une balle, vous formez donc un lien, puis vous lancez la balle pour que votre partenaire soit plus susceptible d'être prêt à l'attraper. Ainsi, TCP établit réellement la connexion, puis commence à effectuer la transmission proprement dite.
Voyons comment cela crée une telle connexion. Ce protocole utilise une négociation à trois pour créer une connexion. Ce terme n’est pas très technique, mais il est utilisé depuis longtemps pour décrire une connexion TCP. Une négociation à trois voies est initiée par le périphérique expéditeur, le client envoyant un paquet avec un indicateur SYN au serveur.
Disons que la fille au premier plan, dont nous pouvons voir le visage, est l'appareil A, et la fille en arrière-plan, dont le visage n'est pas visible, est l'appareil B. La fille A envoie un paquet SYN à la fille B, et elle dit : "super, qui- alors il veut communiquer avec moi. Alors je dois répondre que je suis prêt à communiquer ! Comment faire? On pourrait simplement renvoyer un autre paquet SYN, puis un ACK indiquant la réception du paquet SYN d'origine. Mais au lieu d'envoyer les ACK séparément, le serveur forme un paquet commun contenant le SYN et l'ACK et le transmet sur le réseau.
Ainsi, à ce stade, le périphérique A a envoyé un paquet SYN et a reçu un paquet SYN/ACK. L'appareil A doit désormais envoyer à l'appareil B un paquet ACK, c'est-à-dire confirmer qu'il a reçu le consentement de l'appareil B pour établir la communication. Ainsi, les deux appareils ont reçu les paquets SYN et ACK, et nous pouvons maintenant dire que la connexion a été établie, c'est-à-dire qu'une négociation en 3 étapes a été effectuée à l'aide du protocole TCP.
Nous examinerons ensuite la technologie TCP Windowing. En termes simples, il s'agit d'une méthode utilisée dans TCP/IP pour négocier les capacités de l'expéditeur et du destinataire.
Disons que sous Windows, nous essayons de transférer un fichier volumineux, disons de 2 Go, d'un lecteur à un autre. Au tout début du transfert, le système nous informera que le transfert du fichier prendra environ 1 an. Mais quelques secondes plus tard, le système se corrigera et dira : « oh, attends une minute, je pense que cela prendra environ 6 mois, pas un an. » Un peu plus de temps passera et Windows dira : « Je pense que je pourrai peut-être transférer le fichier dans 1 mois. » Viennent ensuite le message « 1 jour », « 6 heures », « 3 heures », « 1 heure », « 20 minutes », « 10 minutes », « 3 minutes ». En fait, l’ensemble du processus de transfert de fichiers ne prendra que 3 minutes. Comment est-ce arrivé? Initialement, lorsque votre appareil tente de communiquer avec un autre appareil, il envoie un paquet et attend une confirmation. Si l'appareil attend longtemps la confirmation, il pense : « si je dois transférer 2 Go de données à cette vitesse, cela prendra environ 2 ans ». Après un certain temps, votre appareil reçoit un ACK et pense : « D'accord, j'ai envoyé un paquet et reçu un ACK, le destinataire peut donc recevoir 1 paquet. Maintenant, je vais essayer de lui envoyer 10 colis au lieu d’un. L'expéditeur envoie 10 paquets et reçoit après un certain temps une confirmation ACK de l'appareil récepteur, ce qui signifie que le destinataire attend le 11ème paquet suivant. L’expéditeur pense : « super, puisque le destinataire a traité 10 paquets à la fois, 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, avec le 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 initialement indiqué - cela est dû à la capacité accrue à transférer de grandes quantités de données. Cependant, il arrive un moment où de nouvelles augmentations du volume de transmission deviennent impossibles. Supposons que vous ayez envoyé 10000 9000 paquets, mais que le tampon du périphérique du récepteur ne peut en accepter que 9000 9001. Dans ce cas, le récepteur envoie un ACK avec le message : "J'ai reçu 9000 9000 paquets et je suis maintenant prêt à en recevoir 9000 3". L'expéditeur en conclut que le tampon du périphérique de réception n'a qu'une capacité de XNUMX XNUMX, ce qui signifie qu'à partir de maintenant, je n'enverrai pas plus de XNUMX XNUMX 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 XNUMX XNUMX paquets, et lui donne XNUMX minutes. Ces trois minutes constituent la durée réelle de transmission. C'est ce que fait TCP Windowing.
Il s’agit de l’un de ces mécanismes de limitation du trafic grâce auxquels l’appareil émetteur finit par comprendre quelle est la capacité réelle du réseau. Vous vous demandez peut-être pourquoi ils ne parviennent pas à se mettre d'accord à l'avance sur la capacité de l'appareil de réception ? Le fait est que cela est techniquement impossible car il existe différents types d’appareils sur le réseau. Disons que vous possédez un iPad et qu'il a une vitesse de transfert/réception de données différente de celle d'un iPhone, vous pouvez avoir différents types de téléphones, ou peut-être avez-vous un très vieil ordinateur. Par conséquent, chacun dispose d’une bande passante réseau différente.
C'est pourquoi la technologie TCP Windowing a été développée, lorsque la transmission de données commence à faible vitesse ou avec la transmission d'un nombre minimum de paquets, augmentant progressivement la « fenêtre » du trafic. Vous envoyez un paquet, 5 paquets, 10 paquets, 1000 10000 paquets, XNUMX XNUMX paquets et ouvrez lentement cette fenêtre de plus en plus jusqu'à ce que « l'ouverture » atteigne le volume maximum possible de trafic envoyé dans une période de temps spécifique. Ainsi, la notion de Windowing fait partie du fonctionnement du protocole TCP.
Nous examinerons ensuite les numéros de port les plus courants. La situation classique est celle où vous disposez d’un serveur principal, peut-être un centre de données. Il comprend un serveur de fichiers, un serveur Web, un serveur de messagerie et un serveur DHCP. Désormais, si l'un des ordinateurs clients contacte le centre de données situé au milieu de l'image, il commencera à envoyer le trafic du serveur de fichiers aux appareils clients. Ce trafic est affiché en rouge et sera transmis sur un port spécifique pour une application spécifique depuis un serveur spécifique.
Comment le serveur savait-il où devait aller certains trafics ? Il l'apprend grâce au 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 numéro de port source. Vous pouvez voir que le trafic bleu et rouge, et le trafic bleu est le trafic du serveur Web, tous deux vont vers le même serveur physique, sur 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 vers 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 Wikipédia « Liste des ports TCP et UDP », vous verrez qu’il répertorie tous les numéros de ports standards.
Si vous faites défiler cette page, vous pouvez voir la taille de cette liste. Il contient environ 61 000 numéros. Les numéros de port compris entre 1 et 1024 21 sont connus comme les numéros de port les plus courants. Par exemple, le port 22/TCP sert à l'envoi de commandes FTP, le port 23 à SSH et le port 80 à Telnet, c'est-à-dire à l'envoi de messages non cryptés. Le très populaire port 443 transporte les données via HTTP, tandis que le port XNUMX transporte les données cryptées via HTTPS, similaire à la version sécurisée de HTTP.
Certains ports sont dédiés à la fois à TCP et à UDP, et certains effectuent des tâches différentes selon que la connexion est TCP ou UDP. Ainsi, officiellement, le port TCP 80 est utilisé pour HTTP, et officieusement le port UDP 80 est utilisé pour HTTP, mais sous un protocole HTTP différent - QUIC.
Par conséquent, les numéros de port dans TCP ne sont pas toujours destinés à faire la même chose que dans UDP. Vous n'avez pas besoin d'apprendre cette liste par cœur, elle est impossible à retenir, mais vous devez connaître certains numéros de ports 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 d'autres ont un objectif non officiel, comme c'est le cas de Chromium.
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 circulent à travers le réseau en fonction du peu d'informations dont nous disposons. Disons que l'ordinateur 10.1.1.10 souhaite 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 l'exemple d'une adresse MAC avec seulement les 4 derniers caractères, mais en pratique il s'agit d'un nombre hexadécimal de 48 bits avec 12 caractères. Puisque chacun de ces nombres est constitué 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 à trois doit être effectuée en premier, c'est-à-dire l'envoi d'un paquet SYN. Lorsque cette demande est effectuée, l'ordinateur 3 spécifiera le numéro de port source, que Windows crée dynamiquement. Windows sélectionne au hasard un numéro de port compris entre 10.1.1.10 et 1 65,000. Mais comme les numéros de départ compris entre 1 et 1024 25000 sont largement connus, dans ce cas, le système prendra en compte les nombres supérieurs à 25113 XNUMX et créera un port source aléatoire, par exemple le numéro XNUMX XNUMX.
Ensuite, le système ajoutera un port de destination au paquet, dans ce cas il s'agit du port 21, car l'application qui tente de se connecter à ce serveur FTP sait qu'elle doit envoyer du trafic FTP.
Ensuite, notre ordinateur dit : « D'accord, 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 pour former une requête SYN, et ce paquet ne changera pas jusqu'à la fin de la connexion.
Je veux que vous compreniez à partir de cette vidéo comment les données se déplacent sur le réseau. Lorsque notre ordinateur qui envoie la demande voit l'adresse IP source et l'adresse IP de destination, il comprend que l'adresse de destination ne se trouve pas sur ce réseau local. J'ai oublié de dire que ce sont toutes des adresses IP /24. Ainsi, si vous regardez les adresses IP /24, vous vous rendrez compte que les ordinateurs 10.1.1.10 et 30.1.1.10 ne sont pas sur le même réseau. Ainsi, l'ordinateur qui envoie la requête comprend que pour quitter ce réseau, il doit contacter la passerelle 10.1.1.1, qui est configurée sur l'une des interfaces du routeur. Il sait qu'il doit accéder à 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 requête ARP de diffusion que tous les appareils du réseau recevront, mais seul le routeur avec l'adresse IP 10.1.1.1 y répondra.
Le routeur répondra avec son adresse MAC AAAA, et les adresses MAC source et destination seront également placées dans cette trame. Une fois la trame prête, une vérification de l'intégrité des données CRC, qui est un algorithme permettant de trouver une somme de contrôle pour détecter les erreurs, sera effectuée avant de quitter le réseau.
Le CRC de redondance cyclique signifie que l'intégralité de cette trame, du 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. La valeur de hachage, ou somme de contrôle MD5, est ensuite placée au début de la trame.
Je l'ai appelé FCS/CRC car FCS est une séquence de vérification de trame, une valeur CRC de quatre octets. Certaines personnes utilisent la désignation FCS et d'autres la désignation CRC, j'ai donc simplement inclus les deux désignations. Mais fondamentalement, c'est juste une valeur de hachage. Il est nécessaire de s'assurer que toutes les données reçues sur le réseau ne contiennent pas d'erreurs. Par conséquent, lorsque cette trame atteint le routeur, la première chose que fera le routeur est de calculer lui-même la somme de contrôle et de la comparer avec la valeur FCS ou CRC que contient la trame reçue. De cette façon, il peut vérifier que les données reçues sur le réseau ne contiennent pas d'erreurs, après quoi il supprimera la somme de contrôle de la trame.
Ensuite, le routeur examinera l'adresse MAC et dira : « D'accord, l'adresse MAC AAAA signifie que la trame m'est adressée » et supprimera la partie de la trame contenant les adresses MAC.
En regardant l'adresse IP de destination 30.1.1.10, il comprendra que ce paquet ne lui est pas adressé et doit passer plus loin par le routeur.
Maintenant, le routeur « pense » qu'il a besoin de voir où se trouve le réseau portant l'adresse 30.1.1.10. Nous n'avons pas encore abordé le concept complet du routage, mais nous savons que les routeurs disposent d'une table de routage. Cette table contient une entrée pour le réseau avec l'adresse 30.1.1.0. Comme vous vous en souvenez, il ne s'agit pas de l'adresse IP de l'hôte, mais de l'identifiant du réseau. Le routeur « pensera » qu’il peut atteindre l’adresse 30.1.1.0/24 en passant par le routeur 20.1.1.2.
Vous vous demandez peut-être comment sait-il cela ? Gardez simplement à l’esprit qu’il le saura soit grâce aux protocoles de routage, soit grâce à vos paramètres si vous, en tant qu’administrateur, avez configuré une route statique. Mais dans tous les cas, la table de routage de ce routeur contient l'entrée correcte, il sait donc qu'il doit envoyer ce paquet au 20.1.1.2. En supposant que le routeur connaît déjà l'adresse MAC de destination, nous continuerons simplement à transférer le paquet. S'il ne connaît pas cette adresse, il relancera ARP, recevra l'adresse MAC 20.1.1.2 du routeur et le processus d'envoi de la trame continuera.
Nous supposons donc qu'il connaît déjà l'adresse MAC, nous aurons alors l'adresse MAC source BBB et l'adresse MAC de destination CCC. Le routeur calcule à nouveau le FCS/CRC et le place au début de la trame.
Il envoie ensuite cette trame sur le réseau, la trame atteint le routeur 20.1.12, il vérifie la somme de contrôle, s'assure que les données ne sont pas corrompues et supprime le FCS/CRC. Il "tronque" ensuite les adresses MAC, examine la destination et constate qu'il s'agit du 30.1.1.10. Il sait que cette adresse est connectée à son interface. Le même processus de formation de trame est répété, le routeur ajoute les valeurs des adresses MAC source et de destination, effectue le hachage, attache le hachage à la trame et l'envoie sur le réseau.
Notre serveur, ayant finalement reçu la requête SYN qui lui est adressée, vérifie la somme de contrôle du hachage, et si le paquet ne contient pas d'erreurs, il supprime le hachage. Puis il supprime les adresses MAC, regarde l'adresse IP et se rend compte que ce paquet lui est adressé.
Après cela, il tronque les adresses IP liées à la troisième couche du modèle OSI et examine les numéros de port.
Il voit le port 21, qui signifie le trafic FTP, voit le SYN et comprend donc que quelqu'un essaie de communiquer avec lui.
Désormais, sur la base de ce que nous avons appris sur la poignée de main, le serveur 30.1.1.10 créera un paquet SYN/ACK et le renverra à l'ordinateur 10.1.1.10. Lors de la réception de ce paquet, le périphérique 10.1.1.10 créera un ACK, le transmettra à travers le réseau de la même manière qu'un paquet SYN, et une fois que le serveur aura reçu l'ACK, la connexion sera établie.
Une chose que vous devez savoir, c’est que tout cela se passe en moins d’une seconde. C'est un processus très, très rapide, que j'ai essayé de ralentir pour que tout soit clair pour vous.
J'espère que vous trouverez utile ce que vous avez appris dans ce didacticiel. Si vous avez des questions, écrivez-moi à [email protected] ou laissez des questions sous cette vidéo.
À partir de la leçon suivante, je sélectionnerai les 3 questions les plus intéressantes de YouTube, que je passerai en revue à la fin de chaque vidéo. À partir de maintenant, j'aurai une section « Principales questions », je posterai donc une question avec votre nom et y répondrai en direct. Je pense que ce sera bénéfique.
Merci de rester avec nous. Vous aimez nos articles ? Vous voulez voir du contenu plus intéressant ? Soutenez-nous en passant une commande ou en recommandant à vos amis, 30 % de réduction pour les utilisateurs Habr sur un analogue unique de serveurs d'entrée de gamme, que nous avons inventé pour vous : (disponible 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 gratuit jusqu'à l'été lors du paiement pour une période de six mois, vous pouvez commander .
Dell R730xd 2 fois moins cher ? Ici seulement aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99$ ! En savoir plus
Source: habr.com