[Réseau informatique] Résumé des connaissances de base du réseau informatique (recrutement d'automne)

Enterprise 2023-07-26 01:52:57 views: null

Annuaire d'articles

avant-propos

L'auteur du réseau informatique dans le résumé des notes de recrutement d'automne
est écrit par chatgpt, il peut donc y avoir une issue pour certaines réponses (la version 3.5 de GPT a quelques défauts), la plupart des réponses ont été corrigées après avoir fini d'écrire , et s'il y a des divergences, j'espère que tous les étudiants ont souligné.
Manuel de référence : Réseau informatique 7e édition
2023.7.25 Première mise à jour

notes sur le réseau informatique

Cette note se concentre sur les protocoles TCP et HTTP

Quelle est la différence entre TCP et UDP

insérez la description de l'image ici

TCP (Transmission Control Protocol) et UDP (User Datagram Protocol) sont deux protocoles de couche de transport couramment utilisés dans les réseaux informatiques .

TCP est un protocole orienté connexion qui assure une transmission de données fiable. Il assure la transmission fiable des données en utilisant des technologies telles que les numéros de séquence, les numéros de confirmation, les mécanismes de retransmission et le contrôle de la congestion. TCP établit une connexion, transmet les données, garantit l'ordre et l'intégrité des données et libère la connexion une fois la transmission terminée. TCP convient aux applications qui nécessitent une grande fiabilité de transmission de données, telles que la transmission de fichiers, le courrier électronique, la navigation Web, etc.

UDP est un protocole sans connexion qui fournit un transfert de données non fiable. UDP encapsule les données dans des datagrammes, chaque datagramme est indépendant, il n'y a pas d'ordre et il n'y a pas de mécanisme de confirmation et de retransmission. UDP n'a pas besoin d'établir de connexion et envoie les données directement. UDP convient aux applications avec des exigences élevées en temps réel et des exigences de fiabilité des données relativement faibles, telles que la transmission audio et vidéo en temps réel, les jeux en ligne, etc.

la différence:

  1. Connectivité : TCP est un protocole orienté connexion et UDP est un protocole sans connexion. TCP doit établir une connexion avant de communiquer, tandis que UDP envoie les données directement.
  2. Fiabilité : TCP fournit une transmission de données fiable et UDP ne fournit aucune garantie de fiabilité. TCP utilise des mécanismes d'accusé de réception et de retransmission pour assurer l'intégrité et la fiabilité des données, tandis que UDP ne fournit pas ces mécanismes.
  3. Séquence : TCP garantit l'ordre de transmission des données, tandis que UDP ne garantit pas l'ordre des données. TCP trie les paquets pour s'assurer que les données sont reçues dans l'ordre dans lequel elles ont été envoyées, tandis qu'UDP ne trie pas les paquets.
  4. Contrôle de la congestion : TCP dispose d'un mécanisme de contrôle de la congestion qui peut ajuster le débit de transmission des données en fonction des conditions du réseau pour éviter la congestion du réseau. UDP n'a pas de mécanisme de contrôle de congestion et le débit de transmission des paquets de données est déterminé par l'application.
  5. Efficacité de transmission : UDP a une faible surcharge de transmission et une efficacité de transmission élevée, tandis que TCP a une surcharge de transmission importante. TCP doit établir une connexion, maintenir les informations d'état et effectuer une détection d'erreur.Ces surcharges supplémentaires entraîneront une faible efficacité de transmission.
  6. Scénarios d'application : TCP convient aux applications nécessitant une grande fiabilité de transmission de données, telles que le transfert de fichiers, la messagerie électronique, la navigation Web, etc. UDP convient aux applications avec des exigences élevées en temps réel et des exigences de fiabilité des données relativement faibles, telles que la transmission audio et vidéo en temps réel, les jeux en ligne, etc.
  7. Limite de taille : TCP n'a pas de limite de taille de paquet fixe, qui peut être ajustée en fonction des conditions du réseau et des exigences de l'application. La taille des paquets UDP est limitée par l'unité de transmission maximale (MTU) du réseau, généralement 1500 octets.
  8. Nombre de connexions : TCP peut prendre en charge les connexions un à un, un à plusieurs et plusieurs à un, tandis que UDP est généralement utilisé pour les communications simples un à un ou un à plusieurs.

Vous devez choisir d'utiliser TCP ou UDP en fonction des exigences spécifiques de l'application. Si la fiabilité et la séquentialité de la transmission des données sont importantes, vous pouvez choisir TCP. Si le temps réel et l'efficacité de la transmission sont plus importants, vous pouvez choisir UDP.

Quels sont les protocoles de couche supérieure basés sur les deux protocoles TCP et UDP ?

Les protocoles de couche supérieure basés sur le protocole TCP sont :

  1. HTTP (Hypertext Transfer Protocol) : utilisé pour transmettre des données hypertextes entre les navigateurs Web et les serveurs Web, c'est le protocole le plus couramment utilisé pour les applications Web.
  2. FTP (File Transfer Protocol) : utilisé pour transférer des fichiers entre un client et un serveur.
  3. SMTP (Simple Mail Transfer Protocol) : utilisé pour transférer les e-mails entre les clients de messagerie et les serveurs de messagerie.
  4. POP3 (Post Office Protocol Version 3) : utilisé pour recevoir des e-mails d'un serveur de messagerie.
  5. IMAP (Internet Message Access Protocol) : utilisé pour gérer les e-mails entre les clients de messagerie et les serveurs de messagerie.

Les protocoles de couche supérieure basés sur le protocole UDP sont :

  1. DNS (Domain Name System) : utilisé pour résoudre les noms de domaine en adresses IP, permettant aux ordinateurs d'accéder aux ressources Internet via des noms de domaine.

  2. DHCP (Dynamic Host Configuration Protocol) : utilisé pour attribuer automatiquement des adresses IP et d'autres informations de configuration réseau aux ordinateurs.

  3. TFTP (Trivial File Transfer Protocol): Utilisé pour transférer des fichiers entre le client et le serveur, similaire à FTP mais plus simple.

  4. SNMP (Simple Network Management Protocol) : utilisé pour la gestion et la surveillance entre les périphériques réseau.

  5. RTP (Real-time Transport Protocol) : utilisé pour transmettre des données audio et vidéo dans des applications en temps réel.

Dans quels domaines TCP et UDP sont-ils davantage utilisés ?

Domaines d'application de TCP :

  1. Navigation Web : TCP est largement utilisé pour transmettre les données du protocole HTTP afin d'assurer une transmission fiable du contenu Web.
  2. Transfert de fichiers : la fiabilité et la nature séquentielle de TCP en font le choix préféré pour les protocoles de transfert de fichiers tels que FTP et SFTP.
  3. E-mail : la fiabilité et la connectivité de TCP en font la base des protocoles de messagerie tels que SMTP et POP3.
  4. Connexion à distance : TCP est utilisé dans les protocoles de connexion à distance tels que SSH (Secure Shell) pour assurer une connexion fiable des terminaux distants.
  5. Accès à la base de données : TCP est utilisé pour les protocoles d'accès aux bases de données, tels que MySQL, PostgreSQL, etc., afin d'assurer une transmission fiable des données.

Champs d'application d'UDP :

  1. Transmission audio et vidéo en temps réel : la faible latence et l'efficacité de transmission élevée d'UDP en font le protocole préféré pour la transmission audio et vidéo en temps réel, comme la VoIP (Voice over IP) et la visioconférence.
  2. Jeux en ligne : UDP est largement utilisé dans les jeux en ligne car il peut fournir une latence plus faible et une vitesse de transmission plus rapide, et convient aux scénarios de jeu avec des exigences élevées en temps réel.
  3. Transmission de données en temps réel : UDP convient aux applications nécessitant une transmission rapide de données en temps réel, telles que les données de capteurs, les cotations boursières, etc.
  4. Résolution DNS : UDP est utilisé dans le processus de résolution du système de noms de domaine (DNS) pour résoudre rapidement les noms de domaine en adresses IP.
  5. Diffusion et multidiffusion : UDP prend en charge les fonctions de diffusion et de multidiffusion, ce qui le rend adapté à la communication multipoint et à la transmission multimédia en continu.

Quelles technologies TCP utilise-t-il pour obtenir une transmission fiable ? (Comment TCP parvient à une transmission fiable)

Certaines des principales techniques utilisées par TCP pour atteindre la fiabilité :

  1. Numéro de séquence et mécanisme de confirmation : TCP divise les données en petits blocs de données et attribue un numéro de séquence unique à chaque bloc de données. Le récepteur confirme les données reçues en envoyant un segment d'accusé de réception. L'expéditeur détermine quelles données ont été reçues et quelles données doivent être retransmises selon le segment de confirmation reçu.

  2. Délai de retransmission : si l'expéditeur ne reçoit pas de segment d'accusé de réception dans le délai spécifié, il assume la perte de données et renvoie les données. La période de temporisation sera ajustée dynamiquement en fonction des conditions du réseau et des niveaux de congestion.

  3. Fenêtre glissante : TCP utilise un mécanisme de fenêtre glissante pour contrôler la vitesse à laquelle l'expéditeur envoie des données. La taille de la fenêtre glissante dépend de la taille de la mémoire tampon disponible du récepteur et de la congestion du réseau. L'expéditeur ne peut envoyer des données que dans la plage de la fenêtre glissante, et le récepteur met à jour la position de la fenêtre glissante en confirmant le segment.

  4. Contrôle de congestion : TCP utilise des algorithmes de contrôle de congestion pour éviter la congestion du réseau. Il surveille la congestion du réseau en ajustant dynamiquement le taux d'envoi et effectue les ajustements correspondants en fonction des commentaires du réseau.

  5. Réorganisation et réassemblage : TCP peut gérer la réorganisation et le réassemblage des segments du réseau. Il trie et réassemble les segments de message reçus en fonction du numéro de séquence pour garantir l'exactitude des données.

  6. Somme de contrôle de parité : lorsque TCP transmet des données, il calcule la somme de contrôle et ajoute la somme de contrôle au segment de données. Lors de la réception de données, le récepteur recalcule la somme de contrôle et la compare avec la somme de contrôle dans le segment de message pour détecter si les données sont erronées ou endommagées.

Parlez de la retransmission du délai d'attente et du délai d'attente

La retransmission de temporisation et le temporisateur de temporisation sont deux mécanismes importants du protocole TCP pour une transmission de données fiable.

La retransmission du délai d'attente signifie qu'après que l'expéditeur a envoyé des données, s'il ne reçoit pas de message d'accusé de réception (ACK) dans un certain délai, il considérera les données comme perdues et déclenchera un mécanisme de retransmission du délai d'attente. L'expéditeur renverra les données non acquittées pour assurer une transmission fiable des données. Le temps de retransmission des heures supplémentaires est généralement contrôlé par un temporisateur.

Le temporisateur d'expiration est un temporisateur utilisé par l'expéditeur pour conserver l'heure. Lorsque l'expéditeur envoie des données, il démarre une minuterie d'expiration et définit une période d'expiration. Si le message de confirmation n'est pas reçu dans le délai d'expiration, le temporisateur d'expiration sera déclenché, et l'expéditeur considérera les données perdues et déclenchera le mécanisme de retransmission d'expiration. L'heure du temporisateur de temporisation est généralement ajustée dynamiquement par l'algorithme de contrôle de congestion pour s'adapter aux différents environnements réseau. (Si la congestion du réseau est importante, l'expéditeur réglera le délai d'expiration sur une durée plus courte, afin de détecter plus rapidement la perte de paquets et de déclencher le mécanisme de retransmission du délai d'expiration. À l'inverse, si la congestion du réseau est faible, l'expéditeur expirera. est réglé plus longtemps pour éviter les retransmissions inutiles.)

Parlez du contrôle des fenêtres coulissantes

Le contrôle de fenêtre glissante est un mécanisme de contrôle de flux basé sur une fenêtre pour une transmission de données fiable. Il contrôle la transmission des données à travers la fenêtre entre l'expéditeur et le destinataire.

Le principe de la commande par fenêtre glissante est le suivant :

  1. Fenêtre d'envoi : l'expéditeur maintient une fenêtre d'envoi, qui représente la plage de segments de données que l'expéditeur peut envoyer. La taille de la fenêtre d'envoi dépend de la bande passante et du délai du réseau, et peut être ajustée dynamiquement en fonction de l'état du réseau.
  2. Fenêtre de réception : le récepteur maintient une fenêtre de réception, qui représente la plage de segments de données que le récepteur peut recevoir. La taille de la fenêtre de réception dépend de la puissance de traitement du récepteur et de la taille de la mémoire tampon.
  3. Fenêtre coulissante : lors de l'envoi de données, l'expéditeur divise les données en plusieurs segments de données et les envoie au destinataire en séquence. L'expéditeur attendra que le destinataire envoie un message de confirmation, confirmant que les données ont été reçues avec succès. Une fois que le destinataire a confirmé la réception d'un segment de données, l'expéditeur peut faire glisser la fenêtre d'envoi vers l'avant, ce qui permet d'envoyer davantage de données.
  4. Accusé de réception et retransmission : après avoir reçu le segment de données, le récepteur enverra un message d'accusé de réception à l'expéditeur. Si l'expéditeur ne reçoit pas d'accusé de réception dans un certain délai, il considérera le segment de données comme perdu et le retransmettra. L'expéditeur peut retransmettre sélectivement des segments de données perdus sans retransmettre l'intégralité du flux de données.

Le flux de travail du contrôle de fenêtre coulissante est le suivant :

  1. L'expéditeur divise les données en plusieurs segments de données et les envoie séquentiellement en fonction de la taille de la fenêtre.
  2. Après avoir reçu le segment de données, le récepteur le stocke dans le tampon de réception et envoie un message d'accusé de réception à l'expéditeur.
  3. Après avoir reçu le message de confirmation, l'expéditeur fait glisser la fenêtre d'envoi vers l'avant pour permettre l'envoi de plus de données.
  4. Si l'expéditeur ne reçoit pas d'accusé de réception dans un certain délai, il considérera le segment de données comme perdu et le retransmettra.

Grâce au contrôle de la fenêtre coulissante, l'expéditeur et le destinataire peuvent contrôler la transmission des données en fonction de la taille de la fenêtre et de la vitesse de glissement. Ce mécanisme peut améliorer l'efficacité et la fiabilité de la transmission des données tout en s'adaptant aux différents environnements et conditions du réseau.

Pour résumer, le contrôle de la fenêtre glissante contrôle la transmission des données via la fenêtre d'envoi et la fenêtre de réception. L'expéditeur fait glisser la fenêtre en fonction de l'accusé de réception du destinataire, ce qui permet d'envoyer davantage de données. Le récepteur confirme les données reçues avec succès en fonction de la taille de la fenêtre de réception et envoie un message de confirmation à l'expéditeur. Grâce à ce mécanisme, le contrôle de la fenêtre glissante peut améliorer l'efficacité et la fiabilité de la transmission des données.

Les aléas des fenêtres coulissantes trop grandes ou trop petites

Une fenêtre glissante trop grande ou trop petite affectera négativement l'efficacité et la fiabilité de la transmission des données.

  1. La fenêtre coulissante est trop grande :
    • Gaspillage de bande passante : si la fenêtre glissante est trop grande, l'expéditeur enverra en continu un grand nombre de segments de données, et le destinataire peut ne pas être en mesure de traiter et de confirmer ces segments de données à temps. Cela provoque un débordement de la mémoire tampon côté réception, entraînant une perte de données et donc un gaspillage de la bande passante du réseau.
    • Congestion accrue : Si la fenêtre glissante est trop grande, la congestion du réseau augmentera. Lorsqu'un expéditeur envoie successivement un grand nombre de segments de données, le réseau peut devenir encombré, ce qui entraîne une latence accrue et une perte de paquets accrue. Cela réduit l'efficacité et la fiabilité globales de la transmission.
  2. La fenêtre coulissante est trop petite :
    • Faible efficacité de transmission : si la fenêtre glissante est trop petite, l'expéditeur ne peut envoyer qu'une petite quantité de segments de données à chaque fois et doit attendre que le destinataire envoie un message de confirmation avant d'envoyer le prochain lot de données. Cela empêchera l'expéditeur d'utiliser pleinement la bande passante du réseau et réduira l'efficacité de la transmission des données.
    • Délai accru : si la fenêtre glissante est trop petite, cela augmentera le délai de transmission des données. L'expéditeur doit attendre les informations d'accusé de réception du destinataire, ce qui augmentera le temps d'attente de l'expéditeur, prolongeant ainsi le temps de transmission des données.

Par conséquent, la taille de la fenêtre glissante doit être définie raisonnablement en fonction de la bande passante, du délai et de la congestion du réseau. Si la fenêtre est trop grande, cela peut entraîner un gaspillage de bande passante et une congestion accrue ; si la fenêtre est trop petite, cela peut entraîner une transmission inefficace et un retard accru. Avec une taille de fenêtre appropriée, une transmission de données efficace et fiable peut être obtenue.

Comment une fenêtre coulissante permet-elle de contrôler le flux ?

Voici le principe de base de la fenêtre coulissante pour obtenir un contrôle de flux :

  1. L'expéditeur maintient la taille de la fenêtre d'envoi : l'expéditeur contrôle la quantité de données envoyées en maintenant une fenêtre d'envoi. La taille de la fenêtre d'envoi dépend de la bande passante et du délai du réseau, et peut être ajustée dynamiquement en fonction de l'état du réseau.
  2. Le récepteur maintient la taille de la fenêtre de réception : le récepteur contrôle sa propre puissance de traitement et la taille de sa mémoire tampon en maintenant une fenêtre de réception. La taille de la fenêtre de réception indique la quantité de données que le récepteur peut actuellement recevoir.
  3. L'expéditeur envoie des données en fonction de la taille de la fenêtre de réception du destinataire : l'expéditeur détermine la quantité de données pouvant être envoyées en fonction de la taille de la fenêtre de réception du destinataire. L'expéditeur ne peut envoyer des données que dans la fenêtre d'envoi, mais ne peut pas dépasser la taille de la fenêtre de réception.
  4. Le destinataire envoie des informations sur la taille de la fenêtre à l'expéditeur : le destinataire inclura ses informations sur la taille de la fenêtre de réception dans le message de confirmation et l'enverra à l'expéditeur. De cette manière, l'émetteur peut ajuster la taille de sa fenêtre d'émission en fonction de la taille de la fenêtre de réception du récepteur.
  5. Ajuster dynamiquement la taille de la fenêtre d'envoi : l'expéditeur ajuste dynamiquement la taille de sa fenêtre d'envoi en fonction des informations de taille de fenêtre de réception envoyées par le destinataire. Si la fenêtre de réception du récepteur devient plus grande, l'expéditeur peut envoyer plus de données ; si la fenêtre de réception du récepteur devient plus petite, l'expéditeur doit réduire la quantité de données envoyées.

De cette manière, le mécanisme de fenêtre glissante met en œuvre un contrôle de flux, garantissant que le débit de transfert de données entre l'expéditeur et le destinataire s'adapte aux conditions du réseau. L'expéditeur contrôlera la quantité de données envoyées en fonction de la taille de la fenêtre de réception du destinataire, afin d'éviter d'envoyer trop de données et d'empêcher le destinataire de les traiter à temps, améliorant ainsi l'efficacité et la fiabilité de la transmission des données.

Quelle est la technologie de contrôle de congestion de TCP ? Quels sont les algorithmes de contrôle de congestion courants ?

[Le transfert d'image du lien externe a échoué, le site source peut avoir un mécanisme anti-leeching, il est recommandé d'enregistrer l'image et de la télécharger directement (img-dO7etMCJ-1690270230621) (C:\Users\93701\AppData\Roaming\Typora\ typora-user-images\image-20230723144208996.png)]

Le contrôle de la congestion est un mécanisme de gestion du trafic réseau utilisé pour éviter ou réduire l'occurrence de la congestion du réseau dans les réseaux informatiques. La congestion se produit lorsque le trafic de données dans un réseau dépasse la capacité de traitement des liaisons réseau, des commutateurs ou des routeurs, ce qui entraîne une dégradation des performances du réseau, une latence accrue et même une perte de données.

L'objectif du contrôle de la congestion est de maintenir la stabilité et la fiabilité du réseau en limitant le débit de transmission de données de l'expéditeur ou en ajustant l'allocation des ressources du réseau pour garantir que le trafic dans le réseau ne dépassera pas la capacité du réseau.

La fenêtre de congestion (Congestion Window) est un mécanisme utilisé dans le protocole TCP pour contrôler la quantité de données envoyées par l'expéditeur. Il s'agit d'un mécanisme de contrôle de flux introduit pour éviter la congestion du réseau.

La taille de la fenêtre de congestion indique la quantité de données que l'expéditeur peut envoyer. Initialement, la taille de la fenêtre de congestion est relativement petite et l'expéditeur ne peut envoyer qu'une petite quantité de données. Avec le fonctionnement normal du réseau et la transmission réussie des paquets de données, la fenêtre de congestion augmentera progressivement et l'expéditeur pourra envoyer plus de données.

Les techniques de contrôle de la congestion utilisées par TCP comprennent principalement le démarrage lent, l'évitement de la congestion, la retransmission rapide et la récupération rapide .

  1. Démarrage lent : lorsque la connexion TCP est établie pour la première fois, l'expéditeur définit la fenêtre de congestion initiale sur une petite valeur, puis double la taille de la fenêtre de congestion à chaque fois qu'un temps d'aller-retour (RTT) passe pour augmenter progressivement le nombre d'expéditeurs. Le débit d'émission jusqu'à atteindre le point de congestion du réseau ou la valeur maximale de la fenêtre de congestion. (Augmentez la fenêtre d'envoi de petite à grande, continuez d'essayer)

  2. Évitement de la congestion : après la fin de la phase de démarrage lent, l'expéditeur entrera dans la phase d'évitement de la congestion. À ce stade, l'expéditeur n'augmente la taille de la fenêtre de congestion que d'un RTT à chaque fois, de manière à augmenter lentement le débit d'envoi pour éviter un trafic de données excessif entrant dans le réseau. (Au lieu de doubler la croissance du démarrage lent, il appartient à la croissance linéaire, "augmentation supplémentaire")

  3. Retransmission rapide : lorsque l'expéditeur reçoit trois accusés de réception répétés (ACK) d'affilée, il pensera qu'un paquet est perdu, et non en raison de la congestion du réseau . L'expéditeur retransmet immédiatement les paquets perdus sans attendre le déclenchement du temporisateur. (La retransmission rapide peut augmenter le débit de l'ensemble du réseau d'environ 20 %)

  4. Récupération rapide : après une retransmission rapide, l'expéditeur entrera dans la phase de récupération rapide. Dans cette phase, l'expéditeur divise par deux la fenêtre de congestion et définit la taille de la fenêtre de congestion à la moitié de ce qu'elle était avant de perdre des paquets. Ensuite, l'expéditeur continue d'augmenter progressivement la taille de la fenêtre de congestion avec l'algorithme d'évitement de congestion.

Les algorithmes courants de contrôle de la congestion incluent :

  • Algorithme Tahoe : le premier algorithme de contrôle de la congestion TCP, uniquement un démarrage lent et une phase d'évitement de la congestion.

  • Algorithme Reno : basé sur l'algorithme Tahoe, des mécanismes de récupération rapide et de retransmission rapide sont ajoutés.

  • Nouvel algorithme Reno : l'algorithme Reno a été amélioré et un mécanisme de récupération et de retransmission rapide plus flexible a été ajouté.

  • Algorithme cubique : basé sur la fonction carrée de la fenêtre de congestion, il a une meilleure adaptabilité et équité du réseau.

  • Algorithme BBR : basé sur l'estimation de la bande passante et du temps d'aller-retour, il peut ajuster le taux d'envoi avec plus de précision et améliorer le débit du réseau.

La différence entre le contrôle de flux TCP et le contrôle de congestion

Le contrôle de flux TCP et le contrôle de congestion sont deux mécanismes différents dans le protocole TCP, et leurs objectifs et méthodes de mise en œuvre sont également différents.

Le contrôle de flux consiste à garantir que le destinataire peut traiter les données de l'expéditeur et à empêcher l'expéditeur d'envoyer trop de données afin que le destinataire ne puisse pas les traiter à temps. Le contrôle de flux est effectué entre l'expéditeur et le destinataire, le destinataire envoyant des informations sur la taille de la fenêtre à l'expéditeur, indiquant à l'expéditeur l'espace dont il dispose dans le tampon de réception. L'expéditeur contrôle le débit d'envoi des données en fonction de la taille de la fenêtre du destinataire pour s'assurer que le destinataire peut traiter les données à temps.

Le contrôle de la congestion est un mécanisme introduit pour éviter la congestion du réseau. Le contrôle de la congestion est effectué dans le réseau et le débit d'envoi de l'expéditeur est ajusté en surveillant le degré de congestion du réseau et les informations de retour du récepteur. Lorsque le réseau est encombré, le contrôle de la congestion réduira le débit d'envoi de l'expéditeur afin de réduire la charge sur le réseau et d'empêcher une nouvelle aggravation de la congestion. L'algorithme de contrôle de congestion ajustera dynamiquement la taille de la fenêtre de congestion de l'expéditeur en fonction de la congestion du réseau pour obtenir un contrôle de flux raisonnable.

Pour résumer, le contrôle de flux est le contrôle permettant de s'assurer que le récepteur peut traiter les données, et le contrôle de congestion est le contrôle permettant d'éviter la congestion du réseau. Le contrôle de flux est effectué entre l'expéditeur et le destinataire tandis que le contrôle de la congestion est effectué dans le réseau. Les deux visent à assurer la transmission fiable des données et l'optimisation des performances du réseau, mais leurs objectifs et leurs méthodes de mise en œuvre sont différents.

Parlez du principe de fonctionnement de l'établissement de la connexion TCP

TCP (Transmission Control Protocol) est un protocole de couche de transport fiable et orienté connexion, qui joue un rôle important dans la communication réseau. Voici une brève introduction au fonctionnement de TCP :

  1. Établir une connexion : avant la communication TCP, le client et le serveur doivent établir une connexion via une poignée de main à trois. Tout d'abord, le client envoie un message SYN (synchronisation) au serveur, et le serveur répond un message SYN+ACK (synchronisation + confirmation) au client après l'avoir reçu, et enfin, le client répond un message ACK (confirmation) au serveur. De cette façon, la connexion est établie. (poignée de main à trois)
  2. Transfert de données : une fois la connexion établie, le client et le serveur peuvent commencer à transférer des données. TCP utilise un mécanisme de fenêtre glissante pour le contrôle de flux et le contrôle de congestion. L'expéditeur divise les données en petits morceaux appelés segments TCP et les envoie au destinataire. Le destinataire confirmera les données reçues et l'expéditeur pourra ajuster le débit d'envoi en fonction des informations de confirmation du destinataire.
  3. Confirmation et retransmission : Après avoir reçu les données, le destinataire enverra un message de confirmation à l'expéditeur, indiquant qu'elles ont été reçues avec succès. Si l'expéditeur ne reçoit pas le message de confirmation dans un certain délai, il considérera les données comme perdues et les retransmettra. Le récepteur peut utiliser le numéro de séquence pour vérifier les segments de données manquants et les éliminer pour éviter un traitement répété.
  4. Fermez la connexion : Lorsque la transmission des données est terminée ou que la connexion doit être interrompue, la connexion peut être fermée par une prise de contact à quatre voies. Tout d'abord, une partie envoie un message FIN (fin) à l'autre partie, et l'autre partie répond avec un message ACK pour confirmation après l'avoir reçu. Ensuite, l'autre partie envoie un message FIN à la première partie, et la première partie répond avec un message ACK pour indiquer la confirmation après l'avoir reçue. Enfin, la connexion est fermée. (agite quatre fois)

Le principe de fonctionnement de TCP assure la transmission fiable et la séquentialité des données, et dispose également de mécanismes de contrôle de flux et de contrôle de congestion pour répondre aux exigences de transmission dans différents environnements réseau. Cela fait de TCP l'un des protocoles de transport les plus utilisés sur Internet.

Concentrez-vous sur la poignée de main à trois voies et le processus d'onde à quatre voies de TCP

Lorsqu'une connexion TCP est établie, une poignée de main à trois est requise ; lorsque la connexion est fermée, quatre poignées de main sont nécessaires. Ensuite, je vais me concentrer sur l'explication du processus de la poignée de main à trois et de la poignée de main à quatre voies de TCP.

  1. Poignée de main à trois :

    a. Étape 1 : Le client envoie un message SYN (synchronisation) au serveur, qui contient un numéro de séquence initial (seq) . Ce message SYN équivaut au signal indiquant que le client initie une demande de connexion, indiquant que le client souhaite établir une connexion avec le serveur.

    b. Étape 2 : Après avoir reçu le message SYN, le serveur répondra par un message SYN+ACK (synchronisation + confirmation), qui contient le numéro de confirmation (ack) et le numéro de séquence initial du serveur (seq).

    c. Étape 3 : Après avoir reçu le message SYN+ACK du serveur, le client enverra un message ACK (confirmation), qui contient le numéro de confirmation (ack), indiquant que la connexion a été établie.

    De cette manière, grâce à la prise de contact à trois voies, le client et le serveur confirment mutuellement la capacité d'envoi et de réception et le numéro de série initial, et une connexion fiable bidirectionnelle est établie.

  2. Prise de contact à quatre voies : a. Étape 1 : Lorsque le client souhaite fermer la connexion, il enverra un message FIN (fin) au serveur. b. Étape 2 : Après avoir reçu le message FIN, le serveur enverra un message ACK en guise de confirmation. c. Étape 3 : Le serveur envoie un message FIN au client, indiquant que le serveur ferme également la connexion. d. Étape 4 : Après avoir reçu le message FIN du serveur, le client envoie un message ACK en guise de confirmation.

    De cette façon, en agitant quatre fois, les deux parties confirment l'intention de fermeture de l'autre partie et terminent le processus de fermeture de la connexion.

Au cours de la poignée de main à trois voies et de la poignée de main à quatre voies, chaque étape nécessite que les deux parties envoient et reçoivent des informations de confirmation pour garantir la fiabilité et la séquence de la connexion. L'échange de messages et de numéros de confirmation dans ces processus vise à garantir que les deux parties peuvent correctement comprendre le statut et les intentions de l'autre, afin de garantir la fiabilité de l'établissement et de la fermeture de la connexion. (Les deux images ci-dessous sont très importantes, et l'état à l'intérieur est également important)

[Le transfert d'image du lien externe a échoué, le site source peut avoir un mécanisme de lien antivol, il est recommandé d'enregistrer l'image et de la télécharger directement (img-Z1iG7e2e-1690270230621) (C:\Users\93701\AppData\Roaming\Typora \typora-user-images\image-20230723112552073.png)]

L'accusé de réception minuscule est le numéro de séquence et l'accusé de réception majuscule est le drapeau.

SYN=1 indique qu'un indicateur de numéro de séquence synchrone (SYN) est défini sur 1.

Le processus de prise de contact dans la figure est généralement le suivant :

  1. Le client envoie un paquet TCP au serveur avec l'indicateur SYN défini sur 1 et l'indicateur ACK (accusé de réception) défini sur 0. En même temps, le client génère un numéro de séquence aléatoire, disons x.

  2. Une fois que le serveur a reçu le paquet de données SYN=1, il répond au client avec un paquet de données dans lequel les drapeaux SYN et ACK sont définis sur 1. Le serveur génère également un numéro de séquence aléatoire, disons y, et définit le numéro de confirmation sur x+1.

  3. Après avoir reçu les paquets de données SYN=1 et ACK=1 du serveur, le client envoie un paquet de données de confirmation au serveur, dans lequel l'indicateur SYN est 0, l'indicateur ACK est 1 et le numéro de confirmation est défini sur y+1. Le numéro de séquence doit toujours être x+1 (dans la deuxième poignée de main, le numéro de confirmation du serveur est x+1, indiquant que le numéro de séquence du prochain octet qu'il s'attend à recevoir est x+1)

[Le transfert d'image du lien externe a échoué, le site source peut avoir un mécanisme anti-leeching, il est recommandé d'enregistrer l'image et de la télécharger directement (img-baVz2K76-1690270230621) (C:\Users\93701\AppData\Roaming\Typora\ typora-user-images\image-20230723121127429.png)]

L'agitation à quatre mains fait référence au processus dans lequel la communication entre les deux parties se termine lorsque la connexion TCP est fermée. Voici le processus en quatre vagues et les changements dans les domaines connexes :

  1. Première vague:
    • La partie fermante active (Client) envoie un segment de message avec le drapeau FIN défini sur 1 à la partie fermante passive (Serveur). FIN=1
    • Le numéro de séquence dans le segment de message indique le numéro de séquence du dernier octet envoyé par la partie fermante active. suite=u
  2. Deuxième vague :
    • Après avoir reçu le segment de message de la première onde manuelle, la partie de fermeture passive envoie un segment de message avec le bit d'indicateur ACK défini sur 1 à la partie de fermeture active, indiquant que la demande de fermeture a été reçue. ACK=1
    • Le numéro d'accusé de réception dans le segment de message indique le numéro de séquence de l'octet suivant que la partie de fermeture passive s'attend à recevoir. ack=u+1,seq=v
  3. Troisième vague :
    • La partie fermante passive envoie un segment de message avec l'indicateur FIN défini sur 1 à la partie fermante active, indiquant qu'elle est également prête à fermer la connexion. FIN=1, ACK=1 ack=u+1
    • Le numéro de séquence dans le segment de message indique le numéro de séquence du dernier octet envoyé par la partie de fermeture passive. seq=w ( la raison pour laquelle il est différent du second seq=v est que le serveur a peut-être envoyé des données, mais que le côté client a cessé d'envoyer des données )
  4. Quatrième vague :
    • Une fois que le correspondant de fermeture actif a reçu le segment de message agité pour la troisième fois, il envoie un segment de message avec le drapeau ACK défini sur 1 au correspondant de fermeture passif, indiquant que la demande de fermeture a été reçue. ACK=1
    • Le numéro d'accusé de réception dans le segment indique le numéro de séquence de l'octet suivant que la partie proche active s'attend à recevoir. ack=w+1,seq=u+1

Parlez du processus de transition d'état de la poignée de main à trois voies et de la vague à quatre voies de TCP (quels sont les états)

Processus de prise de contact à trois : (Pour plus de détails, veuillez vous référer à la figure ci-dessous)

[Le transfert d'image du lien externe a échoué, le site source peut avoir un mécanisme anti-leeching, il est recommandé de sauvegarder l'image et de la télécharger directement (img-uMoc55wm-1690270230622) (C:\Users\93701\AppData\Roaming\Typora\ typora-user-images\image-20230723112552073.png)]

  1. Etat initial : l'extrémité client est à l'état FERMÉ et l'extrémité serveur est à l'état ÉCOUTE.

  2. Première prise de contact : le client envoie un segment de message avec l'indicateur SYN défini sur 1 au serveur et sélectionne un numéro de séquence initial (ISN) en même temps.

    • L'état du client passe à SYN_SENT, attendant la confirmation du serveur.

  3. La deuxième poignée de main : après avoir reçu le segment de message SYN du client, le serveur envoie un segment de message avec le bit d'indicateur ACK de 1 au client, et envoie également un segment de message avec le bit d'indicateur SYN de 1 au client pour confirmer la réception du client SYN et choisissez votre propre numéro de séquence initial.

    • L'état du serveur passe à SYN_RCVD.

  4. La troisième prise de contact : Après avoir reçu le segment de message SYN/ACK du serveur, le client envoie un segment de message avec le bit d'indicateur ACK défini sur 1 au serveur pour confirmer la réception du SYN/ACK du serveur.

    • L'état du client passe à ÉTABLI.

  5. Après avoir reçu le segment ACK du client, le serveur entre également dans l'état ESTABLISHED.

    • L'état du serveur passe à ESTABLISHED.

Le processus d'agiter quatre fois : (Pour plus de détails, veuillez vous reporter à la figure ci-dessous)

[Le transfert d'image du lien externe a échoué, le site source peut avoir un mécanisme anti-leeching, il est recommandé d'enregistrer l'image et de la télécharger directement (img-CaRvbyiU-1690270230622) (C:\Users\93701\AppData\Roaming\Typora\ typora-user-images\image-20230723121127429.png)]

  1. État initial : le client et le serveur sont tous deux à l'état ÉTABLI.
  2. Première vague : le client envoie un segment de message avec l'indicateur FIN défini sur 1 au serveur, indiquant qu'il n'a pas de données à envoyer, mais qu'il peut toujours recevoir des données.
    • L'état du client passe à FIN_WAIT_1.
  3. La deuxième vague : après avoir reçu le segment FIN du client, le serveur envoie un segment avec le drapeau ACK défini sur 1 au client pour confirmer la réception du FIN du client.
    • L'état du serveur devient CLOSE_WAIT et l'état du client devient FIN_WAIT_2.
  4. La troisième vague : le serveur envoie un segment de message avec le drapeau FIN mis à 1 au client, indiquant qu'il n'a pas de données à envoyer.
    • L'état du serveur passe à LAST_ACK.
  5. Quatrième vague : Après avoir reçu le segment FIN du serveur, le client envoie un segment avec le drapeau ACK défini sur 1 au serveur pour confirmer la réception du FIN du serveur.
    • L'état du client passe à TIME_WAIT et passe à l'état CLOSED après avoir attendu deux fois la durée de vie de segment la plus longue (MSL).
  6. Après avoir reçu le segment ACK du client, le serveur entre également dans l'état CLOSED.
    • L'état du serveur passe à FERMÉ.

En ce qui concerne l'état de la connexion TCP, il existe des états communs :

  1. CLOSED : L'état initial ou l'état dans lequel la connexion a été fermée. Dans cet état, la connexion TCP n'a pas été établie ou a été fermée.
  2. LISTEN (écoute): Le serveur attend l'état du client pour se connecter. Dans cet état, le serveur écoute sur le port spécifié et est prêt à accepter les demandes de connexion des clients.
  3. SYN_SENT (envoi synchrone) : le client attend la confirmation du serveur après avoir envoyé le segment SYN. Dans cet état, le client a envoyé une demande de connexion et attend une réponse du serveur.
  4. SYN_RECEIVED (reçu de manière synchrone) : l'état du serveur qui envoie son propre segment de message SYN après avoir reçu le segment de message SYN du client. Dans cet état, le serveur a reçu la demande de connexion du client et a envoyé sa propre confirmation de connexion.
  5. ESTABLISHED (établi) : la connexion a été établie et les deux parties peuvent effectuer la transmission de données. Dans cet état, la connexion entre le client et le serveur a été établie avec succès et la transmission de données peut être effectuée.
  6. FIN_WAIT_1 (termination wait 1) : le client attend la confirmation du serveur après l'envoi du segment FIN. Dans cet état, le client a envoyé une demande de terminaison de connexion et attend un accusé de réception du serveur.
  7. CLOSE_WAIT (fermer l'attente) : le serveur attend pour fermer la connexion après avoir reçu le segment FIN du client. Dans cet état, le serveur a reçu la demande de terminaison de connexion du client et attend de fermer la connexion.
  8. FIN_WAIT_2 (termination wait 2) : le client attend que le serveur envoie un segment FIN. Dans cet état, le client a reçu la demande de terminaison de connexion du serveur et attend que le serveur envoie sa propre demande de terminaison de connexion.
  9. LAST_ACK (confirmation finale) : Le serveur attend la confirmation du client après avoir envoyé le segment FIN. Dans cet état, le serveur a envoyé une demande de terminaison de connexion et attend un accusé de réception du client.
  10. TIME_WAIT (temps d'attente) : la connexion a été fermée et elle passe à l'état FERMÉ après avoir attendu un certain temps. Dans cet état, le client attend un certain temps pour s'assurer que tous les segments ont été reçus avant d'entrer dans l'état FERMÉ.

Qu'est-ce que MSL ? TIME_WAIT Pourquoi attendre 2 MSL ici ?

MSL (Maximum Segment Lifetime) fait référence à la durée de vie de segment la plus longue du protocole TCP. Il représente le temps de survie maximal d'un segment TCP dans le réseau.

Dans le protocole TCP, chaque segment de message est divisé en plusieurs paquets de données plus petits pour la transmission. Ces paquets de données sont transmis via divers périphériques réseau et liens du réseau. En raison de facteurs tels que le retard, la congestion et la défaillance du routeur dans le réseau, la transmission des segments de message peut rencontrer certains problèmes, tels que la perte, la répétition ou le hors séquence. Afin de s'assurer que le segment de message peut être normalement transmis et reçu correctement dans le réseau, le protocole TCP stipule un concept de durée de vie de segment de message la plus longue (MSL). MSL indique la durée de vie maximale d'un paquet dans le réseau. Passé ce délai, le paquet sera rejeté. La valeur spécifique de MSL est déterminée en fonction des caractéristiques et de la configuration du réseau, généralement entre quelques minutes et des dizaines de minutes. Le temps d'attente de 2MSL dans le protocole TCP est de s'assurer que tous les segments retardés sont rejetés pendant cette période et d'éviter les interférences avec les connexions suivantes.

Pourquoi attendre l'heure 2MSL ?

Il y a plusieurs raisons de choisir d'attendre 2 fois le MSL :

  1. Assurez-vous que tous les segments retardés du réseau sont ignorés : Attendre 2 fois le MSL peut être plus prudent en garantissant que tous les segments retardés du réseau ont disparu. Cela évite toute confusion et erreur possibles. (L'ancien segment de demande de connexion n'apparaîtra pas dans la prochaine nouvelle connexion)
  2. Evitez toute confusion entre les nouvelles connexions et les anciennes connexions : si vous n'attendez que 1 fois le temps MSL, il peut encore y avoir des segments retardés sur le réseau pendant ce temps. S'il redémarre et établit une nouvelle connexion avec la même adresse IP et le même numéro de port pendant cette période, ces segments retardés peuvent être attribués à tort à la nouvelle connexion, entraînant une confusion des données et des erreurs. Attendre 2 fois le MSL garantit que tous les segments de l'ancienne connexion sont supprimés avant que la nouvelle connexion ne soit établie.
  3. Compatible avec différents périphériques et implémentations dans le réseau : différents périphériques réseau et implémentations TCP peuvent avoir différentes méthodes de traitement pour la durée de survie du segment de message. Certains appareils peuvent supprimer des segments plus tôt, tandis que d'autres peuvent conserver des segments plus longtemps. Le temps d'attente pour 2x le MSL s'adapte mieux aux différences entre les appareils et les implémentations, garantissant des connexions fiables et correctes.
  4. Situation réseau non fiable : Si l'hôte ferme la connexion immédiatement après avoir attendu 1 fois le MSL, alors pendant cette période, si les données de retransmission côté serveur sont retardées ou perdues dans le réseau , l'hôte ne pourra pas recevoir la retransmission données (segment FIN+ACK), ce qui peut entraîner une perte de données ou une erreur. Attendre 2 fois le MSL peut fournir une fenêtre de réception plus longue pour s'assurer que l'hôte peut recevoir les données de retransmission du délai d'expiration du serveur . Cela peut augmenter la fiabilité de la connexion et éviter les pertes de données ou les erreurs.

Qu'est-ce que cela signifie que chaque octet du flux d'octets établi par TCP doit être numéroté dans l'ordre ? (Le rôle du numéro de série) (La méthode de maintien de l'ordre du flux d'octets)

Le protocole TCP utilise des numéros de série pour numéroter les flux d'octets afin d'assurer la transmission ordonnée et la fiabilité des données.

Une fois la connexion TCP établie, l'expéditeur divise les données à envoyer en plusieurs segments de données (un segment de données est un segment TCP) et attribue un numéro de séquence à chaque segment de données. Le numéro de séquence est un entier de 32 bits utilisé pour identifier la position du segment de données dans le flux d'octets. Chaque segment de données a un numéro de séquence de départ, qui indique la position du premier octet dans le segment de données dans le flux d'octets entier. Les segments de données suivants incrémentent tour à tour les numéros de séquence.

Par exemple:

Supposons que l'expéditeur veuille envoyer un flux de données contenant 100 octets.

L'expéditeur divise le flux de données en segments de données, qui sont numérotés séquentiellement. Supposons que la taille de chaque segment de données soit de 10 octets, alors il y aura 10 segments de données.

Le numéro de séquence de départ du premier segment de données est 1, indiquant la position du premier octet dans le flux d'octets entier. Le numéro de séquence de départ du deuxième segment de données est 11, le numéro de séquence de départ du troisième segment de données est 21, et ainsi de suite.

Lorsque l'expéditeur envoie des données, chaque segment de données aura un numéro de séquence. Le récepteur confirme le segment de données reçu conformément au numéro de séquence et notifie à l'expéditeur le numéro de séquence du prochain segment de données reçu attendu.

En supposant que le récepteur a reçu avec succès le segment de données avec le numéro de séquence 1 et le segment de données avec le numéro de séquence 11, le récepteur enverra un message d'accusé de réception avec le numéro de confirmation 21 à l'expéditeur, indiquant le prochain segment de données prévu pour être reçu Le numéro de séquence de départ est 21.

Si l'expéditeur constate que le segment de données avec le numéro de séquence 21 est perdu lors de l'envoi du segment de données, il retransmettra conformément au numéro de confirmation reçu pour assurer une transmission de données fiable.

Quel est le numéro de confirmation dans TCP ? quel est l'effet?

Le numéro de confirmation sert à deux fins :

  1. Indique un segment de données qui a été reçu avec succès : le numéro d'accusé de réception indique le numéro de séquence du dernier octet d'un segment de données qui a été reçu avec succès par le récepteur. Grâce au numéro de confirmation, l'expéditeur peut savoir quelles données ont été correctement reçues par le destinataire. (Par exemple, si le numéro de confirmation est N, cela signifie que toutes les données jusqu'à N-1 ont été correctement reçues)
  2. Indique le numéro de séquence du prochain segment de données que l'on s'attend à recevoir : la valeur du numéro d'accusé de réception est généralement le numéro de séquence du dernier octet du segment de données reçu plus 1 . Après avoir reçu le message de confirmation, l'expéditeur peut déterminer le numéro de séquence du segment de données suivant à envoyer selon le numéro de confirmation. ( Le numéro de série initial du segment de données envoyé par l'expéditeur est 1001 et la longueur est de 200 octets. Le récepteur reçoit avec succès le segment de données et espère recevoir le segment de données suivant avec le numéro de série 1201. Dans ce cas, le récepteur envoie le segment de données à l'expéditeur Le paquet ACK envoyé doit contenir un numéro d'accusé de réception de 1201. )

Que contient l'en-tête d'un segment TCP ?

[Le transfert d'image du lien externe a échoué, le site source peut avoir un mécanisme anti-leeching, il est recommandé de sauvegarder l'image et de la télécharger directement (img-uopPAgt4-1690270230622) (C:\Users\93701\AppData\Roaming\Typora\ typora-user-images\image-20230723114411399.png)]

L'en-tête d'un segment TCP contient les champs suivants :

  1. Numéro de port source (Source Port) : champ de 16 bits, indiquant le numéro de port de l'expéditeur.
  2. Port de destination (Destination Port) : champ de 16 bits, indiquant le numéro de port du récepteur.
  3. Numéro de séquence : un champ de 32 bits utilisé pour numéroter les octets envoyés afin d'assurer la transmission ordonnée des données.
  4. Numéro d'accusé de réception : champ de 32 bits, valide uniquement lorsque le drapeau ACK est à 1, indiquant le numéro de séquence du prochain octet que l'on s'attend à recevoir.
  5. Décalage de données (Data Offset) : champ de 4 bits, indiquant la longueur de l'en-tête TCP, en unités de 4 octets. La valeur maximale est 15, donc la longueur maximale de l'en-tête TCP est de 60 octets.
  6. Réservé : champ de 6 bits, réservé pour une utilisation future, actuellement défini sur 0.
  7. Bit de contrôle (drapeaux) : il y a 6 bits d'indicateur au total, à savoir : URG (bit valide de pointeur urgent), ACK (bit valide de numéro d'accusé de réception), PSH (le récepteur doit transmettre les données à la couche application dès que possible) , RST (bit de réinitialisation de connexion), SYN (bit de numéro de séquence de synchronisation) et FIN (bit de fin de connexion).
  8. Taille de la fenêtre (Window Size) : champ de 16 bits, indiquant la taille de la fenêtre de réception de l'expéditeur, utilisé pour le contrôle de flux.
  9. Somme de contrôle (Checksum) : champ de 16 bits, utilisé pour détecter s'il y a une erreur dans l'en-tête et les données TCP.
  10. Pointeur urgent (Urgent Pointer) : champ de 16 bits, valide uniquement lorsque le drapeau URG est à 1, indiquant le décalage d'octet des données urgentes.
  11. Options (Options) : champ de longueur variable utilisé pour étendre les fonctions TCP, telles que la confirmation de sélection, l'horodatage, etc.
  12. Remplissage : utilisé pour s'assurer que la longueur de l'en-tête TCP est un multiple de 4 octets.

Parlez du drapeau FIN Drapeau ACK Drapeau SYN

Indicateur FIN (Finish) : utilisé pour indiquer que l'expéditeur a fini d'envoyer des données et demande de fermer la connexion. Lorsqu'une partie d'une connexion TCP envoie un segment avec l'indicateur FIN défini sur 1, cela signifie que la partie n'envoie plus de données, mais peut toujours recevoir des données.

Drapeau ACK (accusé de réception) : utilisé pour indiquer que le champ du numéro d'accusé de réception (numéro d'accusé de réception) dans le segment de message est valide. Lorsque le drapeau ACK est mis à 1, le champ du numéro d'accusé de réception est considéré comme valide. Lors de l'établissement et de la fermeture de la connexion TCP, le drapeau ACK est utilisé pour confirmer la réception du segment de message envoyé par l'autre partie.

Indicateur SYN (Synchronize) : utilisé pour la synchronisation lors de l'établissement d'une connexion TCP. Lorsqu'une partie d'une connexion TCP envoie un segment de message avec l'indicateur SYN défini sur 1, cela signifie que la partie demande à établir une connexion et spécifie le numéro de séquence initial (numéro de séquence).

La taille du bit d'indicateur est d'un bit (bit), c'est-à-dire qu'un seul bit binaire est occupé

Qu'est-ce que SACK ?

SACK fait référence à Selective Acknowledgement (accusé de réception sélectif), qui est une extension facultative du protocole TCP. SACK permet au récepteur de signaler les segments de données manquants à l'expéditeur, améliorant ainsi la fiabilité et les performances de TCP.

Dans le protocole TCP traditionnel, lorsque le destinataire reçoit des segments de données dans le désordre, il ne peut envoyer qu'un accusé de réception cumulatif à l'expéditeur, indiquant à l'expéditeur quel segment de données il a reçu et s'attendant à ce que l'expéditeur retransmette le segment de données toutes les données après cela. Il y a un problème avec cette méthode, c'est-à-dire que si plusieurs segments de données sont perdus, l'expéditeur doit retransmettre la totalité de la fenêtre perdue, ce qui entraîne un gaspillage de ressources réseau et une augmentation du délai.

SACK résout ce problème en introduisant un mécanisme de confirmation sélective. Le récepteur peut signaler à l'expéditeur la plage spécifique de segments de données manquants, et pas seulement le dernier segment de données reçu. De cette façon, l'expéditeur peut retransmettre uniquement les segments de données manquants sans retransmettre la fenêtre entière.

SACK fonctionne comme suit :

  1. Après avoir reçu le segment de données dans le désordre, le récepteur enregistrera la plage du segment de données perdu.
  2. Le récepteur inclut l'option SACK dans le message d'accusé de réception, indiquant la plage de segments de données perdus par l'expéditeur.
  3. Après avoir reçu l'option SACK, l'expéditeur peut retransmettre de manière sélective en fonction de la plage de segments de données perdus.

En utilisant SACK, TCP peut gérer plus efficacement les segments de données perdus, réduire les retransmissions inutiles et améliorer le débit et les performances du réseau. SACK est une extension TCP facultative qui doit être prise en charge par l'expéditeur et le destinataire pour prendre effet.

Qu'est-ce que TCP keepalive ?

Keepalive est un protocole réseau ou un mécanisme permettant de détecter et de maintenir la vivacité des connexions réseau. Il confirme si l'autre partie est toujours active en envoyant périodiquement de petits paquets de sonde, afin d'éviter que la connexion ne soit fermée en raison d'une absence de transmission de données pendant une longue période. (C'est-à-dire que le serveur peut l'utiliser pour déterminer si le client est déconnecté et connecté)

Dans le protocole TCP, Keepalive est implémenté en envoyant périodiquement des paquets de détection Keepalive sur des connexions inactives. Lorsque la connexion TCP est inactive, c'est-à-dire lorsqu'il n'y a pas de transmission de données, le mécanisme Keepalive enverra périodiquement des paquets de détection à l'autre partie. Si l'autre partie ne répond pas dans un certain délai, la connexion sera considérée comme invalide et la connexion sera fermée. Cela peut éviter une connexion invalide à long terme en raison d'une panne de réseau ou d'une sortie anormale de l'autre partie.

L'utilisation de keepalives peut améliorer la fiabilité et la stabilité des connexions réseau. Il peut être utilisé pour détecter la disponibilité de la connexion, empêcher la fermeture de la connexion en raison d'un temps d'inactivité trop long et détecter une défaillance du réseau ou une sortie anormale de l'autre partie.

Il convient de noter que le mécanisme Keepalive doit être configuré et activé dans le système d'exploitation ou l'application. Différents systèmes d'exploitation et applications peuvent avoir différents paramètres keepalive et paramètres par défaut, qui peuvent être configurés et ajustés en fonction de besoins spécifiques.

Que signifie le mécanisme du rythme cardiaque ?

Heartbeat (battement de cœur) est un mécanisme permettant de maintenir les connexions actives, similaire à keepalive. Il confirme la vivacité des parties communicantes en envoyant périodiquement de petits messages de sondage.

Heartbeat est généralement implémenté au niveau de la couche application pour détecter et maintenir les connexions entre les applications. Il peut s'agir d'un mécanisme pour envoyer périodiquement des messages ou des signaux pour s'assurer que les parties communicantes sont toujours en vie. Habituellement, une application envoie périodiquement un message de pulsation à une autre application. Si aucun message de pulsation n'est reçu dans un certain laps de temps, on considérera que la connexion a été déconnectée ou que l'autre partie n'est plus active.

Le mécanisme Heartbeat est très courant dans les systèmes distribués et est utilisé pour surveiller et gérer l'état de la connexion entre les nœuds. Il peut être utilisé pour détecter les défaillances ou les anomalies des nœuds et prendre les mesures correspondantes, telles que la réaffectation des tâches, la reconnexion, etc. Heartbeat peut également être utilisé pour coordonner différents nœuds dans un système distribué afin d'assurer la synchronisation et la cohérence entre les nœuds.

La fréquence et l'implémentation spécifique de Heartbeat peuvent être configurées et ajustées en fonction des besoins de l'application. Habituellement, la fréquence du message de pulsation doit être déterminée en fonction du délai du réseau, de la stabilité de la connexion et des exigences en temps réel de l'application. Une fréquence de pulsation inférieure peut réduire l'utilisation de la bande passante du réseau, mais peut entraîner des retards dans la détection de l'état de la connexion. Une fréquence de pulsation plus élevée peut détecter plus rapidement les changements d'état de connexion, mais augmentera la consommation de bande passante du réseau.

Que sont l'accusé de réception différé et l'accusé de réception cumulatif de TCP ? quelle scène utiliser

Delayed ACK (Delayed ACK) et Cumulative Acknowledgment (accusé de réception cumulatif) sont des concepts liés à l'accusé de réception de données dans le protocole TCP.

Un ACK retardé signifie que le récepteur TCP n'envoie pas de message d'accusé de réception (ACK) immédiatement après avoir reçu les données, mais attend pendant un certain temps, espérant envoyer un ACK en même temps pour confirmer plusieurs paquets de données. Cela réduit le nombre de messages ACK, économisant ainsi la bande passante du réseau. Le délai par défaut pour retarder ACK est généralement de 200 millisecondes.

L'accusé de réception cumulatif signifie que lorsque le récepteur TCP envoie un message ACK, il confirme une série de paquets de données reçus en continu, plutôt que de confirmer chaque paquet de données un par un. Par exemple, si le récepteur a reçu les paquets 1, 2, 3, 4, il peut simplement envoyer un message ACK pour accuser réception de ces quatre paquets. Cela peut réduire le nombre de messages ACK et améliorer l'efficacité de la transmission réseau.

L'utilisation d'un ACK retardé et d'un accusé de réception cumulatif peut réduire efficacement le nombre de messages ACK dans le réseau, réduisant ainsi le retard du réseau et la consommation de bande passante. Cependant, les accusés de réception retardés et les accusés de réception cumulés peuvent également entraîner un certain retard, car le récepteur doit attendre un certain laps de temps ou un certain nombre de paquets avant d'envoyer le message d'accusé de réception. Dans certains scénarios d'application spécifiques, tels que la communication en temps réel ou la transmission de données à grande vitesse, il peut être nécessaire d'ajuster les paramètres d'accusé de réception retardé et d'accusé de réception cumulatif pour équilibrer les exigences de délai et de bande passante.

Il convient de noter que l'accusé de réception retardé et l'accusé de réception cumulatif sont un mécanisme d'optimisation dans le protocole TCP et qu'il n'est pas nécessaire de les utiliser. L'utilisation ou non d'un ACK retardé et d'une réponse cumulative, ainsi que des paramètres, dépend de l'environnement réseau spécifique et des exigences de l'application.

Quel est le problème des paquets collants de données TCP ?

Le problème de collage des données TCP fait référence au phénomène selon lequel, lors de l'utilisation du protocole TCP pour la transmission de données, les données envoyées par l'expéditeur sont collées ensemble par le récepteur, ce qui entraîne le phénomène selon lequel le récepteur ne peut pas correctement analyser et traiter les données.

TCP est un protocole de transmission fiable orienté connexion, qui divise les données en paquets de données individuels pour la transmission. Cependant, en raison de l'incertitude de la transmission réseau, le récepteur peut ne pas être en mesure de recevoir en fonction de la limite du paquet de données envoyé par l'expéditeur, ce qui entraîne le collage de plusieurs paquets de données pour former un bloc de données plus grand, qui est le protocole TCP. problème de paquet collant de données.

Il existe de nombreuses raisons pour lesquelles les paquets collants de données TCP peuvent se produire, notamment le retard du réseau, la congestion, la limitation de la bande passante, etc. Lorsque le récepteur reçoit les blocs de données collés ensemble, il doit être traité pour analyser correctement la limite et le contenu de chaque paquet de données.

Existe-t-il une solution au problème des paquets collants de données TCP ?

Afin de résoudre le problème des paquets persistants de données TCP, les méthodes suivantes peuvent généralement être adoptées :

  1. Longueur fixe du message : l'expéditeur fixe la longueur de chaque paquet de données et le récepteur le divise en fonction de la longueur fixe.
  2. Séparation des caractères spéciaux : l'expéditeur ajoute des caractères spéciaux comme séparateurs entre les paquets de données et le destinataire les divise en fonction des caractères spéciaux.
  3. Identification de l'en-tête du message : l'expéditeur ajoute des informations d'identification à l'en-tête de chaque paquet de données, y compris la longueur du paquet de données, et le destinataire les divise en fonction des informations d'identification.
  4. Utiliser les limites du message : l'expéditeur ajoute un identifiant de limite de message à la fin de chaque paquet de données, et le récepteur le divise en fonction des limites du message.

Selon les scénarios d'application et les exigences spécifiques, il est très important de choisir une solution appropriée pour faire face au problème de blocage des données TCP.

Parlez du protocole HTTP

HTTP (Hypertext Transfer Protocol) est un protocole de transfert de données entre les navigateurs Web et les serveurs Web. Il s'agit d'un protocole de couche application sans état basé sur un modèle client-serveur.

Voici quelques fonctionnalités clés du protocole HTTP :

  1. Sans état : HTTP est sans état, ce qui signifie que le serveur ne se souvient pas des requêtes précédentes. Chaque demande est indépendante et le serveur ne conserve pas d'informations d'état sur le client. Afin de traiter l'état, vous pouvez utiliser la session (Session) ou utiliser le cookie pour suivre l'état du client.
  2. Modèle requête-réponse : HTTP est basé sur un modèle requête-réponse. Le client envoie une requête HTTP au serveur, le serveur traite la requête et renvoie une réponse HTTP au client. Les requêtes et les réponses se composent d'une ligne de départ, de champs d'en-tête et d'un corps de message facultatif.
  3. URL (Uniform Resource Locator) : HTTP utilise des URL pour spécifier les ressources auxquelles accéder. Une URL se compose d'un type de protocole (par exemple http://), d'un nom d'hôte, d'un numéro de port, d'un chemin et de paramètres de requête facultatifs.
  4. Méthodes de requête : HTTP définit plusieurs méthodes de requête, les plus courantes étant GET et POST. La méthode GET est utilisée pour demander des ressources, tandis que la méthode POST est utilisée pour soumettre des données au serveur. Les autres méthodes de requête courantes incluent PUT (ressource de mise à jour), DELETE (ressource de suppression), etc.
  5. Code d'état : La réponse HTTP contient un code d'état, qui est utilisé pour indiquer le résultat du traitement de la requête. Les codes d'état courants incluent 200 (succès), 404 (non trouvé), 500 (erreur de serveur interne), etc.
  6. Champs d'en-tête : les requêtes et les réponses HTTP contiennent des champs d'en-tête qui sont utilisés pour transmettre des informations supplémentaires sur la requête ou la réponse. Par exemple, Content-Typeles champs d'en-tête sont utilisés pour spécifier le type de contenu de la réponse, et User-Agentles champs d'en-tête sont utilisés pour identifier le client qui envoie la demande.
  7. Connexion persistante : HTTP/1.1 introduit une connexion persistante (Keep-Alive), qui permet d'envoyer plusieurs requêtes et réponses HTTP sur une seule connexion TCP afin de réduire la surcharge d'établissement et de fermeture de connexion.

Le protocole HTTP est la base de la communication des applications Web, qui définit les règles de communication entre le client et le serveur. Via HTTP, le client peut demander des ressources au serveur, et le serveur peut renvoyer les ressources au client. Ce protocole simple et flexible a rendu possible le développement du Web et la vulgarisation d'Internet.

Quelles sont les méthodes de requête du protocole HTTP ?

Le protocole HTTP définit une variété de méthodes de requête, chacune avec un objectif et une sémantique différents. Voici les méthodes de requête courantes dans le protocole HTTP :

  1. GET : utilisé pour demander des données pour une ressource spécifiée. Les requêtes GET sont idempotentes, c'est-à-dire que l'envoi de la même requête GET plusieurs fois doit renvoyer le même résultat.
  2. POST : utilisé pour soumettre des données au serveur, généralement pour créer de nouvelles ressources ou soumettre des données de formulaire. Les requêtes POST ne sont pas idempotentes, c'est-à-dire que l'envoi de la même requête POST plusieurs fois peut entraîner des résultats différents.
  3. PUT : utilisé pour télécharger ou mettre à jour le contenu de la ressource spécifiée sur le serveur. Les requêtes PUT sont généralement utilisées pour mettre à jour une ressource existante ou pour créer une nouvelle ressource si la ressource n'existe pas.
  4. DELETE : Utilisé pour supprimer la ressource spécifiée.
  5. HEAD : similaire à une requête GET, mais ne renvoie que l'en-tête de la réponse, pas le corps de la réponse. Il est principalement utilisé pour obtenir les métadonnées de la ressource, telles que la taille et le type de la ressource.
  6. OPTIONS : utilisé pour obtenir des informations telles que les méthodes de requête prises en charge par le serveur, les champs d'en-tête de réponse, etc.
  7. PATCH : utilisé pour effectuer des mises à jour partielles des ressources. Contrairement aux requêtes PUT, les requêtes PATCH n'ont besoin de transmettre que la partie des données qui doit être mise à jour, et non la totalité de la ressource.
  8. TRACE : Utilisé pour faire écho aux informations de requête sur le lien requête-réponse, principalement pour les tests ou le diagnostic.

Outre les méthodes de requête courantes mentionnées ci-dessus, le protocole HTTP permet également l'extension de méthodes de requête personnalisées. Mais dans les applications pratiques, les méthodes de requête couramment utilisées sont GET, POST, PUT et DELETE.

Les plus utilisés sont get et post

Quels sont les codes d'état courants du protocole HTTP ?

Le protocole HTTP définit un ensemble de codes d'état pour indiquer le résultat du traitement de la requête. Chaque code d'état a une signification spécifique et est utilisé pour indiquer des conditions telles que le succès de la demande, la redirection, l'erreur du client ou l'erreur du serveur. Voici les codes d'état courants dans le protocole HTTP :

  1. 1xx (codes d'état informatifs) : indique que la demande a été reçue, est en cours de traitement ou nécessite une action supplémentaire.

    • 100 Continuer : Le serveur a reçu la partie initiale de la demande et le client doit continuer à envoyer le reste.
    • 101 Switching Protocols : Le serveur a compris la requête et va basculer vers un nouveau protocole.

  2. 2xx (code d'état de réussite) : indique que la demande a été traitée avec succès.

    • 200 OK : la requête aboutit et les données demandées sont renvoyées.
    • 201 Créé : La demande a été traitée avec succès et une nouvelle ressource a été créée.
    • 204 Aucun contenu : la demande a abouti, mais la réponse ne contenait aucun contenu.

  3. 3xx (code d'état de redirection) : indique qu'une action supplémentaire est requise pour terminer la demande.

    • 301 Déplacé définitivement : la ressource demandée a été déplacée définitivement vers un nouvel emplacement.
    • 302 Trouvé : La ressource demandée a été temporairement déplacée vers un nouvel emplacement.
    • 304 Non modifié : la ressource demandée n'a pas été modifiée et la version en cache peut être utilisée.

  4. 4xx (code d'état d'erreur client) : indique que la demande contient des erreurs ou ne peut pas être complétée.

    • 400 Bad Request : La requête n'était pas valide et n'a pas pu être comprise par le serveur.
    • 401 Non autorisé : la demande nécessite une authentification.
    • 403 Interdit : Le serveur refuse la demande d'accès à la ressource.
    • 404 Introuvable : la ressource demandée n'existe pas.

  5. 5xx (code d'état d'erreur du serveur) : indique qu'une erreur s'est produite pendant que le serveur traitait la demande.

    • 500 Erreur interne du serveur : le serveur a rencontré une erreur inattendue.

    • 502 Bad Gateway : Le serveur, agissant en tant que passerelle ou proxy, a reçu une réponse non valide d'un serveur en amont.

    • 503 Service indisponible : le serveur est actuellement incapable de traiter la demande, probablement en raison d'une surcharge ou d'une maintenance.

Parlez du processus de la méthode Get request

Lorsqu'un client envoie une requête GET, voici le processus général :

  1. Le client crée une requête GET : le client crée une requête HTTP, y compris la ligne de requête, l'en-tête de requête et le corps de requête facultatif. La ligne de requête contient la méthode de requête (GET), l'URL demandée et la version du protocole.
  2. Le client envoie une requête GET : le client envoie la requête GET construite au serveur cible. La demande contient l'URL de la ressource à obtenir et d'autres informations connexes.
  3. Le serveur reçoit la requête GET : une fois que le serveur cible a reçu la requête GET, il commence à traiter la requête.
  4. Le serveur traite la requête GET : le serveur trouve et obtient la ressource correspondante en fonction de l'URL et d'autres informations contenues dans la requête. Généralement, un serveur récupère le contenu d'une ressource à partir d'un système de fichiers, d'une base de données ou d'une autre source de données.
  5. Le serveur génère une réponse : Le serveur génère une réponse HTTP basée sur le contenu de ressource obtenu. Une réponse se compose d'une ligne de réponse, d'en-têtes de réponse et d'un corps de réponse. La ligne de réponse contient la version du protocole, le code d'état et le message d'état.
  6. Le serveur envoie une réponse : le serveur renvoie la réponse HTTP générée au client.
  7. Le client reçoit une réponse : le client reçoit la réponse envoyée par le serveur.
  8. Client traitant la réponse : le client traite le contenu de la réponse en fonction du code d'état et d'autres informations pertinentes dans la réponse. La méthode de traitement peut consister à afficher le contenu de la réponse, à analyser l'en-tête de la réponse, à effectuer d'autres opérations, etc.
  9. Le client affiche le résultat de la réponse : le client affiche le résultat de la réponse à l'utilisateur, par exemple en affichant le contenu de la page Web dans le navigateur.

Parlez des composants du message de requête Get et des composants du message de réponse

Lorsqu'un client envoie une requête GET, le message de requête se compose des composants suivants :

  1. Ligne de requête : contient la méthode de requête, l'URL demandée et la version du protocole.
    • Par exemple : GET /api/users HTTP/1.1
  2. En-tête de la requête : contient des informations supplémentaires sur la requête, exprimées sous la forme de paires clé-valeur.
    • Par exemple:
      • Hébergeur : example.com
      • Agent utilisateur : Mozilla/5.0 (Windows NT 10.0 ; Win64 ; x64) AppleWebKit/537.36 (KHTML, comme Gecko) Chrome/91.0.4472.124 Safari/537.36
      • Accepter : text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng, / ;q=0.8
  3. Ligne vide : utilisée pour séparer l'en-tête et le corps de la requête.
  4. Corps de la requête : les requêtes GET n'ont généralement pas de corps de requête, car elles sont principalement utilisées pour obtenir des ressources, et non pour envoyer des données.

Voici un exemple complet d'un exemple de message de requête GET :

GET /api/users?name=John&age=25 HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36
Accept: application/json
Authorization: Bearer abc123

La signification de chaque ligne est la suivante :

  1. GET /api/users?name=John&age=25 HTTP/1.1: ligne de demande, y compris la méthode HTTP (GET), le chemin de la demande (/api/users), les paramètres de requête (name=John&age=25) et la version du protocole HTTP (HTTP/1.1).

  2. Host: example.com: Le champ d'en-tête de la demande spécifie l'hôte cible (example.com) de la demande.

  3. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36: Le champ d'en-tête de la requête, qui contient les informations de l'agent utilisateur (navigateur) qui a envoyé la requête.

  4. Accept: application/json: Le champ d'en-tête de la demande spécifie le type de contenu de la réponse (application/json) que le client peut accepter.

  5. Authorization: Bearer abc123: Champ d'en-tête de requête pour l'authentification, où Bearer est le schéma d'authentification et abc123 est le jeton d'authentification.

  6. Une ligne vide indique la fin des en-têtes de requête, suivie d'aucun corps de requête.

Un message de réponse se compose de trois parties principales : la ligne de réponse, les en-têtes de réponse et le corps de la réponse.

  1. Ligne de réponse : la ligne de réponse contient le numéro de version du protocole HTTP, le code d'état et le message d'état. Son format est généralement HTTP/1.1 200 OK, où il HTTP/1.1indique la version du protocole, 200indique le code d'état et OKindique le message d'état.
  2. En-tête de réponse : l'en-tête de réponse contient des méta-informations relatives à la réponse. Il contient une série de paires clé-valeur, chaque paire clé-valeur se compose d'un nom de champ et d'une valeur de champ. Les champs d'en-tête de réponse courants incluent Content-Type(spécifiez le type de contenu du corps de la réponse), Content-Length(spécifiez la longueur du corps de la réponse), Date(spécifiez la date et l'heure de la réponse), etc.
  3. Corps de la réponse : le corps de la réponse contient les données réelles renvoyées par le serveur. Il peut s'agir de données dans divers formats tels que HTML, JSON, XML, etc., selon la logique de traitement du serveur et les besoins du client.

Voici un exemple de message de réponse correspondant, y compris les composants de la ligne de réponse, les en-têtes de réponse et le corps de la réponse :

HTTP/1.1 200 OK

Type de contenu : application/json

Longueur du contenu : 120

Date : lundi 25 juillet 2023 06:46:32 GMT

{

"identifiant": 1,

"nom": "Jean",

« âge » : 25 ans,

« e-mail » : « [email protected] »

}

Analyse comme suit :

  1. HTTP/1.1 200 OK: Ligne de réponse, indiquant que le serveur a traité avec succès la requête et renvoyé un code d'état 200 (OK).
  2. Content-Type: application/json: Le champ d'en-tête de la réponse, spécifiant que le type de contenu du corps de la réponse est application/json.
  3. Content-Length: 120: Champ d'en-tête de réponse, spécifiant que la longueur du corps de la réponse est de 120 octets.
  4. Date: Mon, 25 Jul 2023 06:46:32 GMT: Le champ d'en-tête de réponse spécifie la date et l'heure de la réponse.
  5. Ligne vide : indique la fin de l'en-tête de la réponse.
  6. Corps de la réponse : contient les données renvoyées par le serveur, voici un objet au format JSON, comprenant des attributs tels que id, name, age, et email.

Quels sont les types de contenu ?

Content-Type est l'un des champs d'en-tête HTTP utilisés pour indiquer le type de média du corps d'entité envoyé ou reçu. Voici quelques types de type de contenu courants :

  1. text/plain : type de texte brut.
  2. text/html : type de document HTML.
  3. text/css : type de feuille de style CSS.
  4. application/json : type de données JSON.
  5. application/xml : type de données XML.
  6. application/pdf : type de document PDF.
  7. image/jpeg : type d'image JPEG.
  8. image/png : type d'image PNG.
  9. audio/mpeg : type audio MPEG.
  10. vidéo/mp4 : type de vidéo MP4.

En plus des types ci-dessus, il existe de nombreux autres types de type de contenu utilisés pour représenter différents types de médias et formats de données. Le type de type de contenu approprié peut être sélectionné en fonction des besoins réels.

Parlez du processus de la méthode Post request

Lors de l'utilisation de la méthode de requête POST, la requête envoyée par le client au serveur contiendra un corps de requête, qui contient les données à transmettre au serveur. Voici le processus général de la méthode de requête POST :

  1. Le client établit une connexion avec le serveur : le client établit une connexion avec le serveur en établissant une connexion TCP ou en utilisant d'autres protocoles.
  2. Créer un message de demande : le client crée un message de demande HTTP, qui comprend la ligne de demande, l'en-tête de la demande et le corps de la demande. La méthode de requête est POST et l'URL de la cible de la requête est spécifiée dans la ligne de requête. L'en-tête de la requête peut contenir des informations supplémentaires, telles que Content-Type, Content-Length, etc. Le corps de la requête contient les données à transmettre au serveur.
  3. Envoyer un message de requête : le client envoie le message de requête construit au serveur. Le message de demande sera transmis au côté serveur via le réseau.
  4. Le serveur reçoit le message de requête : le serveur reçoit le message de requête envoyé par le client.
  5. Demande de traitement : le serveur effectue le traitement correspondant en fonction du message de demande reçu. Cela peut impliquer l'authentification de l'utilisateur, le traitement des données de la demande, l'exécution de la logique métier appropriée, etc.
  6. Réponse de retour : le serveur génère un message de réponse HTTP, qui inclut la ligne de réponse, les en-têtes de réponse et le corps de la réponse. La ligne de réponse spécifie le numéro de version du protocole HTTP, le code d'état et le message d'état. Les en-têtes de réponse contiennent des méta-informations liées à la réponse. Le corps de la réponse contient les données renvoyées par le serveur.
  7. Recevoir la réponse : le client reçoit le message de réponse renvoyé par le serveur.
  8. Réponse de traitement : le client effectue le traitement correspondant en fonction du message de réponse reçu. Cela peut inclure l'analyse des données dans le corps de la réponse, le traitement des méta-informations dans les en-têtes de réponse, la gestion des erreurs basée sur les codes d'état, etc.

La méthode de demande POST convient aux scénarios où les données doivent être soumises au serveur, telles que la soumission de données de formulaire, le téléchargement de fichiers, etc. Par rapport à la méthode de requête GET, la méthode de requête POST est plus adaptée à la transmission de grandes quantités de données ou de données sensibles, car la requête POST inclut les données dans le corps de la requête au lieu d'être visibles dans l'URL.

Parlez des composants du message Post request et des composants du message de réponse

Lors de l'envoi d'un message à l'aide d'une requête POST, le message se compose généralement d'une ligne de requête, d'en-têtes de requête et d'un corps de requête. Voici un exemple de requête POST montrant les composants du message :

POST /api/login HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 43

{
  "username": "exampleuser",
  "password": "secretpassword"
}
  • Ligne de requête : la ligne de requête de la requête POST spécifie que la méthode de requête est POST, la cible de la requête est /api/login, et la version du protocole HTTP utilisée est HTTP/1.1.
  • En-tête de la demande : l'en-tête de la demande contient des informations supplémentaires. Dans cet exemple, Hostl'en-tête spécifie le nom d'hôte du serveur, Content-Typel'en-tête spécifie que le type de données du corps de la demande est JSON et Content-Lengthl'en-tête spécifie que la longueur du corps de la demande est de 43 octets.
  • Corps de la requête : Le corps de la requête contient les données à transmettre au serveur. Dans cet exemple, le corps de la requête est un objet JSON contenant un nom d'utilisateur et un mot de passe.

Veuillez noter qu'il ne s'agit que d'un exemple et que le message de demande POST réel peut être personnalisé en fonction de besoins et de scénarios spécifiques.

Lorsqu'un message est envoyé à l'aide d'une requête POST, le serveur renvoie un message de réponse. Voici un exemple de message de réponse :

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 26

{
  "message": "Login successful"
}

  • Ligne de réponse : la ligne de réponse spécifie la version du protocole HTTP et le code d'état. Dans cet exemple, le code d'état dans la ligne de réponse est 200, indiquant que la demande a réussi.

  • En-tête de réponse : l'en-tête de réponse contient des informations supplémentaires. Dans cet exemple, Content-Typel'en-tête spécifie que le type de données du corps de la réponse est JSON, et Content-Lengthl'en-tête spécifie que la longueur du corps de la réponse est de 26 octets.

  • Corps de la réponse : le corps de la réponse contient les données renvoyées par le serveur. Dans cet exemple, le corps de la réponse est un objet JSON contenant un messagechamp nommé Login successful.

Quelle est la différence entre les méthodes de requête GET et POST ?

GET et POST sont deux méthodes de requête courantes dans le protocole HTTP. Elles présentent certaines différences d'utilisation et de caractéristiques :

  1. Où les données sont transférées : les requêtes GET ajoutent les données dans les paramètres de requête de l'URL, tandis que les requêtes POST incluent les données dans le corps de la requête.
  2. Limite de longueur des données : étant donné que la requête GET ajoute des données dans l'URL, la longueur des données est limitée par la limite de longueur de l'URL. La requête POST contient les données dans le corps de la requête, il n'y a pas de limite de longueur claire et une grande quantité de données peut être transmise.
  3. Sécurité des données : les données de la requête GET seront affichées dans l'URL, il n'est donc pas approprié d'utiliser la requête GET pour des informations sensibles, car l'URL peut être enregistrée dans l'historique du navigateur, les journaux du serveur, etc. Les requêtes POST incluent des données dans le corps de la requête et ne seront pas exposées dans l'URL, ce qui est relativement plus sûr.
  4. Mise en cache des données : les requêtes GET peuvent être mises en cache par le navigateur, donc pour la même requête, le navigateur peut obtenir la réponse directement depuis le cache sans envoyer la requête au serveur. Les requêtes POST ne seront pas mises en cache et seront envoyées au serveur à chaque fois.
  5. Idempotence : les requêtes GET sont idempotentes, c'est-à-dire que plusieurs requêtes GET identiques n'auront pas d'effets secondaires sur le serveur. La requête POST n'est pas idempotente et plusieurs requêtes POST identiques peuvent produire des résultats différents pour le serveur.
  6. Scénario d'utilisation : les requêtes GET conviennent à des opérations telles que l'obtention de ressources et l'interrogation de données, tandis que les requêtes POST conviennent à des opérations telles que la soumission de données et la modification de données.

En résumé, les requêtes GET conviennent pour obtenir des données, pour des opérations sans effets secondaires et pour des scénarios qui ne nécessitent pas une sécurité élevée des données. Les requêtes POST conviennent à la soumission de données, aux opérations avec des effets secondaires et aux scénarios avec des exigences élevées en matière de sécurité des données.

Qu'est-ce qu'une URL et quels sont ses composants ?

Une URL (Uniform Resource Locator) est une chaîne de caractères utilisée pour identifier et localiser une ressource sur Internet. Une URL se compose généralement des composants suivants :

  1. Protocole (Protocole) : La première partie de l'URL est le protocole, qui spécifie le protocole utilisé pour la communication entre le client et le serveur, tel que HTTP, HTTPS, FTP, etc. Les accords se terminent généralement ://par .

  2. Nom de domaine (Domain) : Le nom de domaine est la partie principale de l'URL, qui spécifie le nom ou l'adresse IP du serveur auquel accéder. Un nom de domaine peut être un nom d'hôte complet (tel que www.example.com) ou une adresse IP (telle que 192.168.0.1).

  3. Port : le port est facultatif et spécifie le numéro de port spécifique sur le serveur qui écoute. Si aucun port n'est spécifié, le numéro de port par défaut est utilisé. Le numéro de port par défaut du protocole HTTP commun est 80 et le numéro de port par défaut de HTTPS est 443.

  4. Chemin (Path): Le chemin spécifie l'emplacement spécifique de la ressource sur le serveur. Il /commence par une barre oblique et peut contenir plusieurs segments de chemin, séparés par des barres obliques. Par exemple, cela signifie accéder aux ressources sous un répertoire /products/123sur le serveur .products123

  5. Paramètres de requête (paramètres de requête) : les paramètres de requête sont utilisés pour transmettre des données supplémentaires au serveur. Ils commencent par un ?point d'interrogation et plusieurs paramètres sont &séparés. Chaque paramètre se compose d'un nom de paramètre et d'une valeur de paramètre, qui =sont reliés par un signe égal. Par exemple, ?page=1&limit=10le numéro de page demandé est 1 et 10 données sont affichées sur chaque page.

  6. Ancre (Fragment) : une ancre est une partie facultative d'une URL qui spécifie un emplacement spécifique dans une page. Il #commence par un signe dièse suivi du nom de l'ancre. Par exemple, cela signifie que la page défile jusqu'à l'élément dont #section1l'ID est .section1

    Voici un exemple d'URL, - pour mieux comprendre les composants d'une URL :

    https://www.example.com:8080/products/123?category=electronics&sort=price#reviews

    Dans cet exemple, les composants de l'URL sont les suivants :

    • protocole:https://
    • nom de domaine:www.example.com
    • port::8080
    • chemin:/products/123
    • Paramètres de requête :?category=electronics&sort=price
    • point d'ancrage:#reviews

    Cette URL représente un www.example.comserveur situé sur la machine hôte accessible via le protocole HTTPS. Le numéro de port sur lequel le serveur écoute est 8080. Le chemin est , indiquant que les ressources sous le répertoire /products/123sur le serveur doivent être accédées . Il y a deux paramètres dans les paramètres de requête, la valeur de is et la valeur de is . Enfin, le point d'ancrage est , indiquant que la page défile jusqu'à l'élément dont l'ID est .products123categoryelectronicssortprice#reviewsreviews

Quelle est la différence entre l'URL de la méthode Get et la méthode Post ?

Lors de l'utilisation de la méthode GET, les paramètres de requête sont ajoutés directement à la fin de l'URL. Voici un exemple d'URL utilisant la méthode GET :

Exemple d'URL pour une requête GET :

https://www.example.com/api/products?id=123&category=electronics

Dans l'exemple ci-dessus, les paramètres de requête id=123et category=electronicssont ajoutés directement à la fin de l'URL pour demander des données produit avec un ID et une catégorie spécifiques au serveur.

Lors de l'utilisation de la méthode POST, les données seront placées dans le corps de la requête au lieu d'être directement attachées à l'URL. Voici un exemple d'URL utilisant la méthode POST :

Exemple d'URL pour une requête POST :

https://www.example.com/api/products

La différence entre HTTP et HTTPS

HTTP (Hypertext Transfer Protocol) et HTTPS (Hypertext Transfer Protocol Secure) sont des protocoles de transfert de données entre un client et un serveur. Les principales différences entre eux sont les suivantes :

  1. sécurité:
    • HTTP : les données sont en texte brut lors de la transmission et ne sont pas cryptées. Par conséquent, il existe des risques de sécurité dans le protocole HTTP, par exemple, les pirates peuvent intercepter et voler les données transmises.
    • HTTPS : les données sont cryptées par SSL/TLS pendant la transmission pour garantir la sécurité et l'intégrité des données. HTTPS utilise le chiffrement à clé publique et le déchiffrement à clé privée pour empêcher le vol ou la falsification des données.
  2. port:
    • HTTP : le numéro de port 80 est utilisé par défaut.
    • HTTPS : le numéro de port 443 est utilisé par défaut.
  3. Certificat:
    • HTTP : les certificats ne sont pas requis.
    • HTTPS : Un certificat SSL est requis pour vérifier l'identité du serveur. Les certificats SSL sont émis par un tiers de confiance pour établir une connexion sécurisée.
  4. SEO (optimisation pour les moteurs de recherche):
    • HTTP : Les moteurs de recherche n'accordent pas de préférence particulière au classement des sites Web HTTP.
    • HTTPS : les moteurs de recherche ont tendance à classer les sites Web qui utilisent HTTPS plus haut, car HTTPS offre une meilleure sécurité et une meilleure protection de la vie privée des utilisateurs.

En résumé, HTTP est un protocole non crypté, tandis que HTTPS offre une sécurité et une protection des données supérieures en utilisant SSL/TLS pour crypter la transmission des données. Il est recommandé d'utiliser HTTPS lors de la transmission d'informations sensibles, des paiements en ligne ou lorsque la confidentialité des utilisateurs doit être protégée.

Parlez des raisons de l'émergence de la technologie NAT Quelle est la technologie fournie par NAT

La technologie NAT (Network Address Translation, Network Address Translation) a été créée pour résoudre le problème des adresses IPv4 insuffisantes. Au début du développement d'Internet, les ressources d'adresses IPv4 étaient limitées et ne pouvaient pas répondre aux besoins de connexion d'un grand nombre d'appareils. La technologie NAT réalise la fonction de plusieurs appareils partageant une adresse IP publique en effectuant une traduction d'adresse entre le réseau privé et le réseau public.
La technologie NAT offre les fonctions suivantes :

Traduction d'adresse IP : NAT utilise des adresses IP privées pour que les appareils des réseaux privés communiquent, et lors de la communication avec des réseaux publics, NAT convertit les adresses IP privées en adresses IP publiques pour permettre la communication avec les réseaux publics.

Traduction de port : NAT peut également traduire les numéros de port utilisés par les appareils du réseau privé en numéros de port du réseau public. De cette façon, même si plusieurs appareils utilisent la même adresse IP privée, ils peuvent être distingués par des numéros de port différents, de sorte que plusieurs appareils peuvent partager une adresse IP publique.

Mappage d'adresses : la technologie NAT peut également implémenter la fonction de mappage d'adresses, en mappant des adresses IP publiques à des périphériques spécifiques du réseau privé. De cette manière, le réseau externe peut accéder aux appareils du réseau privé en accédant à l'adresse IP publique pour réaliser des fonctions telles que l'accès à distance et la redirection de port.

Qu'est-ce qu'une adresse IP dynamique ?

Une adresse IP dynamique fait référence à une adresse IP temporaire attribuée à un appareil du réseau. Par rapport à l'adresse IP statique, l'adresse IP dynamique est temporaire et une nouvelle adresse IP sera obtenue chaque fois que l'appareil est connecté au réseau.
L'attribution des adresses IP dynamiques est généralement gérée par un serveur DHCP (Dynamic Host Configuration Protocol, Dynamic Host Configuration Protocol). Lorsqu'un appareil se connecte au réseau, il envoie une requête DHCP demandant une adresse IP disponible. Le serveur DHCP sélectionnera une adresse IP disponible à partir d'un pool d'adresses à attribuer à l'appareil, et enverra l'adresse IP attribuée et d'autres informations de configuration réseau à l'appareil. Lorsqu'un appareil a fini d'utiliser une adresse IP, il la renvoie au serveur DHCP afin que d'autres appareils puissent l'utiliser à nouveau.
L'avantage des adresses IP dynamiques est qu'elles permettent une utilisation plus efficace des ressources d'adresses IP. Étant donné que l'adresse IP dynamique est temporaire, lorsque le périphérique n'est plus utilisé, il peut être restitué au pool d'adresses pour être utilisé par d'autres périphériques, réduisant ainsi le gaspillage d'adresses IP. De plus, le processus d'attribution d'adresses IP dynamiques est plus simple et plus automatisé, ce qui réduit la charge de travail des administrateurs réseau.
Cependant, les adresses IP dynamiques ont également certaines limitations. Étant donné que l'adresse IP est temporaire, l'appareil obtiendra une nouvelle adresse IP chaque fois qu'il se connectera au réseau, ce qui peut entraîner des problèmes de configuration pour certaines applications ou certains services réseau. Pour les appareils nécessitant un accès à distance ou nécessitant une adresse IP fixe, une adresse IP statique peut être plus appropriée.

Les adresses IP dynamiques peuvent se produire dans les réseaux publics et privés.
Dans un réseau public, une adresse IP dynamique est une adresse IP temporaire attribuée à un utilisateur par un fournisseur d'accès Internet (FAI). Lorsqu'un utilisateur se connecte à Internet, le FAI lui attribue une adresse IP dynamique disponible. De cette manière, les utilisateurs peuvent communiquer avec Internet via cette adresse IP dynamique.
Dans un réseau privé, une adresse IP dynamique est une adresse IP temporaire attribuée à un appareil par le serveur DHCP du réseau local. Lorsque l'appareil est connecté au réseau privé, le serveur DHCP lui attribue une adresse IP dynamique disponible. De cette façon, les appareils peuvent communiquer dans le réseau privé et échanger des données avec d'autres appareils.

Quelle est la différence entre la traduction de port et le mappage de port ?

Le mappage de port et la conversion de port sont des fonctions utilisées pour permettre aux utilisateurs du réseau public d'accéder aux périphériques ou services du réseau privé.
Le mappage de port fait référence au mappage d'un port spécifique d'une adresse IP de réseau public à un port spécifique d'un périphérique de réseau privé. De cette manière, lorsqu'un utilisateur du réseau public envoie une requête à l'adresse IP du réseau public et au port mappé, le routeur transmettra ces requêtes au port correspondant sur le périphérique de réseau privé correspondant.
La traduction de port (également connue sous le nom de traduction NAT) est un concept plus large qui inclut le mappage de port. La traduction de port fait référence à un processus de conversion au sein du réseau privé, qui convertit la demande de l'utilisateur du réseau privé d'un port à un autre port et la transmet à d'autres appareils du réseau privé. De cette manière, la communication entre les dispositifs internes du réseau privé peut être réalisée, et en même temps, la fonction des utilisateurs du réseau public pour accéder aux dispositifs du réseau privé peut être réalisée.
Par conséquent, le mappage de port est une forme de traduction de port, qui est utilisée par les utilisateurs du réseau public pour accéder aux périphériques ou services du réseau privé. La conversion de port peut également inclure la redirection de port entre les utilisateurs du réseau privé , de manière à réaliser la communication entre les appareils à l'intérieur du réseau privé.

Exemple de traduction de port :
imaginez que vous disposez d'un réseau domestique avec trois appareils connectés au même routeur : l'appareil A, l'appareil B et l'appareil C. Votre réseau domestique utilise une adresse IP publique.
Le périphérique A exécute un serveur Web qui écoute sur le port 80. Supposons que l'appareil B et l'appareil C souhaitent accéder à ce serveur Web sur l'appareil A via Internet.
Étant donné que votre réseau domestique n'a qu'une seule adresse IP publique, ni l'appareil B ni l'appareil C ne peuvent accéder au serveur Web de l'appareil A directement via Internet.
À ce stade, vous pouvez configurer la traduction de port sur le routeur. Vous pouvez spécifier un port externe (par exemple 8080) et le mapper au port 80 du périphérique A.
Désormais, lorsque l'appareil B ou l'appareil C accède à l'adresse IP publique du routeur et au port mappé (par exemple, http://your_public_ip:8080) sur Internet, le routeur transmet ces demandes au serveur Web sur l'appareil A.
De cette façon, l'appareil B et l'appareil C peuvent accéder au serveur Web sur l'appareil A via Internet sans se connecter directement à l'appareil A.
Exemple de mappage de port :
supposons que vous disposiez d'un réseau domestique avec une caméra et que vous souhaitiez pouvoir accéder à cette caméra via l'Internet public. Tout d'abord, vous devez configurer la redirection de port sur le routeur.

Recherchez l'adresse IP de votre webcam, par exemple 192.168.1.101.

Connectez-vous à l'interface d'administration de votre routeur et recherchez les paramètres de transfert de port dans des options telles que les paramètres réseau ou le transfert de port.

Créez une nouvelle règle de mappage de port. Entrez les informations suivantes:

Port public : sélectionnez un numéro de port public inoccupé, tel que 8080.

Adresse IP interne : Entrez l'adresse IP de l'appareil photo, qui est 192.168.1.101.

Port interne : entrez le numéro de port que l'appareil photo surveille, par exemple 80.

Protocole : choisissez TCP ou UDP, selon les exigences de l'appareil photo.

Enregistrez et appliquez cette règle de mappage de port.

Maintenant, lorsque vous accédez à l'adresse IP publique de votre routeur sur l'Internet public et que vous spécifiez le numéro de port 8080, le routeur transmettra cette demande à l'adresse IP de l'appareil photo 192.168.1.101 sur le port 80. De cette façon, vous pouvez accéder à votre appareil webcam via l'Internet public.

Que sont le serveur et la passerelle DHCP ?

Le serveur et la passerelle DHCP jouent des rôles différents dans le réseau et présentent les différences suivantes :

Fonction : Un serveur DHCP est responsable de l'attribution dynamique des adresses IP et d'autres informations de configuration réseau aux appareils connectés au réseau. Il reçoit la demande DHCP de l'appareil et sélectionne une adresse IP disponible dans le pool d'adresses IP préconfigurées à attribuer à l'appareil. La passerelle est le point de sortie du réseau, qui relie la communication entre le réseau local (LAN) et le réseau externe (tel qu'Internet), et est responsable de la transmission des paquets de données d'un réseau à l'autre.

Méthode de travail : le serveur DHCP communique avec l'appareil via le protocole DHCP, reçoit et traite la demande DHCP de l'appareil et renvoie l'adresse IP attribuée et d'autres informations de configuration à l'appareil. Son travail consiste à attribuer automatiquement des adresses IP et des informations de configuration aux appareils lorsqu'ils rejoignent le réseau. La passerelle transmet les paquets de données du réseau source au réseau cible selon la table de routage et les règles de transmission de la couche réseau.

Attribution d'adresse : Le serveur DHCP est responsable de l'attribution dynamique des adresses IP, fournissant des adresses IP temporaires et variables pour les appareils connectés au réseau. Cela permet à l'appareil d'obtenir automatiquement une adresse IP disponible sans configuration manuelle. Une passerelle, d'autre part, a généralement une adresse IP statique, et c'est un point de sortie dans le réseau , qui est utilisé pour transférer des paquets de données d'un réseau à un autre.

Champ d'action : le champ d'action d'un serveur DHCP concerne les périphériques d'un réseau local (LAN), qui fournit des adresses IP et d'autres informations de configuration pour les périphériques connectés au LAN. La portée de la passerelle est l'ensemble du réseau, qui relie le LAN et le réseau externe, et est responsable de la transmission des paquets de données du LAN vers le réseau externe, ou du réseau externe vers le LAN.

Pour résumer, un serveur DHCP est responsable de l'attribution dynamique d'adresses IP et d'autres informations de configuration réseau aux périphériques, tandis qu'une passerelle est un point de sortie dans un réseau, responsable du transfert de paquets de données d'un réseau à un autre. Ils se différencient par leur fonction, leur mode de fonctionnement, l'affectation des adresses et leur champ d'action.

Un serveur DHCP est généralement placé sur un routeur ou un périphérique réseau. Un routeur agit comme une passerelle dans un réseau privé, connectant les communications entre un réseau local (LAN) et un réseau externe tel qu'Internet.

Quels sont les points de sortie dans le réseau ? 192.168.0.1 est-il le point de sortie

Un point de sortie dans un réseau fait référence à la sortie de la communication réseau et peut également être appelé passerelle ou passerelle par défaut. C'est le point de commutation qui relie un réseau local (LAN) ou un réseau privé à des réseaux externes tels qu'Internet.
Le point de sortie est généralement un périphérique réseau tel qu'un routeur ou un pare-feu. Il possède deux interfaces réseau ou plus, une connectée au réseau local et une ou plusieurs connectées au réseau externe. Le point de sortie transmet les données du réseau local au réseau externe, ou transmet les données du réseau externe au réseau local en transmettant les paquets de données.
192.168.0.1 est une adresse IP privée courante qui est souvent utilisée comme adresse IP de la passerelle ou du point de sortie par défaut. La passerelle par défaut signifie que lorsque l'appareil envoie un paquet de données, si l'adresse IP cible n'est pas dans le même sous-réseau, il enverra le paquet de données à la passerelle par défaut, et la passerelle par défaut est responsable de la transmission du paquet de données à l'externe. réseau.
Par conséquent, 192.168.0.1 peut être un point de sortie dans un réseau, agissant comme une passerelle par défaut, responsable de la transmission des paquets du LAN vers le réseau externe, ou du réseau externe vers le LAN. Cependant, il convient de noter que l'adresse IP réelle du point de sortie peut être différente, selon la configuration du réseau et les paramètres de l'appareil.

Je suppose que tu aimes

Origine blog.csdn.net/weixin_46274756/article/details/131919152
conseillé
Classement
du quotidien
Plus
2024-05-18(31)
2024-05-17(4)
2024-05-16(25)
2024-05-15(5)
2024-05-14(11)
2024-05-13(7)
2024-05-12(22)
2024-05-11(31)
2024-05-10(33)
2024-05-09(31)

Code World

© 2018 codetd.com