Wie funktioniert das Internet? Teil 1

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)

Que se passe-t-il lorsque vous accédez à google.com ?

La touche "g" est enfoncée

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 :

• Le clavier est alimenté par une alimentation de 5 V fournie via la broche 1 du contrôleur hôte USB de l'ordinateur.
• Le code clé généré par la pression sur la touche est stocké dans un registre interne appelé « point final ».
• Le contrôleur hôte USB interroge ce « point de terminaison » environ toutes les 10 ms (l'intervalle minimum défini par le clavier), récupérant le code clé stocké.
• Le code clé est envoyé au moteur d'interface série USB (SIE), où il est converti en un ou plusieurs paquets USB conformément au protocole USB.
• Ces paquets sont transmis sur les lignes D et D (les deux broches du milieu) à un débit maximum de 1,5 Mb/s, car le clavier est classé comme « appareil à faible vitesse » (selon les normes USB 2.0).
• Le contrôleur USB hôte de l'ordinateur décode ce signal série et le pilote du périphérique d'interface humaine (HID) interprète la pression sur la touche. Enfin, l'événement clé est transmis à la couche d'abstraction matérielle du système d'exploitation. Diagramme de séquence

Dans le cas d'un clavier virtuel (comme sur les appareils à écran tactile) :

• Lorsque l'utilisateur touche un écran tactile capacitif, une petite quantité de courant est transférée à son doigt. Cette interaction perturbe le champ électrostatique de la couche conductrice de l’écran, créant une chute de tension au point de contact.
• Le contrôleur d'écran détecte cela et déclenche une interruption, signalant les coordonnées du toucher.
• Le système d'exploitation alerte alors l'application actuellement active qu'un événement de presse s'est produit au sein de son interface graphique, généralement sur un bouton du clavier virtuel.
• L'application de clavier virtuel déclenche une interruption logicielle, qui informe le système d'exploitation d'un événement « touche enfoncée ».
• L'application ciblée reçoit cette notification et traite la pression sur la touche en conséquence. Diagramme de séquence décrivant la même chose

Incendies d'interruption [Pas pour les claviers USB]

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

Eine WM_KEYDOWN-Nachricht wird an die App gesendet (unter Windows).

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:

• Wiederholungszählung (in diesem Fall 0),
• Code scannen (der OEM-spezifisch sein kann, aber normalerweise Standard für VK_RETURN ist),
• Erweiterte Tastenflags (zeigt an, ob auch Zusatztasten wie Alt, Umschalt oder Strg gedrückt wurden, was nicht der Fall war).

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.

Ein KeyDown NSEvent wird an die App gesendet (unter OS X)

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.

Der Xorg-Server lauscht auf Schlüsselcodes (unter GNU/Linux)

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.

URL analysieren

Wenn der Browser die URL (Uniform Resource Locator) analysiert, extrahiert er die folgenden Komponenten:

• Protokoll: „http“ Der Browser versteht, dass dieser das Hyper Text Transfer Protocol verwendet, um mit dem Server zu kommunizieren.
• Ressource: „/“ Dies gibt an, dass der Browser die Hauptseite (Indexseite) der Website abrufen sollte, da der /-Pfad normalerweise auf die Stamm- oder Homepage des Servers verweist.

Jede dieser Komponenten hilft dem Browser, die gewünschte Ressource aus dem Web zu interpretieren und abzurufen.

S'agit-il d'une URL ou d'un terme de recherche ?

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.

Convertir les caractères Unicode non ASCII dans le nom d'hôte

• Le navigateur examine le nom d'hôte à la recherche de tous les caractères qui ne font pas partie de la plage ASCII, en particulier ceux qui ne font pas partie des ensembles a-z, A-Z, 0-9, - ou ..
• Dans ce cas, le nom d'hôte est google.com, qui contient uniquement des caractères ASCII, aucune conversion n'est donc nécessaire. Cependant, si des caractères non-ASCII étaient présents dans le nom d'hôte, le navigateur appliquerait le codage Punycode pour convertir le nom d'hôte en une représentation ASCII valide. Ce processus garantit que tous les caractères du nom d'hôte peuvent être correctement traités par les protocoles réseau.

Vérifier la liste HSTS

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.

Recherche DNS

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.

1. Vérification des fichiers d'hôtes locaux :

   • La fonction gethostbyname vérifie d'abord si le nom d'hôte peut être résolu en référençant le fichier hosts local, dont l'emplacement varie selon le système d'exploitation. Ce fichier est un simple fichier texte qui mappe les noms d'hôte aux adresses IP et peut fournir une résolution rapide sans interroger le DNS.

2. Demande de serveur DNS :

   • Si le nom d'hôte n'est pas mis en cache et est introuvable dans le fichier hosts, le navigateur envoie alors une requête au serveur DNS configuré dans la pile réseau. Ce serveur est généralement le routeur local ou le serveur DNS de mise en cache du FAI, qui stocke les noms précédemment résolus pour accélérer les requêtes futures.

3. Processus ARP pour le serveur DNS :

   • Si le serveur DNS se trouve sur le même sous-réseau, la bibliothèque réseau suit le processus ARP (Address Resolution Protocol) pour résoudre l'adresse IP du serveur DNS, garantissant ainsi que la requête est correctement dirigée au sein du réseau local.
   • Si le serveur DNS se trouve sur un sous-réseau différent, la bibliothèque réseau suit plutôt le processus ARP pour l'adresse IP de la passerelle par défaut, qui agit comme intermédiaire pour acheminer la requête vers le sous-réseau approprié.

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

Processus ARP

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.

Vérification du cache 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 table de routage est consultée pour déterminer si l'adresse IP cible se trouve sur l'un des sous-réseaux répertoriés dans la table de routage locale.
  • S'il est trouvé, la bibliothèque utilise l'interface associée à ce sous-réseau.
  • Sinon, la bibliothèque utilise par défaut l'interface qui se connecte à la passerelle par défaut.
• L'adresse MAC de l'interface réseau sélectionnée est ensuite récupérée.

  Envoi de la demande ARP :

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 :

• Mac de l'expéditeur : interface:mac:adresse:ici
• IP de l'expéditeur : interface.ip.goes.here
• MAC cible : FF:FF:FF:FF:FF:FF (diffusion)
• IP cible : target.ip.goes.here

En fonction de la configuration matérielle entre l'ordinateur et le routeur, le comportement de la requête ARP varie :

Directement connecté :

Si l'ordinateur est directement connecté au routeur, le routeur répondra avec une réponse ARP (voir ci-dessous).

Moyeu:

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

Changer:

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.

• Si le routeur est sur le même « fil », il répondra avec une réponse ARP (voir ci-dessous).

Réponse ARP :

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 :

1. Le client DNS établit une connexion socket au port UDP 53 sur le serveur DNS, en utilisant un port source supérieur à 1023.
2. Si la taille de la réponse dépasse la limite UDP, TCP sera utilisé à la place pour accueillir une réponse plus grande.
3. Si le serveur DNS local ou du FAI ne dispose pas des informations demandées, il lancera une recherche récursive, interrogeant une hiérarchie de serveurs DNS jusqu'à ce que le SOA (Start of Authority) soit atteint, moment auquel la réponse est renvoyée.

Ouverture d'une Socket

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.

Traitement de la couche de transport :

• Cette requête est d'abord traitée par la couche Transport, où un segment TCP est créé. Le port de destination est ajouté à l'en-tête et un port source est choisi dans la plage de ports dynamique du noyau (comme spécifié par ip_local_port_range sous Linux).

Traitement de la couche réseau :

• Ce segment est ensuite envoyé à la couche réseau, qui l'enveloppe dans un en-tête IP supplémentaire. Les adresses IP du serveur de destination et de la machine actuelle sont insérées pour former un paquet.

Traitement de la couche de liaison :

• Le paquet arrive ensuite à la couche liaison, où un en-tête de trame est ajouté. Cet en-tête comprend l'adresse MAC de la NIC (Network Interface Card) de la machine ainsi que l'adresse MAC de la passerelle (routeur local). Si le noyau ne connaît pas l'adresse MAC de la passerelle, il doit diffuser une requête ARP pour la retrouver.

À ce stade, le paquet est prêt à être transmis via l'une des méthodes suivantes :

• Ethernet
• Wi-Fi
• Réseau de données cellulaires

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 :

1. Le client choisit un numéro de séquence initial (ISN) et envoie un paquet au serveur avec le bit SYN défini pour indiquer qu'il définit l'ISN.
2. Le serveur reçoit le SYN et, s'il est d'accord, effectue les opérations suivantes :
   • Choisit son propre numéro de séquence initial.
   • Définit le bit SYN pour indiquer qu'il choisit son ISN.

3. Copie le (client ISN 1) dans son champ ACK et ajoute l'indicateur ACK pour indiquer qu'il accuse réception du premier paquet.

4. Le client accuse réception de la connexion en envoyant un paquet qui :

   • Augmente son propre numéro de séquence.
   • Augmente le numéro d'accusé de réception du destinataire.
   • Définit le champ ACK.

5. Transfert de données : Les données sont transférées comme suit :

   • Lorsqu'un côté envoie N octets de données, il augmente son numéro de séquence (SEQ) de ce nombre.
   • Lorsque l'autre côté accuse réception de ce paquet (ou d'une chaîne de paquets), il envoie un paquet ACK avec la valeur d'accusé de réception (ACK) égale à la dernière séquence reçue de l'autre côté.

