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.
Wenn der Interrupt ausgelöst wird, verwendet die CPU den Interrupt-Vektor, um in den IDT zu indizieren und den entsprechenden Interrupt-Handler auszuführen. Dieser Vorgang führt dazu, dass die CPU in den Kernel-Modus wechselt, sodass das Betriebssystem das Tastendruckereignis verwalten kann.
Wenn die Eingabetaste gedrückt wird, übergibt der HID-Transport (Human Interface Device) das Tastendruckereignis an den KBDHID.sys-Treiber, der die HID-Nutzungsdaten in einen Scancode umwandelt. In diesem Fall lautet der Scancode VK_RETURN (0x0D) und stellt die Eingabetaste dar. Der KBDHID.sys-Treiber kommuniziert dann mit dem KBDCLASS.sys-Treiber (dem Tastaturklassentreiber), der alle Tastatureingaben sicher verwaltet. Bevor Sie fortfahren, kann das Signal alle auf dem System installierten Tastaturfilter von Drittanbietern durchlaufen, obwohl dies auch im Kernel-Modus geschieht.
Als nächstes kommt Win32K.sys ins Spiel und bestimmt, welches Fenster gerade aktiv ist, indem es die GetForegroundWindow()-API aufruft. Diese Funktion ruft das Fensterhandle (hWnd) der aktiven Anwendung ab, beispielsweise die Adressleiste des Browsers. Zu diesem Zeitpunkt ruft die Windows-„Nachrichtenpumpe“ SendMessage(hWnd, WM_KEYDOWN, VK_RETURN, lParam) auf. Der lParam-Parameter enthält eine Bitmaske, die zusätzliche Informationen zum Tastendruck bereitstellt, einschließlich:
Die SendMessage-API stellt die Nachricht für das spezifische Fensterhandle in die Warteschlange. Später ruft die dem Fenster (hWnd) zugewiesene Hauptnachrichtenverarbeitungsfunktion des Systems (bekannt als WindowProc) Nachrichten in der Warteschlange ab und verarbeitet sie.
Das aktive Fenster ist in diesem Fall ein Bearbeitungssteuerelement und seine WindowProc-Funktion verfügt über einen Nachrichtenhandler, der auf WM_KEYDOWN-Ereignisse reagiert. Der Handler überprüft den dritten von SendMessage übergebenen Parameter (wParam), erkennt, dass der Wert VK_RETURN ist, und stellt somit fest, dass der Benutzer die Eingabetaste gedrückt hat. Dadurch wird die entsprechende Reaktion für die Anwendung ausgelöst.
Wenn unter OS Dieser Treiber übersetzt das Hardwaresignal in einen Schlüsselcode. Der Schlüsselcode wird dann an den WindowServer übergeben, der die grafische Benutzeroberfläche verwaltet.
Der WindowServer sendet das Tastendruckereignis an die entsprechenden Anwendungen (z. B. die aktiven oder hörenden Anwendungen), indem er es über deren Mach-Port sendet, wo es in ein Ereignis eingefügt wird Warteschlange. Anwendungen mit den entsprechenden Berechtigungen können auf diese Ereigniswarteschlange zugreifen, indem sie die Funktion mach_ipc_dispatch aufrufen.
Die meisten Anwendungen verarbeiten diesen Prozess über die NSApplication-Hauptereignisschleife, die für die Verarbeitung von Benutzereingaben verantwortlich ist. Wenn es sich bei dem Ereignis um einen Tastendruck handelt, wird es als NSEvent vom Typ NSEventTypeKeyDown dargestellt. Die Anwendung liest dann dieses Ereignis und reagiert entsprechend, indem sie basierend auf dem empfangenen Tastencode jeden Code im Zusammenhang mit Tastendruckaktionen auslöst.
Wenn in einer grafischen Umgebung mit dem X-Server eine Taste gedrückt wird, verwendet der X-Server den Treiber evdev (Ereignisgerät), um das Tastendruckereignis zu erfassen. Der Tastencode der physischen Tastatur wird dann mithilfe von X-Server-spezifischen Tastenzuordnungen und Regeln in einen Scancode umgewandelt.
Sobald die Zuordnung abgeschlossen ist, leitet der X-Server den resultierenden Scancode an den Fenstermanager (z. B. DWM, Metacity, i3 usw.) weiter. Der Fenstermanager wiederum sendet das Zeichen- oder Tastenereignis an das aktuell fokussierte Fenster. Die grafische API des fokussierten Fensters verarbeitet dieses Ereignis und zeigt das entsprechende Symbol im entsprechenden Feld mit der richtigen Schriftart an, basierend auf der gedrückten Taste.
Dieser Ablauf stellt sicher, dass das Zeichen in der Benutzeroberfläche der aktiven Anwendung korrekt gerendert wird, wodurch die Tastendruckinteraktion von der Hardware bis zur grafischen Ausgabe abgeschlossen wird.
Wenn der Browser die URL (Uniform Resource Locator) analysiert, extrahiert er die folgenden Komponenten:
Jede dieser Komponenten hilft dem Browser, die gewünschte Ressource aus dem Web zu interpretieren und abzurufen.
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 :
