Fiche de révision : Introduction aux protocoles et architectures réseau

📋 Plan du Cours

1. Rappels des couches supérieures OSI
2. Définitions client-serveur et architectures
3. DNS Domain Name System et BIND
4. Outils d’interrogation DNS et annuaires
5. DNS sur HTTPS DoH et sécurité
6. Standards du web URL HTTP HTML CGI
7. HTML CSS et JavaScript côté client
8. Ajax et communication asynchrone XHR
9. TLS et HTTPS objectifs de sécurité
10. Handshake TLS et validation certificats
11. FTP session et alternatives SFTP FTPS
12. NFS Network File System et démons

📖 1. Rappels des couches supérieures OSI

🔑 Notions clés & Définitions

• Couche session : Couche session : couche OSI qui organise des échanges sous forme de sessions entre utilisateurs et gère le dialogue et la reprise après incident.
• Jeton de parole : Jeton de parole : mécanisme de la couche session qui limite les opérations critiques au processus qui détient le jeton.
• Couche présentation : Couche présentation : couche OSI qui transforme l’information pour assurer une syntaxe et une sémantique compatibles entre systèmes.
• Encodage et décodage : Encodage et décodage : transformation des données selon des normes reconnues pour permettre leur interprétation correcte à l’arrivée.
• Couche application : Couche application : point d’accès aux services réseau pour les applications proches de l’utilisateur, via normes, protocoles, bibliothèques et API.

📝 Points essentiels

• La couche session sert à établir des sessions entre utilisateurs sur des postes différents et à gérer le dialogue.
• La couche session peut utiliser un jeton de parole pour garantir qu’un seul processus réalise une opération critique à la fois.
• La couche session peut synchroniser les échanges via des points de reprise pour reprendre après une interruption.
• La couche présentation traite la syntaxe et la sémantique de l’information transmise entre systèmes.
• La couche présentation réalise l’encodage/décodage selon des normes comme Unicode, MIME, HTML, ou ASN.1/BER.
• Dans Internet (TCP/IP), on regroupe sous « couche Application » les couches session, présentation et application d’OSI.

💡 Astuce mémo

Session = « dialogue + reprise » ; Présentation = « sens + format » ; Application = « accès aux services ».

📖 2. Définitions client-serveur et architectures

🔑 Notions clés & Définitions

• DNS : Le DNS est un système distribué qui traduit des noms de domaine en informations exploitables par les applications.
• FQDN : Un FQDN est un nom de domaine complet qui se termine par un point, indiquant la racine des domaines.
• Enregistrement de ressources : Un enregistrement de ressources DNS décrit une information associée à un nom de domaine via plusieurs champs structurés.
• Resolver DNS : Un resolver DNS est le composant qui reçoit une requête de nom et cherche la réponse en cache ou via des serveurs DNS.
• BIND 9 : BIND 9 est un logiciel client-serveur DNS utilisé pour fournir un service de résolution de noms via un démon serveur.

📝 Points essentiels

• Un enregistrement de ressources DNS contient cinq champs : nom de domaine, durée de vie, classe, type et valeur.
• Le nom de domaine d’un enregistrement est un FQDN qui se termine par « . » (symbole de la racine).
• La durée de vie est exprimée en secondes et la classe vaut notamment IN pour Internet.
• Les types d’enregistrements incluent A (IPv4), AAAA (IPv6), MX (messagerie), SOA (autorité de zone), NS (serveurs de noms), CNAME (alias), PTR, HINFO et TXT.
• La résolution DNS passe par des zones organisées en arbre, avec serveurs primaire et secondaires pour chaque zone.
• Le resolver local renvoie la réponse depuis son cache si possible, sinon il interroge le serveur primaire et peut utiliser des requêtes itératives ou récursives jusqu’à obtenir l’enregistrement officiel.

💡 Astuce mémo

