Vous êtes-vous déjà demandé ce qui se passe lorsque vous cliquez sur un lien ? ? How The Internet Works vous emmène dans les coulisses du monde numérique, décomposant une technologie complexe en informations simples et succinctes. Des paquets de données aux serveurs et au-delà, découvrez la magie qui alimente votre expérience en ligne ! (Hook écrit avec l'aide de l'IA, parce que je ne peux pas :D)
Laissez-moi vous expliquer les actions physiques du clavier et les interruptions du système d'exploitation. Lorsque vous appuyez sur la touche "g", le navigateur enregistre l'événement, déclenchant les fonctions de saisie semi-automatique. En fonction de l'algorithme de votre navigateur et que vous soyez en mode normal ou privé/incognito, diverses suggestions apparaissent dans une liste déroulante sous la barre d'URL.
Ces suggestions sont généralement hiérarchisées et triées en fonction de facteurs tels que votre historique de recherche, vos favoris, les cookies et les recherches Internet populaires. Au fur et à mesure que vous continuez à taper « google.com », de nombreux processus s'exécutent en arrière-plan et les suggestions s'affinent à chaque frappe. Le navigateur peut même prédire « google.com » avant que vous ayez fini de taper.
Parcourir les séquences de saisie semi-automatique
La touche "entrée" touche le fond
Pour établir un point de départ, considérons la touche Entrée d'un clavier lorsqu'elle atteint le bas de sa course. À ce moment, un circuit électrique dédié à la touche Entrée est fermé (soit mécaniquement, soit capacitivement), permettant à un petit courant de circuler dans les circuits logiques du clavier. Ce circuit analyse l'état de chaque interrupteur à clé, filtre le bruit électrique provenant de la fermeture rapide de l'interrupteur (anti-rebond) et traduit l'action en un code clé, dans ce cas, le nombre entier 13. Le contrôleur du clavier code ensuite ce code clé pour la transmission. à l'ordinateur. Aujourd'hui, cela se fait presque toujours via une connexion Universal Serial Bus (USB) ou Bluetooth, bien que les anciens systèmes utilisaient PS/2 ou ADB.
Dans le cas d'un clavier USB :
Diagramme de séquenceDans le cas d'un clavier virtuel (comme sur les appareils à écran tactile) :
Diagramme de séquence décrivant la même chosePour les claviers non USB, tels que ceux utilisant des connexions existantes (par exemple, PS/2), le clavier signale une interruption via sa ligne de demande d'interruption (IRQ). Cette IRQ est mappée sur un vecteur d'interruption (un nombre entier) par le contrôleur d'interruption du système. Le CPU consulte l'Interrupt Descriptor Table (IDT), qui relie chaque vecteur d'interruption à une fonction correspondante appelée gestionnaire d'interruption, fournie par le noyau du système d'exploitation.
Lorsque l'interruption est déclenchée, le CPU utilise le vecteur d'interruption pour indexer dans l'IDT et exécuter le gestionnaire d'interruption approprié. Ce processus provoque la transition du processeur en mode noyau, permettant au système d'exploitation de gérer l'événement de pression de touche.
Lorsque la touche Entrée est enfoncée, le transport HID (Human Interface Device) transmet l'événement de touche au pilote KBDHID.sys, qui convertit les données d'utilisation HID en un code d'analyse. Dans ce cas, le code de numérisation est VK_RETURN (0x0D), représentant la touche Entrée. Le pilote KBDHID.sys communique ensuite avec le pilote KBDCLASS.sys (le pilote de classe du clavier), qui gère en toute sécurité toutes les entrées au clavier. Avant de continuer, le signal peut passer par tous les filtres de clavier tiers installés sur le système, bien que cela se produise également en mode noyau.
Ensuite, Win32K.sys entre en jeu, déterminant quelle fenêtre est actuellement active en appelant l'API GetForegroundWindow(). Cette fonction récupère le handle de fenêtre (hWnd) de l'application active, comme la barre d'adresse du navigateur. À ce stade, la « pompe à messages » Windows appelle SendMessage(hWnd, WM_KEYDOWN, VK_RETURN, lParam). Le paramètre lParam contient un masque de bits qui fournit des informations supplémentaires sur la pression sur la touche, notamment :
L'API SendMessage met le message en file d'attente pour le handle de fenêtre spécifique. Plus tard, la fonction principale de traitement des messages du système (appelée WindowProc) attribuée à la fenêtre (hWnd) récupère et traite les messages dans la file d'attente.
La fenêtre active dans ce cas est un contrôle d'édition et sa fonction WindowProc possède un gestionnaire de messages qui répond aux événements WM_KEYDOWN. Le gestionnaire vérifie le troisième paramètre (wParam) passé par SendMessage, reconnaît que la valeur est VK_RETURN et détermine ainsi que l'utilisateur a appuyé sur la touche Entrée. Cela déclenche la réponse appropriée pour l'application.
Lorsqu'une touche est enfoncée sous OS X, le signal d'interruption déclenche un événement dans le pilote de clavier du kit I/O (une extension du noyau ou "kext"). Ce pilote traduit le signal matériel en un code clé. Le code clé est ensuite transmis au WindowServer, qui gère l'interface utilisateur graphique.
Le WindowServer distribue l'événement d'appui sur une touche aux applications appropriées (telles que celles actives ou en écoute) en l'envoyant via leur Port Mach, où il est placé dans un événement file d'attente. Les applications disposant des privilèges appropriés peuvent accéder à cette file d'attente d'événements en appelant la fonction mach_ipc_dispatch.
La plupart des applications gèrent ce processus via la boucle d'événements principale NSApplication, qui est responsable du traitement des entrées de l'utilisateur. Lorsque l’événement est une pression sur une touche, il est représenté comme un NSEvent de type NSEventTypeKeyDown. L'application lit ensuite cet événement et répond en conséquence, déclenchant tout code lié aux actions de pression sur une touche en fonction du code clé reçu.
Lorsqu'une touche est enfoncée dans un environnement graphique utilisant le serveur X, le serveur X utilise le pilote evdev (périphérique d'événement) pour capturer l'événement de pression de touche. Le code clé du clavier physique est ensuite remappé en un scancode à l'aide de claviers et de règles spécifiques au serveur X.
Une fois le mappage terminé, le serveur X transmet le scancode obtenu au gestionnaire de fenêtres (tel que DWM, Metacity, i3, etc.). Le gestionnaire de fenêtres, à son tour, envoie le caractère ou l'événement clé à la fenêtre actuellement sélectionnée. L'API graphique de la fenêtre ciblée traite cet événement et affiche le symbole correspondant dans le champ approprié, en utilisant la police correcte, en fonction de la touche enfoncée.
Ce flux garantit que le caractère est correctement rendu dans l'interface de l'application active, complétant ainsi l'interaction entre le matériel et la sortie graphique.
Lorsque le navigateur analyse l'URL (Uniform Resource Locator), il extrait les composants suivants :
Chacun de ces composants aide le navigateur à interpréter et à récupérer la ressource souhaitée sur le Web.
Lorsqu'aucun protocole (par exemple "http") ou nom de domaine valide n'est fourni, le navigateur interprète le texte dans la barre d'adresse comme un terme de recherche potentiel. Au lieu d'essayer de le résoudre sous forme d'URL, le navigateur transmet le texte à son moteur de recherche Web par défaut.
Dans la plupart des cas, le navigateur ajoute un identifiant spécial à la requête de recherche, indiquant que la requête provient de la barre d'URL du navigateur. Cela permet au moteur de recherche de gérer et de prioriser ces recherches en conséquence, améliorant ainsi la pertinence des résultats en fonction du contexte.
Ce processus aide le navigateur à déterminer s'il doit tenter de naviguer directement vers un site Web ou fournir des résultats de recherche basés sur le texte saisi.
Le navigateur vérifie d'abord sa liste HSTS (HTTP Strict Transport Security) préchargée, qui contient des sites Web qui ont explicitement demandé à être accessibles uniquement via HTTPS.
Si le site Web demandé se trouve dans cette liste, le navigateur envoie automatiquement la demande en utilisant HTTPS plutôt que HTTP. Si le site Web ne figure pas dans la liste HSTS, la demande initiale est envoyée via HTTP.
Il est important de noter qu’un site Web peut toujours implémenter HSTS sans être inclus dans la liste préchargée. Dans de tels cas, la première requête HTTP effectuée par l'utilisateur renverra une réponse demandant au navigateur d'envoyer uniquement les requêtes suivantes via HTTPS. Cependant, cette requête HTTP initiale pourrait exposer l'utilisateur à une attaque de rétrogradation, où un attaquant pourrait intercepter la requête et la forcer à rester non chiffrée. Cette vulnérabilité est la raison pour laquelle les navigateurs Web modernes incluent la liste HSTS, améliorant ainsi la sécurité des utilisateurs en empêchant l'établissement de connexions non sécurisées.
Le navigateur commence le processus de recherche DNS en vérifiant si le domaine est déjà présent dans son cache. (Pour afficher le cache DNS dans Google Chrome, accédez à chrome://net-internals/#dns.)
Si le domaine n'est pas trouvé dans le cache, le navigateur appelle la fonction de bibliothèque gethostbyname (la fonction spécifique peut varier selon le système d'exploitation) pour effectuer la résolution du nom d'hôte.
Vérification des fichiers d'hôtes locaux :
Demande de serveur DNS :
Processus ARP pour le serveur DNS :
Cette approche systématique garantit que le navigateur résout efficacement les noms de domaine en adresses IP, lui permettant ainsi d'établir une connexion avec le site Web souhaité. En vérifiant d'abord le cache, en utilisant le fichier d'hôtes local et enfin en interrogeant le serveur DNS, le navigateur minimise le temps consacré à la résolution du nom d'hôte.
Diagramme de séquence
Afin d'envoyer une diffusion ARP (Address Resolution Protocol), la bibliothèque de pile réseau a besoin de deux informations clés : l'adresse IP cible qui doit être recherchée et l'adresse MAC de l'interface qui sera utilisée pour envoyer sur la diffusion ARP.
Le cache ARP est d'abord vérifié pour une entrée correspondant à l'adresse IP cible. Si une entrée existe, la fonction bibliothèque renvoie le résultat au format :
IP cible = MAC.
Si l'entrée n'est pas dans le cache ARP :
S'il n'y a aucune entrée pour l'adresse IP cible, les étapes suivantes sont prises :
La bibliothèque réseau construit et envoie une requête ARP de couche 2 (couche liaison de données du modèle OSI) au format suivant : Requête ARP :
En fonction de la configuration matérielle entre l'ordinateur et le routeur, le comportement de la requête ARP varie :
Si l'ordinateur est directement connecté au routeur, le routeur répondra avec une réponse ARP (voir ci-dessous).
Si l'ordinateur est connecté à un hub, le hub diffusera la requête ARP depuis tous ses autres ports. Si le routeur est connecté au même « fil », il répondra par une réponse ARP (voir ci-dessous).
Si l'ordinateur est connecté à un commutateur, le commutateur vérifiera sa table CAM/MAC locale pour identifier le port dont l'adresse MAC est interrogée. Si le commutateur n'a aucune entrée pour l'adresse MAC, il rediffusera la requête ARP vers tous les autres ports. Si le commutateur a une entrée dans sa table MAC/CAM, il enverra la requête ARP uniquement au port qui a l'adresse MAC correspondante.
La réponse ARP aura le format suivant :
Expéditeur MAC : cible:mac:adresse:ici
IP de l'expéditeur : target.ip.goes.here
MAC cible : interface:mac:adresse:ici
IP cible : interface.ip.goes.here
Maintenant que la bibliothèque réseau a obtenu l'adresse IP soit du serveur DNS, soit de la passerelle par défaut, elle peut reprendre son processus DNS :
Une fois que le navigateur reçoit l'adresse IP du serveur de destination, il la combine avec le numéro de port spécifié dans l'URL (où HTTP par défaut est le port 80 et HTTPS le port 443). Le navigateur appelle ensuite la fonction de bibliothèque système nommée socket, demandant un flux de socket TCP à l'aide de AF_INET ou AF_INET6 et SOCK_STREAM.
À ce stade, le paquet est prêt à être transmis via l'une des méthodes suivantes :
Pour la plupart des connexions Internet domestiques ou de petites entreprises, le paquet passera depuis votre ordinateur, éventuellement via un réseau local, puis via un modem (Modulateur/Démodulateur). Ce modem convertit les 1 et les 0 numériques en un signal analogique adapté à la transmission via des connexions téléphoniques, par câble ou sans fil. À l'autre extrémité de la connexion, un autre modem reconvertit le signal analogique en données numériques pour le traitement par le prochain nœud de réseau, où les adresses d'origine et de destination seraient analysées plus en détail.
En revanche, les grandes entreprises et certaines connexions résidentielles plus récentes utiliseront des connexions fibre optique ou Ethernet directes, permettant aux données de rester numériques et d'être transmises directement au nœud de réseau suivant pour traitement.
Finalement, le paquet atteindra le routeur gérant le sous-réseau local. À partir de là, il continuera à voyager vers les routeurs frontières du système autonome (AS), à traverser d’autres AS et finalement à arriver au serveur de destination. En cours de route, chaque routeur extrait l'adresse de destination de l'en-tête IP et l'achemine vers le tronçon suivant approprié. Le champ de durée de vie (TTL) dans l'en-tête IP est décrémenté de un pour chaque routeur qui le traite. Le paquet sera abandonné si le champ TTL atteint zéro ou si le routeur actuel n'a pas d'espace dans sa file d'attente (ce qui peut se produire en raison d'une congestion du réseau).
Ce processus d'envoi et de réception se produit plusieurs fois suivant le flux de connexion TCP :
Copie le (client ISN 1) dans son champ ACK et ajoute l'indicateur ACK pour indiquer qu'il accuse réception du premier paquet.
Le client accuse réception de la connexion en envoyant un paquet qui :
Transfert de données : Les données sont transférées comme suit :
Fermeture de la connexion : Pour fermer la connexion :
Ouverture d'une Socket : Diagramme de Séquence
This handshake process establishes a secure connection between the client and server, ensuring that data transmitted over the connection is protected from eavesdropping and tampering.
Sometimes, due to network congestion or flaky hardware connections, TLS packets may be dropped before reaching their final destination. In such cases, the sender must decide how to react. The algorithm governing this response is known as TCP congestion control. The specific implementation can vary depending on the sender, with the most common algorithms being Cubic on newer operating systems and New Reno on many others.
This congestion control mechanism helps optimize network performance and stability, ensuring that data can be transmitted efficiently while minimizing the impact of packet loss.
If the web browser used was developed by Google, instead of sending a standard HTTP request to retrieve a page, it may attempt to negotiate an "upgrade" from HTTP to the SPDY protocol with the server.
If the client is using the HTTP protocol and does not support SPDY, it sends a request to the server in the following format:
GET / HTTP/1.1 Host: google.com Connection: close [other headers]
Here, [other headers] refers to a series of colon-separated key-value pairs formatted according to the HTTP specification and separated by single newlines. This assumes that the web browser is free of bugs that violate the HTTP specification and that it is using HTTP/1.1. If it were using a different version, such as HTTP/1.0 or HTTP/0.9, it might not include the Host header in the request.
HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after the response is completed. For example:
Connection: close
HTTP/1.1 applications that do not support persistent connections MUST include the "close" connection option in every message.
After sending the request and headers, the web browser sends a single blank newline to the server to indicate that the content of the request is complete.
The server then responds with a response code that denotes the status of the request, structured as follows:
200 OK [response headers]
This is followed by a single newline and then the payload containing the HTML content of www.google.com. The server may either close the connection or, if requested by the headers sent by the client, keep the connection open for reuse in further requests.
If the HTTP headers sent by the web browser contained sufficient information for the web server to determine whether the version of the file cached by the web browser has been unmodified since the last retrieval (for example, if the web browser included an ETagheader), the server may instead respond with:
304 Not Modified [response headers]
This response will have no payload, and the web browser will retrieve the HTML from its cache.
After parsing the HTML, the web browser (and server) repeats this process for every resource (image, CSS, favicon.ico, etc.) referenced in the HTML page. In these cases, instead of GET / HTTP/1.1, the request will be structured as:
GET /$(URL relative to www.google.com) HTTP/1.1
If the HTML references a resource on a different domain than www.google.com, the web browser returns to the steps involved in resolving the other domain, following all steps up to this point for that domain. The Host header in the request will be set to the appropriate server name instead of google.com.
The HTTPD (HTTP Daemon) server is responsible for handling requests and responses on the server side. The most common HTTPD servers include Apache and Nginx for Linux, as well as IIS for Windows.
By following these steps, the HTTPD server efficiently processes incoming requests and returns the appropriate responses to the client.
The primary functionality of a browser is to present the web resources you choose by requesting them from a server and displaying them in the browser window. The resource is typically an HTML document but may also include PDFs, images, or other types of content. The location of the resource is specified by the user using a URI (Uniform Resource Identifier).
The way a browser interprets and displays HTML files is defined by the HTML and CSS specifications, which are maintained by the W3C (World Wide Web Consortium), the standards organization for the web.
Browser user interfaces share many common features, including:
The components of a browser can be broken down as follows:
Chacun de ces composants fonctionne ensemble pour créer une expérience de navigation transparente, permettant aux utilisateurs d'accéder et d'interagir efficacement avec les ressources Web.
Le moteur de rendu commence à récupérer le contenu du document demandé à partir de la couche réseau, généralement par morceaux de 8 Ko. La principale responsabilité de l'analyseur HTML est de transformer le balisage HTML en une représentation structurée appelée arbre d'analyse.
L'arbre de sortie, appelé « arbre d'analyse », se compose d'une hiérarchie d'éléments et de nœuds d'attributs DOM (Document Object Model). Le DOM sert de représentation objet du document HTML, fournissant une interface permettant aux éléments HTML d'interagir avec des scripts externes, tels que JavaScript. La racine de cet arbre est l'objet "Document", et avant toute manipulation de script, le DOM maintient une correspondance presque biunivoque avec le balisage d'origine.
Le HTML ne peut pas être analysé efficacement à l'aide d'analyseurs traditionnels descendants ou ascendants en raison de plusieurs facteurs :
Classements des échanges de crypto-monnaie
La différence entre tas et pile
utilisation de location.reload
que signifie bbs
Logiciel gratuit pour créer des sites Web
Que dois-je faire si mon ordinateur ne s'allume pas ?
si qu'est-ce que ça veut dire
Comment vérifier le plagiat sur CNKI Étapes détaillées pour vérifier le plagiat sur CNKI
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
