[Réseau informatique] Examen sommaire (1)

Cet article enregistre principalement une certaine expérience lors de l'observation du codage de Kobayashi, et enregistrera certains points de connaissance et sentiments que je pense importants

Principes de base du réseau

protocole osi à sept couches
tcp/ip protocole à quatre couches couche application couche transport couche réseau couche interface réseau

Scène réelle :

• URL de sortie vers le processus d'affichage de la page Web
• Analyse d'URL (protocole + serveur Web + chemin de la source de données)
• Générer un message de requête http
• Requête d'adresse de serveur (dns) pour obtenir l'adresse IP
  Visitez d'abord le DNS local pour vérifier s'il y a un cache Sinon, vous pouvez utiliser une requête récursive ou une requête itérative pour mettre en cache les résultats finaux de la requête dans le DNS local
• Appeler la pile de protocoles
  La pile de protocoles comprend des parties supérieure et inférieure, la partie supérieure est tcp/udp et la partie inférieure est ip pour la transmission de paquets réseau et la détermination de l'itinéraire
• l'envoi tcp ajoute une poignée de main à trois voies d'en-tête tcp pour établir la segmentation des données de connexion et d'autres opérations pour générer un message tcp
• ip send ajouter un en-tête ip et utiliser la table de routage pour déterminer la carte réseau (source ip)
• Si l'en-tête mac contient l'adresse mac du récepteur dans le cache arp, sortez-le et utilisez-le ; s'il n'inclut pas arp à diffuser, obtenez l'adresse mac du récepteur
• Carte réseau, ajouter un en-tête et un caractère de début de trame, vérifier la séquence
• Le commutateur (adresse mac), le routeur recherche l'adresse du prochain saut en fonction de la table de routage
• Le serveur reçoit la demande du client, la décompresse, encapsule les informations requises puis les envoie au client

Processus d'envoi et de réception de paquets réseau sous Linux

• Pour recevoir des données
  , la trame reçue sur la carte réseau sera écrite dans la mémoire spécifiée (ring buffer) à la manière du DMA. Initiez ensuite une interruption au CPU pour notifier au CPU que les données sont arrivées. Lorsque le CPU reçoit une demande d'interruption, il appelle le gestionnaire d'interruption enregistré par le pilote réseau. La fonction de traitement des interruptions de la carte réseau ne fait pas trop de travail, envoie une demande d'interruption logicielle, puis libère le processeur dès que possible. Lorsque ksoftirqd détecte qu'une demande d'interruption logicielle arrive, il appelle poll pour commencer à interroger et recevoir des paquets (sk_buff), et après l'avoir reçu, il est transmis aux piles de protocoles à tous les niveaux pour traitement. Pour les paquets UDP, ils seront placés dans la file d'attente de réception du socket utilisateur.
• Envoyer des données
  Les données sont copiées dans le noyau sk_buff, et tcp copiera une copie pour la retransmission du délai d'attente pour ajouter l'
  en-tête, l'interruption logicielle notifie le pilote de la carte réseau et le sk_buff est placé dans le tampon en anneau

http

http est un protocole bidirectionnel

code d'état

Les codes d'état 1xx appartiennent aux informations d'invite, qui sont un état intermédiaire dans le traitement du protocole, et sont rarement utilisés dans la pratique.

Les codes d'état 2xx indiquent que le serveur a traité avec succès la demande du client, qui est l'état que nous sommes le plus disposés à voir.

• "200 OK" est le code d'état de réussite le plus courant, indiquant que tout va bien. S'il s'agit d'une requête non HEAD, l'en-tête de réponse renvoyé par le serveur contiendra des données de corps.

• "204 No Content" est également un code d'état de réussite courant, qui est fondamentalement le même que 200 OK, mais l'en-tête de réponse n'a pas de données de corps.

• "206 Partial Content" est appliqué au téléchargement par bloc HTTP ou au téléchargement avec reprise, indiquant que les données du corps renvoyées par la réponse ne sont pas toutes de la ressource, mais une partie de celle-ci, qui est également l'état du traitement réussi du serveur.

Le code d'état 3xx indique que la ressource demandée par le client a changé et que le client doit renvoyer la demande pour obtenir la ressource avec une nouvelle URL, c'est-à-dire une redirection.