FQDN = « point final = racine » ; Resolver = « cache d’abord, puis serveurs ».

📖 3. DNS Domain Name System et BIND

🔑 Notions clés & Définitions

• DNS : Système de noms qui traduit un nom de domaine en adresse IP afin de permettre l’accès aux ressources sur Internet.
• BIND : Logiciel serveur DNS largement utilisé pour héberger et répondre aux requêtes de résolution de noms de domaine.
• Résolution DNS : Étape où un client interroge le DNS pour obtenir l’adresse IP correspondant à un nom de domaine demandé.
• Enregistrement de ressource DNS : Entrée DNS qui associe un nom à des informations, comme une adresse IP via un type d’enregistrement.

📝 Points essentiels

• Le navigateur détermine l’URL demandée puis interroge le résolveur DNS pour obtenir l’adresse IP du domaine.
• Le DNS répond avec un enregistrement de ressource, par exemple un enregistrement de type A reliant un nom à une adresse IPv4.
• Après la réponse DNS, le navigateur établit une connexion TCP vers le port 80 de l’hôte correspondant pour envoyer la requête HTTP.
• La résolution DNS est nécessaire avant toute connexion réseau vers un serveur web identifié par un nom (ex. www.w3.org).
• Le type d’enregistrement A est illustré dans le format « nom IN A adresse_IP » (ex. www.w3.org IN A 128.30.52.37).
• BIND est un serveur DNS : il reçoit des requêtes de résolution et renvoie les enregistrements de ressource associés aux noms demandés.

💡 Astuce mémo

DNS = « Nom → IP » : sans IP, pas de TCP/HTTP.

📖 4. Outils d’interrogation DNS et annuaires

🔑 Notions clés & Définitions

• SGML : SGML est une norme ISO de description de documents, dont XML s’inspire pour structurer des données via des balises.
• HTML : HTML est un langage de balisage qui décrit la structure et la présentation d’une page web, avec une interactivité surtout via des hyperliens.
• CSS : CSS, feuilles de style en cascade, est un langage dédié à la mise en forme et à la présentation du contenu d’une page web.
• JavaScript : JavaScript est un langage de script exécuté côté client, basé sur la programmation événementielle et l’interaction avec la page.
• Document Object Model : Le Document Object Model (DOM) décrit la structure et le contenu d’une page web pour permettre à un script de la modifier.

📝 Points essentiels

• HTML décrit la présentation et la structure d’une page, qui reste statique hors actions déclenchées par des hyperliens.
• HTML a évolué jusqu’à une version 4.0 qui dure depuis 1999, et une variante basée sur XML existe avec XHTML 1.0.
• HTML5 est normalisé en octobre 2014 et apporte des nouveautés majeures par rapport aux versions précédentes.
• CSS3 est en cours de spécification, donc son évolution dépend des versions et des fonctionnalités adoptées.
• JavaScript est intégré dans le code d’une page HTML et s’exécute sur le client à différents moments du cycle de vie de la page ou après des actions utilisateur.
• JavaScript peut valider les données de formulaires et modifier le document via le DOM en réponse à des événements.

💡 Astuce mémo

SGML→XML (structure), HTML→page (statique), CSS→style, JS→actions (événements) via DOM.

📖 5. DNS sur HTTPS DoH et sécurité

🔑 Notions clés & Définitions

• DNS sur HTTPS : Technologie qui transporte les requêtes DNS via le protocole HTTPS pour joindre la résolution de noms à un canal chiffré.
• DoH : Abréviation de DNS sur HTTPS, désignant l’usage de requêtes DNS encapsulées dans HTTPS.
• Chiffrement HTTPS : Mécanisme de protection des échanges applicatifs via HTTPS, qui réduit la visibilité du contenu transmis sur le réseau.
• Confidentialité DNS : Propriété visant à limiter l’accès tiers aux informations liées aux requêtes DNS, notamment les noms consultés.

📝 Points essentiels

