FreshRSS

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
Aujourd’hui — 6 octobre 2022Flux principal

Vous pouvez chercher 100 fois mieux avec Google que ce que vous faites déjà

6 octobre 2022 à 16:31

recherche

Google fournit des outils permettant de rehausser la qualité de vos recherches sur le web. Ces techniques sont connues de celles et ceux travaillant en informatique, mais moins du grand public.  [Lire la suite]

Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/

Hier — 5 octobre 2022Flux principal

Elon Musk achète Twitter pour le détruire

5 octobre 2022 à 11:08

Elon Musk a confirmé qu'il allait bien racheter Twitter, mais ne se montre pas très rassurant quant à son avenir. Le milliardaire présente Twitter comme le fondement d'une nouvelle application nommée « X » après avoir longtemps promis qu'il venait pour améliorer le réseau social.  [Lire la suite]

Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/

Microsoft Edge 106 est disponible en téléchargement, quoi de neuf ?

5 octobre 2022 à 11:01
Microsoft Edge 106

Microsoft Edge 106 est désormais disponible en téléchargement. Cette nouvelle version propose des améliorations importantes et deux nouvelles fonctionnalités.

Disponible depuis peu la version 106 du navigateur natif de Windows, Microsoft Edge, promet d’importantes avancées. Le géant du logiciel affirme que nous avons une défense Web plus fiable et percutante. Ce travail est le résultat d’une bibliothèque Microsoft Defender SmartScreen réécrite pour Microsoft Edge sur Windows. Elle a été introduite dans Microsoft Edge 103. La firme explique que la stratégie NewSmartScreenLibraryEnabled est désormais déconseillée et sera obsolète dans la prochaine version du navigateur (107).

La barre d’adresse profite d’ajustements. Le nombre maximal de résultats de travail passe de 2 à 4, ce qui offre plus de contenu lors d’une recherche. Par contre cette fonctionnalité nécessite l’activation de la stratégie AddressBarMicrosoftSearchInBingProviderEnabled pour fonctionner.

A ce deux nouveautés s’ajoute de nouvelles stratégies, des stratégies désormais déconseillées et d’autres considérées comme obsolète. Le plus important est cependant le mode d’efficacité qui peut être activé avec une stratégie dédiée dans le navigateur. Les nouvelles stratégies sont :

  • EfficiencyModeEnabled -> Mode d’efficacité activé
  • EfficiencyModeOnPowerEnabled -> Activer le mode d’efficacité lorsque l’appareil est connecté à une source d’alimentation
  • InternetExplorerIntegrationAlwaysUseOSCapture -> Utilisez toujours le moteur de capture du système d’exploitation pour éviter les problèmes de capture des onglets de mode Internet Explorer

Le navigateur Internet Micosoft Edge 106 est disponible en téléchargement direct ou sous la forme d’une mise à jour via son module de maintenance si vous l’utilisez déjà. Il faut se rendre dans

Aide et commentaires > A propos de Microsoft Edge.

La nouvelle version se télécharge automatiquement. Un redémarrage du navigateur est nécessaire pour que les changements prennent effet.

Cet article Microsoft Edge 106 est disponible en téléchargement, quoi de neuf ? a été publié en premier par GinjFo.

À partir d’avant-hierFlux principal

Elon Musk va racheter Twitter (oui, encore)

4 octobre 2022 à 21:47

En conflit avec Twitter depuis plusieurs mois, Elon Musk a finalement décidé d'honorer l'accord qu'il a signé en avril 2022. Le réseau social dit avoir pour intention de boucler le rachat.  [Lire la suite]

Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/

Meta et Pinterest jugés « responsables » du suicide une adolescente

4 octobre 2022 à 15:14

Un tribunal anglais a reconnu les deux réseaux sociaux responsables d'avoir poussé au suicide une jeune Anglaise en 2017. C'est la première fois que les plateformes sont reconnues comme ayant eu légalement un lien avec un décès.  [Lire la suite]

Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/

Serveur Web : tests de charge en Python avec Locust

4 octobre 2022 à 10:00

I. Présentation

Dans cet article, nous allons apprendre à utiliser Locust, un outil de test de charge pour les services et serveurs web. L'idée du test de charge est d'évaluer la réaction et le comportement d'un serveur ou service web, d'un pare-feu, reverse-proxy, load-balancer ou même d'une solution de cache face à la navigation de plusieurs utilisateurs (10, 100, 1000) en même temps. Nous pourrons par exemple découvrir que lorsque 100 utilisateurs accèdent à la même page au même moment, notre serveur web montre des signes de faiblesse (temps de réponse allongé).

Locust se veut simple d'utilisation, sans interface graphique complexe. Il se paramètre et s'utilise majoritairement via du code Python. Ce dernier sert en effet à définir le comportement des utilisateurs que nous voulons simuler et à lancer le test de charge. Une interface web permet ensuite d'ajuster les derniers paramètres puis de suivre le test de charge et surtout d'obtenir des rendus sur les résultats obtenus.

II. Installation de Locust

Nous pouvons utiliser le gestionnaire de module Python pip pour installer locust (Python3) :

$ pip -V
pip 22.2.1 from /home/itc/.local/lib/python3.10/site-packages/pip (python 3.10)

$ pip install locust

Nous pourrons ensuite importer locust dans nos scripts Python :

