9.20. Récapitulatif

Vous avez parcouru les couches qu’un message réseau traverse sur son chemin depuis la caméra vers le reste du monde :

  • La motivation – les réseaux existent parce que le câblage point à point cesse de passer à l’échelle dès que plus de quelques appareils ont besoin de dialoguer, ou que le correspondant n’est pas sur le même câble, ou que de nombreux programmes partagent le même lien à la fois. La réponse, ce sont les supports partagés, les adresses logiques et le routage.

  • Le modèle en couches – cinq couches, chacune résolvant un problème et offrant une interface propre à la suivante. Les couches physique et liaison gèrent les bits et les trames entre voisins immédiats, la couche réseau gère l’adressage et le routage à travers Internet, la couche transport gère la livraison de programme à programme, et les protocoles applicatifs s’appuient sur tout cela.

  • Les couches inférieures – Ethernet et Wi-Fi comme technologies de liaison pratiques ; les adresses MAC identifient le matériel sur un segment local. Le module network de la caméra expose un réglage qui mérite d’être connu : à quel réseau Wi-Fi se joindre. Après cela, tout ce qui est en dessous est automatique.

  • La couche réseau (IP) – les adresses IPv4 et IPv6 identifient les hôtes indépendamment du câble auquel ils sont branchés. Les routeurs font sauter les paquets entre les segments locaux jusqu’à ce qu’ils arrivent. Les plages d’adresses privées et le NAT sont la raison pour laquelle les réseaux domestiques et de bureau possèdent leur propre espace d’adressage interne et une seule adresse publique partagée en bordure ; le trafic sortant fonctionne librement, le trafic entrant a besoin d’aide.

  • La couche transport – les ports identifient les programmes à l’intérieur d’un hôte ; la paire complète (IP, port) identifie un socket précis. UDP est une fine couche qui envoie un datagramme autonome à la fois sans aucune garantie – rapide, économique, et l’outil adapté lorsque la perte est acceptable. TCP est un flux d’octets orienté connexion, fiable et ordonné – le cheval de trait de la majeure partie du trafic Internet, payé d’un aller-retour de latence de poignée de main.

  • L’API Python – socket.socket est la classe unique pour les deux protocoles. sendto() / recvfrom() pour UDP ; les schémas connect-ou-listen plus send() / recv() pour TCP. Les sockets se marient proprement avec asyncio : asyncio.open_connection() et asyncio.start_server() donnent à chaque connexion TCP une paire reader/writer, de sorte que de nombreuses conversations concurrentes partagent une seule boucle d’événements sans threads.

  • Noms et temps – socket.getaddrinfo() transforme un nom comme example.com en une adresse IP prête à être passée à un socket. network.hostname() définit le nom propre de la caméra, que les routeurs enregistrent dans leur DNS local et auquel le répondeur mDNS intégré de la caméra répond sous la forme <name>.local. ntptime.settime() est la même idée de « rechercher quelque chose sur le réseau » appliquée à l’heure murale, réglant l’horloge embarquée à l’heure UTC depuis un serveur NTP public.

  • Chiffrement – ssl enveloppe un socket dans TLS. La caméra est livrée sans magasin d’autorités de certification, donc d’emblée vous obtenez uniquement le chiffrement – la conversation n’est plus en clair, mais la caméra ne vérifie pas qui a répondu. Pour une véritable authentification – vérifier des serveurs HTTPS publics, faire fonctionner la caméra comme serveur TLS, le TLS mutuel – le flux de travail basé sur les certificats est traité dans Travailler avec les certificats TLS. DTLS (TLS sur UDP) utilise le même module de la même manière.

  • Un véritable protocole applicatif – MQTT comme exemple concret de toutes les couches inférieures assemblées. Un octet de type et d’indicateurs d’un octet, un champ de longueur restante de taille variable, un sujet UTF-8 préfixé par sa longueur, et la charge utile, le tout circulant sur TCP (et éventuellement à l’intérieur de TLS) vers un courtier qui distribue le message à tous les abonnés du sujet. Le client mqtt fourni enveloppe le format filaire dans une API connect / publish / subscribe assez petite pour être lue d’une traite.

C’est suffisant pour écrire des applications de caméra qui dialoguent avec d’autres machines, publient des données vers des services distants, acceptent des connexions de clients sur le réseau local, et font tout cela de façon concurrente avec le reste du travail de la caméra.

9.20.1. Utiliser cette référence plus tard

Traitez les chapitres sur les réseaux comme du matériel de référence ; y revenir pour la forme exacte d’un récepteur UDP ou du schéma TLS-avec-asyncio est l’usage prévu. Les pages de référence network — configuration réseau, socket — module socket, ssl — Module SSL/TLS et ntptime — client NTP simple listent en un seul endroit chaque méthode, indicateur et constante lorsque la question est simplement « quel est le nom exact de cet appel ».

9.20.2. Où aller à partir d’ici

Les serveurs web sont le prochain grand sujet. Avec les sockets opérationnels et TLS disponible, la couche supérieure naturelle suivante regroupe les protocoles qui s’appuient sur eux : HTTP pour servir du contenu et des API, WebSockets pour garder les connexions ouvertes dans les deux sens, et les petits frameworks qui masquent le code répétitif. Tout ce qui vient de cette section est réutilisé – un serveur web n’est, après tout, qu’un serveur TCP qui parle HTTP sur ses sockets acceptés, souvent avec TLS enveloppant le tout.