\nMaintenant que cette base est pos\u00e9e, revenons \u00e0 nos moutons \u00e9lectriques et connectons-nous \u00e0 \u00ab\u00a0https:\/\/www.google.fr\u00a0\u00bb<\/p>\n
TCP\/IP<\/h1>\n
La premi\u00e8re \u00e9tape, consiste \u00e0 savoir par quelle magie on va relier notre ordinateur, \u00e0 la machine sur laquelle est h\u00e9berg\u00e9 le site web de google… Et pour r\u00e9aliser cette prouesse, notre ordinateur va envoyer une requ\u00eate ; c’est-\u00e0-dire un genre de message destin\u00e9 au serveur de google : \u00ab\u00a0S’il te pla\u00eet gentil serveur, montre-moi la page internet que tu abrites s’il te pla\u00eet\u00a0\u00bb. Et pour faire \u00e7a, il va utiliser le protocole TCP\/IP<\/strong>. Le protocole TCP<\/strong>, organise les donn\u00e9es afin qu’elles puissent \u00eatre transmises sur le r\u00e9seau C’est \u00e9galement TCP<\/strong> qui divise les grosses quantit\u00e9s de donn\u00e9es en petits morceaux qu’on appelle des paquets.<\/p>\n Pour faire une analogie, au lieu d’envoyer tout un livre d’un coup, c’est comme si on envoyait le livre page par page<\/strong>, en demandant \u00e0 chaque fois : Le protocole IP,<\/strong> lui, permet de d\u00e9finir les adresses de d\u00e9part et d’arriv\u00e9e<\/strong> de la requ\u00eate, et pour chaque paquet, il va trouver un chemin<\/strong> possible (sans garantir que tous les paquets suivent le m\u00eame chemin)<\/p>\n Il faut imaginer que chaque paquet a une petite \u00e9tiquette<\/strong> avec l’adresse<\/strong> de<\/strong> destination<\/strong> et l’adresse<\/strong> de<\/strong> d\u00e9part<\/strong>. Et \u00e0 chaque routeur crois\u00e9 sur le chemin regarde l’adresse de destination. Le routeur ne conna\u00eet pas forc\u00e9ment l\u2019adresse finale, mais il conna\u00eet ses voisins et sait dans quelle direction<\/strong> il doit envoyer le paquet pour se rapprocher de la destination. Il renvoie donc le paquet \u00e0 un autre routeur, qui fait la m\u00eame chose, et ainsi de suite<\/strong>, jusqu\u2019\u00e0 ce que le paquet atteigne le bon serveur. C’est pourquoi ces deux technologies sont utilis\u00e9es ensemble dans ce qu’on appelle TCP\/IP<\/strong> car elles vont de pair, et comme j’expliquais plus t\u00f4t : on en arrive \u00e0 confondre parfois qui fait quoi.<\/p>\n Maintenant qu’on sait \u00e7a, on pense que le plus dur est fait et qu’on peut envoyer nos paquets \u00e0 la bonne adresse… Et ben non !<\/strong> et en IPv6 pour les num\u00e9ros suivants :<\/p>\n Or, le protocole IP qui trouve le chemin entre le point de d\u00e9part, et le point d’arriv\u00e9e a justement besoin de ces num\u00e9ros !<\/strong> C’est pas vraiment le but de l’article mais pour faire court… Dans des temps imm\u00e9moriaux : au d\u00e9but de l’\u00e9mergence d’internet fin des ann\u00e9es 80, d\u00e9but des ann\u00e9es 90, le monde d\u00e9couvre la version 4 de IP<\/strong> qui ne devait servir qu’\u00e0 faire des tests \u00e0 l’\u00e9chelle mondiale<\/strong> chez les gros acteurs du moment comme IBM, les universit\u00e9s, ou les agences gouvernementales. (Les versions pr\u00e9c\u00e9dentes de IP \u00e9taient exp\u00e9rimentales et n’ont \u00e9t\u00e9 utilis\u00e9es en laboratoire dans les d\u00e9partements de R&D et \u00e0 tr\u00e8s petite \u00e9chelle.) Au d\u00e9part, personne ne pensait que cette technologie d\u00e9passerait ce cercle restreint<\/strong>. Mais \u00e7a fonctionnait bien, et Internet a commenc\u00e9 \u00e0 se populariser<\/strong> \u00e0 partir des ann\u00e9es 90 et ce prototype qui ne devait \u00eatre que temporaire pour une phase de test est devenu la norme. C’est pourquoi a \u00e9t\u00e9 cr\u00e9\u00e9 IPv6<\/strong> qui lui, propose des adresses \u00e9crites sur 8 blocs en hexad\u00e9cimal<\/strong> comme par exemple : 2a0c:e303:0:8400:aaf5:6906:834d:a605<\/em><\/p>\n Et le nombre possible d’adresses avec ce syst\u00e8me est gigantesque<\/strong> ! On dit que ce nombre est tellement grand qu\u2019on dit souvent qu\u2019il d\u00e9passe le nombre d\u2019atomes dans l\u2019univers observable. Autant dire qu\u2019on est tranquilles pour un moment.<\/strong><\/p>\n Et pour les petits malins du fond de la salle qui se demandent \u00ab\u00a0Et IPv5 ? On passe de 4 \u00e0 6 ?\u00a0\u00bb<\/em> Et oui ! IPv5 est lui aussi exp\u00e9rimental et n’a servi qu’\u00e0 faire des tests th\u00e9oriques dans les laboratoires de R&D<\/p>\n Vous me direz que ce petit cours d’histoire \u00e9tait vachement sympathique, mais on fait quoi avec de nos adresses et de nos num\u00e9ros ?<\/p>\n C’est l\u00e0 que le DNS intervient !<\/p>\n DNS<\/strong> pour Domain Name Server<\/em> est une technique qui permet de faire le lien entre les noms et les num\u00e9ros.<\/strong> On trouve souvent sur internet cette explication : que les DNS ont \u00e9t\u00e9 invent\u00e9s uniquement pour faciliter la vie aux humains qui pr\u00e9f\u00e8rent des noms uniques et m\u00e9morisables<\/strong> comme \u00ab\u00a0mon-super-site.bidule\u00a0\u00bb<\/em> plut\u00f4t que \u00ab\u00a0195.042.217.12\u00a0\u00bb.<\/em> C’est en partie vrai.<\/p>\n L’autre explication c’est que ces noms permettent une stabilit\u00e9<\/strong> par rapport aux adresses IP. En effet, les adresses IP sont distribu\u00e9es par les fournisseurs, et elles peuvent changer.<\/p>\n Pour faire une analogie, je sais que Bob<\/strong> habite au 42 Ada Lovelace Street \u00e0 Gen\u00e8ve<\/em>, mais s’il d\u00e9m\u00e9nage, je dois conna\u00eetre sa nouvelle adresse postale. De la m\u00eame fa\u00e7on, utiliser un nom de domaine avec un syst\u00e8me de DNS permet de (presque) toujours vous rediriger vers la bonne adresse de serveur (sans que vous n’ayez rien \u00e0 faire car tout \u00e7a se passe dans votre dos) m\u00eame quand la machine ou le fournisseur d’acc\u00e8s change (et par cons\u00e9quent les adresses IP).<\/p>\n Il suffit d’une requ\u00eate qui demande gentiment \u00ab\u00a0O\u00f9 se trouve l’adresse de ‘mon-super-site.fr’ s’il te pla\u00eet ?\u00a0\u00bb<\/em> et le DNS nous r\u00e9pond ! Maintenant que l’on a vu qu’il faut une adresse IP pour que les machines puissent discuter, et qu’un serveur DNS sur le principe permet de faire le lien entre les noms et les adresses IP, il faut s’int\u00e9resser au fonctionnement de la r\u00e9solution DNS. <\/strong><\/p>\n Et pour comprendre \u00e7a, il faut d’abord que je vous explique les diff\u00e9rents niveaux…<\/p>\n Les noms de domaines sont \u00e9crits d’une certaine fa\u00e7on avec plusieurs niveaux. Quelques exemples de nom de domaine :<\/p>\n En pratique<\/strong>, on utilise g\u00e9n\u00e9ralement 2 ou 3 niveaux<\/strong> (comme Maintenant que l’on conna\u00eet la structure des noms de domaine, voyons comment c’est traduit en adresse IP. Au d\u00e9part, la demande est faite \u00e0 une machine qu’on appelle le r\u00e9solveur DNS qui est g\u00e9n\u00e9ralement situ\u00e9 chez votre FAI, mais elle peut \u00eatre aussi sur un r\u00e9seau local d’entreprise, ou d’universit\u00e9 par exemple.<\/p>\n Cette machine ne conna\u00eet pas l’adresse de Note :<\/strong> L’adresse et le nom sont fictifs Et vous vous dites s\u00fbrement \u00ab\u00a0Mais \u00e7a doit \u00eatre super long !\u00a0\u00bb Et oui, \u00e7a l’est. Mais il faut savoir que le serveur r\u00e9solveur met en cache<\/strong> les requ\u00eates qu’il a d\u00e9j\u00e0 effectu\u00e9es. \u00c7a veut dire qu’il garde de c\u00f4t\u00e9<\/strong> certaines informations pendant un certain temps, pour ne pas aller redemander \u00e0 chaque fois .<\/strong><\/p>\n Dans notre exemple si dessus, si maintenant on veut acc\u00e9der \u00e0 Youpi !<\/p>\n Maintenant qu’on a r\u00e9cup\u00e9r\u00e9<\/strong> l’adresse via le DNS<\/strong>, et qu’on sait envoyer des paquets<\/strong> vers cette adresse via TCP\/IP<\/strong>, comment on envoie la demande ? Le probl\u00e8me, c’est que avec HTTP<\/strong>, les demandes sont envoy\u00e9es en clair,<\/strong> c’est-\u00e0-dire que n’importe qui de mal intentionn\u00e9 sur le r\u00e9seau pourrait voir votre demande et la r\u00e9ponse. Un peu \u00e0 la mani\u00e8re d’une carte postale : tout le monde peut voir ce qui est \u00e9crit dessus. C’est pourquoi on utilise HTTPS !<\/strong><\/p>\n HTTPS pour Hypertext Transfer Protocol<\/em> Secure <\/em>permet de chiffrer les \u00e9changes entre le client et le serveur avec le chiffrement SSL\/TLS.<\/strong><\/p>\n SSL\/TLS est un protocole qui permet de chiffrer les \u00e9changes. SSL<\/strong> (Secure Sockets Layer) est l’ancien nom du protocole qui n’est normalement plus utilis\u00e9. Et TLS<\/strong> (Transport Layer Security<\/em>) est sa version moderne et s\u00e9curis\u00e9e qui permet de prot\u00e9ger les donn\u00e9es, d’assurer qu’elles ne soient pas modifi\u00e9es, et de v\u00e9rifier qu’on parle au bon serveur via un certificat.<\/p>\n Afin de s’assurer qu’on parle au bon serveur, et que notre requ\u00eate n’est pas redirig\u00e9e par des petits malins sur un autre serveur, on utilise un principe de certificat. Concr\u00e8tement, lorsqu’on tente de se connecter \u00e0 un serveur, ce dernier commence par envoyer un certificat. C’est en quelque sorte un document qui stipule : \u00ab\u00a0Hey, je suis google.fr et voici ma cl\u00e9 publique ! D’ailleurs, \u00e7a \u00e9t\u00e9 v\u00e9rifi\u00e9 par une autorit\u00e9 de confiance !\u00a0\u00bb<\/em> Si un vilain pirate voulait falsifier ce certificat, il faudrait que Let’s Encrypt lui donne sa signature. Or Let’s Encrypt va demander une preuve pour \u00eatre s\u00fbr et certain qu’il fournit sa signature au propri\u00e9taire du serveur et pas \u00e0 un vilain pirate. Et une des m\u00e9thodes utilis\u00e9es c’est de demander un enregistrement DNS sp\u00e9cifique. <\/strong>C’est-\u00e0-dire que le propri\u00e9taire du site doit ajouter une ligne dans l’annuaire du domaine \u00ab\u00a0Le site web est \u00e0 l’adresse 123.123.123.123 type A, et voici une preuve pour lets encrypt : Blablabla…\u00a0\u00bb<\/em> On a bien avanc\u00e9 dans notre voyage ! On a commenc\u00e9 par trouver l’adresse IP<\/strong> de notre serveur via les DNS<\/strong>, puis on a chiffr\u00e9 notre demande via HTTPS, <\/strong>et TCP s’est occup\u00e9 de mettre tout \u00e7a dans des petits paquets et de les envoyer sur le r\u00e9seau, et IP<\/strong> de trouver un chemin pour les distribuer ! Ce pare-feu agit comme un filtre \u00e0 l’entr\u00e9e du serveur. Il v\u00e9rifie qui a le droit d’entrer (on peut filtrer par adresse, par port, par protocole par exemple) et permet ainsi de bloquer certaines attaques, ou du spam.<\/p>\n C’est une v\u00e9ritable barri\u00e8re de s\u00e9curit\u00e9 qui permet de bloquer certaines connexions avant m\u00eame qu’elles atteignent le serveur.<\/p>\n Typiquement le protocole HTTPS utilise le port 443, on peut donc param\u00e9trer le serveur pour dire \u00ab\u00a0Je ne veux accepter que des communications chiffr\u00e9es et s\u00e9curis\u00e9es, donc je n’accepte que les connexions entrantes sur le port 443.\u00a0\u00bb Une fois le pare-feu pass\u00e9, le client ne parle pas encore directement en HTTPS totalement chiffr\u00e9. La premi\u00e8re chose qu\u2019il fait, c\u2019est demander le certificat du serveur. Alors le serveur lui pr\u00e9sente gentiment (prouvant son identit\u00e9 comme expliqu\u00e9 plus haut) ; et le client v\u00e9rifie que tout est correct<\/strong> (signature par une autorit\u00e9 de confiance, domaine, etc.). Si tout est bon, le chiffrement est activ\u00e9<\/strong>.<\/p>\n La vraie requ\u00eate HTTPS<\/strong> commence alors : tout est d\u00e9sormais chiffr\u00e9 et donc illisible pour les curieux<\/strong>.<\/p>\n C’est ce qu’on appelle le TLS Handshake <\/em>dans le jargon<\/p>\n C\u2019est comme envoyer une carte postale disant : \u00c7a y est ! On a pass\u00e9 la \u00ab\u00a0s\u00e9curit\u00e9\u00a0\u00bb on est dans le serveur ! On arrive alors \u00e0 une esp\u00e8ce d’aiguillage. Car imaginons que le site est tellement populaire qu’un seul serveur ne suffit pas \u00e0 traiter toutes les demandes; il faudrait r\u00e9partir le flux de visiteurs vers plusieurs serveurs. Un peu comme au supermarch\u00e9, y’a plusieurs caisses enregistreuses pour g\u00e9rer le flux des visiteurs, et on dispatch les visiteurs vers les caisses libres. Il existe d’autres fa\u00e7ons de faire, mais ce sont les algorithmes les plus courants. On arrive enfin au web server<\/strong> apr\u00e8s toutes ces p\u00e9rip\u00e9ties !
\nIl s’agit de deux protocoles; et si vous \u00eates un peu malin vous avez devin\u00e9 qu’il s’agit de TCP<\/strong> et IP<\/strong> !
\nOn confond souvent les deux, car ils vont souvent ensemble, mais c’est bien deux protocoles distincts<\/strong><\/p>\nTCP<\/h2>\n
\nC’est ce protocole qui \u00e9tablit la connexion entre la source et la destination, et garantit que cette connexion reste active du d\u00e9but \u00e0 la fin de la communication.<\/p>\n
\n\u00ab\u00a0Je viens de t’envoyer la page 53, tu l’as bien re\u00e7ue ? Oui ? Alors j’envoie la suivante ! Non ? Eh bien, c’est pas grave, je te la renvoie !\u00a0\u00bb<\/em>
\n\u00c0 l’autre bout de la cha\u00eene, c’est \u00e9galement TCP<\/strong> qui reprend les pages une par une pour reconstituer<\/strong> le livre complet.
\nOn parle alors de recomposition de donn\u00e9e.<\/strong><\/p>\nIP<\/h2>\n
Trouver un chemin<\/h3>\n
\nEn revanche, c’est TCP<\/strong> qui est charg\u00e9 du suivi<\/strong> des paquets, de la v\u00e9rification<\/strong>, et de la remise en ordre<\/strong> des paquets.<\/p>\nLes num\u00e9ros gagnants<\/h1>\n
\nEn effet, les humains parlent avec des noms. Exemple google.fr<\/code>, wikipedia.org<\/code> ou blog.nanuq.me<\/code>
\nMais les machines elles… elles parlent avec des num\u00e9ros ! Respectivement \u00e7a correspondrait en IPv4 aux num\u00e9ros suivants pour les exemples ci-dessus :<\/p>\n\n
\n
\nEt avant d’aller plus loin, vous vous demandez s\u00fbrement pourquoi il y a deux num\u00e9ros diff\u00e9rents ?<\/strong><\/p>\nIPv4 & IPv6<\/h2>\n
\nOr, IPv4 un syst\u00e8me d’adresse en 4 blocs de chiffres allant de 0 \u00e0 255.<\/strong> Il y a quelques adresses r\u00e9serv\u00e9es et quelques exceptions mais en gros \u00e7a repr\u00e9sente donc 4 milliards<\/strong> d’adresses diff\u00e9rentes. Et ce nombre n’est pas extensible. Il y a un nombre fini d’adresses, mais le nombre d’utilisateurs augmente, ainsi que le nombre de machines, et il fallait plus d’adresses !<\/p>\nDNS<\/h2>\n
\nImaginez un monde o\u00f9 les noms de domaine n’existeraient pas et qu’il faudrait se souvenir de tous les num\u00e9ros… Pas pratique hein ?
\nLe DNS un peu \u00e0 la mani\u00e8re d’un agenda de t\u00e9l\u00e9phone, indiquera pour chaque nom de chaque site, son num\u00e9ro d’adresse IP.<\/p>\n
\nMais dans les faits, je m’en fiche de savoir o\u00f9 il habite, moi je veux juste voir mon ami Bob<\/strong> !<\/p>\n
\nC’est quand m\u00eame plus sympa pour b\u00e2tir une marque ou une identit\u00e9 sur internet !<\/p>\nLes r\u00e9solveurs DNS et les serveurs faisant autorit\u00e9<\/h1>\n
Les niveaux<\/h2>\n
\n
\n
![\"\"](\"https:\/\/blog.nanuq.me\/wp-content\/uploads\/2025\/05\/Capture-decran-du-2025-05-15-21-31-15.png\")
\n
www.google.fr<\/code>), mais techniquement<\/strong>, rien n’emp\u00eache d\u2019avoir beaucoup plus<\/strong>, tant que le nom complet<\/strong> ne d\u00e9passe pas 253 caract\u00e8res<\/strong> ! Un petit exemple avec une adresse fictive :<\/p>\n![\"\"](\"https:\/\/blog.nanuq.me\/wp-content\/uploads\/2025\/05\/Capture-decran-du-2025-05-15-21-47-28.png\")
Les r\u00e9solveurs DNS<\/h2>\n
\nReprenons notre exemple de bilbo.baggins.hobbiton.middleearth.lotr<\/code><\/p>\nbilbo.baggins.hobbiton.middleearth.lotr<\/code> . Pour ainsi dire, elle ne sait rien. Elle est b\u00eate. Et tout ce qu’elle conna\u00eet c’est l’adresse des serveurs root. Et elle va donc demander successivement \u00e0 plusieurs \u00ab\u00a0personnes\u00a0\u00bb :<\/p>\n\n
\n
bilbo.baggins.hobbiton.middleearth.lotr<\/code> ?\u00a0\u00bb<\/em><\/li>\n.lotr<\/code> … Lui il saura te renseigner !\u00a0\u00bb<\/em><\/li>\n<\/ul>\n<\/li>\n.lotr<\/code>\n\n
bilbo.baggins.hobbiton.middleearth.lotr<\/code> ?\u00a0\u00bb<\/em><\/li>\n.middleearth.lotr<\/code> … Lui il saura te renseigner !\u00a0\u00bb<\/em><\/li>\n<\/ul>\n<\/li>\n.middleearth.lotr<\/code><\/em>\n\n
bilbo.baggins.hobbiton.middleearth.lotr<\/code> ?\u00a0\u00bb<\/em><\/li>\n.hobbiton.middleearth.lotr<\/code> … Lui il saura te renseigner !\u00a0\u00bb<\/em><\/li>\n<\/ul>\n<\/li>\n.hobbiton.middleearth.lotr<\/code><\/em>\n\n
bilbo.baggins.hobbiton.middleearth.lotr<\/code> ?\u00a0\u00bb<\/em><\/li>\n.baggins.hobbiton.middleearth.lotr<\/code> … Lui il saura te renseigner !\u00a0\u00bb<\/em><\/li>\n<\/ul>\n<\/li>\n.baggins.hobbiton.middleearth.lotr<\/code><\/em>\n\n
bilbo.baggins.hobbiton.middleearth.lotr<\/code><\/em> ?\u00a0\u00bb<\/li>\n
\nL’ensemble des serveurs auquel on a demand\u00e9 notre chemin s’appelle des serveurs faisant autorit\u00e9 (\u00e0 ne pas confondre avec le serveur r\u00e9solveur) <\/strong>parce que ces serveurs ont une base de donn\u00e9es (comme expliqu\u00e9 plus t\u00f4t) qui connaissent la liste de tous les domaines du niveau inf\u00e9rieur qui sont enregistr\u00e9s chez eux.
\nEt ainsi, de proche en proche on sait retrouver l’adresse IP du site.<\/p>\nmap.hobbiton.middleearth.lotr<\/code><\/em> et bien notre r\u00e9solveur sait d\u00e9j\u00e0 qu’il faut demander \u00e0 hobbiton.middleearth.lotr<\/code><\/em> et il a d\u00e9j\u00e0 enregistr\u00e9 l’adresse du serveur faisant autorit\u00e9 sur ce domaine, et va donc lui demander directement sans repasser par racine, TLD, deuxi\u00e8me niveau, troisi\u00e8me niveau…<\/p>\nHTTP<\/h1>\n
\nC’est au tour de HTTP<\/strong> (Hypertext Transfer Protocol<\/em>) d’entrer en jeu.
\nCe protocole permet de d\u00e9finir les r\u00e8gles pour \u00e9changer les documents web (pages, images, texte, etc…). Comme on l’a vu pr\u00e9c\u00e9demment TCP\/IP<\/strong> s’occupe du transport du paquet, par analogie, HTTP<\/strong> \u00e7a serait ce qu’on met dedans par exemple \u00ab\u00a0Donne-moi la page d’accueil<\/em>\u00a0\u00bb ou \u00ab\u00a0Envoie-moi telle image<\/em>\u00a0\u00bb<\/p>\nHTTPS & SSL\/TLS<\/h1>\n
SSL\/TLS<\/h2>\n
Les certificats<\/h2>\n
\nVous vous dites peut-\u00eatre, mais n’importe qui peut dire que \u00ab\u00a0Je suis google.fr faites-moi confiance !\u00a0\u00bb <\/em> Et bien pas vraiment.
\nParce que le navigateur va regarder la signature du certificat, et g\u00e9n\u00e9ralement on ne fait confiance qu’\u00e0 des organismes reconnus comme Let’s Encrypt par exemple.<\/p>\n
\nSi on peut faire \u00e7a, c’est qu’on a les mots de passe pour aller faire \u00e7a et donc qu’on est propri\u00e9taire du serveur.<\/p>\nLe firewall<\/h1>\n
\nMais avant de pouvoir rentrer dans le serveur, les paquets passent souvent par un firewall (ou pare-feu en fran\u00e7ais).<\/p>\n
\nCe qui revient \u00e0 dire que si on utilise HTTP (sans le S) sur le port 80, le pare-feu bloquera l\u2019entr\u00e9e et on restera dehors, porte close !<\/p>\nOn se sert la main ?<\/h1>\n
Une petite analogie :<\/h3>\n
\u00ab\u00a0Salut copain, on se parle avec notre super code secret pour les prochains \u00e9changes ?\u00a0\u00bb<\/em>
Et d\u00e8s que votre ami r\u00e9pond oui, vous commencez \u00e0 chiffrer tous les \u00e9changes suivants.<\/p>\nLe load balancer<\/h1>\n
\nLe load balancer va donc recevoir toutes les connexions entrantes pour les r\u00e9partir entre plusieurs serveurs derri\u00e8re lui. Et pour \u00e7a il peut utiliser diff\u00e9rents algorithmes :<\/p>\n\n
\n
\n
\n
\n
\nLe load balancer<\/strong> agit donc comme un r\u00e9partiteur intelligent<\/strong>, pour que personne ne fasse la queue trop longtemps<\/strong> et que le site reste rapide et disponible<\/strong>, m\u00eame en cas de forte affluence<\/strong>.<\/p>\nLe web server<\/h1>\n
\nC’est le logiciel qui \u00e9coute sur un port HTTP<\/strong> ou HTTPS<\/strong> (80 ou 443 par d\u00e9faut donc) et qui s’occupe de recevoir les requ\u00eates