Lorsque vous entrez dans une URL, ce qui est arrivé à l'arrière-plan

En tant que développeur de logiciels, vous aurez certainement une compréhension complète et hiérarchique du fonctionnement des applications réseau, et cela comprend également les technologies utilisées dans ces applications: telles que les navigateurs, HTTP, HTML, serveurs Web, traitement des exigences, etc.

Cet article étudiera plus en profondeur ce qui se passe à l'arrière-plan lorsque vous entrez dans une URL ~

1. Tout d'abord, vous devez saisir l'URL souhaitée dans le navigateur : 2. Le navigateur recherche l'adresse IP du nom de domaine

La première étape de la navigation consiste à découvrir son adresse IP en accédant au nom de domaine. Le processus de recherche DNS est le suivant:

Cache de navigateur - Le navigateur cache DNS enregistre pendant un certain temps. Fait intéressant, le système d'exploitation ne dit pas au navigateur le temps de stocker l'enregistrement DNS, afin que différents navigateurs stockent un temps auto-fixé (allant de 2 minutes à 30 minutes). Cache système - Si l'enregistrement requis n'est pas trouvé dans le cache du navigateur, le navigateur passera un appel système (GethostByName dans Windows). Cela vous permet d'obtenir des enregistrements dans le cache système. Cache du routeur - Ensuite, la demande de requête précédente est envoyée au routeur, qui a généralement son propre cache DNS. ISP DNS Cache - La prochaine chose à vérifier est le serveur où l'ISP cache DNS. C'est là que les enregistrements de cache correspondants peuvent généralement être trouvés. Recherche récursive - Le serveur DNS de votre FAI commence par le serveur de noms de domaine, du serveur de noms de domaine .com de niveau supérieur au serveur de noms de domaine de Facebook. Généralement, il y aura des noms de domaine dans le serveur de noms de domaine .com dans le cache des serveurs DNS, de sorte que le processus de correspondance au serveur de niveau supérieur n'est pas si nécessaire.

La recherche récursive DNS est indiquée dans la figure ci-dessous:

DNS est un peu inquiétant, c'est-à-dire que le nom de domaine entier comme wikipedia.org ou facebook.com semble correspondre à une adresse IP distincte. Heureusement, il existe plusieurs façons d'éliminer ce goulot d'étranglement:

Loop DNS est la solution lors du retour de plusieurs IPS lors de la recherche DNS. Par exemple, Facebook.com correspond en fait à quatre adresses IP. Un équilibreur de charge est un périphérique matériel qui écoute une adresse IP spécifique et transmet les demandes réseau à un serveur de cluster. Certains grands sites utilisent généralement cet équilibreur de charge haute performance coûteux. Le DNS géographique améliore l'évolutivité en mappant les noms de domaine à plusieurs adresses IP différentes basées sur l'emplacement géographique de l'utilisateur. De cette façon, différents serveurs ne peuvent pas mettre à jour l'état de synchronisation, mais il est très bon de cartographier le contenu statique. Anycast est une technologie de routage qui mappe plusieurs hôtes physiques avec des adresses IP. Le seul inconvénient est que le protocole Anycast et TCP ne sont pas bien adaptés, ils sont donc rarement utilisés dans ces solutions.

La plupart des serveurs DNS utilisent AnyCast pour obtenir des recherches DNS efficaces et faibles.

3. Le navigateur envoie une demande HTTP au serveur Web

Parce que des pages dynamiques comme les pages d'accueil de Facebook, elles expireront bientôt et même immédiatement dans le cache du navigateur après l'ouverture, et il ne fait aucun doute qu'ils ne peuvent pas les lire.

Ainsi, le navigateur enverra une demande au serveur où se trouve Facebook:

 Obtenez http://facebook.com/ http / 1.1
 Accepter: application / x-ms-application, image / jpeg, application / xaml + xml, [...]
 User-Agent: Mozilla / 4.0 (compatible; MSIE 8.0; Windows NT 6.1; Wow64; [...]
 Codage d'acceptation: gzip, dégonfler
 Connexion: Keep-Alive
 Hôte: Facebook.com
 Cookie: datr = 1265876274 - [...]; Locale = en_us; lsd = ww [...]; c_user = 2101 [...]

Obtenez cette demande définit l'URL à lire: http://facebook.com/. Le navigateur lui-même définit (en-tête d'utilisateur-agent ) et quel type de correspondant (en-tête d'accepter et d'acceptation de codage ) il veut accepter. L'en-tête de connexion nécessite que le serveur ne ferme pas la connexion TCP pour les demandes suivantes.

