Se lancer avec HTTP

1. Bienvenue dans ce cours !: Bonjour les gars et bienvenue dans ce cours sur le protocole HTTP. m'appelle Alex et je suis ingénieur logiciel qui écrit code utilisé dans ce protocole depuis trois ans. Lorsque j'ai entendu parler de la possibilité de créer un cours pour expliquer comment cela fonctionne, j'étais très impatient d'en développer un. Ce cours sera structuré en dix leçons qui contiennent des étapes pratiques à suivre pour comprendre ce qu' est le protocole HTTP et comment tirer parti de ces connaissances avec le codage. rythme de l'onde T, je vais vous montrer comment vous pouvez voir toutes les demandes faites depuis et vers votre machine, mais pas avant. Je vais expliquer ce que nos méthodes HTTP renvoient des codes gérés par d'autres choses. Si vous êtes intéressé par le fonctionnement d'Internet, envisagez ce cours pour vous. n'y a pas d'autres exigences que la connexion Internet pour le projet de ce cours, sera extrêmement pratique et il vous faudra suivre les étapes présentées dans le cours. Vous pouvez donc commencer votre parcours d'écriture de code avec un énorme bloc de connaissances sous votre ceinture. Il s'agit du protocole HTTP. Nous avons pensé à l'ensemble, je pense que nous vous voyons rarement dans la première leçon. 2. Codes de statut HTTP: Bonjour les gars, et bon retour sur Discourse. Dans cette conférence, nous allons examiner les codes d'état HTTP, également appelés codes de retour. Il s'agit d'un élément fondamental de la communication sur le Web. La raison pour laquelle ces codes de données sont si importants est qu'ils sont émis par un serveur en réponse à la demande d'un client adressée à ce serveur spécifique et qu'ils constituent les informations les plus pertinentes et les plus courtes sur le déroulement de la demande. Le premier chiffre du code d' état indique l'une des cinq classes de réponses standard. Les phrases de message affichées sont typiques, mais toute alternative lisible par l'homme peut être proposée. Comme je le disais, les codes de retour HTTP comportent trois chiffres. Si ces trois chiffres commencent par un, le statut que vous recevez est informatif, ce qui signifie que la demande a été reçue. S'il commence par deux, cela signifie que la demande a été une opération réussie, c' est-à-dire qu'elle a été reçue, comprise et acceptée avec succès . Avec trois, cela signifie qu' une redirection, comme dans le cas d'autres mesures, doit être entreprise pour terminer la demande. S'il commence par quatre, cela signifie que votre demande comportait une erreur client. Une erreur s'est produite côté client et la demande contient une mauvaise syntaxe ou ne peut tout simplement pas être satisfaite. Enfin, si votre code à trois chiffres commence par le chiffre cinq, cela signifie que votre demande comportait une erreur de serveur. Quelque chose s'est mal passé du côté du serveur, par exemple, le serveur peut ne pas répondre à une demande apparemment valide. Passons maintenant en revue les différentes catégories de réponses et listons quelques exemples pour chacune d'entre elles. Pour les réponses informatives, nous avons le code 100 avec le mot clé continue. Cela signifie que le serveur a reçu les en-têtes de demande et que le client doit procéder à l'envoi du corps de la demande Ce code est utilisé dans les situations où le serveur doit confirmer qu'il est prêt à accepter la demande. Par exemple, un utilisateur peut soumettre un fichier volumineux à télécharger sur un service de partage de fichiers. Imaginez que nous transférons, le serveur répond par un continuum de 100 pour indiquer qu'il est prêt à recevoir ce gros fichier et que l'utilisateur peut procéder au téléchargement proprement dit . Nous en avons également 11 avec les mots clés des protocoles de commutation. Le serveur indique ici un changement protocole tel que le passage du protocole HTTP au socket Web. Le client doit suivre ce nouveau protocole pour toute communication ultérieure. Pour la catégorie suivante, nous avons des réponses positives, et nous avons ici un code très connu, qui est 200, suivi du mot-clé okay. Il s'agit du code de réussite le plus courant, indiquant que la demande a été acceptée, que le serveur l'a traitée et que la réponse contient les données ou informations demandées. Imaginons, par exemple, qu'un utilisateur accède à un article de blog et que le serveur répond avec un code d'état de 2 000 K fournit le contenu de blog demandé avec succès. Nous en avons également 21, ce qui signifie créé. Ce code d'état indique que la demande a entraîné la création d'une nouvelle ressource. Il est souvent utilisé pour les demandes de publication ou de vente. Vous pouvez penser à un utilisateur qui soumet un formulaire d'inscription sur un site Web et le serveur répond en indiquant que 21 ont été créés, espoir d'indiquer qu' un nouveau compte utilisateur a été créé avec succès. De plus, en ce qui concerne les messages de réussite, nous en avons 24 pour indiquer qu'il n'y avait aucun contenu tant que le serveur a traité la demande avec succès. Dans ce cas, il n'a aucun corps de réponse à renvoyer au client. Ceci est souvent utilisé pour les demandes de suppression. Si un utilisateur supprime un commentaire sur un réseau social et le serveur répond en indiquant 24 « aucun contenu », il confirme la suppression sans renvoyer de données redondantes supplémentaires Passons aux messages de redirection, nous en avons 31 avec les mots clés « déplacés définitivement ». La ressource demandée a été définitivement déplacée vers une nouvelle URL. Le client doit mettre à jour ses signets ou ses liens en conséquence. Vous pouvez penser à un site Web de commerce électronique qui modifie sa structure d'URL et où l'utilisateur tente d'accéder à une ancienne. Page du produit. Le serveur répond en déplaçant 31, redirigeant définitivement l'utilisateur vers la nouvelle URL du produit Nous avons également ici le code 34 non modifié. Ce statut est utilisé pour indiquer que la version mise en cache de la ressource par le client est toujours valide et qu'il n'est pas nécessaire de la télécharger à nouveau Si un utilisateur accède un site Web américain fréquemment visité, le serveur, reconnaissant que le cache du navigateur de l'utilisateur est à jour, répond en indiquant que ces trois ou quatre réponses ne sont pas modifiées, indiquant que la version mise en cache est toujours valide et qu'aucune nouvelle donnée n'est requise Pour les réponses d'erreur des clients, nous en avons 400, ce qui est une mauvaise demande. Le serveur n'a pas pu comprendre la demande ici en raison d'une syntaxe non valide, paramètres manquants ou peut-être d'autres problèmes liés au site client. Pensez à un utilisateur qui soumet une requête de recherche avec des paramètres non valides sur un site de réservation de voyages, et le serveur répond avec 400 demandes erronées indiquant que la demande ne contient pas d'informations essentielles. De plus, nous en avons 41 pour personnes non autorisées. La demande nécessite l'authentification de l'utilisateur. Le client qui envoie cette demande doit fournir des informations d'identification valides, par exemple un nom d'utilisateur et un mot de passe ou un jeton. Tout cela afin d' accéder à la ressource. Par exemple, si un utilisateur tente d'accéder à un document privé sur un service de stockage dans le cloud sans authentification appropriée, le serveur répondra naturellement en demandant à l'utilisateur de fournir des identification de connexion valides avant recevoir la réponse complète Enfin, nous en avons 43 interdits. Le serveur a compris la demande mais refuse d'y répondre. La demande du client est valide, mais le serveur a décidé de ne pas servir la ressource. Si un utilisateur essaie d'accéder à une section réservée aux administrateurs d'une application Web et que le serveur répond en indiquant 43 interdits, cela indique que l' utilisateur ne dispose pas des autorisations nécessaires pour effectuer cette action. Vous pouvez constater que 41 non autorisées sont reçues lorsque vous ne fournissez aucune information d'identification et 43 entrées interdites lorsque vous fournissez des informations d'identification, mais elles ne disposent pas des autorisations nécessaires. Nous en avons également 44 introuvables ici. La ressource demandée est introuvable sur le serveur. Cela indique que l'URL n'est pas valide ou que la ressource n'existe plus. Si un utilisateur clique sur un lien rompu menant à une page de produit supprimée sur un site Web de commerce électronique, le serveur répondra en indiquant 44 « non trouvé », afin d'informer l'utilisateur que la ressource demandée n'existe plus. Pour les réponses aux erreurs du serveur, nous en avons 500, ce qui signifie Internal Server Error. s'agit d'un message d'erreur générique qui indique qu' une situation inattendue a empêché le serveur de répondre à la demande. C'est un piège pour les erreurs côté serveur. Vous pouvez penser ici à un utilisateur qui tente de passer une commande sur une boutique en ligne, mais en raison d'un problème inattendu sur le serveur, cette demande entraîne une erreur interne de 500. Il est conseillé à l'utilisateur de réessayer ultérieurement. De plus, nous en avons 52 pour une mauvaise passerelle. Ce code d'état indique qu' un serveur agissant en tant que passerelle ou proxy a reçu une réponse non valide d' un serveur en amont, indique souvent des problèmes de réseau. Vous pouvez penser à un utilisateur qui accède à un serveur Web ou une API qui agit comme une passerelle ou un autre service Le serveur de passerelle rencontre un problème lors du transfert de la demande au serveur en amont, ce qui entraîne une réponse de passerelle de 52 lits. Bien entendu, il y a beaucoup plus de codes de retour que ceux que j'ai énumérés, mais si vous en rencontrez un qui n'est pas mentionné ici, vous pouvez le rechercher sur Google et vous serez en mesure de comprendre exactement ce qui s'est passé avec votre demande En ce qui concerne la distinction entre les méthodes HTTP sûres et non sécurisées, cela n'est pas directement lié au code d'état HTTP. Les méthodes sûres telles que get and hand sont conçues pour n'avoir aucun impact significatif sur les ressources. Elles sont généralement associées à des réponses réussies ou informatives. les méthodes peu sûres telles que le put ou le post peuvent avoir diverses réponses en fonction de la situation spécifique, notamment le succès, les erreurs du client et du serveur. En conclusion de cette leçon, les codes de retour HTTP sont essentiels pour comprendre les résultats des requêtes HTTP. Ils fournissent des informations sur le succès, la redirection, les erreurs du client et même les erreurs du serveur associées à une demande donnée. Ces codes constituent un élément fondamental du développement Web et de la résolution aident à la fois les développeurs comme vous et les utilisateurs à diagnostiquer les problèmes et à interpréter les résultats de leurs interactions avec les services Web Tout cela étant dit, je vous remercie d' être restés avec moi jusqu'à la fin de cette conférence, et j'ai hâte de vous voir lors de la prochaine. 3. Méthodes de demande HTTP: Bonjour les gars, et bienvenue dans ce cours. Dans cette conférence, nous allons examiner un concept très important, à savoir les méthodes HTTP. Ils sont souvent appelés verbes HTVP et constituent la base de la communication entre les clients et les serveurs sur le Web mondial Ils définissent les actions qu' un client peut demander à un serveur, agisse de récupérer des données ou de modifier des ressources Dans cette leçon, nous allons explorer les différentes méthodes HTTP, leurs exemples pratiques, leur rôle dans la communication Web, leur classification comme sûre ou non sûre, et le concept fondamental clé de la puissance des objets. Pour commencer, abordons d'abord l'acronyme C RD. Il représente les quatre opérations fondamentales de gestion des données dans une base de données ou un système de stockage de données. Il est couramment utilisé dans le contexte des bases de données et du développement de logiciels des API pour décrire les actions de base qui peuvent être effectuées sur les données. Chaque lettre de l' acronyme correspond à une opération spécifique destinée à créer. L'opération de création implique l'ajout de nouvelles données, enregistrements ou ressources à une base de données ou à un magasin de données. Il s'agit de l'action d'insérer une nouvelle information ou une nouvelle entité Dans le contexte d'une API, cela signifie généralement l'envoi d'une demande pour créer une nouvelle ressource. La lettre R est à lire. Cette opération implique de récupérer ou accéder aux données d'une base de données ou d'un magasin de données Cette opération ne modifie pas les données. Il s'agit de récupérer et de visualiser les informations existantes dans les API Cela correspond souvent à l'envoi d'une demande pour récupérer des données d'une ressource. U signifie mise à jour. Cela implique de modifier les données existantes dans une base de données. Il s'agit de l'action de modifier un enregistrement existant, exemple en le mettant à jour, ses attributs ou son contenu. Dans une API, la mise à jour nécessite généralement l'envoi d'une demande de modification d'une ressource. D signifie suppression, et cette opération consiste à supprimer des données, des enregistrements ou des ressources d' une base de données ou d'un magasin de données. Cela entraîne la suppression permanente des informations spécifiées dans le contexte des API. Cela correspond à l'envoi d'une demande de suppression d'une ressource. Les opérations CRUD sont fondamentales pour la gestion et la manipulation des données Ils servent de base à la création et à l'interaction avec des bases , des services Web et des applications permettant d'effectuer ces tâches essentielles. Lors de la conception d'API ou de l'utilisation de bases de données, les opérations CRUD sont un concept crucial pour les développeurs comme vous, car elles fournissent un moyen standardisé de gérer les données de manière efficace et précise Nous avons d'abord parlé des opérations CRUD car elles sont étroitement liées aux verbes HTTP post, from create, get from read, put from update et delete, comme nous Revenons-en maintenant aux méthodes HTTP. Tout d'abord, nous avons Get It qui permet de récupérer les données d'une ressource probablement identifiée par un paramètre d'identification ou une liste générale contenant tous les éléments de cette ressource. Quelques remarques sur les requêtes get indiquent qu' elles peuvent être mises en cache et mises en favoris Ils restent dans l' historique du navigateur et ne doivent jamais être utilisés pour traiter des données sensibles. De plus, ils ont certaines restrictions concernant la longueur, comme je l'ai dit lors de leur définition. Ils sont utilisés uniquement pour récupérer des données et non pour les modifier sous quelque forme que ce soit. Imaginez que vous utilisez un navigateur Web pour accéder à un site Web d' actualités en ligne. Lorsque vous cliquez sur un article d'actualité, votre navigateur envoie une requête get au serveur du site Web demandant le contenu de l'article. Le serveur répond en renvoyant l'article demandé, ce qui vous permet, en tant que client, de le lire. Ensuite, nous avons le post. Cette méthode HTTP crée une nouvelle ressource et l'envoie pour qu'elle soit traitée par le serveur. Cela n'est pas sûr et peut avoir des effets secondaires sur le serveur ou la ressource. Certaines observations concernant les méthodes de publication sont que, contrairement aux méthodes get, elles ne peuvent pas être mises en cache, mises signet ou même dans l'historique du navigateur De plus, ils n'ont aucune restriction sur la longueur. De plus, le bouton de retour, s'il est cliqué sur la demande de publication, soumettra à nouveau les données Contrairement à une requête Get où cela ne nuira pas à un scénario réel. Imaginez ici que vous utilisez une application de réseau social et que vous décidez de créer une nouvelle publication. Lorsque vous cliquez sur le bouton de publication proprement dit, l'application envoie une demande de publication au serveur, y compris le texte et tout support joint. Le serveur traite votre demande, enregistre le message et le rend visible pour vos abonnés. Ensuite, nous avons mis la méthode HTTP. Cela met à jour une ressource spécifiée, ce qui signifie qu'elle remplace toutes les représentations actuelles de la ressource cible par la charge utile de la demande La principale différence en ce qui concerne les méthodes post et put réside dans les résultats que vous obtenez en les répétant encore et encore. Bien que la méthode put produise toujours le même résultat lorsqu'elle met à jour une ressource à plusieurs reprises, la méthode post aura des effets secondaires si vous essayez saisir deux fois la même entité dans un système. Imaginez que vous avez un blog personnel et que vous remarquez une faute de frappe dans l'un de vos articles publiés Vous utilisez un système de gestion de contenu et apportez des corrections au contenu des articles. Lorsque vous enregistrez les modifications, le CMS envoie une demande mise à jour de l'article sur le serveur, garantissant ainsi que la version corrigée est désormais affichée. Ensuite, nous avons supprimé. Cette méthode demande la suppression d' une ressource à l'URL spécifiée. Il doit supprimer la ressource si elle existe. Imaginons que vous ayez une application de messagerie ouverte, comme le courrier électronique, et que vous souhaitiez encombrer votre boîte de réception en supprimant un e-mail périmé Lorsque vous sélectionnez cet e-mail spécifique et que vous cliquez sur Supprimer, l'application envoie une demande de suppression au serveur de messagerie, qui le supprime de votre boîte de réception. En ce qui concerne le correctif de méthode HTTP, il est utilisé pour appliquer des modifications partielles à une ressource. Il est souvent utilisé lorsque vous souhaitez mettre à jour uniquement un sous-ensemble des données des ressources Imaginez que vous utilisez une application de gestion des tâches pour suivre votre travail. Vous vous rendez compte que la date d'échéance ou qu'une tâche a changé Vous ouvrez donc l'application et ne mettez à jour que la date d'échéance sans modifier les autres détails de la tâche. L'application envoie une demande de correctif au serveur qui modifie uniquement la date d'échéance de la tâche Ensuite, nous avons la tête. Head est similaire à Get, mais il ne demande que les en-têtes de la ressource Sans les données réelles, il est utilisé pour vérifier les ressources affectées aux données ou à l'existence sans transférer l'intégralité du contenu réel. Cela peut être utilisé par exemple si vous naviguez sur un site Web d'achat et souhaitez y acheter un produit. Avant de consulter les détails du produit, cliquez sur le bouton Vérifier la disponibilité. Le site Web envoie une demande préalable au serveur demandant des données formatées telles que la disponibilité des produits, prix et les informations sur les stocks, sans charger la page complète du produit et tous les détails correspondants Enfin, nous avons la méthode des options HTTP. Cette méthode permet de récupérer des informations sur les options de communication disponibles pour une ressource Il permet au client de découvrir quelles méthodes HTTP sont prises en charge par le serveur. Si vous créez une application Web et que vous devez déterminer quelles actions sont prises en charge par un service Web, cette méthode HTTP est essentielle pour vous. L'application envoie une demande d' options au service demandant quelles méthodes sont disponibles pour des ressources spécifiques. Cela permet à votre application de s'adapter aux fonctionnalités des services et de savoir quel type de demande elle peut lui envoyer. Il s'agissait de toutes les méthodes HTTP, mais il y a d'autres concepts clés à comprendre ici. Voyons maintenant comment classer une méthode HTTP. En ce qui concerne ces verbes HTTP, ils peuvent être globalement classés en deux Tout d'abord, les méthodes sûres sont les méthodes HTTP conçues pour n'avoir aucun impact significatif sur les ressources qu'elles ciblent. En d'autres termes, lorsqu'une méthode sûre est utilisée, elle ne doit pas entraîner de modifications ni effets secondaires sur le serveur ou sur la ressource elle-même. Les méthodes HTTP suivantes sont considérées comme sûres et ne devraient pas modifier l'état de la ressource ou du serveur. Il est uniquement destiné à la récupération de données. De plus, head it récupère les métadonnées sans transférer l'intégralité du contenu, ce qui le rend à nouveau sécurisé Nous avons également des méthodes HTTP peu sûres. Il s'agit en revanche de méthodes HTTP susceptibles d'entraîner des modifications de l'état de la ressource ou du serveur. Ils ne sont pas sûrs dans le sens où ils peuvent avoir des effets secondaires tels que la création, la modification ou la suppression de ressources. Les méthodes HTTP suivantes sont considérées comme dangereuses. publier n'est pas considéré comme sûr car il entraîne souvent la création d'une nouvelle ressource ou la modification d'une ressource existante. autres termes, cela modifie ou crée des ressources, n'est donc pas une méthode sûre Supprimer entraîne la suppression de la ressource spécifiée, la rendant intrinsèquement dangereuse Enfin, le patch, bien qu'il soit plus ciblé que le post ou le put, peut tout de même modifier les données des ressources, ce qui en fait une méthode peu sûre. Passons maintenant au terme très important d' idempuissance dans le contexte des méthodes HTTP. L' idempotencie fait référence à la propriété d'une opération dans laquelle le fait d'exécuter la même action plusieurs fois a le même effet qu'une seule fois a le même effet Cela signifie que si vous envoyez une demande idempotente plusieurs fois, l'état du système et la ressource avec laquelle il interagit devraient rester inchangés après la Examinons quelques exemples de méthodes HTTP idempotentes La méthode get est idempotente lorsque vous récupérez des informations avec une requête get Le fait de faire la même demande encore et encore ne devrait pas modifier l'état du serveur ou de la ressource que vous récupérez. La méthode put est également puissante pour les objets. Si vous utilisez la commande put pour mettre à jour une ressource avec certaines données, l' envoi de la même demande de mise en ligne à plusieurs reprises se traduira par le fait que la ressource contiendra les mêmes données à chaque fois. Enfin, nous avons supprimé ici. Il s'agit d'une méthode idempotente, car si vous demandez la suppression d' une ressource à l'aide de la commande delete, l' envoi répété de la demande ne changera rien au fait que la ressource a été supprimée Contrairement aux méthodes idempotentes, les méthodes non idempotentes ont des résultats différents lorsqu'elles ont des résultats différents Par exemple, la méthode post n'est pas idempotente, et les demandes de publication répétées pour créer une ressource peuvent entraîner la création de plusieurs ressources identiques Chaque demande entraîne l'ajout d'une nouvelle ressource. La demande de correctif n'est généralement pas non plus puissante pour un élément. répétition d'une demande de correctif peut mettre à jour une ressource différente à chaque fois si les modifications sont incrémentielles ou dépendent de l' état actuel de la ressource Voyons maintenant pourquoi la puissance des objets est importante. Tout d'abord, les méthodes utilisant des objets puissants contribuent à la résilience du système. Dans les scénarios où des problèmes de réseau, des délais d'attente ou des défaillances de communication surviennent, opérations puissantes peuvent être réessayées en toute sécurité sans provoquer d' effets secondaires involontaires ni La puissance des objets est également étroitement liée à la mise en cache. Lorsqu'une réponse à une requête puissante relative à un élément est mise en cache, demandes suivantes peuvent être satisfaites à partir du cache, ce qui réduit la charge sur le serveur et améliore les performances Les méthodes puissantes des objets garantissent un comportement prévisible. Les développeurs et les utilisateurs peuvent compter sur le fait que la répétition d'une demande n'entraînera pas de résultats différents ou de changements inattendus dans l'état du système. Enfin, la puissance des objets simplifie la gestion des erreurs. Lorsqu'une demande échoue ou est interrompue, nouvelle tentative n'entraîne pas incohérence ni de résultats inattendus En général, lors de la conception d'API, il est essentiel de choisir les méthodes HTTP appropriées pour les différentes opérations et de documenter le comportement puissant de leurs éléments. Cela permet aux clients et aux développeurs comme vous comprendre comment les demandes doivent être traitées et à quoi s'attendre lorsqu' ils interagissent avec l'API. Ceci étant dit, j'espère vraiment que certains des concepts présentés dans cette conférence vous aideront à l'avenir. Et j'ai hâte de vous voir lors des prochaines conférences. 4. Déboguer les requêtes HTTP: Bonjour les gars et bienvenue dans ce cours HTTP. Dans cette conférence, nous allons aborder dépannage et le débogage des requêtes HTTP Parce qu'à mon avis, au moins en tant que développeur, il est très important de comprendre comment dépanner et déboguer efficacement les requêtes HTTP Cette compétence est essentielle pour garantir le bon fonctionnement des applications Web, diagnostiquer et résoudre les problèmes, et offrir une expérience utilisateur fluide Les requêtes HTTP sont au cœur de chaque interaction Web, qu'il s'agisse du chargement d'une page Web, de la soumission d'un formulaire, de la récupération de données depuis un point d'accès ou même de la diffusion de contenu multimédia en continu Tout commence par une requête HTTP. Cependant, ces demandes ne sont pas toujours exemptes d'erreurs. Divers facteurs peuvent entraîner des problèmes tels que des erreurs de configuration du serveur, des problèmes de réseau, des bogues sur le site client ou des conflits entre différents composants Et c'est exactement là qu' intervient cette conférence pour vous aider à comprendre abord, les problèmes courants qui peuvent survenir dans requêtes HTTP sont les premiers à résoudre des problèmes inefficaces. Nous avons ici des erreurs de serveur, car les serveurs peuvent rencontrer diverses erreurs, telles que 44, qui est le code pour introuvable, 500 pour une erreur interne du serveur, ou 53, qui indique un service indisponible. Ces erreurs peuvent être dues à des serveurs mal configurés ou à des problèmes d'application Nous avons également des erreurs du côté du client. Les clients tels que les navigateurs Web peuvent également générer ces erreurs, exemple 400 pour une mauvaise demande ou 43 pour une demande interdite. Cela se produit souvent en raison de problèmes liés à la demande ou aux autorisations du client. Les problèmes de réseau constituent un autre facteur susceptible perturber la communication entre le client et le serveur. Cela inclut des problèmes tels que le DNS, des échecs de résolution, des connexions lentes ou même des pannes complètes du réseau Les violations du partage de ressources entre origines peuvent également bloquer les demandes adressées à un autre domaine. S'il n'est pas configuré correctement, cela peut entraîner des problèmes de sécurité et de fonctionnalité. Enfin, nous avons des erreurs SSL et TLS. Ces deux niveaux de sécurité peuvent être à l'origine d'erreurs. Elles peuvent se produire lorsque les connexions HTTP ne sont pas correctement établies. Ces erreurs peuvent perturber le transfert sécurisé des données. Maintenant, la partie la plus importante de la leçon est le débogage des requêtes HTTP Il peut s'agir d'un processus systématique visant à identifier et à résoudre les problèmes de manière efficace. Voici les étapes à suivre. Tout d'abord, vérifiez les outils de développement du navigateur. La plupart des navigateurs Web modernes proposent des outils de développement qui vous permettent d'inspecter les requêtes réseau. Vous pouvez consulter les en-têtes des demandes et des réponses, les charges utiles et les messages d'erreur Cela se produira dans Google Chrome, par exemple, si vous appuyez sur la touche Ctrl F 12 ou sur la fonction F 12 si vous êtes sur un Mac, puis que vous vous connectez au réseau. Ensuite, vous devez passer en revue les codes d'état HTTP. Ces codes figurant dans la réponse fournissent des informations précieuses sur le résultat de la demande. Familiarisez-vous avec les codes d'état courants pour identifier rapidement le problème. Vous pouvez également inspecter les en-têtes de demande et de réponse. Portez une attention particulière aux en-têtes de demande et de réponse. Ils peuvent révéler des détails essentiels sur le problème, tels que des jetons d'authentification manquants, des types de contenu incorrects ou des problèmes de cours. Ensuite, vous pouvez examiner les données de charge utile si la demande implique un transfert de données Inspectez les anomalies ou les problèmes de charge utile. formats de données incompatibles, des données corrompues ou des paramètres manquants peuvent entraîner des problèmes Vous devriez également consulter les journaux du serveur. Les journaux du serveur peuvent fournir des informations sur ce qui se passe côté serveur. Ils peuvent révéler des erreurs, des problèmes de performances ou, encore une fois, des erreurs de configuration Ensuite, vous pouvez vérifier la connectivité réseau Assurez-vous que votre connexion réseau sur la machine à partir de laquelle vous envoyez des demandes est stable. Parfois, des problèmes de connectivité intermittents peuvent entraîner l'échec des demandes. Enfin, vous pouvez utiliser des outils de débogage en ligne. Plusieurs outils en ligne sont disponibles pour tester et déboguer les requêtes HTTP Ces outils peuvent aider à simuler des demandes, vérifier les en-têtes et à valider les réponses Ici, il convient de mentionner que si vous développez l' application Web dans laquelle l'erreur HTTP se produit, vous pouvez à nouveau appuyer sur la fonction F 12 pour accéder aux outils de développement du navigateur, puis appuyer sur la commande P et rechercher le script dans la fonction F 12 pour accéder aux outils de développement du navigateur, puis appuyer sur la commande P et rechercher lequel vous pensez que l'erreur se produit, y mettre un point de rupture, puis poursuivre le débogage ce que vous pouvez faire en actualisant la page. En ce qui concerne les outils de débogage courants, il en existe plusieurs qui peuvent aider au débogage des requêtes HTTP Tout d'abord, nous avons, bien sûr, Postman. Cet outil de test d'API populaire vous permet d'envoyer et de recevoir des requêtes HTTP, inspecter les en-têtes et d'afficher les réponses Ensuite, nous avons Curl. L'outil de ligne de commande est excellent pour envoyer requêtes HTTP et visualiser les réponses dans un terminal. Nous avons également Hitler, un proxy de débogage Web qui enregistre et inspecte le trafic HTTP et HTTPS entre l'ordinateur sur lequel enregistre et inspecte le trafic HTTP et HTTPS entre l'ordinateur il est installé et Enfin, nous avons Wireshark, qui est un analyseur de protocole réseau qui peut vous aider à résoudre les problèmes au niveau du réseau qui est un analyseur de protocole réseau qui peut vous aider à résoudre les problèmes au niveau du réseau affectant les requêtes HTTP. En matière de résolution des problèmes et de débogage, une collaboration efficace avec votre équipe est essentielle pour résoudre les problèmes complexes liés aux requêtes HTTP Conservez une documentation complète de vos résultats, y compris les messages d'erreur, les journaux et les étapes de débogage Partagez ces informations avec des collègues susceptibles vous aider à diagnostiquer et à résoudre le problème En conclusion, le dépannage et le débogage requêtes HTTP constituent une compétence fondamentale pour les développeurs Web, car le protocole HTTP est le protocole fondamental des interactions Web Être capable d' identifier et de résoudre les problèmes rapidement et efficacement est essentiel pour fournir des applications Web fiables et une expérience utilisateur fluide. En utilisant des outils de développement, en examinant les codes d'état, en inspectant les en-têtes et les charges utiles, vérifiant les journaux du serveur et en utilisant Les développeurs comme vous peuvent diagnostiquer et résoudre les problèmes liés aux requêtes HTTP tout en garantissant le bon fonctionnement de leurs applications. Tout cela étant dit, je vous remercie beaucoup d'être restés à mes côtés jusqu'à la fin de cette conférence. J'espère que cela vous a donné un avantage sur le dépannage et débogage des requêtes HTTP qui vous seront présentées à l'avenir. J'étais X et j'ai hâte de te voir dans le prochain. 5. Qu'est-ce que HTTP ?: Bonjour les gars et bienvenue à nouveau dans ce cours HTTP. Dans cette première conférence, nous allons examiner le protocole HTTP , discuter de ce qu'il est et avoir un aperçu de base son fonctionnement. Pour démarrer, HTTP est un protocole principalement utilisé pour transférer informations sous forme de données sur le World Wide Web. Il fait partie de la suite Internet Protocol. Il définit les commandes et les services utilisés pour transmettre les données des pages Web. Vous pouvez considérer le HTTP comme le fondement de la communication de données ou du Web mondial. Bien entendu, les documents hypertextes incluent des hyperliens vers d'autres ressources auxquelles l'utilisateur qui les voit peut facilement accéder. Par exemple, en cliquant avec la souris ou en touchant l'écran dans un navigateur Web. Le protocole HTTP fonctionne par un serveur. Modèle client. Ici, un client peut être un ordinateur personnel, un ordinateur portable ou même un appareil mobile. Le serveur HTTP est généralement un hôte Web exécutant un logiciel de serveur Web tel que IIS. Par exemple, lorsque vous accédez à un site Web, votre navigateur envoie une demande au serveur Web correspondant et il répond par un code d'état HTTP Si l'URL est valide et que la connexion est créée, le serveur enverra à votre navigateur la page Web au format HTML standard, ainsi que d' autres fichiers connexes. Une autre remarque, digne d'attention ici, serait que le HTTP est un système de réponse aux demandes sans état La connexion est maintenue entre le client et le serveur uniquement pour la demande immédiate. Ensuite, une fois cette demande satisfaite, la connexion est fermée. Une fois que le client HTTP a établi une connexion TCP avec le serveur et lui a envoyé une commande de demande, le serveur renvoie sa réponse et ferme la connexion Aujourd'hui, les codes de retour HTTP les plus courants sont ceux de 200. Cela signifie que la demande réussie, également connue sous le nom de page Web laquelle vous essayez d'accéder, existe. Ensuite, nous avons le code d'état 31, qui signifie déplacé définitivement, et qui est souvent transféré vers une nouvelle URL lors de la réception de ce code. Ensuite, nous avons 41, qui représente la demande non autorisée, et vous avez essentiellement besoin d'une autorisation pour dépasser ce point. Si vous essayez d'accéder à cette URL, vous pouvez également avoir un quatre ou trois, ce qui est interdit, ce qui signifie que l'accès n' est pas autorisé à la page ou au répertoire auquel vous essayez d'accéder via l'URL. Enfin, il existe également 500 pour Internal Server error, ce qui est souvent utilisé par une configuration de serveur incorrecte. Http définit également des commandes, peuvent être similaires à get et post, qui sont utilisées pour gérer la soumission de formulaires sur des sites Web. connexions HTTP cryptées s'effectuent via HTTPS, une extension du protocole HTTP conçue pour une transmission de données sécurisée. Cette connexion sécurisée est rendue disponible par cryptage à l'aide du certificat SSL. Le SSL provient de couche de sockets sécurisée et a également un successeur de nos jours , appelé LS, également connu sous le nom de sécurité de la couche de transport. Il s'agit de protocoles permettant d'établir des liens authentifiés et chiffrés entre les réseaux et les ordinateurs Bien que le protocole SSL soit devenu obsolète avec la sortie de la première version de LS, il est toujours courant de désigner cette technologie associée sous le nom de SSL ou SSL De nos jours, la version la plus récente est le TLS 13. Ne vous inquiétez pas pour le SSL et le HTTPS pour le moment, car cette conférence n'est qu'un aperçu et dans une prochaine conférence, nous aborderons l'ensemble du protocole HTTPS de manière plus détaillée. Les différences entre le HTTP et le HTTPS, etc., pour que vous compreniez en profondeur ces notions. Pour l'instant, revoyons les notions une fois de plus. Dans le protocole HTTP, il existe deux entités. Le client, qui est votre navigateur Web personnel, et le serveur Web lui-même. Ces deux éléments peuvent communiquer, plus précisément lorsque le client fait des demandes au serveur Web et que le serveur renvoie des réponses. Cette communication est structurée en blocs, appelés messages, par opposition à un flux continu de données Dans la prochaine conférence, nous allons examiner le protocole HTTP, ses composants clés et sa structure. Donc, si cela vous semble intéressant, j'ai hâte de vous y voir. Et merci beaucoup d'être restée à mes côtés jusqu'à la fin de cette conférence. 6. Composants HTTP: Bonjour les gars, et bienvenue dans le cours HTTP. Dans cette conférence, nous allons examiner de plus près quels sont exactement les principaux composants clés du protocole HTTP. Je considère qu'il s'agit d'un facteur clé pour que nous puissions comprendre exactement comment fonctionne l'ensemble de ce protocole. Maintenant, il y a bien sûr plus d'entités que le client et le serveur. Dans cette conférence, nous allons les examiner soit s' il existe d'autres serveurs d' autorisation, comme c' est le cas dans le protocole 00 to that O, s'il existe d'autres routeurs ou modems, etc. En tant que collectif, ces entités situées entre le client et le serveur Web sont, après tout, les deux principaux acteurs de ce protocole HTTP. Toutes les autres entités sont appelées proxies. Désormais, l'entité la plus importante du protocole HTTP est l'utilisateur, également appelé client. Cet utilisateur accède à un site Web sur Internet à l'aide d' un outil qui agit en son nom et qui s'appelle un navigateur Web, comme vous le savez peut-être déjà Ou un agent utilisateur en termes spécifiques. Chez cet utilisateur, vous pouvez vous considérer comme chez vous en train de travailler sur votre propre machine. Lorsque vous ouvrez Google Chrome et que vous tapez une URL de Facebook ou d'une plate-forme de réseau social à laquelle vous essayez d'accéder, vous êtes l'utilisateur, la partie la plus importante de ce protocole HTTP. Maintenant, dans tout ce processus, c'est à chaque fois le navigateur qui lance la demande et jamais le serveur Web auquel vous faites la demande. Maintenant, vous remarquerez peut-être que c'est vous qui avez créé le compte de réseau social et que c'est vous qui le vérifiez. L'ensemble du processus provient de vous, le client, et également de l' outil que vous utilisez. Comme je l'ai déjà mentionné, c'est le navigateur Web de votre machine. Maintenant, lorsque vous êtes chargé de vous montrer la page Internet que vous avez demandée avec votre navigateur. Votre navigateur est chargé de récupérer le document HTML représentant ce site Web que vous avez demandé au serveur. Il peut même faire des demandes supplémentaires si cette page contient des références à d'autres ressources qui doivent être récupérées. Par exemple, vous pouvez penser à des images, des PNG, etc., mais la réponse contient toutes les informations et le navigateur les rassemblera dans un document HTML qui vous sera présenté Passons maintenant à l'autre côté de cet échange d'informations qui a lieu dans le cadre de ce protocole nous avons le serveur Web, une entité qui fournit les documents demandés par le client en réponse à sa demande. Ce que nous devons comprendre ici, c'est que même si dans notre conférence nous décrivons ce serveur Web comme une entité unique, dans la plupart des cas aujourd'hui, compte tenu des grandes quantités de données stockées par les entreprises sur leurs serveurs, ce ne sera certainement pas le cas Il ne s'agira pas d'une seule entité derrière le serveur Web. Vous pouvez penser aux données des entreprises de médias sociaux provenant de tous les utilisateurs qui ont un compte chez elles. Et si les utilisateurs se comptent par millions, vous pouvez penser qu'il serait pratiquement impossible de conserver toutes les données sur une seule machine. Le serveur dont nous parlons et qui héberge toutes les informations des utilisateurs est en fait composé d'une multitude de serveurs. Donc, si vous avez déjà vu des entrepôts d'entreprise où ils stockent leurs serveurs, soit dans des films ou que vous pouvez simplement rechercher des serveurs sur le Web, vous verrez ces immenses salles remplies de serveurs Web. Alors tu sauras de quoi je parle. Ils partagent entre eux les informations qu'ils stockent. Ils partagent donc et équilibrent toute la charge qu'ils ont entre eux. Cette multitude de serveurs peut outre adresser des requêtes à des bases de données distantes afin de fournir le document final demandé par le client. Et dans cette base de données, il peut s'agir d'autres informations qu'ils peuvent interroger concernant les utilisateurs ou un autre domaine qui leur est lié Le dernier acteur de ce protocole sont les proxys eux-mêmes qui sont, comme je l'ai déjà mentionné, nombreuses autres machines qui transmettent les messages envoyés par ces deux acteurs principaux, le client et le serveur Ces proxys peuvent être non transparents ou transparents Non transparent signifie qu'ils peuvent le modifier, et transparent signifie qu' ils ne font que le transférer et qu'ils ne modifient sous aucune forme s'ils le modifient Ils ne sont donc pas transparents. Ils peuvent faire beaucoup de choses, comme le filtrer, le mettre en cache dans votre navigateur. Vous pouvez même équilibrer la demande faite par le client en permettant à différents serveurs de commencer à traiter différentes parties de la demande. Ce sont donc les composants clés et les principaux acteurs disponibles dans le protocole HTTP. Dans la prochaine conférence, nous allons examiner de plus près l' ensemble des flux HTTP comment ce protocole fonctionne exactement étape par étape. Merci les gars d'être restés avec moi jusqu'à la fin de cette conférence, et j'ai vraiment hâte de vous voir lors de la prochaine. 7. Le flux de travail HTTP: Bonjour les gars, et bienvenue dans ce cours HTTP. Dans cette conférence, nous allons examiner de plus près le flux de travail HTTP pour comprendre exactement comment fonctionne ce protocole. Nous pouvons parler du flux de travail qui a lieu lorsqu'un client fait une demande au serveur Web afin de mieux comprendre le protocole HTTP. Tout d'abord, comme je l'ai dit, le client ouvrirait une nouvelle connexion ou réutiliserait une connexion ouverte avec le serveur Web Cette connexion peut être de type TCP et sera utilisée, comme vous l'avez peut-être deviné, pour faire la demande proprement dite au serveur Comme vous pouvez le voir ici, encore une fois, le client est celui qui initie l' ensemble du flux de travail, comme nous l'avons vu dans une conférence précédente L'étape suivante consiste à envoyer le message HTTP, qui indique la ressource vous souhaitez récupérer en tant que client, c'est-à-dire la page Web à laquelle vous essayez d'accéder. Une fois que vous aurez reçu une réponse du serveur Web, votre navigateur la lira et l'analysera dans un document HTML lisible par l'homme et esthétique Enfin, la connexion peut être fermée ou utilisée. De plus, pour d'autres flux tels que celui qui vient d'être mentionné, bien entendu. Maintenant, en y réfléchissant, on peut observer que ce flux peut être légèrement différent si nous connaissons le concept de pipeline HTTP et ce que signifie le pipeline HTTP Cela permet donc au client de faire plusieurs demandes à différents serveurs sans avoir à attendre au préalable les réponses précédentes. Parce que ce processus était enseigné comme linéaire auparavant. Mais le pipeline HTTP trouve une solution à tout cela Il s'agissait d'un aperçu général du flux de travail HTTP. Dans la prochaine conférence, nous allons discuter de ce qu'est une URL et plus tard de sa structure exacte. Si cela vous semble intéressant, j'ai hâte de vous y voir. Merci beaucoup d'être restée avec moi jusqu'à la fin de cette conférence. 8. Mise en cache: Bonjour les gars, et bon retour discours sur le protocole HTTP. Dans cette conférence, nous allons parler d' une stratégie fondamentale pour optimiser les performances d'une application Web, la mise en cache. Cela implique le stockage des données et des ressources fréquemment consultées afin de réduire le besoin récupération de données redondantes Cela se traduit par des temps de chargement plus rapides, une meilleure expérience utilisateur et une réduction de la charge du serveur. Lorsqu'il s'agit d'optimiser les performances Web, mise en cache joue un rôle clé Et c'est un concept que tout développeur Web doit comprendre. Mais avant de le comprendre, parlons de la nécessité et de l'importance de la mise en cache. Les applications Web reposent sur le transfert de données entre des clients qui sont généralement des navigateurs Web et des serveurs. Nous avons déjà parlé de l'ensemble de ce flux dans une leçon précédente. Chaque demande de ressource telle qu'une page HTML, un fichier Javascript ou une image nécessite un trajet aller-retour entre le client et le serveur Le temps qu'il faut. Cet aller-retour peut avoir un impact significatif sur la perception qu'a l'utilisateur de la rapidité et de la réactivité d' un site Web La mise en cache permet de relever ce défi en stockant des copies des ressources à différents emplacements, qui réduit le besoin de récupérer les mêmes données à Il accélère la diffusion du contenu à l'utilisateur et minimise la charge sur les serveurs La mise en cache peut se produire à différents niveaux de l'architecture Web Du côté client aux serveurs intermédiaires et réseaux de diffusion de contenu, également appelés CDN. Examinons maintenant les types de mise en cache qui existent Tout d'abord, nous avons la mise en cache du navigateur. Les navigateurs Web conservent leurs caches locaux, lesquels ils stockent des ressources telles que des feuilles de style, des images et des scripts Lorsqu'un utilisateur revisite un site Web, le navigateur peut récupérer ces ressources de son cache, permet d'économiser du temps et de la bande passante Vous pouvez penser à l'image d' une page Web et elle est mise en cache par le navigateur de l'utilisateur Lorsque l'utilisateur accède à une autre page du même site, l' image est chargée à partir du cache local, réduit le besoin d' une demande au serveur Le deuxième type de cache est appelé mise en cache CDN, ou réseau de diffusion de contenu CDN sont des réseaux distribués de serveurs placés stratégiquement dans différents emplacements géographiques Ils mettent en cache et diffusent le contenu depuis des emplacements proches de l'utilisateur. En stockant et en diffusant du contenu à partir de serveurs H, les CDN peuvent réduire considérablement latence et améliorer les temps de chargement auxquels l'utilisateur sera confronté Un site Web utilise un CDN pour diffuser ses images. Supposons que lorsqu'un utilisateur en Europe accède au site, les images soient diffusées depuis un serveur CDN situé à proximité plutôt que depuis le serveur d'origine, ce qui réduit le temps de chargement Troisièmement, nous avons la mise en cache des serveurs proxy dans les réseaux d'entreprise Les serveurs proxy sont souvent utilisés pour mettre en cache les sites Web externes fréquemment consultés. Cela améliore non seulement les performances, mais permet également d'économiser de la bande passante en réduisant la quantité de données extraites à plusieurs reprises depuis des serveurs externes Par exemple, le serveur proxy d'une entreprise met en cache les sites Web externes fréquemment consultés, améliore les performances et permet également d' ce qui améliore les performances et permet également d' économiser de la bande passante Dans le protocole HTTP, il existe des en-têtes de cache, le protocole SCTP, sous-jacent Le Web mondial inclut plusieurs en-têtes de mise en cache qui indiquent aux clients et aux intermédiaires comment mettre en cache et valider les ressources Ces en-têtes sont essentiels pour contrôler et optimiser la mise en cache des ressources Web Ces en-têtes sont comme les autres en-têtes dont nous avons parlé, les en-têtes d' autorisation, etc., mais ils sont appelés balise de contrôle du cache et modifiés pour la dernière fois. L'en-tête de contrôle du cache définit les directives Par exemple, le maximum H pour définir la durée maximale pendant laquelle une ressource est considérée comme fraîche. Une étiquette d'entité, représentée par l'en-tête de balise, est un identifiant unique pour une ressource. Lorsqu'une ressource change, la balise change, ce qui permet aux clients de vérifier si la ressource est toujours valide. L' en-tête de dernière modification indique l' heure de dernière modification d'une ressource. Cela permet aux clients de vérifier si leur copie mise en cache est toujours actuelle et pertinente En matière de mise en cache, les développeurs peuvent appliquer plusieurs stratégies La première est appelée destruction du cache, et elle est utilisée lorsque les ressources changent fréquemment Les développeurs peuvent associer des numéros de version ou des paramètres de requête uniques aux URL des ressources, forçant ainsi les navigateurs à récupérer le contenu le Ensuite, vous pouvez exploiter les caches du navigateur. Les développeurs peuvent optimiser les URL des ressources et définir en-têtes de contrôle du cache appropriés afin maximiser les avantages de la mise en cache du navigateur Enfin, vous pouvez utiliser des CDN. Les réseaux de diffusion de contenu sont très efficaces pour le téléchargement des ressources du serveur et la diffusion de contenu pour les serveurs situés à proximité, améliorant ainsi les performances La mise en cache et l'optimisation des performances présentent de nombreux avantages cache et l'optimisation des performances Ils incluent une latence réduite, car la mise en cache réduit considérablement le temps nécessaire au chargement des ressources, ce qui se traduit par une expérience utilisateur plus rapide Ils minimisent également la charge du serveur en fournissant des ressources de mise en cache Les serveurs n' ont plus à gérer les demandes répétées pour le même client. Vous économiserez également de la bande passante. mise en cache permet d'économiser de la bande passante en réduisant la quantité de données transférées entre les serveurs et Nous avons également amélioré l' expérience utilisateur, car des temps de chargement plus rapides et des applications plus réactives améliorent l'expérience et la satisfaction des utilisateurs. Bien que la mise en cache et l'optimisation des performances soient très avantageuses, il convient de garder à l' esprit certains défis et considérations lors de leur mise en œuvre Tout d'abord, vous devez faire attention à l'expérience utilisateur. trouver un équilibre entre égard, il est essentiel de trouver un équilibre entre sécurité et commodité pour l'utilisateur. Les stratégies de mise en cache complexes peuvent parfois décourager les utilisateurs. Vous devez également tenir compte de la complexité de la mise en œuvre correctement. La mise en œuvre de la mise en cache, l'optimisation des URL des ressources et la configuration des en-têtes nécessitent une planification et un examen minutieux En résumé, la mise en cache est une technique prédominante pour optimiser les performances avec Il réduit la latence, préserve la bande passante et améliore l'expérience utilisateur en exploitant différents types de mise en cache, d'en-têtes de mise en cache et Les développeurs Web peuvent créer des applications Web rapides et réactives qui répondent aux exigences des utilisateurs Web modernes. Dans un monde où les performances Web sont un facteur essentiel du succès d'applications comme celle dans laquelle nous vivons aujourd'hui, la maîtrise de l'art de la mise en cache est C'est une compétence qui peut transformer un site Web lent en une plateforme rapide et réactive, plateforme rapide et réactive, satisfaisant les utilisateurs et réduisant la charge de travail des serveurs. Vous le trouverez peut-être sur votre site Web et j'ai hâte de connaître expériences de votre homme alors qu' Internet continue de croître et d'évoluer. Le rôle de cette capture dans l' optimisation des performances reste plus important que jamais Cela étant dit, je vous remercie d'être restés avec moi jusqu'à la fin de cette conférence. J'espère vraiment que vous en avez tiré quelque chose, et j'ai hâte de vous voir dans le prochain. 9. Partage de ressources d'origine croisée: Bonjour les gars et bienvenue dans ce cours HTTP. Dans cette conférence, nous allons parler du partage de ressources d'origine croisée. Il s'agit d'une fonctionnalité de sécurité très importante des applications Web modernes, qui permet un accès contrôlé aux ressources de différents domaines. À une époque où les applications Web interagissent avec divers services et API sur Internet, le cours joue un rôle essentiel dans le maintien de la sécurité tout en permettant partage de données d'origine croisée. Au début du Web, les navigateurs appliquaient une politique d'origine identique stricte. Cela signifiait que les pages Web ne pouvaient envoyer des requêtes qu'au domaine à partir duquel elles avaient été chargées. Bien que cette politique soit essentielle pour la sécurité, elle est devenue une limitation importante fur et à mesure de l'évolution des applications Web. applications Web modernes, en revanche, nécessitent souvent l' accès à des ressources hébergées sur différents domaines. Cela inclut le chargement de fonds à partir de scripts Google Images et de données provenant de serveurs et d'API tiers afin de remédier à cette limitation et de permettre le contrôle des demandes d'origine croisée. Le cours a été introduit en tant que fonctionnalité de sécurité. Le cours permet aux serveurs Web de spécifier qui peut accéder aux ressources et dans quelles conditions. Il fait partie du protocole HTTP et fonctionne en ajoutant en-têtes HTTP aux réponses envoyées par les serveurs Web Ces en-têtes transmettent les politiques du serveur concernant les demandes d'origine croisée Jetons maintenant un coup d' œil aux composants clés. Bien sûr, nous avons d'abord l'origine. Quel terme fait référence à la combinaison du domaine du protocole et du port à partir duquel une page Web a été chargée. Par exemple, Htp, exemple.com est une origine, tandis que Http exemple.com et Http sub exemple.com sub exemple.com Ensuite, nous avons les en-têtes HTTP. Le cours les utilise pour communiquer les autorisations relatives aux demandes d'origine croisée. Les en-têtes les plus critiques sont l'en-tête d'origine envoyé par le client pour indiquer l'origine de la page demandée contrôle d'accès autorise l' en-tête d'origine défini par le serveur pour spécifier quelles origines sont autorisées à accéder à ses ressources. Méthodes d'autorisation de contrôle d'accès. L'en-tête indique les méthodes HTTP get, post, put, delete autorisées pour les requêtes d'origine croisée. Et le contrôle d'accès autorise les en-têtes qui répertorient les en-têtes HTTP qui peuvent être utilisés dans la demande elle-même Maintenant que les en-têtes sont terminés, examinons de plus près processus du cours et les étapes qu'il implique réellement La première étape est la demande de pré-vol. Lorsqu'une page Web envoie une demande d'origine croisée avec certaines conditions, par exemple en-têtes ou des informations d'identification personnalisés, le navigateur envoie une demande de prévol, c'est-à-dire une demande d'options HTTP, au serveur cible Cette demande préalable au vol demande l'autorisation de faire la demande d'origine croisée proprement dite Ensuite, le serveur cible répond à la demande de prévol avec les en-têtes de cours appropriés Si le serveur approuve la demande, elle inclut des en-têtes tels que contrôle d' accès, autoriser l'origine , les méthodes d'autorisation, et les en-têtes d'autorisation de contrôle d'accès Enfin, si la réponse du serveur à la demande de pré-vol est positive, le navigateur envoie la demande réelle au serveur cible Le serveur peut inclure des en-têtes de cours dans la réponse pour indiquer si la demande d'origine croisée est autorisée J'ai choisi de parler du cours dans cette conférence parce qu'il est essentiel dans divers scénarios du monde réel. Vous pouvez penser aux API tierces ici. Les applications Web intègrent souvent des services tiers et des API pour diverses fonctionnalités telles que le partage sur les réseaux sociaux, le traitement des paiements ou les services de cartographie. Le cours permet à ces intégrations de se faire en toute sécurité. Les sites Web peuvent avoir besoin de charger des ressources telles que des polices ou des scripts à partir de réseaux de diffusion de contenu ou de diffuser des données à partir de serveurs distants. Le cours garantit que le partage de données entre origines est sûr et contrôlé. Authentification et connexion uniques. De nombreux fournisseurs d'identité mettent en œuvre le quatrième cours, les solutions d'authentification unique. Il permet une expérience de journalisation fluide et sécurisée même si le fournisseur d'identité réside sur un domaine différent. Enfin, le cours est également un élément fondamental de la sécurité Web. En permettant aux serveurs de définir les origines qui accèdent à leur demande, cela permet d'empêcher les demandes inter-origines non autorisées. Bien que Course améliore la sécurité du Web, sa mise en œuvre doit être abordée avec prudence, car tout d'abord, politiques de cours mal configurées peuvent par inadvertance ouvrir par inadvertance Il est donc très important de valider et de tester minutieusement les configurations de cours. De plus, tous les navigateurs ne sont pas entièrement compatibles avec le cours. Certains anciens navigateurs peuvent ne pas le gérer correctement ou présenter des limitations. Les développeurs doivent être conscients de ces limites lorsqu'ils utilisent le cours. Les demandes de pré-vol ajoutent un aller-retour supplémentaire aux demandes d'origine croisée, ce qui peut avoir un impact sur les performances Il est essentiel de minimiser les demandes avant le vol pour garantir l'efficacité des applications. Cela étant dit, le partage de ressources entre origines fait partie intégrante de la sécurité et des fonctionnalités modernes du Web. Il permet aux applications Web d'accéder aux ressources et services de différents domaines tout en maintenant des interactions contrôlées et sécurisées. Les développeurs et les administrateurs de serveurs ont besoin d'une solide compréhension, bien entendu, pour s'assurer que leurs applications Web peuvent exploiter tout le potentiel des requêtes d' origine croisée tout en se protégeant contre les menaces de sécurité. Merci beaucoup d'être restés avec moi jusqu'à la fin de cette conférence. J'espère que vous en avez tiré quelque chose et que vous utiliserez partage de ressources entre origines dans vos futures requêtes HTTP. J'étais Ox et j'ai hâte de vous voir lors de la prochaine conférence. 10. Qu'est-ce qu'une URL ?: Bonjour les gars, et bienvenue dans ce tutoriel HDDP. Dans cette conférence, nous allons discuter des URL et de quoi sont-elles exactement ? L'acronyme d'une URL provient de l' Uniform Resource Locator. Une URL n'est rien d'autre que l'adresse d'une ressource sur le World Wide Web. Bien entendu, cette ressource peut être une page Web réelle, une image ou tout autre type de données réunies sur Internet. Une observation ici est que chaque valeur de l'URL pointe sur le Web mondial vers une ressource unique. Ces ressources peuvent être une page HTML, un document CSS, une image, etc. peut même s'agir d'un agrégat Json qui, lorsque vous l'ouvrez, ne contient que des données entre accolades Certains d'entre eux peuvent être déplacés ou supprimés. Par conséquent, Internet évolue si vite de nos jours. Si tel est le cas, cela pourrait vous indiquer directement un code de retour HTTP à quatre ou quatre caractères non trouvés, ne vous inquiétez pas pour les codes de retour. Nous aurons une prochaine section qui leur sera entièrement consacrée et nous en discuterons en détail. La façon dont nous accèderions à une URL serait de la taper dans la barre de notre navigateur et d'appuyer sur Entrée. Ce qui se passerait dans le backend de ce processus que l'utilisateur de base ne connaît pas et ne sait pas, en gros, comment il fonctionne serait ce navigateur UR Le navigateur de l'utilisateur adresserait donc une demande au serveur spécifié dans l'URL pour récupérer exactement les informations spécifiées dans le chemin de cette URL. Nous pouvons voir que ces URL sont un outil qui nous permet de demander au serveur à partir de nos navigateurs locaux Ils sont donc très utiles. Maintenant, selon le contexte dans lequel nous nous trouvons, il n'existe que deux types d'URL qui sont classés en URL absolues et URL relatives La différence est assez subtile entre les deux, mais elle mérite d'être connue car c'est un concept assez basique que vous pourriez rencontrer. Si vous vous lancez dans développement Web ou si vous entrez simplement un F 12 sur Google Chrome et essayez de lire la ressource d'une page Web, vous pourriez rencontrer ce concept. Et il est préférable de le couvrir afin de pouvoir le comprendre profondément lorsque vous le rencontrez. Il est préférable d'utiliser une URL absolue en l'absence de contexte. Par exemple, sur la page d'accueil de notre navigateur. Absolu signifie que vous devez spécifier le chemin complet de la demande que vous faites. Maintenant, à l'autre bout du spectre, en ce qui concerne les URL relatives, si une URL est utilisée dans un document HTML, par exemple, vous pouvez simplement spécifier le chemin relatif à partir de l'endroit où vous vous trouvez et il devra désormais vous y mener Cela peut se produire parce que le navigateur dispose alors de l'URL du document où vous vous trouvez et peut l'utiliser pour combler le vide du chemin relatif que vous entrez. Il peut l'utiliser comme point intermédiaire pour vous amener là où vous voulez aller par rapport à ce point. Si vous voyez un chemin qui commence par une barre oblique, le navigateur place le chemin restant une fois que la barre oblique relative au chemin se trouve barre oblique relative au chemin se trouve à ce point, c' est-à-dire après celui-ci Et nous vous emmènerons à la destination choisie si elle est valide. C'est pourquoi le nom d' URL relatif a été choisi. Quand on y pense, les URL sont un moyen très simple et lisible par l'homme qui nous permet de naviguer rapidement et simplement sur Internet sans trop de connaissances technologiques En outre, étant donné le manque d' expérience de la plupart des utilisateurs d'Internet, la propriété sémantique des URL devrait être conservée en tant que bonne pratique afin de maintenir cette clarté lors la manipulation des chemins des demandes par les utilisateurs moyens Dans les prochaines conférences, nous examinerons de plus près les éléments clés exacts de la structure d' une URL et nous les décomposerons pour voir ce que chacun d'eux fait en détail Si cela vous semble intéressant, j'ai hâte de vous y voir. Merci beaucoup d'être restée à mes côtés jusqu'à la fin de cette conférence. 11. La structure d'une URL: Bonjour les gars, et bienvenue dans ce tutorville HTTP. Dans cette conférence, nous allons examiner de plus près la structure d'une URL. Quelque chose auquel vous ne penserez peut-être jamais puisque vous venez de l'écrire dans la barre de votre navigateur d'accueil. Mais ces URL ont en fait une structure, et chaque partie d'entre elles signifie quelque chose Quant à leur assemblage, ils peuvent nous mener exactement là où nous voulons aller, peut-être une partie spécifique d'un document HTML provenant du Web que le serveur héberge. Comme je l'ai dit, une URL est composée de différentes parties, dont certaines sont obligatoires, tandis que d'autres sont facultatives. La première partie d'une URL est son schéma. Cela indique le protocole que le navigateur doit utiliser, demander la ressource, généralement pour les sites Web, le protocole est HTTPS ou HTTP. L'adressage de pages Web nécessite l'un des deux. C'est en gros assez simple, et vous avez peut-être vu le schéma dans certaines URL que vous avez écrites, ou peut-être que si vous avez cliqué sur l'URL de la page Web sur laquelle vous vous trouvez actuellement, vous pouvez voir qu'elle commence par HTTP ou HTTPS Je ne pense pas que cela vous soit étrange maintenant, vous en savez juste plus sur son appellation. Ensuite, après le schéma, nous avons la partie d'autorité qui est séparée du schéma par un schéma de caractères, savoir la colonne suivie de deux barres obliques Dans cette autorité, nous avons le nom de domaine, par exemple. Cela pourrait être www.thenameofyoursite.com Il s'agit du domaine, de l' adresse réelle sur laquelle Cela peut même inclure le port, même si ce n'est pas très habituel, car nous verrons pourquoi dans un instant. Et ces deux éléments sont à nouveau séparés par une colonne. Cela ressemblerait donc à la colonne site.com. Et puis le Port 88 peut-être. Le domaine indique maintenant quel serveur Web est demandé, comme vous le voyez dans votre vie quotidienne lorsque vous écrivez W, puis le site Web auquel vous essayez d'accéder, ce serveur Web est demandé. À présent, le port indique la porte technique utilisée pour accéder à la ressource sur le serveur Web. Il est généralement omis si le serveur Web utilise les ports standard du protocole HTTP C'est pourquoi on ne le voit presque jamais. Le serveur Web utilise presque toujours les ports standard du protocole HTTP. Pour ma part, j'ai rarement vu un port après le domaine. Maintenant, après la partie autorité dans la structure d'une URL, vient le chemin de la ressource sur le serveur Web. Au début du Web, un chemin comme celui-ci représentait un emplacement physique sur le serveur Web. Mais maintenant, il s'agit principalement d'une abstraction gérée par des serveurs Web sans aucune réalité physique. Le chemin dont nous parlons ici peut être constitué de barres obliques indiquant, par exemple, l'utilisateur, puis l'ID d'un utilisateur spécifié, puis encore une fois, un fait concernant cet utilisateur peut être sa page d'informations Chacun de ces mots clés est donc séparé, comme je l'ai dit, par des barres obliques après l'autorité, et ils pointent vers un emplacement très précis sur ce Il est donc accompagné d'informations supplémentaires. Même s'il s' agit des parties principales, nous pouvons également avoir des paramètres. Il s'agit d'une liste de paires clé-valeur séparées par le symbole de fin. Cela peut également apparaître assez souvent dans les URL, et le serveur Web peut utiliser ces paramètres pour ajouter du personnel supplémentaire entre les renvois de la ressource Enfin, nous avons peut-être une ancre. Cela représente une sorte de signet à l'intérieur de la ressource, donnant au navigateur les instructions pour afficher le contenu situé à cet endroit dans un signet sur un document HDML Par exemple, une ancre ferait défiler automatiquement le navigateur vers le bas jusqu'au point où l' ancre est définie. Et sur un document vidéo ou audio dans le navigateur, celui-ci essaiera d'aller à l'heure indiquée par l'ancre. Il convient de noter que la partie située après le H t est également connue sous le nom d'identifiant de fragment, et il s'agit essentiellement de la syntaxe d'une ancre. C'était à peu près la structure d'une URL en détail. J'espère que vous en avez tiré quelque chose. Et à partir de maintenant, chaque fois que vous saisirez une URL, vous serez en mesure de séparer chacune de ses parties dans votre tête et de comprendre le nom de chacune d'elles, et plus important encore, ce que fait chacune d'elles. Dans la section suivante, nous allons parler d'un processus appelé encodage d'URL, qui est assez intéressant et utile en ce qui concerne Internet. Donc, si cela vous semble intéressant, j'ai hâte de vous y voir. Merci beaucoup d'être restée à mes côtés jusqu'à la fin de cette conférence. 12. Encodage d'URL: Bonjour les gars, et bienvenue dans ce cours HTTB. Dans cette conférence, nous allons aborder le processus d' encodage des URL. Qu'est-ce que c'est, pourquoi et quand c'est utile en matière de codage d'URL, également connu sous le nom de codage en pourcentage. L'ensemble de ce processus convertit les caractères dans un format qui peut être transmis sous URL sur le World Wide Web Pour ce faire, il traite essentiellement le jeu de caractères G. À ce stade, vous vous demandez peut-être quel est l'intérêt d' avoir ce codage ? Eh bien, c'est nécessaire car le plus souvent, les URL contiennent caractères qui ne font pas partie du G set et doivent être converties dans ce format pour que cette URL spécifique fonctionne lors de la saisie dans un navigateur Web L'ensemble du fonctionnement de cet encodage est assez simple et direct. Pour chaque caractère qui n' est pas un caractère SG, il est remplacé par un signe de pourcentage suivi de deux chiffres hexadécimaux. Cela signifie que pour chaque personnage qui n'est pas un personnage Asch Il associe essentiellement ce caractère à une structure à trois caractères dont le premier est toujours le pourcentage, et les deux suivants sont des chiffres hexadécimaux. Maintenant, en ce qui concerne les espaces en particulier, si vous y avez pensé, ils ne sont pas non plus autorisés à l'intérieur d'une URL. Et ils sont remplacés dans l'URL par le signe plus si vous avez déjà essayé de les représenter. Il existe sur Internet des tables complètes où vous pouvez voir quoi chaque caractère est mappé ce qui concerne le codage de l'URL Ou vous avez une approche encore plus simple que cela. Si vous souhaitez encoder une URL à partir de votre texte autre qu'Asch Il existe des sites Web comme URL Encoder.org et si vous y collez du texte UR, il peut automatiquement l' encoder sous forme d'URL codée s'agit donc d'un processus assez simple et simple à comprendre, mais il est essentiel que vous sachiez qu' il est utilisé pour écrire à peu près tout ce qui n' aurait pas été autorisé à s'y trouver autrement dans une nouvelle URL . Merci les gars d'être restés avec moi jusqu'à la fin de cette conférence. Dans la prochaine section, nous allons examiner la session HTTP ainsi que les cookies afin de mieux comprendre ce protocole. Donc, si cela vous intéresse, j'ai hâte de vous y voir. 13. Sessions et cookies: Bonjour les gars, et bienvenue dans le tutoriel HTTP. Dans cette conférence, nous allons discuter de la session HTTP ainsi que des cookies disponibles ici afin mieux comprendre ce protocole et son fonctionnement. Les sessions HTTP fonctionnent en utilisant des cookies ainsi que des techniques cryptographiques afin de maintenir date sans stocker autant de données sur le serveur Lors de la présentation d'une page Web dynamique, le serveur envoie les données d' état actuelles au client, c'est-à-dire au navigateur Web, sous la forme d'un cookie. ce qu'est un cookie, le client enregistre ce cookie dans la mémoire qu'il a reçue ou sur le disque. De cette façon, le serveur Web n'en a pas besoin. À chaque demande successive, le client retransmet le cookie au serveur. Le serveur utilise les données pour mémoriser l'état de l'application pour ce client spécifique et pour générer une réponse appropriée. Ce mécanisme peut fonctionner correctement dans presque tous les contextes, mais il existe quelques exceptions vous avez peut-être constatées en accédant un nouveau site Web qui vous obligent à accepter tous les cookies. Voilà ce que cela signifie. Il vous enverra une partie des informations afin qu'ils n' aient pas à les stocker sur leurs serveurs Web. Informations concernant la session à laquelle vous êtes en train de participer. Et pour plus d'informations à ce sujet, si vous cliquez sur ce site Web plus tard, il saura d'où vous diriger. Cependant, les données stockées sur un client, c'est-à-dire sur vous, vulnérables à l'utilisation sessions côté client où la confidentialité et l'intégrité sont requises. Les éléments suivants doivent être garantis. Nous avons besoin de confidentialité. Données, intégrité et authenticité. confidentialité provient du fait que rien d'autre que le serveur ne doit être en mesure d' interpréter les données de session, c'est-à-dire qu'aucun tiers ou pirate informatique ne doit être en mesure d'interpréter. L'intégrité signifie que rien d'autre le serveur ne doit manipuler les données accidentellement ou de manière malveillante Et l'authenticité signifie que rien d'autre que le serveur ne devrait être en mesure d'initier des sessions valides. Maintenant, pour réaliser ces trois propriétés et s'assurer qu' elles sont respectées, le serveur doit chiffrer les données de session avant de les envoyer au client Et la modification de telles informations par toute autre partie doit être empêchée par ce moyen cryptographique La transmission de l' état dans les deux sens à chaque demande n'est pratique que si la taille du coca est petite Essentiellement, les sessions côté client échangent l'espace disque du serveur ou la bande passante supplémentaire requise par chaque requête Web. De plus, le navigateur Web limite le nombre et la taille des cookies qui peuvent être stockés par un site Web afin d'améliorer l'efficacité et de permettre un plus grand nombre de données de cessation. Le serveur peut compresser les données avant de créer le cookie et décompresser ultérieurement lorsque le cookie est renvoyé par le client Cela peut fonctionner avec des outils de compression tels que programmes Win Sip ou Seven P que vous connaissez peut-être En augmentant la taille des cookies, le compromis n'en vaudrait plus la peine, car la bande passante pour les envoyer serait évidemment énorme Il s'agit de la session HTTP, façon dont elle est améliorée par les cookies J'espère que vous avez tiré quelque chose de cette conférence. Dans la prochaine, nous allons examiner en détail toutes les méthodes de requête HTTP, voir ce qu'elles sont, ce qu'elles font et en quoi elles peuvent être utiles notre parcours pour mieux comprendre le protocole HTTP. Si cela vous semble intéressant, j'ai hâte de vous y voir. Merci d'être restée avec moi jusqu'à la fin de cette conférence. 14. Sockets Web: Bonjour les gars et bienvenue dans ce cours sur le protocole HTTP. Dans cette conférence, nous allons examiner les sockets Web. Ils sont très importants dans la communication en temps réel lorsqu'il s'agit du protocole HTTP. Dans le paysage moderne de la technologie Web, attentes des utilisateurs en matière de communication en temps réel ont atteint de nouveaux sommets. Comme vous pouvez le constater, tout ce qui vous entoure , c'est discuter avec des amis sur Whatsapp, surveiller les données de la vie ou collaborer avec des collègues de travail. La demande d'interactions instantanées et fluides sur le Web n'a jamais été aussi forte. Pour répondre à cette demande, les développeurs Web se tournent généralement vers les Web Sockets, une technologie qui facilite communication en temps réel via le protocole HTTP. Dans cette leçon, nous aborderons le monde des sockets Web Et comment ils permettent une communication en temps réel sans avoir besoin de requêtes HTTP constantes. Ils constituent vraiment un élément essentiel de ce protocole. Mais avant cela, examinons de nouveau le modèle de réponse aux requêtes HTTP dont nous avons déjà parlé. Il suffit de le rafraîchir. Avant d'explorer les sockets Web, il est essentiel de comprendre les fondements sur lesquels ils fonctionnent. Le protocole de transfert hypertexte ou shortshort. protocole HTTP est depuis longtemps l'épine dorsale du World Wide Web, servant de mécanisme d'échange de données entre les clients, généralement les navigateurs Web et les serveurs. Dans le modèle de réponse HTTP traditionnel, le client envoie une demande au serveur qui traite la demande et renvoie une réponse. Bien que ce modèle fonctionne bien pour de nombreuses interactions sur le Web, il présente des limites lorsqu' il s'agit de communication en temps réel. Dans le modèle HTTP traditionnel, une nouvelle requête est requise pour chaque interaction entre le client et le serveur. Cela signifie que pour récupérer de nouvelles données ou de nouveaux messages, le client doit envoyer des demandes à plusieurs reprises, ce qui entraîne une série d' échanges aller-retour. Cette approche n'est pas adaptée. Applications en temps réel où les données doivent circuler en continu et entrer instantanément dans les sockets Web Ils ont été introduits comme solution aux limites du protocole HTTP traditionnel. Ils fournissent un canal de communication bidirectionnel full plex via une seule connexion de longue durée avec des sockets Web Le client et le serveur peuvent initier la communication indépendamment. Cela signifie que les données peuvent être transmises du serveur au client, ou vice versa, sans avoir besoin d' une nouvelle requête HTTP à chaque fois, comme c'était le cas auparavant. Examinons maintenant les principales fonctionnalités des sockets Web et les principales raisons pour lesquelles vous devriez envisager de les implémenter dans vos propres applications. Tout d'abord, nous avons une connexion persistante. Les sockets Web maintiennent une connexion permanente entre le client et le serveur. Une fois la connexion établie, elle reste ouverte, ce qui permet aux données de circuler en continu sans avoir des ouvrir et à fermer des connexions pour chaque interaction. Deuxièmement, nous avons des demandes de communication en temps réel à faible latence . Faible latence, et les sockets Web répondent aux attentes à cet égard. Comme la connexion est toujours ouverte, données peuvent être transmises dans un délai minimal, ce qui rend les sockets Web idéaux pour les applications où les mises à jour instantanées sont essentielles. La troisième caractéristique clé du Web Socket est le protocole léger. Le protocole Web socket est conçu pour être léger, réduisant ainsi les frais de transfert de données. Cette efficacité contribue à la rapidité et à la réactivité des applications en temps réel Enfin, nous avons une communication inter-origines, qui est prise en charge par des sockets Web, ce qui signifie que les clients peuvent se connecter à serveurs de sockets Web sur différents domaines. Cela le rend adapté à divers cas d'utilisation, notamment les applications de chat et les flux de données en direct. Nous allons maintenant examiner quelques cas d'utilisation réels afin que vous puissiez mieux comprendre l'ensemble du concept de websocket Les avantages des sockets Web sont évidents dans diverses applications du monde réel. Pour le premier scénario, considérons les applications de chat. Ils bénéficient des fonctionnalités de messagerie instantanée des sockets Web. Les utilisateurs peuvent échanger des messages en temps réel sans avoir à actualiser la page en permanence. Ici, vous pouvez penser à votre application de chat préférée, que ce soit sur mobile ou sur le Web. Ensuite, nous avons les jeux en ligne. Celles-ci nécessitent souvent des mises à jour en temps réel telles que les mouvements des joueurs et les modifications de l'état du jeu. Les sockets Web permettent une synchronisation fluide des données de jeu entre les joueurs. Également, si vous investissez. Vous pourriez penser au marché boursier et aux plateformes financières. Dans le secteur des services financiers, les données en temps réel sont essentielles. Les plateformes boursières utilisent sockets Web pour fournir aux traders les cours des actions en direct , les tendances du marché et les exécutions des transactions. Enfin, les outils de collaboration tels que les tableaux blancs partagés et les éditeurs de documents s'appuient sur des mises à jour en temps réel pour garantir que tous les participants voient instantanément les dernières modifications Lorsqu'il s'agit de mettre en œuvre des sockets Web, le client et le serveur ont besoin du support des sockets Web. script Java via l' API Web Socket est couramment utilisé côté client. frameworks et bibliothèques côté serveur, tels que no JS avec la bibliothèque YS ou le pattern avec websocket, permettent cette prise en charge des websockets côté serveur C'est un très bon point de départ pour les bibliothèques à examiner si vous avez déjà une situation client-serveur dans laquelle vous souhaitez implémenter des sockets Web. Bien que les sockets Web offrent une solution puissante pour la communication en temps réel, ils présentent certains défis et considérations. Tout d'abord, nous avons l'évolutivité. La gestion d'un grand nombre de connexions Web Socket peut s'avérer difficile. L'équilibrage de charge et une gestion efficace des connexions sont essentiels pour les applications Web Socket évolutives. Ensuite, nous avons des problèmes de pare-feu et de proxy. Certains réseaux et configurations de sécurité peuvent limiter le trafic des sockets Web Dans de tels cas, les connexions Web Socket peuvent avoir besoin d'être tunnelées via HTTP ou d'autres protocoles Ou vous pouvez même implémenter une solution de secours au cas où votre implémentation du socket Web échouerait Troisièmement, nous avons activé la sécurité. La sécurité des connexions Web est vitale. mettre en œuvre des connexions Web Socket sécurisées, qui sont des connexions à double protocole YSS, et de valider les données pour éviter les failles de sécurité En résumé, les sockets Web ont révolutionné communication en temps réel sur le Web en surmontant les limites du HDDP traditionnel Ils fournissent une faible latence grâce connexion directionnelle qui sert de colonne vertébrale à de nombreuses applications en temps réel, des plateformes de chat aux jeux en ligne et aux outils collaboratifs. Les développeurs Web dotés de connaissances en matière de sockets Web occupent position royale pour créer la prochaine génération d' applications Web en temps réel qui répondent aux demandes croissantes des utilisateurs en matière interaction instantanée et fluide. Merci les gars d'être restés avec moi jusqu'à la fin de cette conférence. J'espère vraiment que tu en as tiré quelque chose. Et les websockets seront désormais un concept que vous comprendrez parfaitement J'ai hâte de vous voir lors de la prochaine leçon. 15. HTTP: Bonjour les gars, et bienvenue dans le cours HTTP. Dans cette conférence, nous allons discuter du protocole HTTPS, ce qu'il fait de mieux que le HTTP, si nous devons l'utiliser et comprendre de manière basique et même plus avancée comment il fonctionne. Pour commencer, le protocole et l' acronyme HTTPS désignent le protocole de transfert hypertexte issu de secure. C'est à peu près la même chose que HTTP, mais celui-ci est associé au S et au mot clé sécurisé. Et pour passer en revue le principal problème de sécurité du protocole HTTP dont nous avons parlé jusqu'à présent, c'est que les informations qui circulent du serveur au client ne sont pas du tout cryptées. De plus, le problème ce manque de cryptage est qu' il peut être vu par n'importe qui exactement dans sa forme actuelle. Cela signifie que, bien sûr, il peut être facilement volé, mais qu'il peut également être remplacé par un pirate informatique ou un tiers assistant à cet échange, il peut y intervenir. Le protocole HTTPS y remédie en utilisant un certificat SSL. L'acronyme SSL vient de Security Sockets Layer, et ce certificat permet de créer une connexion cryptée sécurisée entre le serveur Web et le navigateur client. Ainsi, il protège en outre les informations sensibles contre le vol lors de leur transfert entre le serveur et le navigateur. Le chiffrement de ces informations signifie qu'elles sont mappées autre forme qu' un tiers ou un attaquant ne peut pas comprendre, ni même les voir, y accéder ou les voler différence la plus importante entre les protocoles HTTP et HTTPS est évidemment le certificat SSL. En fait, le HTTPS est essentiellement un protocole HTTP simple dont nous avons parlé jusqu'à présent avec juste une couche de sécurité supplémentaire, ce qui est très important. Cependant, cette sécurité supplémentaire peut être extrêmement importante, en particulier pour les sites Web qui stockent des informations sensibles pour leurs utilisateurs, telles que les informations de carte de crédit. Par exemple, si vous avez acheté quelque chose sur un site Web, vous l'avez peut-être vu ou vous avez simplement vu votre mot de passe. Donc, si vous ne voyez pas de cadenas à gauche de l'URL et que vous essayez d'accéder à votre compte en saisissant votre mot de passe ou en essayant d' acheter quelque chose contenant les informations de votre carte de crédit. Vous devriez simplement arrêter car ce n'est pas sûr et vos données pourraient être volées à un attaquant qui observe ce processus. Maintenant, le certificat SSL chiffre les informations, comme je l'ai dit, que les utilisateurs fournissent au site, ce qui signifie essentiellement qu'il traduit les données en code Même si quelqu'un parvient à voler les données échangées entre le serveur et le destinataire, il ne pourra pas les comprendre grâce au cryptage appliqué par le certificat de cellule S. De plus, en plus d' appliquer cette couche supplémentaire, HTTPS est également sécurisé via le protocole TLS Désormais, le protocole et l' acronyme TLS proviennent de la sécurité de la couche de transport Et ce qu'il fait, il contribue à garantir l'intégrité des données, ce qui permet d'empêcher le transfert de données à des fins de modification ou même de corruption. Une autre chose qu'il fait, c'est qu'il fournit une authentification qui prouve aux utilisateurs qu'ils communiquent réellement avec les sites Web réels. Cela signifie qu'en fin de compte, le tiers ne peut pas venir modifier le contenu transmis entre le client et le serveur. C'est très important, les utilisateurs peuvent identifier si un site utilise le protocole HTTPS grâce à l'adresse Web, la toute première partie de l'adresse Web ou à l'URL, comme nous l'avons vu dans la leçon précédente, appelée autorité avant le début du nom principal. Cette partie indique si le site utilise le protocole HTTP ou HTTPS. Vous devriez simplement regarder votre URL et vous en rendre compte. Vous pouvez également vérifier le verrou présent dans la partie gauche de l'URL. Cela vous indiquera également si vous accédez à une page sécurisée par le protocole HTTPS ou non. Maintenant, pour faire un bref récapitulatif, la principale différence entre le protocole HTTP et le protocole HTTPS réside simplement dans la présence du certificat d' inutilité. Http n'a pas le certificat SSL et le HTTPS en possède un. certificat d'évaluateur chiffre vos informations afin que votre connexion soit sécurisée et que les informations que vous transmettez ne puissent pas être volées ou modifiées par un tiers ou un pirate informatique C'était à peu près tout avec le protocole HTTPS. Dps est évidemment un protocole préféré de nos jours et qui est presque toujours implémenté sur les pages Web De plus, si vous vous intéressez au développement Web et que vous essayez de créer un site Web, je vous suggère vivement d'utiliser ce protocole plus sécurisé, en particulier si vous essayez d'obtenir des données sensibles auprès des utilisateurs. Ce protocole va donc vous rendre moins vulnérable aux SMS d'éventuels pirates informatiques. Merci beaucoup d'être restés avec moi jusqu'à la fin de cette conférence. Dans la prochaine, nous allons examiner des outils très utiles avec lesquels nous pouvons voir les requêtes HTTP réelles qui sont faites de notre machine à d'autres serveurs Web et les capturer pour voir quelles informations sont envoyées ou reçues, etc. Ce sera donc la partie la plus concrète et la plus exploitable de notre tutoriel ici Donc, si cela vous semble intéressant, j'ai hâte de vous y voir. 16. Adresses IP: Bonjour les gars, et bienvenue dans le cours HTTP. Dans cette conférence, nous allons en apprendre davantage sur ce qu' est une adresse AP et sur la façon dont nous pouvons l'utiliser dans nos efforts avec le protocole HTTP L'adresse AP représente une adresse de protocole Internet. C'est de là que vient le NP, le protocole Internet. Ce que c'est, c'est une étiquette numérique telle que 1902121. Cette étiquette représente votre connexion à un réseau informatique qui utilise le protocole Internet pour la communication, c'est pourquoi il s'agit d'une adresse de protocole Internet. Une adresse AP remplit deux fonctions principales. La fonction d'identification de l'interface réseau et la fonction d' adressage de localisation. Dans un instant, nous parlerons plus largement ces deux fonctions dans des termes plus faciles à comprendre. Mais tant que les versions du protocole Internet existent, il existe deux versions principales du protocole Internet. La première, lorsqu' elle a été lancée, s' appelle la version quatre, également connue sous le nom IPV quatre, et définit une adresse AP comme un nombre de 32 bits Cependant, en raison de la croissance d'Internet et de l'épuisement des quatre adresses IPV disponibles, une nouvelle version de l'IP a été créée Parce que vous ne pouvez pas penser qu'un nombre 32 bits ne peut stocker qu'un nombre limité d'adresses. pour répondre à ce besoin que nous avons créé l'IPV six, qui est la version six du protocole Internet Ces adresses IP utilisent 128 bits au lieu de 32 bits seulement. Maintenant, une autre mention notable est que l'espace d'adresses IP est géré à échelle mondiale par l'autorité des numéros attribués à Internet. Ces adresses IP sont écrites et affichées dans des notations lisibles par l'homme Dans l'exemple que je vous ai donné, une adresse IP valide est 1902120 Les administrateurs réseau d' Internet ont attribué des numéros, des pouvoirs ou, en général, une adresse IP à chaque appareil connecté à un réseau. Ces assignations peuvent se faire sur une base statique ou dynamique. Cela signifie qu'ils peuvent être fixes ou permanents. Tout dépend des pratiques du réseau que vous utilisez et des fonctionnalités logicielles de la machine sur laquelle vous travaillez. Maintenant, pour en venir à l'objectif de l'adresse AP et à la raison exacte, il est important que vous sachiez des choses à ce sujet. C'est parce qu'une adresse IP identifie l'hôte. Et vous pouvez le constater si vous tapez l'adresse IP de Google. Certains sites sont disposés à afficher votre propre adresse IP et indiqueront également exactement où vous vous trouvez sur une carte mondiale. Bien entendu, si vous n' utilisez pas de VPN ou quelque chose comme ça, cela redirigera votre accès à Internet vers un autre endroit distinct L'adresse IP identifie l'hôte ou plus précisément son interface réseau avec celui-ci. Comme je l'ai dit, il fournit l'emplacement de l' hôte dans le réseau. De cette façon, il a la capacité d'établir un chemin vers cet hôte. Cette ligne a été caractérisée comme un nom qui indique ce que nous voyons. Une adresse indique où elle se trouve et l'itinéraire indique comment s'y rendre. L'en-tête de chaque paquet IP contient l'adresse AP de l'hôte émetteur et celle de l'hôte de destination, nous verrons dans un instant lorsque nous examinerons certaines requêtes HDTP effectuées dans Fiddler ou Wireshark En conclusion, les adresses IP sont essentiellement l' identifiant qui permet d' envoyer des informations entre les appareils d'un réseau. Ils contiennent des informations de localisation et rendent également les appareils accessibles pour la communication. Internet a besoin d'un moyen de différencier les différents ordinateurs, routeurs et sites Web C'est exactement ce que fournit l'adresse IP, un moyen de le faire et c' est un élément essentiel du fonctionnement d'Internet de nos jours. J'espère vraiment que vous avez tiré quelque chose d'utile de cette conférence. Merci beaucoup d'être restée avec moi jusqu'à la fin, et j'ai hâte de vous voir dans le prochain. 17. Demandes HTTP dans la pratique: Aidez les gars et bienvenue dans le tutoriel HTTP. Dans cette première conférence de la section où nous avons acquis une plus grande expérience pratique avec des outils réels qui nous aideront non seulement mieux comprendre l' ensemble du protocole HTTP et ses requêtes, mais aussi peut-être même à faire certaines choses à leur sujet. Il ne suffit pas de les comprendre pour voir exactement comment une demande est faite, les informations la concernant dans la pratique, et même voir si chose ne va pas avec elle ou quelque chose comme ça. Pour cette première conférence, nous allons examiner un logiciel développé par une société appelée Alaric Cela s'appelle Fiddler. Vous vous demandez peut-être maintenant quoi sert cet outil Fiddler Eh bien, il s'agit d'une entité mandataire, dont nous avons parlé dans la conférence précédente, si vous vous en souvenez . L'entité proxy était une entité située entre l'entité serveur et l'entité client. Et il a fait passer la demande réelle entre ces deux entités principales par son intermédiaire. Et il était transparent ou non transparent selon qu'il manipulait ou non les données de la demande. ce qu'est Fiddler, c'est un serveur proxy qui vous montrera, bien sûr, tout le trafic Web sur votre machine locale sur laquelle vous l'avez installé sur différents serveurs Web Par exemple, si vous accédez un site Web de réseau social à partir de votre ordinateur, il vous montrera la demande que vous avez déjà faite et vous pourrez la voir de manière beaucoup plus détaillée. Maintenant, la raison pour laquelle cet outil est utilisé est de déboguer le trafic Web pour les applications dans les navigateurs Cela signifie , par exemple, que vous avez créé le site Web et que vous vouliez voir exactement comment votre demande au site Web est faite. Si quelque chose ne va pas, vous devriez examiner cette demande spécifique pour voir ce qui ne va pas. Et les deux vous y aideront en vous montrant de nombreuses informations sur chaque demande spécifique qui a été faite depuis vos machines locales ou depuis vos machines locales ou depuis votre machine cliente vers le serveur Web. Maintenant, pour télécharger le logiciel Fiddler, vous pouvez aller sur Google, juste ce qu'il faut, Fiddler, bien sûr, la version nue est une version encore plus basique et vous pouvez également la choisir Mais quand vous l'aurez, vous devez taper votre e-mail, puis sélectionner le pays dans lequel vous vous trouvez et des informations comme ça. Téléchargez-le directement. De plus, si vous utilisez un environnement Apple ou Linux, vous devez utiliser l'un de ces boutons de téléchargement. Mais nous sommes sous Windows. Sur les machines, j'ai choisi le téléchargement standard, il suffira de télécharger un exécutable pour vous. Ce serait assez simple, et une fois que vous l'avez ouvert, vous pouvez voir qu'il ne vous montre qu'un contrat de licence. Ensuite, une fois que vous avez cliqué sur Accepter, il commencera à l'installer sur votre machine locale. Une fois l'installation terminée, nous allons avoir un aperçu de cet outil pour voir exactement comment les demandes sont affichées et comment nous pouvons progresser dans la compréhension de ce protocole en utilisant cet outil. Une fois que vous l'avez ouvert, vous pouvez vous connecter avec votre compte. Je vais le faire dans un instant et je vous recontacterai une fois que je serai dans l'application. D'accord ? Je suis donc de retour après avoir créé mon compte chez Fiddler Une fois que nous aurons ouvert l'application, vous verrez que cela vous fera suivre un didacticiel rapide. Tout d'abord, dites-vous simplement qu'il ne suivra pas votre trafic HTTPS car celui-ci est crypté et non suivi. Mais vous pouvez cliquer sur l'icône de suppression pour changer cela Ensuite, il vous montrera toute la partie gauche de l'outil où trafic apparaîtra et chacune de ces lignes signifie quelque chose. Bien entendu, le résultat se trouve dans le code d'état de la demande dont nous avons parlé. Ensuite, la méthode comme dans get post et ainsi de suite. Le processus, l'adresse IP distante puis l'URL suivante, une fois que vous aurez cliqué sur une demande dans la partie gauche, vous verrez la réponse réelle et le contenu réel de la réponse en HTML, Json, et d'autres manières de l'afficher ici, vous pouvez capturer le trafic en direct ou non. Ensuite, nous pouvons bien sûr avoir des sessions sécurisées. Une fois le didacticiel terminé , vous pouvez cliquer sur le bouton Moi, puis sur signe d'exclamation rouge situé après le symbole URL Et une fois que vous aurez cliqué dessus, il commencera également à suivre les demandes et réponses réelles qui passent par HTTPS. Parce que vous allez lui accorder ce certificat pour lui permettre de voir les demandes qui sont faites en toute sécurité. Par exemple, j'ai ouvert mon Chrome ici et j'ai ouvert mon compte Instagram. Vous pouvez voir qu' une fois que je l'ai fait, j'ai reçu beaucoup de photos provenant de mon fil Instagram et, bien sûr, d'autres pour accéder à des jetons qui m' ont été donnés en m'authentifiant via Facebook, sur Instagram, etc. Vous pouvez donc également voir dans la première partie, non seulement le numéro de la demande qui a été faite en fonction du type, mais également le type de réponse que vous avez reçue. Par exemple, il s' agit d'images que vous avez vues. C'est une réponse de Jason. Ce sont des méthodes de publication qui sont utilisées pour créer des choses, etc. Bien entendu, vous pouvez les regrouper par résultats. Tout d'abord, si vous voulez que les demandes de résultats soient correctes, vous pouvez le faire et elles augmenteront alors. Par exemple, voici le dernier qui a reçu une réponse de 43. Ensuite, nous avons la méthode si vous souhaitez d'abord obtenir des types de demandes, etc. Ensuite, les processus de l'IP ainsi que la taille du corps ou les commentaires. Vous pouvez également les commander par ce biais. Maintenant, lorsque vous recevez cette demande, vous pouvez voir certaines choses. En voici un aperçu. Nous pouvons le voir au format brut. Vous pouvez voir le corps de la demande ainsi que les en-têtes qui l'accompagnent Nous avons ici, bien sûr, des informations assez générales à ce sujet, comme le jour où il a été modifié le dernier jour , le type de connexion, la longueur du contenu , etc. Encore une fois, la réponse est également affichée ici. Vous pouvez enregistrer la session. Ainsi, une session est une fois que vous commencez à voir certaines demandes, vous pouvez démarrer la session et vous avez quelques demandes , y mettre fin puis les enregistrer. Dans le cadre de la session ici, vous pouvez également tous les supprimer si vous voulez faire table rase. Comme je l'ai dit, la session de sécurité peut partager la session. Vous pouvez en fait utiliser des filtres avancés tels que les en-têtes de réponse et les en-têtes de demande afin de ne voir que certaines des demandes qui ont lieu Ici, vous avez quelques notifications, votre profil, les paramètres. Ce ne sont que des informations de base, mais cela peut être très utile, comme je l'ai dit, si vous voulez créer un site Web ou simplement exposer des API à votre service Web et vous voulez voir à quoi ressembleront les demandes faites pour obtenir l'API des points de terminaison Il s'agit de l'outil que vous souhaiteriez utiliser. Bien sûr, il existe également un autre outil appelé Wireshark, et nous allons passer cet outil ensuite et l'examiner de plus près, mais pour le moment, il s'agissait de l'outil Fiddler Je vous remercie beaucoup d'être restés avec moi jusqu'à la fin de cette conférence. 18. Wireshark: Bonjour les gars et bienvenue dans ce tutoriel HTTP. Dans cette dernière conférence, nous allons approfondir un autre outil qui permettra d'améliorer nos connaissances sur le protocole HTTP et les requêtes qui sont faites de manière plus précise. Cela s'appelle également Wireshark, comme vous pouvez le voir à l'écran Et c'est une autre application très similaire à la dernière application qui portait sur ce domaine, et nous en avons parlé dans la conférence précédente, qui était Fiddler Cette application vous permet également de capturer et étudier en détail le trafic réseau que vous avez, c'est-à-dire les demandes effectuées et les réponses reçues entre le client, c'est-à-dire le navigateur Web que vous avez sur la machine locale sur laquelle vous l'avez également installé, et le serveur Web auquel vous envoyez des demandes. Et cela peut varier en fonction du site Web que vous consultez et de ce que vous en avez reçu. Encore une fois, ici, nous pouvons simplement effectuer une recherche sur Google Wireshark. C'est un outil gratuit, et une fois que vous êtes sur WireShark.org, vous pouvez commencer en commencer Je suis sous Windows, je vais aussi installer ce 64 bits. Mais encore une fois, ils ont aussi l' si vous utilisez un produit Apple, vous pouvez le choisir pour l'installer. Et une fois que vous avez cliqué dessus, comme vous pouvez le voir, l' exécutable sera également téléchargé. Ensuite, je vais également vous expliquer la configuration. Comme c'est assez simple, vous pouvez simplement l'installer avec tout ce qui est fourni avec Caes. Nous vous demanderons également d'associer toutes ces extensions de différents fichiers à Wireshark Nous allons l' installer dans le lecteur C. Je ne vais pas utiliser ce MP 1102, ni l'USB, je ne vais juste pas cliquer dessus Vous n'avez pas vraiment besoin de ces outils pour simplement observer ces demandes et voir exactement quels sont les détails les concernant. Comme vous pouvez le voir ici, le Wireshark est en cours d'installation. Et je vous recontacterai une fois que l'outil sera installé et ouvert sur ma machine afin que nous puissions voir ce qui se passe et comment nous pouvons l'utiliser, les gars. Une fois que vous avez ouvert le Wireshark, vous pouvez sélectionner la connexion que J'ai choisi Internet puis, comme vous pouvez le voir à l'écran, je l'ai simplement arrêté pour le moment. Vous aurez donc un meilleur aperçu de ce qui se passe exactement ici. Mais bien entendu, le signe d'un requin est utilisé ici pour démarrer la capture effective de la demande. Et voici le bouton d'arrêt dans la première partie supérieure. Contrairement au feu qui avait ces parties verticalement, celui-ci les a à l'horizontale. Mais ici, vous pouvez voir la demande réelle qui a eu lieu, le protocole, la source dans les adresses IP de destination. qui peut être très utile si vous souhaitez simplement, Ce qui peut être très utile si vous souhaitez simplement, par exemple, voir une demande envoyée par votre ordinateur sur le réseau. Vous pouvez trier à partir de la source et les adresses IP seront affichées par ordre trié. Ensuite, bien sûr, la longueur de la réponse, le nombre d'entre elles. Si vous souhaitez entrer plus en détail sur une demande réelle, vous devez cliquer dessus. Ensuite, il vous montrera dans les deuxième et troisième fenêtres plus d'informations sur cette demande spécifique. Dans la troisième fenêtre, vous verrez la réponse réelle en langage décimal Dans le second, il vous montrera corps de la demande et une réponse réelle en XML ou dans n'importe quel format. Les réponses et toutes ces bonnes choses apparaîtront également dans le second type de fenêtre. Cela concerne également Wireshark. Il n'y a pas tellement de différence entre les deux. Je travaille généralement avec Wireshark tel que je le trouve, plus simple et direct Mais ils sont tous les deux assez bons pour ce travail. Vous pouvez donc choisir celui avec lequel vous vous sentez le plus à l'aise fonction de ce que vous avez vu dans ces deux conférences. C'était à peu près tout avec le tutoriel HTTP, les gars. J'espère que vous en avez tiré quelque chose et que vous comprenez maintenant mieux le protocole HTTP, ce que sont les requêtes, quelles sont les entités un flux de travail client-serveur et tous les autres éléments dont nous avons parlé, codes d' état et les méthodes de requête HTP Si vous avez des questions sur le protocole HTTP, vous pouvez me joindre et m'envoyer un message. Et je ferai en sorte de vous répondre dans les plus brefs délais. Mais encore une fois, merci beaucoup de m'avoir suivi jusqu'à la fin du tutoriel et de l'avoir regardé, et j'ai hâte de vous retrouver dans d'autres tutoriels que je créerai.