• "301 Moved Permanently" indique une redirection permanente, indiquant que la ressource demandée n'existe plus et doit être à nouveau accessible avec une nouvelle URL.

• "302 Found" indique une redirection temporaire, indiquant que la ressource demandée est toujours là, mais qu'elle doit être temporairement accessible par une autre URL.

  301 et 302 utilisent le champ Location dans l'en-tête de réponse pour indiquer l'URL à rediriger, et le navigateur redirigera automatiquement vers la nouvelle URL.

• "304 Not Modified" n'a pas le sens de sauter, indiquant que la ressource n'a pas été modifiée, redirigeant le fichier tampon existant, également appelé redirection de cache, c'est-à-dire indiquant au client de continuer à utiliser la ressource de cache pour le contrôle du cache .

Le code d'état 4xx signifie que le message envoyé par le client est erroné et que le serveur ne peut pas le traiter, ce qui est la signification du code d'erreur.

• "400 Bad Request" indique qu'il y a une erreur dans le message demandé par le client, mais ce n'est qu'une erreur générale.

• "403 Forbidden" signifie que le serveur interdit l'accès aux ressources, pas que la demande du client est erronée.

• "404 Not Found" signifie que la ressource demandée n'existe pas ou n'est pas trouvée sur le serveur, elle ne peut donc pas être fournie au client.

Le code d'état 5xx indique que le message de demande du client est correct, mais qu'une erreur interne s'est produite lors du traitement du serveur, qui appartient au code d'erreur côté serveur.

• "Erreur interne du serveur 500" et les types 400 sont des codes d'erreur généraux et courants. Nous ne savons pas quelle erreur s'est produite sur le serveur.

• "501 Non implémenté" signifie que la fonction demandée par le client n'est pas encore prise en charge, similaire à "ouverture prochaine, veuillez l'attendre avec impatience".

• "502 Bad Gateway" est généralement un code d'erreur renvoyé par le serveur en tant que passerelle ou proxy, indiquant que le serveur lui-même fonctionne normalement et qu'une erreur s'est produite lors de l'accès au serveur principal.

• "503 Service indisponible" signifie que le serveur est actuellement occupé et temporairement incapable de répondre au client, similaire à "le service réseau est occupé, veuillez réessayer plus tard".

champs communs

