9.20. Összegzés

Végigjártad a rétegeket, amelyeken egy hálózati üzenet áthalad a kamerától a világ többi része felé vezető útján:

  • A motiváció – a hálózatok azért léteznek, mert a pont-pont kábelezés abban a pillanatban megszűnik skálázódni, amint néhánynál több eszköznek kell beszélnie, vagy a partner nem ugyanazon a vezetéken van, vagy sok program osztozik egyszerre ugyanazon a kapcsolaton. A válasz a megosztott közeg, a logikai címek és az útválasztás.

  • A rétegmodell – öt réteg, mindegyik egy problémát old meg és tiszta interfészt kínál a következőnek. A fizikai és adatkapcsolati rétegek a biteket és kereteket kezelik a közvetlen szomszédok között, a hálózati réteg a címzést és útválasztást kezeli az interneten át, a szállítási réteg a programtól programig történő kézbesítést kezeli, és az alkalmazási protokollok mindezekre épülnek.

  • Az alsó rétegek – az Ethernet és a Wi-Fi mint gyakorlati adatkapcsolati technológiák; a MAC-címek azonosítják a hardvert egy helyi szegmensen. A kamera network modulja egy tudni érdemes vezérlőt tesz elérhetővé: melyik Wi-Fi-hálózathoz csatlakozzon. Ezt követően minden, ami alatta van, automatikus.

  • A hálózati réteg (IP) – az IPv4- és IPv6-címek attól függetlenül azonosítják az állomásokat, hogy melyik kábelbe vannak bedugva. Az útválasztók csomagokat ugratnak a helyi szegmensek között, amíg meg nem érkeznek. A privát címtartományok és a NAT az oka annak, hogy az otthoni és irodai hálózatoknak saját belső címterük és egy megosztott nyilvános címük van a peremen; a kimenő forgalom szabadon működik, a bejövőnek segítségre van szüksége.

  • A szállítási réteg – a portok azonosítják a programokat egy állomáson belül; a teljes (IP, port) pár azonosít egy konkrét socketet. A UDP egy vékony réteg, amely egyszerre egy önálló datagramot küld garanciák nélkül – gyors, olcsó, és a megfelelő eszköz, amikor a veszteség elfogadható. A TCP egy kapcsolatorientált, megbízható, rendezett bájtfolyam – az internetes forgalom nagy részének igáslova, amelyért egy körútidőnyi kézfogás-késleltetéssel fizetünk.

  • A Python API – a socket.socket az egyetlen osztály mindkét protokollhoz. A sendto() / recvfrom() a UDP-hez; a connect-vagy-listen minták plusz a send() / recv() a TCP-hez. A socketek tisztán párosulnak az asyncio modullal: az asyncio.open_connection() és az asyncio.start_server() minden TCP-kapcsolatnak ad egy reader/writer párt, így sok egyidejű beszélgetés osztozhat egyetlen eseményhurkon szálkezelés nélkül.

  • Nevek és idő – a socket.getaddrinfo() egy nevet, mint az example.com, IP-címmé alakít, amely készen áll a socketnek való átadásra. A network.hostname() beállítja a kamera saját nevét, amelyet az útválasztók a helyi DNS-ükben regisztrálnak, és amelyre a kamera beépített mDNS-válaszadója <name>.local formában válaszol. Az ntptime.settime() ugyanaz a „keress meg valamit a hálózaton” ötlet a faliórán mutatott időre alkalmazva, beállítva a fedélzeti órát UTC-re egy nyilvános NTP-szerverről.

  • Titkosítás – az ssl egy socketet TLS-be csomagol. A kamera tanúsítványkiadó-tárolóval nem szállítja, így alapból csak titkosítást kapsz – a beszélgetés már nem nyílt, de a kamera nem ellenőrzi, hogy ki válaszolt. A valódi hitelesítéshez – nyilvános HTTPS-szerverek ellenőrzéséhez, a kamera TLS-szerverként való futtatásához, kölcsönös TLS-hez – a tanúsítványalapú munkafolyamatot a TLS tanúsítványok kezelése oldal ismerteti. A DTLS (TLS UDP felett) ugyanazt a modult ugyanúgy használja.

  • Egy valódi alkalmazási protokoll – az MQTT mint az alatta lévő minden réteg összekötésének kidolgozott példája. Egy 1 bájtos típus-és-jelzők bájt, egy változó hosszúságú hátralévő-hossz mező, egy hosszelőtaggal ellátott UTF-8 topic, és a hasznos adat, mindez TCP-n (és opcionálisan TLS-en belül) utazva egy brókerhez, amely az üzenetet szétosztja a topic minden feliratkozójának. A mellékelt mqtt kliens a vezetékformátumot egy connect / publish / subscribe API-ba csomagolja, amely elég kicsi ahhoz, hogy egy ültő helyében elolvasható legyen.

Ez elég ahhoz, hogy olyan kameraalkalmazásokat írj, amelyek más gépekkel beszélnek, adatokat tesznek közzé távoli szolgáltatásoknak, kapcsolatokat fogadnak el a helyi hálózat klienseitől, és mindezt a kamera többi munkájával párhuzamosan teszik.

9.20.1. Ennek a referenciának a későbbi használata

Kezeld a hálózati fejezeteket referenciaanyagként; az a szándékolt használat, hogy visszatérsz egy UDP-figyelő pontos alakjáért vagy a TLS-asyncio mintáért. A network — hálózati konfiguráció, a socket — socket modul, az ssl — SSL/TLS modul és a ntptime — egyszerű NTP-kliens referenciaoldalak minden metódust, jelzőt és állandót egy helyen felsorolnak, amikor a kérdés csak az, hogy „mi ennek a hívásnak a pontos neve”.

9.20.2. Hová tovább innen

A webszerverek a következő fő téma. Mivel a socketek működnek és a TLS elérhető, a természetes következő réteg felfelé azok a protokollok, amelyek rájuk épülnek: a HTTP a tartalom és API-k kiszolgálásához, a WebSocketek a kapcsolatok kétirányú nyitva tartásához, és a kis keretrendszerek, amelyek elrejtik a sablonkódot. Minden ebből a szakaszból tovább él – egy webszerver, végül is, csak egy TCP-szerver, amely HTTP-t beszél az elfogadott socketjein, gyakran TLS-sel az egész köré csomagolva.