Cycle de vie des requêtes HTTP
J'ai récemment commencé mon travail en tant que développeur de backend d'application web. Je suis un peu coincé dans la compréhension du cycle de vie d'une demande Http.
Ce que j'ai compris c'est
- Chaque demande Http contacte d'abord un serveur DNS qui résout le domaine URL de demande en une adresse IP.
- Après avoir récupéré la demande d'adresse IP du serveur Web lui est transmise (via la demande PUT). Un serveur Web comme Apache gère cette demande et la transmet à l'application qui doit gérer cela.
Après cela, je suis perdu avec
- Comment la réponse est-elle envoyée par l'application à l'utilisateur qui l'a demandée et Apcache y participera-t-il?
- Puis-je voir l'intégralité du flux dans mon navigateur avec certains outils de débogage?
- Quelqu'un peut-il renvoyer quelques liens pour comprendre cela en profondeur?
Je pense que vous vous trompez un peu sur votre compréhension.
Si vous allez sur www.google.com (n'utilisez aucun formulaire, voulez simplement le site), voici ce qui se passe:
- Le navigateur doit d'abord traduire www.google.com en une adresse IP s'il ne le connaît pas déjà. S'il le sait, rien ne se passe à ce stade. S'il ne le connaît pas, il contacte un serveur DNS pour résoudre le nom.
- Ensuite, le navigateur ouvrira une connexion TCP à l'adresse IP de www.google.com et enverra une demande HTTP GET. Dans cet exemple, il sera
GET / HTTP/1.1
Host: www.google.com - Le logiciel serveur recevra cette requête HTTP. Il va en quelque sorte générer une réponse HTTP et la renvoyer via la connexion TCP. La façon dont le serveur fait cela dépend du logiciel serveur. Vous pouvez par exemple brancher le code d'application dans Apache, ou simplement faire Apache renvoyer un fichier à partir du système de fichiers. PHP est une application appelée par certains logiciels, qui génère ensuite la réponse envoyée au navigateur. Lorsque la réponse est envoyée, dans HTTP version 1.0, la connexion est fermée. HTTP 1.1 peut cependant avoir des connexions persistantes.
- Lorsque le navigateur obtient la réponse, il l'affiche généralement à l'écran. La requête HTTP est maintenant terminée. Un clic sur "rechercher" enverra une nouvelle demande au serveur.
GET, PUT, POST, DELETE et autres sont méthodes de requête HTTP . Ils ont une signification particulière que vous pouvez voir dans le RFC.
Cookies sont couramment utilisés pour identifier le même utilisateur sur plusieurs requêtes HTTP, appelées sessions. Par conséquent, ces cookies sont appelés cookies de session
Vous pouvez déboguer la communication à l'aide d'un outil de détection de réseau, par exemple Wireshark . Firefox a un plugin tiers appelé Tamper Data qui peut modifier la demande avant qu'elle ne soit envoyée au serveur.
Le HTTP RFC est une bonne source de la façon dont tout cela fonctionne.
J'espère que ça aide.
Cela fait partie des questions d'entrevue les plus populaires posées dans diverses sociétés de produits.
HTTP est un protocole de demande-réponse. Par exemple, un agent utilisateur lance une demande à un serveur, généralement en ouvrant une connexion TCP/IP à un port particulier sur un hôte (port 80 par défaut). La demande elle-même comprend:
une ligne de demande,
un ensemble d'en-têtes de demande et une entité.
Un serveur HTTP écoutant sur ce port attend que le client envoie un message de demande. Dès réception de la demande, le serveur envoie une réponse qui comprend:
une ligne d'état, un ensemble d'en-têtes de réponse et une entité. L'entité dans la demande ou la réponse peut être considérée simplement comme la charge utile, qui peut être des données binaires. Les autres éléments sont lisibles ASCII caractères. Lorsque la réponse est terminée, le navigateur ou le serveur peut mettre fin à la connexion TCP/IP, ou le navigateur peut envoyer une autre demande.
tandis que le serveur reçoit la demande du navigateur, le navigateur sera lié à un port de l'hôte, l'adresse IP et le numéro de port du navigateur seront joints à la demande qui sera envoyée au serveur. le serveur envoie la réponse à l'adresse IP et au numéro de port
J'ai trouvé cette ressource très utile pour comprendre les étapes suivies au cours de la HTTP lifecycle: assez intéressant en fait, n'était pas au courant de toutes les étapes intermédiaires, en particulier avec la vérification du cache lors de la détermination du IP Address d'une URL.