• Le transport DNS via HTTPS vise à réduire la capacité d’observation du réseau sur les requêtes DNS en les encapsulant dans un flux HTTPS.
• DoH s’appuie sur HTTPS, donc la résolution de noms suit le même canal que le trafic web chiffré.
• La confidentialité DNS dépend du chiffrement du canal et de la façon dont le client et le résolveur DoH établissent la connexion.
• Le passage par un résolveur DoH implique que le traitement des requêtes DNS est délégué à l’infrastructure du service DoH.
• Sans détails supplémentaires dans le cours, la section ne couvre pas les mécanismes précis d’authentification, de validation cryptographique ou de contrôle d’intégrité côté DNS.

💡 Astuce mémo

DoH = DNS + HTTPS : même tunnel chiffré que le web, donc requêtes DNS moins visibles.

📖 6. Standards du web URL HTTP HTML CGI

🔑 Notions clés & Définitions

• HTTP : Protocole de transport du web qui permet l’échange de requêtes/réponses entre client et serveur.
• URL : Chaîne de caractères qui identifie de façon unique une ressource accessible sur le web.
• HTML : Langage de balisage utilisé pour structurer et présenter le contenu des pages web.
• CGI : Mécanisme côté serveur qui exécute un programme pour produire une réponse à partir d’une requête web.
• SOAP : Architecture de services web basée sur l’échange de messages structurés, souvent en XML, pour appeler des traitements distants.

📝 Points essentiels

• SOAP est un protocole de type RPC orienté objet qui structure les messages échangés entre applications via internet.
• SOAP transmet des messages en XML entre objets distants, et utilise souvent HTTP pour le transport.
• Avantage de SOAP : il s’appuie fréquemment sur XML et HTTP, ce qui facilite le passage via pare-feux/proxys avec POST.
• Inconvénients de SOAP : messages verbeux (XML) et couplage plus fort entre serveur et clients.
• REST utilise des verbes HTTP (GET, POST, PUT, DELETE) pour lire, créer, modifier et supprimer des ressources.
• REST repose sur un couplage lâche et une communication asynchrone, et se limite au transfert de données entre applications.

💡 Astuce mémo

SOAP = XML + POST (verbeux) ; REST = verbes HTTP (CRUD).

📖 7. HTML CSS et JavaScript côté client

🔑 Notions clés & Définitions

• FTP : Protocole de transfert de fichiers qui permet à un client d’échanger des fichiers avec un serveur via des commandes et des connexions dédiées.
• Connexion FTP : Échange de contrôle et de signalisation entre client et serveur qui encadre chaque transfert de fichiers.
• Mode actif FTP : Mode FTP où le serveur ouvre la connexion de données depuis son port 20 vers un port indiqué par le client.
• Mode passif FTP : Mode FTP où le client initie la connexion de données sur un port choisi par le serveur et communiqué au préalable.
• Session FTP : Enchaînement d’étapes d’un échange FTP, avec identification puis commandes jusqu’à la fin de session.

📝 Points essentiels

• En FTP, le client ouvre une connexion de contrôle pour échanger commandes et informations de signalisation.
• En mode actif, le serveur utilise le port de données 20 et se connecte au port spécifié par le client.
• En mode passif, le serveur détermine un port de données et le communique au client avant que celui-ci initie la connexion.
• La session FTP commence par une procédure d’identification du client auprès du serveur.
• La session se termine soit par une commande du client (quit ou bye), soit par un timeout côté serveur.
• Pendant une session, des commandes comme help, pwd, lpwd, cd, lcd, ls, get, put, delete sont utilisables.

💡 Astuce mémo

Actif = serveur parle au client (port 20 → port client) ; Passif = client parle au serveur (port annoncé par le serveur).

📖 8. Ajax et communication asynchrone XHR

🔑 Notions clés & Définitions