$ python3
Python 3.10.5 [GCC 11.3.0] on linux
>>> from locust import *

Nous voilà prêts à réaliser notre premier script de test de charge avec Locust !

III. Premier test de charge d'un service web

Pour commencer, faisons simple. Je vais ouvrir un mini serveur web HTTP avec Python dans un terminal :

python3 -m http.server

Cela me permettra d'avoir une cible pour mon script Locust, mais aussi de rapidement voir les journaux HTTP et constater si mon script se comporte comme je le souhaite. Créons un script simple, que je nomme /tmp/loc.py :

from locust import HttpUser, between, task

class WebsiteUser(HttpUser):
wait_time = between(3, 6)

def on_start(self):
self.client.get("/")

@task
def task1(self):
self.client.get("/")

@task
def task2(self):
self.client.get("/operation.php")

Première chose, pas besoin de spécifier l'URL/domaine cible dans le script, ce paramètre est géré plus tard via l'interface web. Nous allons à présent détailler notre premier script :

from locust import HttpUser, between, task

Importation du module Python locust est des fonctions utiles.

class WebsiteUser(HttpUser):

Création d'une classe WebsiteUser provenant du module Locust. Une instance de cette classe représente un utilisateur, qui pourra réaliser plusieurs requêtes/actions au cours du test.

wait_time = between(3, 6)

Délai d'attente de l'utilisateur entre chaque action, la valeur est ici sélectionnée aléatoirement entre 3 et 6 secondes. Au cours du test, nos utilisateurs seront créés tous en même temps ou au fur et à mesure et réaliseront des actions en boucle, avec un délai d'attente aléatoire entre chaque action.

def on_start(self):
self.client.get("/")

Définition du comportement de l'utilisateur lors de sa création, il ne réalisera cette action (ici, se rendre sur la racine de la cible web) qu'une fois. 

@task
def task1(self):
self.client.get("/")

@task
def task2(self):
self.client.get("/operation.php")

Création de deux tâches, qui, elles, seront exécutées en boucle :

  • aller sur la racine du site web (requête GET)
                  OU
  • aller sur la page /operation.php (requête GET)

Ces tâches sont identifiées par le décorateur @task. Il faut bien noter qu'à la suite de la tâche réalisée, le script observe un temps d'attente (paramétré entre 3 et 6 secondes ici), puis sélectionne une autre tâche et la réalise.

Maintenant que nous avons un script, assez simple, il nous suffit de le lancer. Si vous avez installé Locust via pip, il y a de bonnes chances pour que le binaire locust se situe dans votre dossier bin/ personnel (~/.local/bin/locust). Si vous l'avez installé via apt/yum, il doit être dans le dossier des binaires standard (/usr/bin) donc déjà dans votre PATH :).

$ /~/.local/bin/locust -f /tmp/loc.py
[2022-10-01 15:29:52,466] itc-test/INFO/locust.main: Starting web interface at http://0.0.0.0:8089 (accepting connections from all network interfaces)
[2022-10-01 15:29:52,481] itc-test/INFO/locust.main: Starting Locust 2.12.1

Nous pouvons à présent nous rendre sur l'interface web http://0.0.0.0:8089 :

Locust

Ici, on peut paramétrer le nombre total d'utilisateurs que nous souhaitons simuler et le nombre de créations d'utilisateurs par seconde. Par exemple, si je souhaite simuler 200 utilisateurs avec une création de 20 par seconde, j'aurai tous mes utilisateurs au bout de 10 secondes et chacun d'entre eux feront des boucles avec un délai d'attente de 3 a 6 secondes, puis une requête sur / ou /operation.php, tel que défini dans mon script.

Dans Advanced Options, le paramètre Run time permet de paramétrer une durée du test, utile pour faire des tests d'une durée équivalente entre plusieurs sites ou pour comparer des paramétrages différents côté service web.

Nous pouvons ensuite cliquer sur Start swarming, un tableau apparaîtra et détaillera le nombre de requêtes faites par point d'entrée, le nombre de fails, et différentes données sur les tailles et durée de réponse obtenue (à noter que RPS signifie request per second) :

Serveur Web - Test de charge Locust

Pour avoir des résultats parlant et contourner les limitations de capacité de mon environnement (voir chapitre "Limitations") j'ai donc monté une VM Linux avec 200 Mo de RAM, qui aura du mal à répondre à de multiples requêtes sur un réseau local d'hyperviseur. Également, j'ai créé sur ce service web une page index.html standard, et une page operation.php qui fait des opérations de chiffrement. Cela afin de simuler l'activité d'un serveur qui effectue des opérations dans une base de données afin de générer une réponse pour chaque requête. Je vous partage ici mon script pour information :

<?php

$s = "Welcome";

$ciphering = "AES-128-CTR";
$iv_length = openssl_cipher_iv_length($ciphering);
$options = 0;
$encryption_iv = '1234567891011121';
$round = rand(30,50);
for ($i =0; $i < $round; $i++)
{
$encryption_key = rand(1000000000,10000000000000);
$s = openssl_encrypt($s, $ciphering, $encryption_key, $options, $encryption_iv);
}
echo "s : $s\n";
?>

III. Analyse des résultats