• héberger
• contentlength (pour résoudre le problème des paquets tcp collants, longueur du corps)
• garder en vie （http 1.1）
• GET POST
  Si vous regardez la sémantique définie par la spécification RFC :
  la méthode GET est sûre et idempotente, car c'est une opération "en lecture seule", peu importe le nombre de fois que l'opération est effectuée, les données sur le serveur sont sûres , et à chaque fois le résultat est Sont les mêmes. Par conséquent, vous pouvez mettre en cache les données de la requête GET.Cette mise en cache peut être effectuée sur le navigateur lui-même (pour éviter que le navigateur n'envoie complètement des requêtes) ou sur le proxy (tel que nginx), et la requête GET dans le navigateur peut être enregistré comme signet.
  Parce que POST est une opération "d'ajout ou de soumission de données", il modifiera les ressources sur le serveur, donc ce n'est pas sûr, et soumettre des données plusieurs fois créera plusieurs ressources, donc ce n'est pas idempotent. Par conséquent, les navigateurs ne mettent généralement pas en cache les requêtes POST et ne peuvent pas non plus enregistrer les requêtes POST sous forme de signets.

cache

• Mise en cache obligatoire Tant que le cache n'a pas expiré, utilisez directement le code d'état du cache du navigateur 200. Utilisez le
  contrôle du cache et expire pour contrôler la période de validité du cache. La priorité du contrôle du cache est supérieure à celle d'expiration.
• Champ de code d'état du cache de négociation 304 si aucun ne correspond et si modifié depuis
  la dernière modification indique l'heure de la dernière modification
  Goose Soup identifie de manière unique la ressource correspondante (priorité plus élevée)
  

protocole http

http1.1

Avantages : l'en-tête et le corps sont faciles à comprendre, simples et faciles à développer, largement utilisés et multiplateformes

Inconvénients : sans état (vous pouvez ajouter des informations sur le cache des cookies), transmission de code en clair, non sécurisé (solution https)

Caractéristiques : connexion longue, réduction des frais généraux causés par la connexion TCP à un établissement répété, réduction de la charge, déconnexion automatique s'il n'y a pas de connexion pendant une longue période

Goulot d'étranglement des performances :

1. Les mêmes informations d'en-tête sont redondantes et inutiles
2. Le mode requête-réponse de blocage en tête de ligne provoque
3. serveur passif

optimisation:

1. Demandes de fusion : remplacez les demandes de plusieurs petites ressources par une demande de grande ressource
2. compression des données

http2.0

1. Compression d'en-tête : le serveur et le client de l'algorithme hpack maintiennent une table d'informations en même temps, envoient un numéro d'index pour améliorer la vitesse
2. Format binaire : transmission de trame, divisée en trame d'informations d'en-tête et trame de données
3. Transmission simultanée : plusieurs flux sont multiplexés dans une connexion TCP
   et différentes requêtes HTTP se distinguent par des ID de flux uniques. L'extrémité réceptrice peut assembler de manière ordonnée des messages HTTP via des ID de flux. Les trames de différents flux peuvent être envoyées dans le désordre, de sorte que différents flux peuvent être simultané, c'est-à-dire que HTTP/2 peut envoyer des requêtes et des réponses en parallèle et entrelacées.
   
4. Server Push
   Le client et le serveur peuvent tous deux créer un flux, et l'ID de flux est également différent. Le flux créé par le client doit être un nombre impair, tandis que le flux créé par le serveur doit être un nombre pair.

Inconvénients :
Le blocage en tête de ligne ne peut pas vraiment être résolu à cause du problème du protocole tcp. Une fois que la perte de paquets se produit, le mécanisme de retransmission TCP sera déclenché, de sorte que toutes les requêtes HTTP dans une connexion TCP doivent attendre que le paquet perdu soit retransmis.

http3.0（rapide）

• Pas de blocage de tête de file d'attente
  QUIC dispose de son propre ensemble de mécanismes pour assurer la fiabilité de la transmission. Lorsqu'une perte de paquets se produit dans un certain flux, seul ce flux sera bloqué et les autres flux ne seront pas affectés, il n'y a donc pas de problème de blocage de tête de ligne
• Établissement de connexion plus rapide
  Le protocole QUIC de HTTP/3 n'est pas en couches avec TLS, mais QUIC contient TLS à l'intérieur, et il transportera le "record" dans TLS dans sa propre trame, plus QUIC utilise TLS/1.3 , donc seulement 1 RTT est nécessaire pour terminer l'établissement de la connexion et l'accord clé "simultanément"
• Migration de connexion
  tcp, lorsque le réseau de l'appareil mobile passe de 4G à WIFI, cela signifie que l'adresse IP a changé, alors la connexion doit être déconnectée puis rétablie. Le protocole QUIC utilise l'ID de connexion pour marquer les deux extrémités de la communication. Le client et le serveur peuvent chacun choisir un ensemble d'ID pour se marquer. Par conséquent, même si le réseau de l'appareil mobile change, ce qui entraîne une modification du Adresse IP, tant que les informations de contexte (telles que l'ID de connexion, la clé TLS, etc.), la connexion d'origine peuvent être réutilisées "de manière transparente", éliminant le coût de la reconnexion, sans le moindre sentiment de bégaiement, et réalisant la fonction de migration de connexion.

protocole https

Par rapport à http, le protocole de sécurité ssl/tsl est ajouté et le protocole de numéro de port (443) nécessite une garantie tierce (CA)

• Le chiffrement hybride
  utilise un chiffrement asymétrique pour échanger des clés et utilise des clés d'échange pour transmettre des informations de manière symétrique
• Algorithmes Digest et signatures numériques
  Calcul des hachages pour s'assurer que le contenu du transfert n'a pas été altéré
• Processus d'établissement d'authentification par un tiers de certificat numérique
  
  (RSA) :
• Envoyer la version du protocole, le nonce et la suite de chiffrement
• Confirmer la version, envoyer un certificat numérique plus un numéro aléatoire
• Utilisez la clé publique dans le navigateur pour obtenir un nombre aléatoire et cryptez un autre nombre aléatoire à envoyer

