Cet article partagera avec vous certaines des questions d'entretien frontales préférées de ByteDance sur les réseaux informatiques. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il sera utile à tout le monde.
Remarque : Le nombre (xx) apparaissant devant chaque question représente la fréquence de cette question. Cette fondation de réseau informatique est basée sur 30+. articles Les questions et réponses correspondantes, les liens de référence, etc. compilés à partir de l'entretien initial. Le contenu de l'article est compilé par la personne qui a reçu l'offre.
(3) Question : Cache HTTP
Le cache HTTP est divisé en cache fort et cache de négociation :
Vérifiez d'abord si le cache fort est disponible via Cache-Control. Si le cache fort est disponible, alors lisez le cache directement
-
Sinon, entrez dans la phase de cache de négociation. et lance une requête HTTP, le serveur vérifie si la ressource est mise à jour en incluant les champs de requête conditionnelle If-Modified-Since et If-None-Match dans l'en-tête de la requête :
Si le la ressource est mise à jour, alors la ressource et 200 sont renvoyés Code d'état
Si la ressource n'est pas mise à jour, dites au navigateur d'utiliser directement le cache pour obtenir la ressource
( 5) Question : Quels sont les codes d'état et les scénarios d'utilisation couramment utilisés de HTTP ?
1xx : Indique que le protocole est actuellement dans un état intermédiaire et qu'une requête ultérieure est requise
2xx : Indique que la demande a réussi
3xx : indique l'état de redirection et doit être demandé à nouveau
-
4xx : indique une erreur de message de demande
5xx : Erreur côté serveur
Codes d'état courants :
101 Basculer le protocole de requête depuis HTTP vers WebSocket
200 La demande est réussie et il y a un corps de réponse
301 Redirection permanente : sera mise en cache
302 Redirection temporaire : ne mettra pas en cache
304 Accès au cache de négociation
403 Accès au serveur interdit
404 Ressource non disponible trouvée
400 Erreur de requête
500 Erreur côté serveur
-
Serveur 503 occupé
Savez-vous quel est le code d'état 302 ? Quels scénarios 302 avez-vous rencontrés lors de votre navigation sur le Web ?
Et 302 signifie une redirection temporaire. Cette ressource n'est pas accessible temporairement, mais elle est toujours accessible après un certain temps. Généralement, lorsque l'accès aux ressources d'un certain site Web nécessite une autorisation, les utilisateurs. seront nécessaires pour se connecter. Après avoir accédé à la page de connexion et connecté, ils peuvent continuer à y accéder.
301 est similaire, il passera à un nouveau site Web, mais 301 signifie que la ressource de l'adresse consultée a été définitivement supprimée. Vous ne devriez plus accéder à cette adresse à l'avenir. un lors de l'exploration. Remplacez cet ancien par l'adresse. L'adresse renvoyée peut être obtenue à partir de l'en-tête d'emplacement de la réponse renvoyée. Le scénario du 301 est le suivant :
(2) Question : Méthodes de requête HTTP courantes, leurs différences et utilisations ?
http/1.1 précise la méthode de requête suivante :
GET : Acquisition universelle des données
HEAD : Accès aux ressources Méta-informations
POST : Soumettre les données
PUT : Modifier les données
SUPPRIMER : Supprimer les données
CONNECT : Établir un tunnel de connexion pour le serveur proxy
OPTIONS : Répertorier les méthodes de requête qui peuvent être implémentées sur les ressources, souvent utilisé pour le domaine transfrontalier
TRACE : suivez le chemin de transmission demande-réponse
() Q : Quelle est votre compréhension des réseaux informatiques
Couche application, couche présentation, couche session, couche transport, couche réseau, couche liaison de données, couche physique
(3) Q : Qu'est-ce que HTTPS ? Processus spécifique
HTTPS établit une couche de sécurité entre HTTP et TCP. Lorsque HTTP communique avec TCP, il doit d'abord passer par une couche de sécurité, chiffrer le paquet de données, puis le paquet de données chiffré. est transmis à TCP, et le TCP correspondant doit déchiffrer le paquet de données avant qu'il puisse être transmis au HTTP ci-dessus.
Le navigateur transmet une liste de clients_random et de méthodes de cryptage. Une fois que le serveur l'a reçu, il transmet au navigateur une liste de server_random, de méthodes de cryptage et un certificat numérique (y compris la clé publique), puis le navigateur effectue une vérification légale. sur le certificat numérique, si la vérification est réussie, un pre_random est généré, puis chiffré avec la clé publique et transmis au serveur. Le serveur utilise client_random, server_random et pre_random pour chiffrer le secret à l'aide de la clé publique, puis l'utilise. secret comme clé secrète pour les transmissions ultérieures pour crypter et déchiffrer les données.
(4) Question : Poignée de main à trois et vague à quatre
Pourquoi une poignée de main à trois est nécessaire : pour confirmer l'envoi et capacités de réception de l’autre partie.
Poignée de main à trois voies
Processus principal de poignée de main à trois :
Au début, les deux parties sont dans l'état FERMÉ, puis le serveur commence à écouter un certain port et entre dans l'état LISTEN
Ensuite, le le client initie activement une connexion, envoie SYN, puis il devient SYN-SENT par lui-même, seq = x
Une fois que le serveur l'a reçu, il renvoie SYN seq = y et ACK ack = x + 1 (pour le SYN envoyé par le client), Après s'être changé en SYN-REVD
, le client envoie ACK seq = x + 1, ack = y + 1 au à nouveau le serveur, se changeant en état EASTABLISHED, et le serveur reçoit ACK , entrez également ESTABLISHED
SYN nécessite une confirmation par les pairs, donc la sérialisation de ACK doit être augmentée de un. Tout ce qui nécessite une confirmation par les pairs consommera la sérialisation des messages TCP
Pourquoi pas deux fois ?
Impossible de confirmer les capacités d'accueil du client.
Si le client envoie d'abord un message SYN, mais qu'il est bloqué dans le réseau, TCP pensera que le paquet est perdu, puis le retransmettra, et la connexion sera établie avec deux poignées de main.
Attendez que le client ferme la connexion. Mais si le paquet arrive plus tard au serveur, le serveur le recevra, puis enverra la table de données correspondante, et le lien sera établi. Cependant, le client a fermé la connexion à ce moment-là, ce qui entraîne un gaspillage des ressources de liaison.
Pourquoi pas quatre fois ?
Plus de quatre fois, c'est bien, mais trois fois suffisent
Agiter quatre fois
Il est d'abord dans l'état ESTABLISH, puis le client envoie un message FIN avec seq = p, et l'état passe à FIN-WAIT-1
Serveur Après réception, envoyez ACK pour confirmer, ack = p + 1, puis entrez dans l'état CLOSE-WAIT
Une fois que le client l'a reçu, il entre dans l'état FIN-WAIT-2
Après un moment, attendez que les données soient traitées, envoyez à nouveau FIN et ACK, seq = q, ack = p + 1, entrez dans l'étape LAST-ACK
Client Après avoir reçu le FIN, le client entre TIME_WAIT (attendre 2MSL), puis envoie ACK au serveur ack = 1 + 1
Le serveur entre dans l'état CLOSED après l'avoir reçu
Le client doit encore attendre deux MSL à ce moment-là. S'il ne reçoit pas de demande de renvoi du serveur, cela signifie que l'ACK a été reçu. est arrivé avec succès, la vague se termine et le client passe à l'état FERMÉ, sinon procédez ACK Resend
Pourquoi devez-vous attendre 2MSL (durée de vie maximale du segment) :
Parce que si vous n'attendez pas, si le serveur a encore de nombreux paquets de données à envoyer au client, et qu'à ce moment le port client est occupé par une nouvelle application, alors des paquets de données inutiles seront reçus, provoquant une confusion des paquets de données. , le moyen le plus sûr est donc d'attendre que tous les paquets de données envoyés par le serveur soient morts avant de démarrer la nouvelle application.
1 MSL garantit que le dernier message ACK de la partie de clôture active en quatre vagues peut enfin atteindre le pair
1 MSL garantit si le end ne reçoit pas d'ACK, alors le message FIN retransmis peut arriver à
Pourquoi est-ce quatre fois au lieu de trois fois ?
** Si c'est trois fois, alors l'ACK et le FIN du serveur sont combinés en une seule vague. Un délai aussi long peut empêcher un TCP FIN d'atteindre le serveur, et le client continuera alors à le faire. retransmettez-le FIN
Références
Q : Que dois-je faire si la transmission des données est terminée pendant l'interaction et que je ne souhaite toujours pas me déconnecter ? Comment puis-je la maintenir ?
Le champ Connexion du corps de la réponse en HTTP est désigné comme keep-alive
Savez-vous quelque chose sur les fenêtres coulissantes TCP ?
Dans le lien TCP, pour l'expéditeur et le destinataire, TCP doit mettre les données envoyées dans le tampon d'envoi et mettre les données reçues dans Receive tampon. Il arrive souvent que l'expéditeur envoie trop de données et que le destinataire ne puisse pas les digérer. Un contrôle de flux est donc nécessaire, qui consiste à contrôler l'envoi de l'expéditeur via la taille du tampon de réception. Si le tampon de réception de l'autre partie est plein, il ne peut pas continuer à envoyer. Ce processus de contrôle de flux nécessite de maintenir une fenêtre d'envoi du côté de l'envoi et une fenêtre de réception du côté de la réception.
Les fenêtres coulissantes TCP sont divisées en deux types : fenêtre d'envoi et fenêtre de réception.
Références
Q : La différence entre WebSocket et Ajax
Essence Différents
Ajax, qui est du JavaScript et du XML asynchrones, est une technologie de développement Web permettant de créer des applications Web interactives
websocket est un nouveau protocole HTML5 qui implémente le réel. -la communication temporelle entre le navigateur et le serveur
a des cycles de vie différents :
Websocket est une connexion longue, la session est toujours maintenue
ajax sera déconnecté après l'envoi et la réception
Champ d'application :
Initiateur :
Connaissez-vous WebSocket ?
Interrogation longue et interrogation courte, WebSocket est une interrogation longue.
Par exemple, dans un scénario de commerce électronique, l'inventaire des marchandises peut changer, il doit donc être reflété à l'utilisateur à temps, donc le client continuera à envoyer des demandes, puis le serveur continuera à vérifier pour les changements, quel que soit le changement, tout est renvoyé. Il s'agit d'une courte interrogation.
Une interrogation longue signifie que s'il n'y a pas de changement, il ne reviendra pas, mais attendra le changement ou le délai d'attente (généralement plus de dix secondes) avant de revenir. S'il n'y a pas de retour, le client n'en a pas besoin. continuer à envoyer des demandes. La pression des deux côtés est donc réduite.
Lien de référence
Comment HTTP implémente-t-il des connexions longues ? À quel moment le temps expire-t-il ?
En définissant Connection: keep-alive dans l'en-tête (en-tête de requête et de réponse), le protocole HTTP1.0 est pris en charge, mais il est désactivé par défaut depuis HTTP1.1. À partir du protocole, la connexion par défaut est Connexion longue
HTTP a généralement le démon httpd, qui peut définir le délai d'attente de maintien lorsque le lien TCP est inactif pendant plus de cette durée. sera fermé. Vous pouvez également définir le délai d'attente dans l'en-tête HTTP Time
-
Le keep-alive de TCP contient trois paramètres, qui peuvent être définis dans net.ipv4 du noyau système : la connexion TCP est inactive et tcp_keepalive_time est inactif, un paquet de détection se produira. Si aucun ACK n'est reçu de l'autre partie, il sera renvoyé tous les tcp_keepalive_intvl jusqu'à ce que tcp_keepalive_probes soit envoyé, et le lien sera supprimé.
En fait, HTTP n'a pas de liens longs et courts, seules les connexions TCP longues peuvent réutiliser un lien TCP pour lancer plusieurs requêtes HTTP, ce qui peut réduire la consommation de ressources, par exemple. en demandant du HTML en même temps, vous devrez peut-être également demander des JS/CSS/images ultérieures, etc.
Lien de référence
Question : La différence entre l'API Fetch et la Request traditionnelle
fetch est conforme à la séparation des préoccupations, utilise Promise, le L'API est plus riche et prend en charge Async/Await
La sémantique est simple et plus sémantique
Vous pouvez utiliser isomorphic-fetch, l'isomorphisme est pratique
Ressources de référence
(2) Question : Quels types de fichiers peuvent généralement être envoyés par POST, et problématiques de traitement des données
Le texte, les images, les vidéos, l'audio, etc. sont tous acceptables
texte/image/audio/ ou application/json, etc.
Q : Comment TCP garantit-il des principes efficaces de transmission et de contrôle de la congestion.
La fiabilité se reflète dans : avec état, Contrôlable
Avec état signifie que TCP confirmera quels messages ont été envoyés, quels messages le destinataire a reçu et lesquels n'ont pas été reçus, garantissant que les paquets de données arrivent dans l'ordre, et non les paquets sont autorisés. Erreur
Contrôlable signifie que si une perte de paquet se produit ou si l'état du réseau est mauvais, il adoptera son propre comportement, réduira la vitesse d'envoi ou renverra
Ainsi, ce qui précède peut garantir la transmission efficace des paquets de données.
Principe de contrôle de la congestion
La raison en est que l'ensemble de l'environnement réseau peut être particulièrement pauvre et que la perte de paquets est facile, l'expéditeur doit donc Faites attention.
Utilisez principalement trois méthodes :
Seuil de démarrage lent + évitement de congestion
Pour le contrôle de la congestion , TCP maintient principalement deux états principaux :
Utilisez la fenêtre de congestion au niveau de l'expéditeur pour contrôler la taille de la fenêtre d'envoi.
Ensuite, un algorithme de démarrage lent relativement conservateur est utilisé pour s'adapter lentement au réseau. Pendant la période de transmission initiale, l'expéditeur et le destinataire établiront d'abord une connexion via une poignée de main à trois pour déterminer la taille de leur réseau respectif. fenêtres de réception, puis initialisez la fenêtre de congestion des deux parties, puis doublez la taille de la fenêtre de congestion après chaque tour de RTT (délai de réception et de transmission) jusqu'à ce que le seuil de démarrage lent soit atteint.
Ensuite, démarrez l'évitement des congestions. La méthode spécifique d'évitement des congestions consiste à doubler la fenêtre de congestion à chaque tour de RTT avant, et maintenant à en ajouter une à chaque tour.
Retransmission rapide
Pendant le processus de transmission TCP, en cas de perte de paquets, l'extrémité réceptrice enverra un ACK répété, par exemple 5 paquets sont perdus, 6 et 7 sont atteints, puis l'extrémité réceptrice enverra l'ACK du quatrième paquet pour 5, 6 et 7. À ce moment, l'extrémité émettrice reçoit 3 ACK répétés lorsqu'elle se rend compte que le paquet est perdu. , il retransmettra immédiatement au lieu d'attendre le RTO (timeout retransmission time)
Retransmission sélective : ajoutez éventuellement l'attribut SACK à l'en-tête du message, marquez les paquets qui sont arrivés par le bord gauche et le bord droit, puis Retransmettre les paquets manqués
Récupération rapide
Si l'expéditeur reçoit 3 ACK en double et découvre une perte de paquets, c'est comme maintenant L'état du réseau est entré un état de congestion, alors il entrera dans la phase de récupération rapide :
réduira le seuil de congestion à la moitié de la fenêtre de congestion
Puis le la taille de la fenêtre de congestion devient le seuil de congestion
Ensuite, la fenêtre de congestion augmente linéairement pour s'adapter aux conditions du réseau
Q : Qu'est-ce que OPTION faire ? Donnez un exemple d'utilisation d'OPTION ?
est conçu pour envoyer une demande de sonde pour déterminer les contraintes qu'une demande pour une certaine adresse cible doit avoir, puis envoyer la vraie demande en fonction des contraintes.
Par exemple, la pré-vérification des ressources inter-domaines est envoyée en premier à l'aide de la méthode OPTIONS de HTTP. Utilisé pour gérer les requêtes inter-domaines
Q : Connaissez-vous http ? Quel niveau d'accord ? (Couche d'application)
Flexible et évolutif, à l'exception de la fourniture d'espaces pour séparer les mots et de sauts de ligne pour séparer les champs, il n'y a aucune restriction. transmettre uniquement du texte, mais également transmettre toutes les ressources telles que des images et des vidéos
Transmission fiable, basée sur TCP/IP, elle hérite donc de cette fonctionnalité
Demande-réponse, il y en a
Apatride, chaque requête HTTP est indépendante, non pertinente, et pas besoin d'enregistrer les informations de contexte par défaut
Inconvénients :
La transmission de texte clair n'est pas sûre
La réutilisation d'un lien TCP entraînera une congestion des pairs
Aucun Statut Dans un scénario de connexion longue, une grande quantité de contexte doit être enregistrée pour éviter de transmettre une grande quantité d'informations répétées
Q : OSI sept -modèle de couche et modèle TCP/IP à quatre couchesCouche d'application
Couche de présentation
Couche de session
Couche de transport
-
Couche réseau
-
Couche liaison de données
-
Physique couche
- Concept à quatre couches TCP/IP :
-
Couche d'application : couche d'application , couche présentation, couche session : HTTP
-
Couche transport : Couche transport : TCP/UDP
Couche réseau : Couche réseau : IP
Couche liaison de données : Couche liaison de données, couche physique
TCP est un protocole de communication de couche de transport fiable et orienté connexion.
UDP est une couche de transport sans connexion. protocole, hérite des caractéristiques IP et est basé sur un datagramme
Pourquoi TCP est-il fiable ? La fiabilité de TCP se reflète dans l'état et le contrôle
enregistrera avec précision quelles données sont envoyées, quelles données sont reçues par l'autre partie et lesquelles ne sont pas reçues, et garantit cela. les paquets de données arrivent dans l'ordre. Aucune erreur n'est autorisée, c'est avec état
-
Lorsqu'il se rend compte que des paquets ont été perdus ou que l'environnement réseau est médiocre, TCP ajustera son comportement en fonction de situation spécifique, contrôler sa vitesse d'envoi ou redémarrer Ceci est contrôlable
-
Au contraire, UDP est apatride et incontrôlable
Améliorations HTTP 2
Multiplexage multicanal
Push du serveur
! !
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
