À propos de la compréhension de Socket, il est grossièrement divisé dans les rubriques suivantes, qu'est-ce que Socket, comment Socket est créé, comment Socket est connecté et envoie et reçoit des données, et comment supprimer Socket Socket.
Qu'est-ce que Socket et comment le créer
Un paquet de données est généré par le programme d'application et entre dans la pile de protocoles pour emballer divers en-têtes.Ensuite, le système d'exploitation appelle le pilote de la carte réseau pour demander au matériel d'envoyer les données à l'hôte opposé. Une illustration générale de l'ensemble du processus est la suivante.
Comme nous le savons tous, la pile de protocoles est en fait une pile de certains protocoles situés dans le système d'exploitation, notamment TCP, UDP, ARP, ICMP, IP , etc. Généralement, un protocole est conçu pour résoudre certains problèmes. Par exemple, TCP est conçu pour transmettre des données en toute sécurité et de manière fiable. UDP est conçu pour avoir de petits paquets et une efficacité de transmission élevée. ARP est conçu pour interroger une adresse physique (Mac) par adresse IP. Adresse, le but de la conception d'ICMP est de renvoyer des messages d'erreur à l'hôte, et le but de la conception IP est de réaliser l'interconnexion d'hôtes à grande échelle.
Les données générées par des applications telles que les navigateurs, les e-mails, les serveurs de transfert de fichiers, etc., seront transmises via le protocole de la couche de transport, et l'application n'établira pas directement de contact avec la couche de transport, mais dispose d'une connexion entre la couche d'application et la couche de transport. Le kit entre les deux, ce kit est Socket.
Dans l'image ci-dessus, l'application comprend Socket et résolveur. La fonction du résolveur est d'initier une requête au serveur DNS pour interroger l'adresse IP cible.
Sous l'application se trouve l'intérieur du système d'exploitation, qui comprend une pile de protocoles, qui est une pile d'une série de protocoles. Sous le système d'exploitation se trouve le pilote de la carte réseau, le pilote de la carte réseau est responsable du contrôle du matériel de la carte réseau et le pilote pilote le matériel de la carte réseau pour effectuer le travail d'envoi et de réception.
A l'intérieur du système d'exploitation, il y a un espace de stockage pour stocker des informations de contrôle, et cet espace de stockage enregistre les informations de contrôle pour contrôler la communication. En fait, l'information de contrôle est l'entité du Socket, ou l'espace mémoire où sont stockées les informations de contrôle est l'entité du socket .
Vous ne savez peut-être pas pourquoi ici, alors j'ai utilisé la commande netstat pour vous montrer ce qu'est un socket.
Nous entrons dans l'invite de commande Windows
netstat -ano
# netstat 用于显示套接字内容 , -ano 是可选选项
# a 不仅显示正在通信的套接字，还显示包括尚未开始通信等状态的所有套接字
# n 显示 IP 地址和端口号
# o 显示套接字的程序 PID
Mon ordinateur affichera les résultats suivants.
Chaque ligne de la figure équivaut à un socket, et chaque colonne est également appelée tuple, donc un socket est un quintuplet (protocole, adresse locale, adresse externe, état, PID). Parfois appelé quad, un quad n'inclut pas de protocole.
Par exemple, dans la première ligne de la figure, son protocole est TCP, l'adresse locale et l'adresse distante sont toutes deux 0.0.0.0, ce qui signifie que la communication n'a pas commencé, l'adresse IP n'a pas encore été déterminée et l'adresse locale port est connu pour être 135, mais le port distant Pas encore connu, l'état à ce moment est LISTENINGque LISTENING indique que l'application a été ouverte et attend d'établir une connexion avec l'hôte distant (pour la transition entre différents états, vous peut lire cet article de l'auteur TCP, youpi est enfin là !! ) Le dernier tuple est PID, l'identifiant du processus, PID est comme notre numéro d'identification, qui peut identifier un processus unique.
Maintenant que vous avez probablement une compréhension de base de Sockets, prenez une gorgée d'eau, faites une pause et continuons à explorer Sockets.
Maintenant, j'ai une question, comment Socket est-il créé ?
Les sockets sont créés avec l'application. Il y a un composant socket dans l'application. Lorsque l'application démarre, elle appelle socket pour demander la création d'un socket, et la pile de protocoles crée un socket en fonction de l'application de l'application : allouez d'abord l'espace mémoire requis par un socket, ce étape Cela revient à préparer un conteneur pour les informations de contrôle, mais seul le conteneur n'a aucun effet pratique, vous devez donc également mettre les informations de contrôle dans le conteneur ; si vous ne demandez pas l'espace mémoire requis pour créer un socket, le contrôle les informations que vous créez ne seront pas disponibles pour stocker, il est donc indispensable d'allouer de l'espace mémoire et de mettre des informations de contrôle . À ce stade, la création du socket est terminée.
Une fois le socket créé, un descripteur de socket est renvoyé à l'application, ce qui équivaut à une plaque signalétique qui distingue les différents sockets. Selon ce descripteur, l'application doit fournir ce descripteur lorsqu'elle confie à la pile de protocoles l'envoi et la réception de données.
prise de connexion
Une fois le socket créé, il servira éventuellement à la transmission et à la réception de données. Avant la transmission et la réception de données, il reste encore une étape connect, à savoir le processus d'établissement d'une connexion. Cette connexion n'est pas une vraie connexion : un tuyau d'eau est inséré entre les deux ordinateurs.
Il s'agit plutôt du processus par lequel un programme d'application est transféré d'un hôte à un autre sur un support réseau via la norme de protocole TCP/IP.
Après la création de la socket, il n'y a pas de données et aucun objet de communication n'est connu. Dans cet état, même si vous laissez l'application cliente déléguer la pile de protocoles pour envoyer des données, elle ne sait pas où les envoyer. Par conséquent, le navigateur doit interroger l'adresse IP du serveur en fonction de l'URL. Le protocole pour ce travail est DNS. Après avoir interrogé l'hôte cible, il indique à la pile de protocoles l'adresse IP de l'hôte cible. À ce stade, le client côté est prêt.
Sur le serveur, un socket doit être créé tout comme le client, mais il ne sait pas non plus qui est le partenaire de communication, nous devons donc laisser le client indiquer au serveur les informations nécessaires pour le client : adresse IP et numéro de port .
Maintenant, les informations nécessaires pour que les deux parties de communication établissent une connexion sont disponibles, et il n'y a qu'un vent du sud-est. Une fois que les deux parties communicantes ont reçu les données, elles ont besoin d'un autre élément 位置à stocker. Cet emplacement est le tampon, qui fait partie de la mémoire. Avec le tampon, les données peuvent être envoyées et reçues.
OK, maintenant le client veut envoyer une donnée au serveur, que faut-il faire ?
Tout d'abord, l'application cliente doit appeler la méthode connect dans la Socketbibliothèque et fournir le descripteur de socket ainsi que l'adresse IP et le numéro de port du serveur.
connect(<描述符>、<服务器IP地址和端口号>)
Ces informations seront transmises au module TCP dans la pile de protocoles, le module TCP encapsulera le paquet de requête, puis le transmettra au module IP pour l'encapsulation de l'en-tête du paquet IP, puis à la couche physique pour l'encapsulation de l'en-tête de trame, puis via le réseau. Le support est transmis au serveur, et le serveur analysera l'en-tête de trame, le module IP et les en-têtes de module TCP pour trouver le socket correspondant. Une fois que le socket aura reçu la requête, il écrira les informations correspondantes et placera le statut Connexion à la place. Une fois le processus de requête terminé, le module TCP du serveur renverra une réponse. Ce processus est le même que celui du client (si vous ne connaissez pas le processus d'encapsulation de l'en-tête du message, vous pouvez lire l'article de l'auteur sur TCP/ Résumé des connaissances de base sur la propriété intellectuelle )
Dans un processus complet de demande et de réponse, les informations de contrôle jouent un rôle très critique (le rôle spécifique sera discuté plus tard).
- SYN est l'abréviation de synchronisation. Le client enverra d'abord un paquet SYN pour demander au serveur d'établir une connexion.
- ACK est le sens correspondant, c'est une réponse à l'envoi d'un paquet SYN.
- FIN signifie terminer, cela signifie que le client/serveur veut mettre fin à la connexion.
En raison de l'environnement réseau complexe et changeant, les paquets de données sont souvent perdus, de sorte que les deux parties doivent se confirmer mutuellement si les paquets de données de l'autre partie sont arrivés lors de la communication, et le critère de jugement est la valeur de ACK.
(L'établissement de la connexion entre les deux parties de communication passera par le processus de poignée de main à trois. Pour une introduction détaillée à la poignée de main à trois, vous pouvez lire l'article de l'auteur TCP Basics )
Lorsque tous les messages d'établissement de la connexion peuvent être émis et reçus normalement, la prise est entrée dans l'état de pouvoir émettre et recevoir A ce moment, on peut considérer que les deux prises sont reliées par une gestion. Bien sûr, le tube n'existe pas réellement. Une fois la connexion établie, l'opération de connexion de la pile de protocoles est terminée, c'est-à-dire que la connexion a été exécutée, et le flux de contrôle est renvoyé à l'application.
Envoyer et recevoir des données
Lorsque le flux de contrôle revient de la connexion à l'application, il entre directement dans l'étape d'envoi et de réception des données. L'opération d'envoi et de réception des données commence lorsque l'application appelle write pour envoyer les données à envoyer à la pile de protocoles, et la pile de protocoles exécute l'opération d'envoi après réception des données. .
La pile de protocoles ne se soucie pas des données transmises par l'application, car ces données seront finalement converties en séquences binaires. Après avoir reçu les données, la pile de protocoles n'enverra pas les données immédiatement, mais placera les données dans le tampon d'envoi . , puis attendez que l'application envoie les données suivantes.
Pourquoi le paquet reçu n'est-il pas envoyé directement, mais placé dans la mémoire tampon ?
Car tant que les données sont envoyées dès qu'elles sont reçues, il est possible d'envoyer un grand nombre de petits paquets, ce qui entraîne une diminution de l'efficacité du réseau. Ainsi, la pile de protocoles doit accumuler des données jusqu'à un certain montant avant de les envoyer. Quant à la quantité de données que la pile de protocoles mettra dans la mémoire tampon, différentes versions et types de systèmes d'exploitation ont des opinions différentes, mais tous les systèmes d'exploitation et types suivront les normes suivantes :
- Le premier élément de jugement est la longueur de données que chaque paquet réseau peut contenir. Le critère de jugement est
MTUqu'il représente la longueur maximale d'un paquet réseau. La longueur maximale inclut l'en-tête, donc si la zone de données est uniquement discutée, la longueur de l'en-tête MTU sera utilisée et la longueur de données maximale résultante est appeléeMSS.
- Un autre critère est le temps. Lorsque les données générées par l'application sont relativement petites et que la pile de protocoles est inefficace pour placer les données dans la mémoire tampon, si elle attend que le MSS les envoie à chaque fois, cela peut entraîner des retards dus au long temps d'attente. Dans ce cas, les données doivent être envoyées même si la longueur des données n'atteint pas le MSS.
La pile de protocoles ne nous dit pas comment équilibrer ces deux facteurs. Si la longueur des données est la priorité, l'efficacité peut être inférieure ; si le temps est la priorité, cela réduira l'efficacité du réseau.
Après un certain temps. . . . . .
Supposons que nous utilisions la règle de longueur finie. À ce moment, le tampon est plein et la pile de protocoles est sur le point d'envoyer des données. La pile de protocoles est sur le point d'envoyer les données, mais constate qu'elle ne peut pas transmettre une si grande quantité de données. (parent) à la fois. Comment faire ?
Dans ce cas, les données dans le tampon d'envoi dépasseront la longueur du MSS, les données dans le tampon d'envoi seront divisées en un paquet avec la taille du MSS, et chaque élément de données divisé sera ajouté avec TCP, IP , l'en-tête Ethernet est ensuite placé dans un paquet réseau séparé.
À ce stade, le paquet réseau est prêt à être envoyé au serveur, mais l'opération d'envoi de données n'est pas terminée, car le serveur n'a pas encore confirmé si le paquet réseau a été reçu. Par conséquent, une fois que le client a envoyé le paquet de données, le serveur doit également confirmer.
Lorsque le module TCP divise les données, il calcule le décalage du paquet réseau.Ce décalage est le nombre d'octets calculés depuis le début des données, et le nombre d'octets calculé sera écrit dans l'en-tête TCP.Le module TCP Il générera également un numéro de série (SYN) du paquet réseau. Ce numéro de série est unique et ce numéro de série est utilisé pour que le serveur le confirme.
Le serveur confirmera le paquet de données envoyé par le client. Une fois la confirmation correcte, le serveur générera un numéro de séquence et un numéro d'accusé de réception (ACK) et les enverra ensemble au client. Une fois que le client aura confirmé, il enverra l'accusé de réception numéro au serveur.
Jetons un coup d'œil au processus de travail réel.
Tout d'abord, le client doit calculer la valeur initiale du numéro de séquence lors de la connexion et envoyer cette valeur au serveur. Ensuite, le serveur calcule le numéro de confirmation à partir de cette valeur initiale et le renvoie au client. La valeur initiale peut être ignorée pendant le processus de communication, donc lorsque le serveur reçoit la valeur initiale, il doit renvoyer le numéro de confirmation pour confirmation. Dans le même temps, le serveur doit également calculer la valeur initiale du numéro de séquence dans le sens du serveur vers le client, et envoyer cette valeur au client. Ensuite, le client doit également calculer le numéro de confirmation en fonction de la valeur initiale envoyée par le serveur et l'envoyer au serveur.À ce stade, l'établissement de la connexion est terminé, puis il peut entrer dans l'étape d'envoi et de réception des données.
Lors de l'étape d'envoi et de réception des données, les deux parties peuvent envoyer des demandes et des réponses en même temps, et les deux parties peuvent également confirmer les demandes en même temps.
Le mécanisme de confirmation de demande est très puissant. Grâce à ce mécanisme, nous pouvons confirmer si le récepteur a reçu un certain paquet, et sinon, le renvoyer. De cette façon, toute erreur dans le réseau peut être détectée même si et corrigée.
Les cartes réseau, les concentrateurs et les routeurs ne disposent pas d'un mécanisme de récupération d'erreur. Une fois qu'une erreur est détectée, le paquet de données est directement supprimé. Le programme d'application ne dispose pas de ce mécanisme et seul le module TCP/IP fonctionne.
En raison de l'environnement réseau complexe et changeant, des paquets de données seront perdus. Par conséquent, il existe certaines règles pour l'envoi de numéros de séquence et de numéros de confirmation. TCP gérera les numéros de confirmation via la fenêtre. Nous ne les répéterons pas dans cet article. Vous pouvez lire cet article de l'auteur TCP Basics à découvrir.
Déconnecter
Lorsque les deux parties communicantes n'ont plus besoin d'envoyer et de recevoir des données, elles doivent se déconnecter. Différentes applications se déconnectent à des moments différents. En prenant le Web comme exemple, le navigateur envoie un message de demande au serveur Web, et le serveur Web renvoie un message de réponse. À ce stade, l'envoi et la réception de données sont terminés. Le serveur peut d'abord initier une réponse de déconnexion, et bien sûr, le client peut l'initier en premier (quel que soit celui qui déconnecte est une décision prise par l'application) et n'a rien à voir avec la pile de protocoles.
Quelle que soit la partie qui initie la demande de déconnexion, la procédure de fermeture de la bibliothèque Socket sera appelée. Prenons l'exemple de la déconnexion du serveur. Le serveur initie une demande de déconnexion et la pile de protocoles génère un en-tête TCP déconnecté, qui consiste en fait à définir le bit FIN, puis à confier au module IP l'envoi de données au client. en même temps, les informations du journal Sockets du serveur sur les déconnexions .
Après avoir reçu la demande FIN du serveur, la pile de protocoles client marquera le socket comme déconnecté, puis le client renverra un numéro de confirmation au serveur, ce qui est la première étape de la déconnexion. Après cela, l'application appelle également read to lire les données. Une fois les données du serveur envoyées, la pile de protocoles informe l'application cliente que les données ont été reçues.
Tant que toutes les données renvoyées par le serveur sont reçues, le client appellera le programme de fermeture pour mettre fin à l'opération d'envoi et de réception. À ce moment, le client générera un FIN et l'enverra au serveur. Après un certain temps , le serveur renverra le numéro ACK. À ce stade, la communication entre le client et le serveur est terminée.
supprimer la prise
Une fois la communication terminée, le socket utilisé pour la communication ne sera plus utilisé et nous pouvons supprimer le socket à ce stade. Cependant, à ce moment, le socket ne sera pas supprimé immédiatement, mais sera supprimé après un certain temps.
Attendre ce laps de temps permet d'éviter une mauvaise opération. La mauvaise opération la plus courante est la perte du numéro de confirmation renvoyé par le client. Quant à la durée d'attente, elle est liée au mode de retransmission des paquets de données.
Lien d'origine : Il s'avère que c'est le Socket !