6. Fermeture de la connexion : Pour fermer la connexion :

   • Le côté initiant la fermeture envoie un paquet FIN.
   • L'autre côté accuse réception du paquet FIN et envoie son propre FIN.
   • Le côté initiateur reconnaît le FIN de l’autre côté avec un ACK.

Ouverture d'une Socket : Diagramme de Séquence

TLS Handshake

• The client computer sends a ClientHello message to the server, which includes its Transport Layer Security (TLS) version, a list of available cipher algorithms, and compression methods.
• In response, the server replies with a ServerHello message that specifies the TLS version, the selected cipher, the selected compression methods, and the server's public certificate signed by a Certificate Authority (CA). This certificate contains a public key that will be used by the client to encrypt the remainder of the handshake until a symmetric key can be agreed upon.
• The client verifies the server's digital certificate against its list of trusted CAs. If trust can be established based on the CA, the client generates a string of pseudo-random bytes and encrypts this string using the server's public key. These random bytes will be used to determine the symmetric key.
• The server decrypts the random bytes using its private key and utilizes these bytes to generate its own copy of the symmetric master key.
• The client sends a Finished message to the server, encrypting a hash of the transmission that has occurred up to this point with the symmetric key.
• The server generates its own hash and then decrypts the hash sent by the client to verify that it matches. If the hashes match, the server sends its own Finished message back to the client, which is also encrypted with the symmetric key.
• From this point forward, the TLS session transmits application (HTTP) data encrypted with the agreed-upon symmetric key.

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.

