Besoin d'une réponse plus technique pour une question d'entrevue sur le fonctionnement d'Internet du début à la fin [fermé]

J'ai eu des entretiens avec 5 personnes distinctes au cours des deux dernières semaines et trois de ces cinq personnes m'ont toutes posé cette question: expliquez ce qui se passe entre le fait de cliquer sur "Google.com" et la page qui s'affiche à l'écran. Fondamentalement, comment fonctionne Internet. Je me dis au bout de trois fois que je ferais mieux de me préparer si jamais je retrouve cette question.

Je sais certaines choses, mais je ne suis pas entièrement convaincu que ma réponse est assez bonne. Fondamentalement, je mentionne que le serveur DNS traduit "google.com" en une adresse IP. Je passe un peu sur TCP / IP, puis je parle du serveur Web qui sert littéralement les pages demandées qui sont renvoyées au navigateur que le navigateur interprète et affiche ensuite.

Comme je l'ai déjà dit, je ne suis pas convaincu que ma réponse soit suffisamment technique. Quelles sont les étapes que je laisse de côté?

Pour ce que ça vaut, deux de ces trois fois ont été dans la même entreprise et je suis rappelé pour une troisième entrevue avec eux, donc je ne peux pas l'avoir bombardé trop fort.

1. Votre navigateur a d'abord le look OS dans son fichier "hosts" pour une entrée qui traduira le nom de domaine en une adresse IP. Il s'agit d'une fonction héritée héritée d'ARPANET, lorsqu'il était possible qu'un seul fichier texte contienne des noms intelligibles pour chaque ordinateur accessible via l'ARPANET, et que chaque ordinateur connecté ait une copie relativement récente. Il avait une valeur restante dans les petits réseaux d'ordinateurs qui ne disposaient pas de NetBIOS ou de protocoles de nommage de nœuds similaires, mais de nos jours, il est tout aussi susceptible d'être une cible pour les pirates (qui peuvent l'utiliser pour contourner DNS et pointer votre ordinateur vers des sites qu'ils contrôlent) comme ayant une utilisation légitime sur un ordinateur client ou son utilisateur / propriétaire.
2. En supposant que votre ordinateur ne dispose pas d'une entrée HOSTS pour ce domaine, votre navigateur envoie une demande UDP au serveur DNS configuré dans les paramètres Internet du système d'exploitation pour la connexion utilisée, en transmettant le "nom d'hôte" alias nom de domaine de la demande (tout entre "http: //" et le premier signe deux-points ou barre oblique suivant ce qui vient ensuite, à savoir "www.google.com"). Ce serveur DNS appartient généralement à votre entreprise ou à votre fournisseur de services Internet local.
   • UDP signifie "Universal Datagram Protocol", et est un protocole de "couche transport" de la même classe que TCP (au-dessus du protocole IP "couche réseau", en dessous des protocoles "couche application" comme HTTP, FTP, SMTP, etc. ). Alors que TCP offre de nombreuses fonctionnalités de vérification des erreurs et de tolérance aux pannes (ajout de données supplémentaires et donc augmentation de la surcharge), UDP adopte une approche beaucoup plus légère, augmentant la bande passante nette des données; le compromis est que le protocole ne prend pas en charge les fonctionnalités disponibles dans TCP comme la division de grandes données en plusieurs paquets (donc les messages doivent être petits) ou la réexpédition de paquets perdus en transit. C'est bon pour les petits messages simples (comme DNS) et pour le streaming, les données de type télémétrie où cela n'a pas d'importance si un paquet est perdu.
3. Ce serveur DNS saura l'une des trois choses suivantes: comment traduire ce nom de domaine directement en une adresse IP (ce qui signifie qu'il s'agit du "serveur de noms faisant autorité" ou ANS pour ce domaine); l'adresse IP de l'ANS ou d'un parent de celui-ci; ou son propre serveur de noms parent qui est plus susceptible de savoir comment atteindre l'ANS. Si le serveur ne traduit pas la demande lui-même, il transmettra la demande "vers le bas" vers un ANS connu, ou "vers le haut" à son NS parent, et ce processus se répète de manière récursive.
   • La "racine" de cette arborescence est un serveur unique qui ne fait que transmettre les demandes qu'il reçoit à l'un des nombreux "domaines de premier niveau" ou serveurs TLD. Il existe, par exemple, un serveur de noms ".com", qui sait comment trouver l'adresse IP de n'importe quel domaine ".com" sur la planète (en transmettant ces demandes aux serveurs de noms de niveau FAI). Ces TLD transmettent des demandes de serveurs de noms de domaine qui ne sont connus par aucun DNS au sein d'une "branche" spécifique d'Internet appartenant à un FAI.