• QUIC : Protocole de transport conçu pour établir des connexions rapides et réduire la latence, notamment via le multiplexage sur UDP.
• HTTP/3 : Version d’HTTP conçue pour fonctionner au-dessus de QUIC, afin d’améliorer les performances et la gestion des connexions.
• MPTCP : MultiPath TCP, protocole qui agrège plusieurs flux TCP pour obtenir un débit global proche de la somme des débits.
• Socket : Interface de communication bas niveau permettant à une application d’envoyer et de recevoir des données via un protocole de transport comme TCP ou UDP.
• XHR : Requête HTTP déclenchée par JavaScript pour récupérer des données sans bloquer l’interface, typiquement utilisée en communication asynchrone côté navigateur.

📝 Points essentiels

• QUIC utilise UDP et permet des connexions multiplexées entre deux points de terminaison pour réduire la latence.
• Lors de la première connexion, le client envoie une requête initiale contenant les informations nécessaires, puis le serveur répond avec des éléments comme des certificats et un identifiant associé au client.
• L’établissement initial de QUIC implique 1 RTT, puis les connexions suivantes peuvent atteindre 0 RTT si le serveur n’a pas changé de cycle de vie.
• QUIC prévoit une estimation de bande passante dans chaque direction pour limiter la congestion.
• HTTP/3 est documenté dans le RFC 9114 et vise l’usage de QUIC pour le transport HTTP.
• MPTCP vise un débit global quasi égal à la somme des débits des flux TCP grâce au multiplexage inverse des chemins/flux disponibles.

💡 Astuce mémo

QUIC = 1 RTT puis 0 RTT (premier handshake, ensuite réutilisation) ; MPTCP = plusieurs TCP additionnés (débit ≈ somme).

📖 9. TLS et HTTPS objectifs de sécurité

🔑 Notions clés & Définitions

• TLS : Protocole de sécurité qui chiffre les échanges réseau et assure l’authentification des parties via des certificats.
• HTTPS : Version sécurisée d’HTTP qui utilise TLS pour protéger le trafic entre le navigateur et le serveur.
• Chiffrement : Mécanisme qui transforme les données en texte illisible pour empêcher leur lecture par des tiers.
• Authentification par certificat : Vérification de l’identité du serveur (et parfois du client) à partir d’un certificat numérique signé.

📝 Points essentiels

• TLS protège la confidentialité en chiffrant les données échangées entre client et serveur.
• TLS protège l’intégrité en détectant les altérations du contenu pendant le transport.
• TLS permet l’authentification du serveur grâce à un certificat présenté lors de l’établissement de la connexion.
• HTTPS encapsule HTTP dans TLS pour que les requêtes et réponses soient transportées de façon sécurisée.
• TLS et HTTPS réduisent les risques d’interception et de modification du trafic, notamment sur des réseaux non fiables.
• TLS s’appuie sur un échange de paramètres de session pour établir une protection chiffrée avant l’envoi des données applicatives.

💡 Astuce mémo

TLS = Confidentialité + Intégrité + Identité (certificat) ; HTTPS = HTTP + TLS.

📖 10. Handshake TLS et validation certificats

🔑 Notions clés & Définitions

• Handshake TLS : Mécanisme d’établissement sécurisé d’une session TLS entre client et serveur, qui négocie les paramètres cryptographiques avant l’échange des données.
• Certificat X.509 : Document signé liant une identité (nom ou domaine) à une clé publique, utilisé pour prouver l’identité du serveur lors de la connexion TLS.
• Chaîne de certification : Ensemble de certificats reliés (serveur puis intermédiaires jusqu’à une autorité racine) permettant de remonter la confiance jusqu’à une racine approuvée.
• Autorité de certification : Entité qui signe des certificats pour attester qu’une clé publique correspond bien à une identité donnée.

📝 Points essentiels