If a Packet is Dropped

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.

• The client chooses a congestion window based on the maximum segment size (MSS) of the connection.
• For each packet acknowledged, the congestion window doubles in size until it reaches the 'slow-start threshold.' In some implementations, this threshold is adaptive and can change based on network conditions.
• Once the slow-start threshold is reached, the window increases additively for each packet acknowledged. If a packet is dropped, the window reduces exponentially until another packet is acknowledged.

This congestion control mechanism helps optimize network performance and stability, ensuring that data can be transmitted efficiently while minimizing the impact of packet loss.

HTTP Protocol

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.

HTTP Server Request Handling

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.

1. Receiving the Request: The HTTPD server receives the incoming request from the client.
2. Breaking Down the Request: The server analyzes the request and extracts the following parameters:
   • HTTP Request Method: This could be one of several methods, including GET, HEAD, POST, PUT, PATCH, DELETE, CONNECT, OPTIONS, or TRACE. In the case of a URL entered directly into the address bar, the method will typically be GET.
   • Domain: In this case, the domain is google.com.
   • Requested Path/Page: Here, the requested path is /, indicating that no specific page was requested; thus, / is treated as the default path.
3. Verifying the Virtual Host: The server checks whether a Virtual Host is configured for google.com.
4. Method Verification: The server verifies that google.com can accept GET requests.
5. Client Permission Check: The server checks if the client is allowed to use this method based on criteria such as IP address, authentication, etc.
6. Request Rewriting: If the server has a rewrite module installed (such as mod_rewrite for Apache or URL Rewrite for IIS), it attempts to match the request against any configured rules. If a matching rule is found, the server rewrites the request according to that rule.
7. Content Retrieval: The server retrieves the content that corresponds to the request. In this case, it will typically default to the index file since the request path is /. While there are cases that can override this behavior, using the index file is the most common method.
8. File Parsing and Processing: The server parses the index file according to the designated handler. If Google is using PHP, for example, the server will utilize PHP to interpret the index file and stream the output back to the client.