Le protocole HTTPS lui-même n'a pas de failles jusqu'à présent. Même si vous menez avec succès une attaque de type "man-in-the-middle", il profite essentiellement des failles du client (l'utilisateur clique pour continuer à accéder ou se fait importer de manière malveillante des certificats racine falsifiés). , et ce n'est pas que HTTPS n'est pas assez sécurisé.

Évitez d'être pris par l'intermédiaire grâce à l'authentification HTTPS bidirectionnelle

rsa donne ecdhe

rsa : Étant donné que le client envoie le nombre aléatoire (une des conditions pour générer une clé de chiffrement symétrique) au serveur en utilisant le chiffrement à clé publique, après l'avoir reçu, le serveur le déchiffre avec la clé privée pour obtenir le nombre aléatoire. Ainsi, une fois la clé privée du serveur divulguée, tous les textes chiffrés de communication TLS interceptés par des tiers dans le passé seront piratés.

La différence entre le processus de poignée de main RSA et ECDHE :

• L'algorithme d'accord de clé RSA "ne prend pas en charge" le secret de transmission, et l'algorithme d'accord de clé ECDHE "prend en charge" le secret de transmission ;
• L'algorithme d'accord de clé RSA est utilisé et les données d'application ne peuvent être transmises qu'après que TLS a terminé la prise de contact en quatre. Pour l'algorithme ECDHE, le client peut envoyer des données HTTP chiffrées à l'avance sans attendre la dernière prise de contact TLS du serveur, enregistrer un Le temps aller-retour du message (ne comprends pas);
• En utilisant ECDHE, dans la deuxième poignée de main TLS, il y aura un message "Server Key Exchange" envoyé par le serveur, mais il n'y a pas un tel message dans le processus de poignée de main RSA ;

RPC

RPC (Remote Procedure Call), également connu sous le nom d'appel de procédure à distance. Ce n'est pas un protocole spécifique lui-même, mais une méthode d'appel.

découverte de services

En HTTP, si vous connaissez le nom de domaine du service, vous pouvez le résoudre via le service DNS pour obtenir l'adresse IP derrière lui, qui est le port 80 par défaut.

Pour RPC, il existe généralement un service intermédiaire dédié pour enregistrer le nom du service et les informations IP, comme Consul ou Etcd, ou même Redis. Pour accéder à un service, rendez-vous sur ces services intermédiaires pour obtenir des informations sur l'IP et le port. Étant donné que DNS est également un type de découverte de service, il existe également des composants pour la découverte de service basés sur DNS, tels que CoreDNS.

formulaire de connexion sous-jacent

En prenant le protocole HTTP/1.1 traditionnel comme exemple, il maintiendra la connexion (Keep Alive) après que la connexion TCP sous-jacente soit établie par défaut, et les requêtes et réponses ultérieures réutiliseront cette connexion.

Le protocole RPC, similaire à HTTP, établit également des liens longs TCP pour l'interaction des données, mais la différence est que le protocole RPC crée généralement un pool de connexions pour le multiplexage.

ce qui est transmis

Message basé sur la transmission TCP, en-tête de message + corps de message.
RPC, avec un degré de personnalisation plus élevé, peut utiliser des protocoles Protobuf plus petits ou d'autres protocoles de sérialisation pour enregistrer les données de structure, et n'a pas besoin de prendre en compte divers comportements de navigateur comme HTTP, tels que la redirection 302 et le saut. Par conséquent, les performances seront meilleures, ce qui est également la principale raison de l'abandon de HTTP dans les microservices internes de l'entreprise et du choix d'utiliser RPC.
http2.0 peut en fait être plus performant, mais pour des raisons historiques.

WebSocket

• Le protocole TCP lui-même est en duplex intégral, mais notre protocole HTTP/1.1 le plus couramment utilisé, bien qu'il s'agisse d'un protocole basé sur TCP, est en semi-duplex. Il n'est pas très convivial pour la plupart des scénarios qui nécessitent que le serveur envoie activement des données vers le client , nous devons donc utiliser le protocole WebSocket qui prend en charge le duplex intégral.
• En HTTP/1.1, tant que le client ne demande pas, le serveur ne répond pas. Sur la base de cette fonctionnalité, pour des scénarios simples tels que la page de connexion, vous pouvez utiliser une interrogation régulière ou une interrogation longue pour obtenir l'effet de poussée du serveur (comète).
• Pour les scénarios complexes nécessitant une interaction fréquente entre le client et le serveur, tels que les jeux Web, le protocole WebSocket peut être envisagé.