4. Une fois que le serveur de noms faisant autorité est trouvé et a traduit le nom de domaine en une adresse IP, cette adresse est renvoyée au client et à son navigateur. Si un ANS ne peut pas être trouvé dans le «temps de vie» de la demande (TTL; le nombre maximal de fois que la demande doit être transférée entre les serveurs, pour éviter un cycle infini entre des serveurs mal configurés), une erreur est renvoyée au client par le nœud à que la demande "expire" (ou le nœud qui est le serveur faisant autorité pour le domaine mais qui ne peut pas traduire le préfixe de domaine particulier).
5. Le navigateur, pour une connexion HTTP, envoie ensuite une requête "TCP SYN" à l'adresse IP et au port spécifié (ou au port HTTP par défaut de 80) pour établir une connexion. Il s'agit d'une demande au niveau du protocole, superposée à l'en-tête IP "au niveau du réseau", qui contient des informations telles que le port de réponse préféré du client (le "port source"), les préférences de communication TCP telles que la taille du segment, l'échelle de la fenêtre et utilisation de fonctionnalités de protocole facultatives.
6. La demande est acheminée au "niveau de la liaison" (régissant la manière dont les circuits électriques réels sont manipulés pour transmettre les données contenues dans les couches réseau, transport et application) à travers la structure d'Internet; généralement, les données se déplaceront le long d'un câble ou d'une fibre jusqu'au "bureau central" de votre maison ou de votre entreprise (c'est le "dernier kilomètre" et c'est généralement le circuit représentant le plus gros goulot d'étranglement de la bande passante) qui est plus ou moins le "onramp" à l'autoroute de l'information. Le CO a ensuite accès à des canaux à large bande passante (transporteurs T, SONET, etc.) qui transmettent votre demande, ainsi que des milliards d'autres, à travers le monde au CO de la destination, qui la transmet au serveur ou au réseau de destination.
   • Ce «routage IP» fonctionne d'une manière conceptuellement similaire à la résolution DNS; Les FAI "de niveau supérieur" se voient attribuer des réseaux IP entiers de "classe A" (chaque adresse possible étant donné un premier octet connu) par l'ICANN, et les autres FAI savent à qui appartient ce réseau de classe A et comment obtenir les données sur le "front" le plus proche de ce réseau. porte ", en utilisant les informations d'une" table de routage ". Ce FAI de niveau supérieur loue ensuite des blocs d'adresses, certains à des FAI locaux, d'autres directement à des utilisateurs d'entreprise, et ces FAI et sociétés ont des routeurs qui utilisent l'adresse IP (et leurs propres tables de routage) pour déterminer s'il faut envoyer des paquets à d'autres circuits à proximité, latéralement à d'autres routeurs FAI locaux, ou jusqu'à des lignes réseau et des routeurs de niveau supérieur.
7. Le serveur reçoit cette demande (à condition qu'elle ne soit pas rejetée à une couche d'abstraction inférieure comme le socket ou un pare-feu), et s'il décide d'accepter la connexion, il enverra une étape de réponse à la demande "SYN-ACK", les deux accusant réception de la demander et spécifier ses propres préférences (y compris toutes les préférences des clients qu'il peut accepter, mais en changeant celles qu'il ne peut pas ou qui n'ont pas été spécifiées).
8. Si le client prend en charge la communication à l'aide du jeu d'options fourni par le serveur, il enverra une réponse ACK, et maintenant la connexion est "établie".
9. Le navigateur envoie ensuite une requête "HTTP GET". La demande comprend l'URI complet de la ressource demandée par le navigateur (même si nous savons que nous parlons à www.google.com, nous envoyons cette chaîne dans le cadre de la demande afin que le serveur puisse, s'il le souhaite, interpréter davantage le nom de domaine pour diriger la demande). Cette demande peut inclure des "cookies"; des données stockées sur le client qui peuvent être transmises au serveur pour faciliter le traitement de la demande de manière efficace et pratique (comme l'identification des préférences de l'utilisateur).
10. Le serveur reçoit la demande GET et décide d'abord s'il souhaite l'honorer (le serveur a peut-être écouté les demandes vers le port TCP 80, mais attend des messages d'un protocole d'application différent comme FTP ou VoIP; c'est rare pour le port 80 mais plus courant pour les autres types de ports). Nous supposerons qu'il l'accepte; le serveur renvoie ensuite une réponse HTTP contenant la ressource demandée (dans ce cas, le HTML de la page par défaut qui est la page de recherche omniprésente de Google). La réponse peut également inclure des "cookies", que le serveur demande au client de stocker (le client peut ou non le faire).
11. Le HTML est digéré par le navigateur et rendu pour dessiner la page dans la fenêtre du navigateur. Pendant ce temps, davantage de requêtes HTTP GET pour Javascript, des feuilles de style, des images et d'autres données nécessaires pour afficher tout le contenu de la page de la manière prescrite par le HTML sont envoyées par le client et les données résultantes sont fournies par le serveur.
12. À une époque révolue, Google était basé sur des formes statiques; vous avez tapé ce que vous vouliez rechercher dans la zone de texte et appuyez sur "Rechercher" (ou "J'ai de la chance"). Lorsque vous effectuez cette opération, une demande HTTP POST est envoyée par le client au serveur; la demande contient l'emplacement, spécifié par le client, auquel les informations doivent être envoyées, et bien sûr les informations elles-mêmes. Ces informations sont digérées par le serveur, qui les utilise pour rechercher les résultats de la recherche, et le serveur crée une page de ces résultats qu'il vous envoie. Ou, il peut transformer les termes de recherche en une "chaîne de requête" et répondre avec une "redirection"; une demande pour que le navigateur envoie une autre demande à un URI différent spécifié dans le message. Le navigateur le fera, puis le serveur créera et transmettra cette page.
13. Dans les temps modernes, la première page de Google est beaucoup plus dynamique. Lorsque vous tapez, JavaScript qui s'exécute côté client dans le navigateur envoie ce que vous saisissez à Google via un "canal latéral" (il utilise les mêmes protocoles de communication, mais parce que ce n'est pas le navigateur lui-même qui envoie des demandes pour des pages entières , l'écran du navigateur n'est pas complètement effacé et redessiné). Pour la première page, ceci est utilisé pour fournir des conseils de requête (suggestions de saisie automatique pour les choses que vous recherchez peut-être parce que d'autres personnes l'ont fait récemment); sur la page de résultats, il fait la même chose mais peut également être utilisé pour fournir des résultats de recherche en temps réel et redessiner complètement la page, sans nécessiter un rechargement complet de la page par le navigateur. Ces types d'astuces relèvent de la rubrique générale d'AJAX (JavaScript asynchrone et XML,

Ce film , qui est celui qu'ils ont montré à mon étudiant de première année "Introduction à l'informatique" au collège, a les bases illustrées dans un format convivial et analogue. Ce n'est pas technique du tout, mais cela donne un bon aperçu conceptuel des pièces de ce puzzle.

Oublier les mentions de cookies et de pare-feu serait une ou deux choses qui manquent ici. Il y a quelque chose à dire pour l'envoi de cookies afin que "Google.com" puisse reconnaître un utilisateur et afficher une page qui peut être différente pour une personne non connectée à Google. Il y a aussi la question de savoir où la personne recherche: Smartphone, tablette ou ordinateur ordinaire (ordinateur portable ou de bureau)?

Je me demande s'il y a peut-être des questions secondaires que vous étiez censé poser, mais cela ne pourrait pas être un facteur ici. Il s'agit plus d'une question de savoir comment le Web fonctionne, car Internet serait un peu plus large et comprendrait le courrier électronique et d'autres choses que je pense.

Je suppose que c'était plus un test de vos capacités de communication. Pouvez-vous prendre une question plutôt technique et la décomposer pour que technique et non technique la comprenne? À quel type de questions répondriez-vous si l'on vous demandait d'expliquer à quelqu'un qui affiche la page d'accueil "Google.com" sur son navigateur? Faites-vous un tas d'hypothèses ou posez-vous les questions? À certains égards, je vois cela comme un parallèle à une question du tableau blanc où les choses sont laissées assez vagues pour que vous posiez des questions afin de pouvoir donner une réponse correcte précise ou que vous fassiez des hypothèses en donnant une réponse.