La demande contient également des cookies pour le nom de domaine stocké par le navigateur. Vous savez peut-être déjà que dans différentes demandes de page, les cookies sont des valeurs clés qui correspondent à l'état d'un site Web. De cette façon, les cookies stockeront le nom d'utilisateur de connexion, le mot de passe attribué au serveur et certains paramètres utilisateur. Les cookies sont stockés dans le client en tant que document texte et envoyés au serveur à chaque demande.

Il existe de nombreux outils pour examiner la demande HTTP d'origine et ses outils correspondants. L'auteur préfère utiliser Fiddler, et bien sûr, il existe d'autres outils comme Firebug. Ces logiciels peuvent être d'une grande aide lors de l'optimisation du site Web.

En plus d'obtenir des demandes, il existe un autre type de demande envoyé, qui est souvent utilisé lors de la soumission des formulaires. Envoyez une demande pour transmettre ses paramètres via l'URL (par exemple: http://robozle.com/puzzle.aspx?id=85). Envoyer la demande envoie ses paramètres après l'en-tête du corps de la demande.

Les barres obliques comme http://facebook.com/ sont cruciales. Dans ce cas, le navigateur peut ajouter en toute sécurité les barres obliques. Pour les adresses comme http://example.com/folderorfile, car le navigateur ne sait pas si FolderorFile est un dossier ou un fichier, il ne peut pas ajouter automatiquement des barres obliques. À l'heure actuelle, le navigateur accède directement à l'adresse sans coupure, et le serveur répondra à une redirection, ce qui entraînera une poignée de main inutile.

4. Réponse de redirection permanente du service Facebook

L'image montre la réponse renvoyée au navigateur par le serveur Facebook:

 Http / 1.1 301 déplacé de façon permanente
 Cache-Control: privé, sans magasin, sans cache, doit-faire-réalider, post-vérification = 0,
 pré-vérifier = 0
 Expire: Sat, 01 janvier 2000 00:00:00 GMT
 Emplacement: http://www.facebook.com/
 P3P: CP = loi DSP
 Pragma: sans cache
 Set-Cookie: Made_Write_Conn = Deleted; expire = thu, 12-feb-2009 05:09:50 GMT;
 chemin = /; domain = .facebook.com; httponly
 Type de contenu: texte / html; Charset = UTF-8
 X-CNECTION: Fermer
 Date: ven, 12 février 2010 05:09:51 GMT
 Longueur du contenu: 0

Le serveur répond à une réponse de redirection permanente 301, de sorte que le navigateur visitera http://www.facebook.com/ au lieu de http://facebook.com/.

Pourquoi le serveur doit-il rediriger au lieu d'envoyer directement le contenu Web que les utilisateurs souhaitent voir? Il y a beaucoup de réponses intéressantes à cette question.

L'une des raisons est liée au classement des moteurs de recherche. Vous voyez, si une page a deux adresses, comme http://www.igoro.com/ et http://igoro.com/, les moteurs de recherche les considéreront comme deux sites Web, entraînant une diminution des liens de recherche pour chacun et ainsi réduisant les classements. Les moteurs de recherche savent ce que signifie la redirection permanente 301, afin qu'ils ne classeront l'accès aux adresses avec www et sans www dans le même classement du site Web.

Une autre chose est que l'utilisation de différentes adresses entraînera la pire dans le cache. Lorsqu'une page a plusieurs noms, il peut apparaître plusieurs fois dans le cache.

5. Adresse de redirection des pistes du navigateur

Maintenant, le navigateur sait que http://www.facebook.com/ est la bonne adresse à accéder, il enverra donc une autre demande GET:

 Obtenez http://www.facebook.com/ http / 1.1
 Accepter: application / x-ms-application, image / jpeg, application / xaml + xml, [...]
 Accept-Language: en-us
 User-Agent: Mozilla / 4.0 (compatible; MSIE 8.0; Windows NT 6.1; Wow64; [...]
 Codage d'acceptation: gzip, dégonfler
 Connexion: Keep-Alive
 Cookie: lsd = xw [...]; c_user = 21 [...]; x-référer = [...]
 Hôte: www.facebook.com

Les informations d'en-tête ont la même signification que dans la demande précédente.

6. Le serveur gère la demande

Le serveur reçoit la demande de récupération, puis traite et renvoie une réponse.

Cela semble être une tâche avant en surface, mais en fait, il y a beaucoup de choses intéressantes au milieu - un site Web simple comme le blog de l'auteur, sans parler d'un site Web comme Facebook!

Logiciel de serveur Web

Le logiciel du serveur Web (comme IIS et Apache) reçoit une demande HTTP, puis détermine le traitement de la demande qui est effectué pour le gérer. Le traitement de la demande est un programme qui peut lire la demande et générer du HTML pour répondre (comme ASP.NET, PHP, Ruby ...).

Pour donner l'exemple le plus simple, le traitement des exigences peut être stocké dans une hiérarchie de fichiers qui mappe la structure d'adresse du site. L'adresse comme http://example.com/folder1/page1.aspx mappera le fichier /httpdocs/folder1/page1.aspx. Le logiciel du serveur Web peut être défini comme le traitement de la demande correspondant manuellement par l'adresse, afin que l'adresse de publication de page1.aspx puisse être http://example.com/folder1/page1.

Demande de traitement

La demande gère la demande de lecture et ses paramètres et cookies. Il lira et mettra à jour certaines données et dira que les données sont stockées sur le serveur. Le traitement des exigences génère ensuite une réponse HTML.

Tous les sites Web dynamiques sont confrontés à une difficulté intéressante - comment stocker les données. La moitié des petits sites Web auront une base de données SQL pour stocker les données. Le stockage de grandes quantités de données et / ou des sites Web fortement visités doit trouver des moyens d'allouer la base de données à plusieurs machines. Les solutions incluent: la rupture (en fonction des valeurs de clé primaire, les tables de données sont diffusées dans plusieurs bases de données), la réplication et les bases de données simplifiées qui utilisent une cohérence sémantique faible.

La délégation du travail au traitement par lots est une technologie bon marché pour maintenir les données à jour. Par exemple, Facebook doit mettre à jour les flux d'actualités avec le temps, mais les fonctions des personnes que vous connaissez avec le support de données ne doivent être mises à jour que chaque nuit (l'auteur devine qu'il est, on ne sait pas comment améliorer la fonction). Les mises à jour du travail par lots peuvent entraîner la dépasse de données moins importantes, mais peuvent rendre les mises à jour des données plus rapidement et plus concises.

7. Le serveur renvoie une réponse HTML

L'image est la réponse générée et renvoyée par le serveur:

 Http / 1.1 200 ok
 Cache-Control: privé, sans magasin, sans cache, doit-faire-réalider, post-vérification = 0,
 pré-vérifier = 0
 Expire: Sat, 01 janvier 2000 00:00:00 GMT
 P3P: CP = loi DSP
 Pragma: sans cache
 Codage du contenu: gzip
 Type de contenu: texte / html; Charset = UTF-8
 X-CNECTION: Fermer
 Codage de transfert:
 Date: ven, 12 février 2010 09:05:55 GMT
 2b3tn @ [...]

La taille de la réponse entière est de 35 Ko, dont la plupart sont transférés sous forme de type blob après tri.

Le terminal codant pour le contenu indique au navigateur que le corps de réponse entier est comprimé à l'aide de l'algorithme GZIP. Après avoir décompressé le bloc blob, vous pouvez voir le HTML attendu comme suit:

 <! Doctype html public - // w3c // dtd xhtml 1.0 strict // en
 http://www.w3.org/tr/xhtml1/dtd/xhtml1-strict.dtd>
 <html xmlns = http: //www.w3.org/1999/xhtml xml: lang = en
 lang = en id = Facebook class = no_js>
 <adal>
 <meta http-equiv = contenu contenu contenu = text / html; charse = utf-8 />
 <méta http-equiv = contenu contenu contenu = en />
 ...

En ce qui concerne la compression, les informations d'en-tête expliquent si cette page est mise en cache, comment le faire si elle est mise en cache, quels cookies doivent être définis (ce point n'est pas trouvé dans la réponse précédente), des informations de confidentialité, etc.

Veuillez noter que le type de contenu est défini sur Text / HTML dans l'en-tête. L'en-tête permet au navigateur de rendre le contenu de réponse dans HTML au lieu de le télécharger sous forme de fichier. Le navigateur décidera comment interpréter la réponse en fonction des informations d'en-tête, mais elle tiendra également compte d'autres facteurs tels que le contenu d'extension d'URL.

8. Le navigateur commence à afficher HTML

Lorsque le navigateur n'accepte pas complètement tous les documents HTML, il commence à afficher cette page:

9. Le navigateur envoie pour obtenir des objets intégrés dans HTML

Lorsque le navigateur affiche HTML, il remarque les balises qui doivent obtenir le contenu des autres adresses. À l'heure actuelle, le navigateur enverra une demande GET pour regagner les fichiers.

Voici quelques URL que nous devons recueillir lors de la visite de Facebook.com:

image

http://static.ak.fbcdn.net/rsrc.php/z12e0/hash/8q2anwu7.gif

http://static.ak.fbcdn.net/rsrc.php/zbs5c/hash/7hwy7at6.gif

… Table de style CSS

http://static.ak.fbcdn.net/rsrc.php/z448z/hash/2Plh8s4n.css

http://stating.ak.fbcdn.net/rsrc.php/zane1/hash/cvtutce.css

… Fichiers JavaScript

http://static.ak.fbcdn.net/rsrc.php/zemoa/hash/c8yzb6ub.js

http://static.ak.fbcdn.net/rsrc.php/z6r9l/hash/cq2lgbs8.js

…

Ces adresses passent par un processus similaire à la lecture HTML. Ainsi, le navigateur recherchera ces noms de domaine dans DNS, envoie des demandes, redirigez, etc.

Mais contrairement aux pages dynamiques, les fichiers statiques permettent au navigateur de les mettre en cache. Certains fichiers peuvent ne pas avoir besoin de communiquer avec le serveur et sont lus directement à partir du cache. La réponse du serveur contient les informations de date limite pour les fichiers statiques, de sorte que le navigateur sait combien de temps ils doivent être mis en cache. De plus, chaque réponse peut contenir un en-tête ETAG (la valeur d'entité de la variable demandée) qui fonctionne comme le numéro de version. Si le navigateur observe que les informations de la version ETAG du fichier existe déjà, le transfert du fichier sera arrêté immédiatement.

Essayez de deviner ce que FBCDN.NET représente dans l'adresse? La réponse intelligente est le réseau de distribution de contenu Facebook. Facebook utilise le Contenu Distribution Network (CDN) pour distribuer des fichiers statiques tels que des images, des tables CSS et des fichiers JavaScript. Par conséquent, ces fichiers seront sauvegardés dans de nombreux centres de données CDN à travers le monde.

Le contenu statique représente souvent la taille de la bande passante du site et peut également être facilement copié via un CDN. Habituellement, les sites Web utilisent des CDN tiers. Par exemple, les fichiers statiques de Facebook sont hébergés par Akamai, le plus grand fournisseur CDN.

Par exemple, lorsque vous essayez de ping static.ak.fbcdn.net, vous pouvez obtenir une réponse d'un certain serveur Akamai.net. Fait intéressant, lorsque vous cinglez à nouveau, le serveur de réponse peut être différent, ce qui signifie que l'équilibrage de charge dans les coulisses commence à fonctionner.

10. Le navigateur envoie une demande asynchrone (AJAX)

Guidé par le grand esprit de Web 2.0, le client reste en contact avec le serveur une fois l'affichage de la page terminé.

Prenez la fonction de chat Facebook comme exemple, il restera en contact avec le serveur pour mettre à jour votre statut d'amis lumineux et gris en temps opportun. Afin de mettre à jour l'état de l'ami de ces avatars, le code JavaScript exécuté dans le navigateur enverra une demande asynchrone au serveur. Cette demande asynchrone est envoyée à une adresse spécifique, qui est une demande de fetch ou d'envoi construite par le programme. Ou dans l'exemple Facebook, le client envoie une demande à http://www.facebook.com/ajax/chat/buddy_list.php pour obtenir les informations de statut en ligne dans votre ami.

En ce qui concerne ce modèle, nous devons parler de l'Ajax - JavaScript asynchrone et XML. Bien qu'il n'y ait aucune raison claire pour laquelle le serveur répond au format XML. Permettez-moi de vous donner un autre exemple. Pour les demandes asynchrones, Facebook renverra des extraits de code JavaScript.

Entre autres choses, l'outil Fiddler vous permet de voir des demandes asynchrones envoyées par votre navigateur. En fait, vous pouvez non seulement servir passivement de spectateur de ces demandes, mais également attaquer activement pour les modifier et les renvoyer. Les demandes de l'Ajax sont si faciles à berner, mais elles font vraiment que les développeurs de jeux en ligne qui marquent les scores sont déprimés. (Bien sûr, ne mentez pas à d'autres comme ça ~)

La fonction de chat Facebook fournit un cas intéressant d'Ajax: pousser les données du serveur vers le client. Étant donné que HTTP est un protocole de demande-réponse, le serveur de chat ne peut pas envoyer de nouveaux messages au client. Au lieu de cela, le client doit interroger le côté serveur toutes les quelques secondes pour voir s'il y a de nouvelles nouvelles.

Le sondage pour ces situations est une technique intéressante pour réduire la charge du serveur. Si le serveur n'a pas de nouveaux messages lorsqu'il est interrogé, il ignore le client. Lorsque le nouveau message du client n'a pas encore expiré, le serveur trouvera la demande inachevée et renverra le nouveau message au client en réponse.