• Le handshake TLS sert à négocier les paramètres de chiffrement et à démarrer une session chiffrée entre client et serveur.
• La validation du certificat vérifie que le certificat présenté est bien signé et rattaché à une autorité de confiance via une chaîne de certification.
• La confiance dépend des certificats racines (ou magasins de confiance) présents côté client, qui déterminent quelles autorités sont acceptées.
• La validation doit aussi contrôler la cohérence entre l’identité demandée (domaine) et l’identité contenue dans le certificat.
• Un certificat expiré ou non valide doit être rejeté, car il ne garantit plus l’authenticité attendue.
• Si la chaîne de certification est incomplète ou ne remonte pas à une racine de confiance, la connexion doit être refusée.

💡 Astuce mémo

TLS = confiance via Certificat : identité (X.509) + signature (chaîne) + racine de confiance.

📖 11. FTP session et alternatives SFTP FTPS

🔑 Notions clés & Définitions

• FTP : Protocole de transfert de fichiers basé sur une session client-serveur, où les commandes et données sont échangées via le réseau.
• SFTP : Alternative à FTP qui transporte les transferts de fichiers de façon sécurisée en s’appuyant sur SSH pour le chiffrement et l’authentification.
• FTPS : Variante de FTP qui ajoute une couche de sécurité via TLS/SSL pour chiffrer les échanges pendant la session FTP.
• Session FTP : Enchaînement d’étapes entre client et serveur pour négocier la connexion, puis transférer les commandes et les données.

📝 Points essentiels

• FTP utilise une logique de session client-serveur pour piloter le transfert de fichiers.
• FTP peut exposer les échanges (commandes et/ou données) si aucune protection cryptographique n’est ajoutée.
• SFTP sécurise le transfert en utilisant SSH, ce qui apporte chiffrement et contrôle d’accès pendant la session.
• FTPS sécurise la session FTP en utilisant TLS/SSL, ce qui chiffre les communications entre client et serveur.
• Choisir SFTP ou FTPS revient à remplacer la partie non chiffrée de FTP par une protection cryptographique adaptée à l’environnement.
• Les alternatives sécurisées visent à réduire les risques d’interception et d’usurpation pendant le transfert de fichiers.

💡 Astuce mémo

FTP = “Fichiers en clair” ; SFTP = “SSH pour chiffrer” ; FTPS = “TLS/SSL pour sécuriser FTP”.

📖 12. NFS Network File System et démons

🔑 Notions clés & Définitions

• RPC : RPC est un mécanisme d’appel de procédure à distance où un programme client invoque une fonction sur un serveur comme si elle était locale.
• Remote Procedure Call : Remote Procedure Call désigne l’appel de procédure distante, c’est-à-dire l’exécution d’une procédure sur un autre hôte via un protocole réseau.
• Liaison statique : La liaison statique fixe à la compilation l’adresse du serveur de noms ou de la procédure distante, sans consultation dynamique.
• Liaison au premier appel : La liaison au premier appel consulte le service de noms une seule fois au démarrage de la première invocation, puis réutilise la localisation.
• Liaison à chaque appel : La liaison à chaque appel interroge le service de noms à chaque invocation pour retrouver la localisation de la procédure distante.

📝 Points essentiels

• Un RPC doit emballer les paramètres et les résultats pour les transmettre à l’appelant, puis les déballer côté réception.
• La localisation d’une procédure distante se fait via un service de gestion de noms (serveur d’annuaire).
• En RPC, client et serveur utilisent des espaces d’adressage différents, donc un pointeur ne peut pas être transmis tel quel.
• Pour remplacer un passage par pointeur, on utilise une copie/restauration des données plutôt que le partage direct d’adresses.
• La sérialisation (marshalling) impose soit un standard comme ASN.1, soit une représentation externe commune comme XDR, soit des conversions côté client ou serveur.
• Le mode synchrone côté client attend la réponse, tandis que le mode asynchrone permet de ne pas bloquer sur l’exécution distante.