By following these steps, the HTTPD server efficiently processes incoming requests and returns the appropriate responses to the client.

Browser

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:

• An address bar for entering a URI
• Back and forward buttons for navigation
• Bookmarking options for saving favorite pages
• Refresh and stop buttons for refreshing or halting the loading of current documents
• A home button that takes you to your home page

Browser High-Level Structure

The components of a browser can be broken down as follows:

• Interface utilisateur : Cela inclut la barre d'adresse, les boutons Précédent/Suivant, le menu de favoris et toute autre partie de l'affichage du navigateur, à l'exception de la fenêtre dans laquelle la page demandée est affichée.
• Moteur de navigateur : Le moteur de navigateur agit comme un pont entre l'interface utilisateur et le moteur de rendu, gérant les actions et les interactions.
• Moteur de rendu : Responsable de l'affichage du contenu demandé, le moteur de rendu analyse HTML et CSS, transformant le contenu analysé en une représentation visuelle à l'écran.
• Réseau : Ce composant gère les appels réseau, tels que les requêtes HTTP, et utilise différentes implémentations adaptées à diverses plates-formes tout en fournissant une interface indépendante de la plate-forme.
• UI Backend : Le backend de l'interface utilisateur est responsable du dessin des widgets de base tels que les zones de liste déroulante et les fenêtres. Il expose une interface générique qui n'est spécifique à aucune plateforme et s'appuie sur les méthodes d'interface utilisateur du système d'exploitation.
• Moteur JavaScript : Ce moteur analyse et exécute le code JavaScript, permettant un contenu dynamique et une interactivité au sein des pages Web.
• Stockage des données : Cela agit comme une couche de persistance, permettant au navigateur de sauvegarder localement différents types de données, telles que les cookies. Les navigateurs prennent également en charge des mécanismes de stockage tels que localStorage, IndexedDB, WebSQL et FileSystem.

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.

Analyse HTML

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.

L'algorithme d'analyse

Le HTML ne peut pas être analysé efficacement à l'aide d'analyseurs traditionnels descendants ou ascendants en raison de plusieurs facteurs :

• Nature indulgente du langage : HTML est conçu pour être indulgent avec les erreurs de syntaxe, permettant aux navigateurs d'afficher du contenu même lorsque le balisage n'est pas parfaitement structuré.
• Tolérance aux erreurs du navigateur : Les navigateurs sont conçus pour gérer les cas courants de code HTML non valide, garantissant ainsi aux utilisateurs une expérience fonctionnelle.
• Réentrance du processus d'analyse : Dans d'autres langages de programmation, la source reste inchangée pendant l'analyse. Cependant, en HTML, les éléments dynamiques (comme les balises
  • Eine eingehende Analyse der Bootstrap-Listengruppenkomponente
  • Detaillierte Erläuterung des JavaScript-Funktions-Curryings
  • Vollständiges Beispiel für die Generierung von JS-Passwörtern und die Erkennung der Stärke (mit Download des Demo-Quellcodes)
  • Angularjs integriert WeChat UI (weui)
  • Wie man mit JavaScript schnell zwischen traditionellem Chinesisch und vereinfachtem Chinesisch wechselt und wie Websites den Wechsel zwischen vereinfachtem und traditionellem Chinesisch unterstützen – Javascript-Kenntnisse