Pendant et à la fin de l'exécution d'un test de charge, il est possible de visualiser les données dans le tableau exposé plus haut, mais également dans trois graphiques (menu Charts).

Le dernier graphique montre la montée en charge des tests avec le nombre d'utilisateurs simulés en même temps (ici 5000 utilisateurs avec une création des utilisateurs par lot 50/seconde).

Le premier graphique indique en vert le nombre de requêtes par seconde et en rouge, nombre d'échecs par seconde (erreur HTTP/500 ou timeout). Le graphique du milieu décrit le temps de réponse médian (ligne verte) et pour le 95eme centile (ligne jaune). C'est le graphique le plus intéressant, car sans causer d'erreur, une surcharge du serveur web va entraîner des temps de réponse de plus en plus longs. Ce que l'on observe dans mon graphique ci-dessus.

Pour rappel, la moyenne est la moyenne arithmétique d'une série de chiffres. la médiane est une valeur numérique qui sépare la moitié supérieure de la moitié inférieure d'un ensemble (50% des requêtes obtiennent un temps de réponse supérieur au temps médian, 50% un temps de réponse inférieur

En statistique le quatre-vingt-quinzième centile est la valeur telle que 95 % des valeurs mesurées sont en dessous et 5 % sont au-dessus.

Le menu Failures permet d'avoir une idée du nombre de message d'erreur reçu et de la réponse du serveur :

Ici, on peut identifier des échecs de réponse côté serveur (pas de réponse/timeout).

IV. Scripting "avancé" avec locust

Nous avons fait un script assez simple contenant deux tâches et des requêtes GET. En parcourant la documentation Locust. Vous remarquez qu'il est possible de faire des choses plus complexes.

A. Prioriser le comportement de l'utilisateur :

Si l'on souhaite orienter le comportement de nos utilisateurs, il est possible de mettre un "poids" assigné à chaque tâche :

class WebsiteUser(HttpUser):
wait_time = between(3, 6)

def on_start(self):
self.client.get("/")

@task(1)
def task1(self):
self.client.get("/")

@task(3)
def task2(self):
self.client.get("/operation.php")

Avec ces valeurs (@task(1), @task(3)), les utilisateurs auront trois fois plus de chance de sélectionner la tâche 2 plutôt que la tâche 1, ce qui permet de simuler une tendance des utilisateurs à aller plus sur une page que sur une autre.

B. Envoyer des données POST

Si vous souhaitez simuler les comportements d'utilisateurs envoyant des données (par exemple : authentification), cela est également possible

@task
def task3(self):
self.client.post("/login", json={"username":"foo", "password":"bar"})

C. Répartition de la charge de travail

Il est également possible de répartir la charge de travail lors du test à l'aide de nœuds esclaves. Il faut pour cela lancer une instance en mode master :

$ ~/.local/bin/locust -f loc.py --master
[2022-10-01 10:27:47,041] itc-test/INFO/locust.main: Starting web interface at http://0.0.0.0:8089 (accepting connections from all network interfaces)
[2022-10-01 10:27:47,056] itc-test/INFO/locust.main: Starting Locust 2.12.1

Les autres instances doivent être démarrées en mode worker et indiquer l'adresse IP du master:

$ /~/.local/bin/locust -f loc.py --worker --master-host=192.168.56.3

Lorsqu'un worker se connecte au master, le message suivant apparaît au niveau du master :

[2022-10-01 10:29:22,021] itc-test/INFO/locust.runners: Worker debian_77b92f24a7a54ac09ceeae99588e984b (index 0) reported as ready. 1 workers connected.

Attention cependant, dans ce cas, le master n'effectuera plus de requête lui-même. Il vous faudra donc au minimum deux workers pour avoir un gain de performance.

D. Pour aller plus loin

Je vous invite à consulter la documentation de Locust pour découvrir toutes ses possibilités : https://docs.locust.io/. Il est par exemple possible de lire le contenu des réponses puis d'afficher un message spécifique quand les résultats (menu Failures) afin d'avoir un tri plus personnalisé des messages d'erreurs et réponses du serveur.

Sans avoir testé toutes ses fonctionnalités, l'outil me paraît facilement personnalisable tant sur la partie test (comportement des utilisateurs) que sur la présentation des résultats.

V. Limitations

A. Capacité système

Il est important de noter que des limitations peuvent exister dans vos environnements de test et empêcher Locust d'atteindre les charges demandées. Votre système n'est à lui seul pas en capacité de lutter contre un serveur digne de ce nom (à moins de trouver une vulnérabilité permettant de décupler votre force de frappe, type amplification). Ce dernier comporte des limitations comme le nombre de fichiers pouvant être ouverts en même temps, ou le nombre de connexions en attente pouvant être active en même temps. Par exemple, voici ce que j'obtiens si je souhaite simuler 10 0000 utilisateurs avec Locust sur une machine virtuelle (4 Go de RAM) :

À première vue, mon test a permis de faire tomber le serveur web, le nombre de "fail" ne fait qu'augmenter ! Cependant, si je regarde le menu Failures pour avoir les détails des messages d'erreurs obtenus, j'obtiens cela :


C'est mon système qui limite les tests (OSError - Too many open files), il ne parvient plus à ouvrir de fichier (il crée certainement un fichier socket par connexion ou utiliser un fichier pour stocker le résultat de chaque requête de façon temporaire). Mon système ici n'est tout simplement pas calibré pour simuler autant de connexions. D'ailleurs, Locust nous prévient rapidement de cette limitation :

# /home/itc/.local/bin/locust -f /home/itc/Documents/loc.py 
WARNING/locust.main: System open file limit '1024' is below minimum setting '10000'.
It's not high enough for load testing, and the OS didn't allow locust to increase it by itself.
See https://github.com/locustio/locust/wiki/Installation#increasing-maximum-number-of-open-files-limit for more info.

En effet, vous pouvez toujours essayer de créer 2000 requêtes par seconde, si votre système ou l'infrastructure réseau n'est pas fait pour supporter une telle charge, Locust ne parviendra au maximum des capacités paramétrées et cela faussera vos tests.

B. Capacité réseau

Les limitations de vos tests peuvent également provenir de votre environnement réseau. Par exemple, j'ai fait mes premiers tests depuis une VM VirtualBox dont l'interface était paramétrée en mode NAT, ce qui impacte très durement les capacités réseau (Locust ne parvenait qu'à faire 9 requêtes par seconde). Le passage en bridge m'a permis de passer à 60 requêtes par seconde. Le tout pour un site situé sur Internet, chemin par lequel d'autres éléments peuvent freiner mon test (mon routeur, mon architecture réseau, etc.).

Également, si votre poste est en Wifi, il risque d'être rapidement limité par les capacités du point d'accès qui acheminera vos paquets jusqu'au serveur web testé.

Il faut donc être conscient de tout cela lorsque l'on fait un test.

C. Contourner les limitations locales

Pour contourner ces limitations techniques, le plus simple semble de louer un serveur à haute capacité (réseau et système) chez un hébergeur cloud (OVHcloud, Azure, Google Cloud Platforme, AWS, etc.). Directement exposé sur Internet et profitant d'infrastructures musclées, ce serveur ne subira les freins et ralentissements éventuels de vos réseaux internes et vos tests ne perturberont pas vos utilisateurs.

Une deuxième option lorsque vous hébergez vos serveurs web dans votre propre Datacenter est de se brancher directement au serveur en question pour avoir un test qui sera le plus "violent" possible.

Dans un contexte réaliste, il ne faut pas oublier de tester non seulement le serveur web, mais aussi tous les composants qui peuvent y mener dans le cadre de l'utilisation de normale de ce dernier. Par exemple, lorsqu'un utilisateur parcourt votre site web depuis internet, il passe par votre routeur périphérique, votre pare-feu, potentiellement un système anti-DDOS, un reverse-proxy, etc. Ces éléments peuvent chacun constituer un point faible au niveau du test de charge : qu'est-ce qu'un SPOF ? 

N'hésitez pas à poser vos questions et partagez vos expériences dans les commentaires ou sur notre Discord.

The post Serveur Web : tests de charge en Python avec Locust first appeared on IT-Connect.

YouTube détériore son service pour vendre des abonnements et c’est une très mauvaise idée

4 octobre 2022 à 10:52

YouTube

Chez certains utilisateurs de YouTube, la 4K est désormais présentée comme une option exclusive à l'abonnement YouTube Premium. On comprend l'intention, mais on doute qu'il s'agisse de la bonne direction.  [Lire la suite]

Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/

Les influenceurs cryptos ne vont plus pouvoir faire de publicités financières sur Google

3 octobre 2022 à 09:59

Le moteur de recherche a annoncé de nouvelles règles concernant les publicités sur les services financiers. Les contrôles vont être renforcés et les annonceurs sélectionnés.  [Lire la suite]

Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/

Hotmail : à la découverte de l’histoire incroyable de ce service de messagerie

3 octobre 2022 à 09:11
Par : UnderNews

L’aventure de la messagerie Hotmail a commencé le 4 juillet 1996 grâce à ses fondateurs du nom de Sabeer Bhatia et Jack Smith. Ces derniers proposaient leurs programmes gratuitement aux utilisateurs d’où son succès fulgurant comme en témoigne le nombre d’inscrits. Nous avons notamment recensé pas moins de 8 millions d’utilisateurs dès l’année 1997. Une […]

The post Hotmail : à la découverte de l’histoire incroyable de ce service de messagerie first appeared on UnderNews.

Il existe un jeu secret sur Firefox : Pong, mais avec des licornes

2 octobre 2022 à 17:51

licorne

Firefox a un mini-jeu secret bien caché : une sorte de Pong, mais une licorne remplace la balle.  [Lire la suite]

Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/

Escalade, combat à l’arme blanche & 3D : 5 chaînes YouTube à découvrir en octobre 2022

1 octobre 2022 à 15:09

Vincent grimpe

Retrouvez notre sélection de chaînes YouTube pour octobre 2022, où l'on va parler de combat à l'arme blanche, de 3D, d'escalade, de fiction et de géopolitique.  [Lire la suite]

Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/

Le crash de DART sur l’astéroïde a été vu simultanément par James Webb et Hubble

1 octobre 2022 à 12:31

Hubble James Webb Dart

C'est une première : deux télescopes spatiaux, Hubble et James Webb, ont observé le même évènement au même moment. Il s'agissait du crash de la sonde DART sur un astéroïde. [Lire la suite]

Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/

« Une tâche critique pour l’humanité » : plongée dans les SMS lunaires d’Elon Musk pendant le rachat de Twitter

30 septembre 2022 à 13:19

À quelques jours du début du procès Twitter v. Musk, plusieurs conversations privées entre les différents acteurs de l'affaire deviennent publics. Elon Musk n'a pas encore témoigné, mais certains de ses textos suffisent pour mieux comprendre ce qu'il s'est passé.  [Lire la suite]

Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/

Le Facebook russe Vkontakte a été banni de l’App Store par Apple

28 septembre 2022 à 15:45

VKontakte

Apple empêche désormais VKontakte d'avoir accès à l'App Store pour distribuer ses applications sur iPhone et iPad. VK, équivalent d'un Facebook russe, est éjecté dans le cadre de sanctions occidentales contre Moscou.  [Lire la suite]

Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/

Comment changer son nom d’utilisateur sur Instagram ?

28 septembre 2022 à 07:07

Instagram

Instagram fournit dans ses paramètres un outil permettant de changer votre nom d'utilisateur. Mais il y a quelques petites choses à savoir avant de se lancer.  [Lire la suite]

Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/

Comment trouver des tweets à partir d’une localisation ?

27 septembre 2022 à 09:00
Par : Korben

Savez vous comment faire une recherche de tweets dans une zone géographique particulière ?

Et bien déjà, il faut vous rendre sur la page de recherche de Twitter en cliquant ici.

Puis entrer votre requête comme ceci :

geocode:LATITUDE,LONGITUDE,RAYON

Je vous donne un exemple. Je récupère les coordonnées GPS en faisant un clic droit sur Google Maps comme ceci :

Puis, je les rentre dans la recherche Twitter en ajoutant un rayon de 1 km :

geocode:45.77242922106398,3.0883699843560533,1km

Et voilà, j’obtiens tous les tweets localisés dans un rayon de 1 km autour de mon point géographique. Super pratique !

Et si vous ne voulez pas vous embêter avec les coordonnées GPS, vous pouvez également vous rendre sur le site Birdhunt qui vous permet de placer un point, de définir un rayon et d’obtenir les tweets que vous chérissez tant. Et en jetant un oeil dans les options avancées, vous pourrez également spécifier la langue, le type de tweets (tous, vidéo, photo), le nombre de likes ou de retweets minimum…etc.

Le protocole HTTP pour les débutants

26 septembre 2022 à 18:15

I. Présentation

Dans cet article "Le protocole HTTP pour les débutants", je vous propose de découvrir le protocole HTTP avant d'étudier le protocole HTTPS au travers d'un prochain article ! Connaître le protocole HTTP est indispensable pour bien appréhender le fonctionnement du protocole HTTPS. Après une brève présentation de ce protocole, nous rentrerons dans le détail et nous finirons par une mise en pratique.

Le protocole HTTP, pour HyperText Transfer Protocol, est un protocole de communication client-serveur qui permet d'accéder à des ressources situées sur un serveur Web. Aujourd'hui, on lui préfère le HTTPS, dont le S signifie Secured, il s'agit d'une variante sécurisée du protocole HTTP et qui s'appuie sur les protocoles TLS pour chiffrer les échanges entre le client et le serveur.

Pour communiquer avec un serveur Web au travers du protocole HTTP, on s'appuiera sur un client HTTP. Au quotidien, ce client HTTP prend la forme d'un navigateur Internet (Firefox, Chrome, Edge, etc...), même s'il existe de nombreux outils, notamment en ligne de commandes, capable d'effectuer des requêtes Web.

Depuis les débuts de l'Internet, le protocole HTTP (et maintenant le HTTPS) est utilisé sur les serveurs Web, notamment pour héberger un site Internet, que ce soit un blog, un site vitrine, ou un site d'e-commerce. Le HTTPS est recommandé, car il est sécurisé (échanges chiffrés) contrairement au HTTP.

Merci à Florian Duchemin pour sa relecture !

II. Les différentes versions de HTTP

Le protocole HTTP a vu le jour en 1989, grâce aux travaux de Tim Berners-Lee et de son équipe lorsqu'il travaillait au CERN. Son idée : créer un système hypertexte sur Internet, ce qui donnera le World Wide Web et les trois fameuses lettres "www", lors de sa mise en place en 1990, avant d'être lancé officiellement auprès du grand public le 6 août 1991.

Note : dans le même temps, le langage HTML (HyperText Markup Language) a vu le jour afin de permettre la création des documents hypertextes. C'est l'un des éléments du WWW, auquel il faut ajouter le protocole HTTP bien sûr, mais aussi la gestion des URL, le client HTTP et le serveur HTTP.

Pour ces premières années d'existences du protocole HTTP, il n'y avait pas réellement de numéro de version associé, alors aujourd'hui on parle de la version HTTP/0.9. On l'appelle aussi le protocole une ligne. Pourquoi ? Tout simplement parce qu'il ne permettait que de demander une page HTML au travers d'une requête, grâce à une commande GET (nous reviendrons sur les commandes). Par exemple, la commande HTTP "GET /page1.html" renvoyait le contenu de la page HTML. Ni plus, ni moins.

C'est en 1996 que HTTP/1.0 a vu le jour quand l'IETF (Internet Engineering Task Force) en a fait une description complète au sein de la première RFC du protocole HTTP : RFC 1945. Cette version a été l'introduction de nouveaux concepts, comme les en-têtes HTTP avec le champ "Content-Type" dans le but de transférer d'autres documents que des documents au format HTML. Néanmoins, bien que basé sur le protocole TCP, le HTTP/1.0 est un protocole stateless, ce qui signifie que chaque communication entre un même client et un même serveur nécessite la création d'une nouvelle connexion.

Ensuite, en 1997 la version HTTP/1.1 a vu le jour, avant d'être révisée un peu plus tard, et elle a apportée plusieurs évolutions bienvenues comme la notion de "Keepalive" pour maintenir les connexions au-delà d'une seule requête, mais aussi, la notion de cache pour mettre en mémoire certains éléments.

En 2015, le protocole HTTP/2 a vu le jour et il est désormais utilisé sur une grande majorité de sites Internet. Néanmoins, la version HTTP/1.1 reste encore utilisée aujourd'hui. Pour l'avenir, et la version HTTP/3, les choses avancent bien même s'il n'y a pas encore de RFC correspondante.

Le HTTP/3 correspond au HTTP-over-QUIC (Quick UDP Internet Connections) et il s'appuie sur QUIC, une version améliorée de l'UDP lancée en 2012 par Google. On peut dire que QUIC est un protocole de transport qui va rentrer en concurrence avec UDP et TCP. Le HTTP/3 est déjà utilisé par certains géants de l'Internet dans le but d'avoir un Web plus rapide. Sur le site de l'IETF, le protocole HTTP/3 bénéficie désormais de sa propre RFC - après plusieurs années de travaux : IETF - RFC 9114 - HTTP/3.

Pour en savoir plus sur les différentes versions du protocole HTTP et son évolution, je vous recommande de lire cette page publiée sur le site de Mozilla : l'évolution du protocole HTTP

Voici un récapitulatif des versions du protocole HTTP :

Les versions du protocole HTTP

III. Quel est le port utilisé par le HTTP ?

Pour les communications entre un client HTTP et un serveur Web, le port 80 est utilisé lorsque le protocole HTTP sert à établir la connexion. Autrement dit, le serveur Web écoute sur le port 80 pour recevoir les requêtes HTTP émises par les clients.

C'est le seul numéro de port associé au protocole HTTP. Ainsi, lorsque l'on se connecte sur une page Web, par exemple "http://www.domaine.fr", le navigateur sait qu'il doit envoyer sa requête sur le port 80 du serveur Web. Néanmoins, il est possible d'utiliser un port d'écoute différent sur son serveur Web, dans ce cas il faudra le spécifier au niveau de la requête. Si le port 80 est remplacé par le port 8080, il faudra utiliser la syntaxe suivante : http://www.domaine.fr:8080.

Pour information, le protocole HTTPS utilise un numéro de port différent puisqu'il s'appuie sur le port 443.

IV. Les requêtes et les réponses HTTP

Lorsqu'un client communique avec un serveur au travers du protocole HTTP, il émet une requête HTTP à destination du serveur. Autrement dit, lorsque votre ordinateur se connecte à un site Web via le protocole HTTP. Ces requêtes contiennent différentes informations, notamment des commandes HTTP et le serveur va envoyer une réponse HTTP au client.

A. Les requêtes HTTP

Commençons par les requêtes HTTP, à destination du serveur Web, émises par un client. Il est important de connaître les méthodes HTTP les plus courantes pour bien comprendre le fonctionnement du protocole HTTP. Une méthode est une commande.

Une requête HTTP contient une méthode, une cible (précisée par son chemin) et la version du protocole utilisé. En complément, la requête HTTP contient un en-tête HTTP avec différents champs qui indiquent l'hôte cible, le langage, etc...

Exemple requête HTTP

  • La méthode GET

GET est probablement la commande la plus populaire et la plus utilisée, car elle permet de demander une ressource au serveur Web. Par exemple, un fichier HTML, un fichier JavaScript ou tout simplement un fichier image. Prenons un exemple :

GET /index.html

Avec cette commande, le client, par l'intermédiaire de son navigateur Web, demande au serveur Web de lui envoyer le contenu du fichier "index.html" : nécessaire pour afficher la page d'accueil du site. En effet, le fichier "index.php" ou "index.html" fait généralement référence à la page d'accueil d'un site.

Pour une image, nous pouvons imaginer une requête comme celle-ci :

GET /images/photo1.png

Dans les deux exemples ci-dessus, nous demandons des ressources statiques au serveur Web. Néanmoins, sur un site Web dynamique, écrit en PHP par exemple, nous pouvons ajouter des paramètres pour affiner la requête. Prenons un exemple :

GET /tutoriels.php?numero=1

Ici, nous appelons la page "tutoriels.php" en précisant le paramètre "numero" avec la valeur 1. On peut imaginer que c'est une façon de demander au serveur Web de nous fournir le contenu du tutoriel avec l'identifiant numéro 1.

Note : il est possible d'ajouter des caractères spéciaux dans les requêtes, en utilisant un encodage. Par exemple, le caractère "é" s'écrit "%C3%A9".

  • La méthode POST

Avec la méthode GET, le contenu de la requête est visible directement dans le navigateur. Ce n'est pas idéal pour certaines informations que l'on aimerait masquer, et ce n'est pas non plus idéal pour envoyer une quantité d'informations importantes (l'URL a une limite de caractères), voire même pour charger un fichier image sur le serveur.

Heureusement, il existe une méthode plus adaptée : la commande POST. Lorsque l'on utilise la commande POST, le client n'ajoute pas les paramètres à la requête donc ils ne sont pas visibles dans l'URL, mais ils sont ajoutés directement dans l'en-tête HTTP.

La méthode POST est très populaire pour envoyer des images et soumettre un formulaire (que ce soit une enquête en ligne ou un simple formulaire de contact). Dans le cas d'un formulaire, la méthode POST est précisée dans la déclaration du formulaire, dans le code HTML, et la page de destination s'attend aussi à réception des informations via la méthode POST.

<form action="contact.php" method="post">
  • La méthode HEAD

Même si les méthodes POST et GET sont les plus populaires, vous devez savoir qu'il existe aussi la méthode HEAD. Cette méthode permet d'obtenir des informations sur la ressource en elle-même, en obtenant l'en-tête de la réponse, sans pour autant demander la ressource en elle-même. Ainsi, on peut obtenir le poids du fichier (champ "content-length" de l'en-tête) sans avoir à le télécharger réellement, par exemple.

Voici un exemple :

HEAD /images/photo1.png

A minima, vous devez connaître ces trois types de méthodes, même s'il en existe plein d'autres : OPTIONS, LOCK, UNLOCK, CONNECT, DELETE, etc.

B. Les réponses HTTP

Lorsqu'un client émet une requête HTTP à destination du serveur Web, il obtient une réponse HTTP de la part du serveur (si la requête est bien arrivée à destination). Tout d'abord, cette réponse HTTP intègre la version du protocole utilisée, mais aussi un code de retour. Ce code de retour est très important, car il indique si la requête a été traitée correctement, si elle est introuvable, ou encore si l'accès est refusé.

Comme pour la requête HTTP, la réponse HTTP intègre un en-tête particulièrement riche en informations. En effet, il peut intégrer le type de serveur Web avec le champ "Server: Apache" pour Apache (même si cela peut être supprimé en adaptant la configuration du serveur), la date, le type de contenu, la taille du contenu, le contenu en lui-même (le code source d'une page HTML, par exemple), etc.

Exemple réponse HTTP

Les codes de retour HTTP sont intéressants pour interpréter la réponse renvoyée par le serveur, et là encore, il y en a certains qui sont à connaître par cœur ! 😉

Voici la liste des codes à connaître et qui sont les plus fréquents :

  • 200 : succès de la requête donc la ressource est chargée correctement
  • 301 et 302 : indique une redirection, permanente (301) ou temporaire (302), c'est utilisé lors du changement d'un domaine sur un site Web, ou lorsqu'une page change d'URL
  • 403 : l'accès à la ressource est refusé par le serveur, ceci peut se produire si l'accès à une page est limité à certaines adresses IP, par exemple
  • 404 : la ressource est introuvable (vous savez, la fameuse page "404 not found" ou "404 page introuvable")
  • 500 : erreur côté serveur, ce qui peut être liée à une erreur de code, par exemple. Il y a aussi les codes 502 et 503, moins fréquents.

Si vous souhaitez obtenir plus d'informations sur l'ensemble des codes HTTP, vous pouvez consulter cette page : Codes HTTP.

V. Mise en pratique du protocole HTTP

Pour mettre en pratique le protocole HTTP, il est possible de mettre en place un serveur Web afin d'avoir accès au serveur et au client. Une grande majorité des serveurs Web tournent sous Linux et ils s'appuient sur Apache ou NginX. Côté Windows, la solution officielle se nomme IIS.

A. Installation d'Apache sur Debian

Si l'on prend l'exemple d'une machine Linux sous Debian, nous pouvons mettre en place un serveur Web très rapidement.

On commence par mettre à jour le cache des paquets :

sudo apt-get update

Ensuite, on installe le paquet "apache2" afin d'obtenir la dernière version d'Apache 2.4.

sudo apt-get install -y apache2

Pour qu'Apache démarre automatiquement en même temps que Debian, saisissez la commande ci-dessous :

systemctl enable apache2

Dès maintenant, le serveur Web est actif et la page par défaut est accessible. Pour le vérifier, dégainez votre navigateur favori et accédez à cette adresse (en remplaçant l'adresse IP par celle de votre serveur) :

http://192.168.100.120

Voici un exemple :

Apache en ligne, sous Debian 11

Vous allez me dire : d'où vient cette page ? En fait, Apache est livré avec un site par défaut qui est stocké à cet emplacement :

/var/www/html

La page d'index qui s'affiche quand on accède au site est située dans ce répertoire.

B. Récupérer des informations sur les en-têtes HTTP avec cURL

L'utilitaire cURL est disponible sur Windows, macOS et Linux. Il s'utilise en ligne de commande et il permet d'interroger un serveur Web afin de récupérer une ressource. Il intègre de très nombreuses options... Nous allons l'utiliser pour récupérer des informations sur les en-têtes HTTP.

Tout d'abord, si l'on indique la page cible sans préciser d'options, l'outil va exécuter la requête HTTP et afficher dans la console le code source de la page. Voici un exemple avec un serveur avec l'adresse IP "192.168.100.14" et qui dispose d'une page personnalisée :

curl http://192.168.100.14

Nous pouvons voir le code source de la page d'accueil de ce site s'afficher en retour dans la console.

Protocole HTTP - Exemple cURL - Code source de la page

Maintenant, si l'on veut en savoir un peu plus la réponse fournie par le serveur, on peut ajouter l'option "-I" (ou "-i" pour avoir en plus le code source) :

curl -I http://192.168.100.14

On obtient ceci :

Protocole HTTP - Exemple cURL - Réponse HTTP

Dans l'exemple ci-dessus, je constate que la ressource s'est chargée correctement, car j'ai un code de retour "200 OK". Je constate aussi que je communique avec un serveur Apache, grâce à la mention "Server: Apache" (à moins que le serveur utilise une fausse valeur pour m'induire en erreur !).

Pour forcer la génération d'une erreur 404, correspondante à une page introuvable, c'est assez simple : il suffit de cibler une URL qui n'existe pas. Par exemple :

curl -I http://192.168.100.14/pageinexistante.html

Ce qui donne :

Protocole HTTP - Exemple cURL - Page introuvable

Dans l'exemple ci-dessus, nous pouvons voir le code de retour "404 Not Found" qui confirme que la page n'existe pas ! Le code source de la page va dans le même sens puisque la page retournée par le serveur (il s'agit d'une page définie dans la configuration du serveur et que ce dernier doit retourner lorsqu'il y a un erreur 404) s'intitule : 404 Not Found.

Pour avoir une sortie encore plus complète, nous pouvons utiliser l'option -v qui va indiquer à la fois des informations sur la requête et sur la réponse. Voici un exemple :

curl -v http://192.168.100.14

Exemple de cURL avec la requête et la réponse HTTP

C. Analyser les flux avec Wireshark

Les informations visibles dans cURL transitent sur le réseau, entre la machine cliente et le serveur Web. De ce fait, nous pouvons capturer ces flux avec un logiciel tel que Wireshark et voir ce qui se passe d'un point de vue réseau. Sur l'image ci-dessous, je capture les flux réseau générés par la commande "curl -v http://192.168.100.14". Au-delà des paquets HTTP (la requête, puis la réponse), il y a aussi des paquets TCP, car le protocole HTTP (sauf HTTP/3) s'appuie sur le protocole de transport TCP pour la gestion des connexions.

Wireshark - Flux HTTP

Le paquet correspondant à la requête HTTP (générée par le logiciel cURL) montre bien que la méthode GET comme commande. Puisque le protocole HTTP n'est pas sécurisé, tout le contenu de la requête est visible en clair sur le réseau.

Wireshark - Flux HTTP - Requête

Ensuite, nous avons également le paquet correspondant à la réponse du serveur Web, avec là aussi, les informations en clair. Nous pouvons voir le code source de la page sous le champ "Line-based text data".

Wireshark - Flux HTTP - Réponse en clair

Lorsque nous ferons le même exercice avec le protocole HTTPS, nous verrons que les flux sont chiffrés et qu'une capture réseau ne permet pas d'obtenir toutes ces informations.

C'est également vrai avec le protocole HTTP/3 qui s'appuie sur le protocole de transport QUIC à la place de TCP, et qui intègre nativement du chiffrement. En effet, QUIC est un nouveau protocole de transport qui bénéficie du chiffrement natif (pas de version en clair), ce qui permet d'utiliser le protocole HTTP tout en bénéficiant du chiffrement. QUIC est un protocole d'avenir, déjà utilisé par les géants du Web (et pris en charge dans certains navigateurs). Il devrait faire parler de lui dans les prochaines années : c'est un protocole optimisé pour le Web, mais qui pourrait être utilisé pour d'autres usages.

D. Ressources supplémentaires

Voici quelques tutoriels complémentaires sur la mise en œuvre d'Apache, Nginx et IIS :

VI. Conclusion

Cette introduction au protocole HTTP touche à sa fin, désormais vous en savez plus sur l'histoire de ce protocole, son fonctionnement et vous êtes en mesure d'interpréter un minimum les requêtes et les réponses HTTP. Dans un prochain article, nous étudierons le protocole HTTPS mais il me semblait important de s'intéresser au protocole HTTP dans un premier temps puisque HTTPS est une évolution qui améliore la sécurité.

The post Le protocole HTTP pour les débutants first appeared on IT-Connect.

Des hackers ont caché un malware dans une image du télescope James Webb

2 septembre 2022 à 09:42

Une société en cybersécurité a repéré une campagne d'hameçonnage utilisant les clichés du célèbre télescope pour installer un programme malveillant. Ce dernier permet de surveiller et espionner l'activité de la victime à distance.  [Lire la suite]

Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/

Twitter mentirait sur beaucoup de choses, selon son ancien chef de la sécurité

23 août 2022 à 18:04

Peiter Zatko, un hacker connu sous le pseudonyme de « Mudge », a été le chef de la sécurité de Twitter entre 2020 et 2022. Dans un rapport envoyé aux autorités américaines, il dénonce son ancien employeur, auteur de multiples infractions.  [Lire la suite]

Abonnez-vous aux newsletters Numerama pour recevoir l’essentiel de l’actualité https://www.numerama.com/newsletter/

❌