💡 Astuce mémo

RPC = Réseau + Copie (pas de pointeurs) + Noms (annuaire).

📅 Repères chronologiques

📊 Tableaux de synthèse

Comparaison HTTP/2 vs HTTP/3 (axes et mécanismes)

⚠️ Pièges & confusions fréquents

1. Confondre couche session et couche présentation : la session gère le dialogue et la reprise (jeton/points de reprise), la présentation traite syntaxe/sémantique et encodage/décodage.
2. Croire que le DNS “fait” la connexion web : en réalité il traduit Nom → IP, puis le navigateur établit la connexion TCP (port 80) et envoie HTTP.
3. Mélanger FQDN et nom de domaine “simple” : le FQDN est écrit avec le point final représentant la racine.
4. Inverser les rôles en FTP actif/passif : en actif c’est le serveur qui initie vers le port de données (port 20 → port client), en passif c’est le client qui initie vers le port annoncé par le serveur.
5. Penser que DoH chiffre tout “comme TLS” sans délégation : le cours précise que le passage par un résolveur DoH délègue le traitement DNS à l’infrastructure du service.
6. Confondre SOAP et REST : SOAP est RPC orienté objet avec messages XML (souvent via HTTP POST), REST utilise les verbes HTTP pour CRUD et repose sur couplage lâche/asynchrone.
7. Croire que TLS remplace HTTP : TLS est une couche de sécurité (entre Transport et Application) et HTTPS est une variante de HTTP qui implémente TLS.

✅ Checklist Examen

1. Rappeler ce que fait la couche session OSI : sessions, gestion du dialogue, jeton de parole et points de reprise.
2. Expliquer le rôle de la couche présentation OSI : syntaxe/sémantique et encodage/décodage selon une norme (ex. Unicode, MIME, HTML, ASN.1/BER).
3. Définir la couche application OSI et préciser le regroupement TCP/IP : session+présentation+application d’OSI sous “Application”.
4. Décrire le modèle client-serveur : client envoie des requêtes, serveur attend et répond, et citer les architectures (2 niveaux, 3 niveaux, P2P).
5. Définir DNS et son objectif : traduire un nom de domaine en adresse IP (ou autres informations) via une base de données répartie et un protocole applicatif (UDP/53).
6. Définir FQDN et expliquer le point final (racine), puis donner la structure d’un enregistrement de ressources (nom, durée de vie, classe, type, valeur).
7. Savoir interpréter les types d’enregistrements cités : A, AAAA, MX, SOA, NS, CNAME, PTR, HINFO, TXT, et relier A à une IPv4.
8. Expliquer le chemin de résolution DNS : resolver local (cache), zones en arbre, serveurs primaire/secondaire, et requêtes itératives/récursives jusqu’à l’enregistrement officiel.
9. Citer BIND 9 et le démon named, puis associer les outils : dig (dnsutils), host, nslookup, whois/RDAP.
10. Expliquer HTTP dans le web : navigateur détermine l’URL, interroge DNS, se connecte en TCP (port 80), envoie GET, puis interprète le document et refait des requêtes pour les ressources incluses.
11. Savoir distinguer URL et URI : URL = identifiant de ressource (adresse web) et URI inclut URL et URN (espace de noms).
12. Connaître les commandes HTTP vues : GET, HEAD, POST, PUT, DELETE et leur intention (lecture, info, création/soumission, mise à jour, suppression).
13. Donner les repères d’évolution HTTP/2 et HTTP/3 : HTTP/2 (RFC 7540, mai 2015) et axes (headers compressés, multiplexage, push), puis HTTP/3 (RFC 9114, juin 2022) et transport QUIC.
14. Expliquer HTML/CSS/JavaScript côté client : HTML structure statique (liens), CSS mise en forme, JavaScript exécuté côté client via événements et DOM, et Ajax/XHR (XHR, asynchronisme, DOM).