Venez jeter un œil aux questions d'entretien de base sur les réseaux informatiques que ByteDance teste fréquemment !

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 :

• Par exemple, passez de http://baidu.com à https://baidu.com

• nom de domaine Remplacé

(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

• https://zhuanlan.zhihu.com/p/86426969

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

• https://juejin.im/post/5e527c58e51d4526c654bf41#heading-38

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 :

• websocket est utilisé pour les données interactives front-end et back-end en temps réel

• ajax non-temps réel

Initiateur :

• Client AJAX initié

• Le serveur WebSocket et le client se poussent mutuellement

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

• https://www.jianshu.com/p/3fc3646fad80

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é.

  • tcp_keepalive_intvl = 15

  • tcp_keepalive_probes = 5

  • tcp_keepalive_time = 1800

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

• https://blog .csdn.net/weixin_37672169/article/details/80283935

• https://www.jianshu.com/p/3fc3646fad80

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

• https://github.com/camsong/blog/ issues/2

(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.

---

• tcp est un protocole de communication de couche transport fiable et orienté connexion.

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

• Retransmission rapide

• Réponse rapide

Seuil de démarrage lent + évitement de congestion

Pour le contrôle de la congestion , TCP maintient principalement deux états principaux :

• Fenêtre de congestion (cwnd)

• Seuil de démarrage lent (ssthresh)

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

(3) Question : Comment le protocole TCP assure-t-il la fiabilité, et pourquoi UDP n'est-il pas fiable ?

• 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

• Performances améliorées :

• Compression d'en-tête

Multiplexage multicanal

Push du serveur

---

Références

• https://juejin.im/post/5d032b77e51d45777a126183

• Pour plus de connaissances sur la programmation, veuillez visiter :
Vidéo de programmation

 ! !