9.20. Riepilogo

Hai attraversato i livelli che un messaggio di rete percorre nel suo tragitto dalla camera al resto del mondo:

  • La motivazione – le reti esistono perché il cablaggio punto-punto smette di scalare nel momento in cui più di un paio di dispositivi hanno bisogno di comunicare, oppure la controparte non è sullo stesso filo, oppure molti programmi condividono lo stesso collegamento contemporaneamente. La risposta è costituita da media condivisi, indirizzi logici e routing.

  • Il modello a livelli – cinque livelli, ognuno dei quali risolve un problema e offre un’interfaccia pulita a quello successivo. I livelli fisico e di collegamento gestiscono bit e frame tra vicini immediati, il livello di rete gestisce l’indirizzamento e il routing attraverso internet, il livello di trasporto gestisce la consegna da programma a programma, e i protocolli applicativi si basano su tutto ciò.

  • I livelli inferiori – Ethernet e Wi-Fi come tecnologie di collegamento pratiche; gli indirizzi MAC identificano l’hardware su un segmento locale. Il modulo network della camera espone una manopola che vale la pena conoscere: a quale rete Wi-Fi collegarsi. Dopodiché, tutto ciò che sta al di sotto è automatico.

  • Il livello di rete (IP) – gli indirizzi IPv4 e IPv6 identificano gli host indipendentemente dal cavo a cui sono collegati. I router fanno saltare i pacchetti tra segmenti locali finché non arrivano. Gli intervalli di indirizzi privati e il NAT sono la ragione per cui le reti domestiche e aziendali hanno il proprio spazio di indirizzamento interno e un unico indirizzo pubblico condiviso all’estremità; il traffico in uscita funziona liberamente, quello in entrata ha bisogno di aiuto.

  • Il livello di trasporto – le porte identificano i programmi all’interno di un host; la coppia completa (IP, port) identifica un socket specifico. UDP è un sottile strato che invia un datagramma autonomo alla volta senza garanzie – veloce, economico e lo strumento giusto quando la perdita è accettabile. TCP è un flusso di byte orientato alla connessione, affidabile e ordinato – il cavallo da lavoro per la maggior parte del traffico internet, pagato con un round-trip di latenza di handshake.

  • L’API Python – socket.socket è l’unica classe per entrambi i protocolli. sendto() / recvfrom() per UDP; i pattern connect-o-listen più send() / recv() per TCP. I socket si abbinano in modo pulito con asyncio: asyncio.open_connection() e asyncio.start_server() forniscono a ogni connessione TCP una coppia reader/writer, così molte conversazioni concorrenti condividono un unico event loop senza threading.

  • Nomi e tempo – socket.getaddrinfo() trasforma un nome come example.com in un indirizzo IP pronto da passare a un socket. network.hostname() imposta il nome proprio della cam, che i router registrano sotto il loro DNS locale e a cui il responder mDNS integrato della cam risponde come <name>.local. ntptime.settime() è la stessa idea di «cercare una cosa sulla rete» applicata all’orario di parete, impostando l’orologio di bordo su UTC a partire da un server NTP pubblico.

  • Cifratura – ssl avvolge un socket in TLS. La cam viene fornita senza un archivio di autorità di certificazione, quindi di base si ottiene solo la cifratura – la conversazione non è più in chiaro, ma la cam non sta verificando chi ha risposto. Per un’autenticazione reale – verifica dei server HTTPS pubblici, esecuzione della cam come server TLS, TLS mutuo – il flusso di lavoro basato sui certificati è trattato in Lavorare con i certificati TLS. DTLS (TLS su UDP) usa lo stesso modulo nello stesso modo.

  • Un vero protocollo applicativo – MQTT come esempio pratico di ogni livello sottostante messo insieme. Un byte di tipo-e-flag di 1 byte, un campo remaining-length a lunghezza variabile, un topic UTF-8 con prefisso di lunghezza e il payload, il tutto viaggiando su TCP (e opzionalmente all’interno di TLS) verso un broker che diffonde il messaggio a ogni subscriber del topic. Il client mqtt incluso avvolge il formato sul filo in un’API connect / publish / subscribe abbastanza piccola da leggere in una sola seduta.

Questo è sufficiente per scrivere applicazioni per la camera che comunicano con altre macchine, pubblicano dati su servizi remoti, accettano connessioni da client sulla rete locale e fanno tutto questo in modo concorrente con il resto del lavoro della camera.

9.20.1. Usare questo riferimento in seguito

Tratta i capitoli sul networking come materiale di riferimento; tornarci per la forma esatta di un listener UDP o del pattern TLS-con-asyncio è l’uso previsto. Le pagine di riferimento network — configurazione di rete, socket — modulo socket, ssl — modulo SSL/TLS e ntptime — semplice client NTP elencano ogni metodo, flag e costante in un unico posto quando la domanda è semplicemente «qual è il nome esatto di questa chiamata».

9.20.2. Dove andare da qui

I server web sono il prossimo argomento principale. Con i socket funzionanti e TLS disponibile, il naturale livello successivo è costituito dai protocolli che vi si basano: HTTP per servire contenuti e API, WebSocket per mantenere le connessioni aperte in entrambe le direzioni, e i piccoli framework che nascondono il boilerplate. Tutto ciò che proviene da questa sezione si trascina avanti – un server web è, dopotutto, semplicemente un server TCP che parla HTTP sui suoi socket accettati, spesso con TLS che avvolge il tutto.