9.20. Recapitulación

Has recorrido las capas que un mensaje de red atraviesa en su camino desde la cámara hacia el resto del mundo:

  • La motivación – las redes existen porque el cableado punto a punto deja de escalar en cuanto más de un par de dispositivos necesitan comunicarse, o el interlocutor no está en el mismo cable, o muchos programas comparten el mismo enlace a la vez. La respuesta son los medios compartidos, las direcciones lógicas y el enrutamiento.

  • El modelo en capas – cinco capas, cada una resolviendo un problema y ofreciendo una interfaz limpia a la siguiente. Las capas física y de enlace manejan bits y tramas entre vecinos inmediatos, la capa de red maneja el direccionamiento y el enrutamiento a través de internet, la capa de transporte maneja la entrega de programa a programa, y los protocolos de aplicación se construyen sobre todo eso.

  • Las capas inferiores – Ethernet y Wi-Fi como tecnologías de enlace prácticas; las direcciones MAC identifican el hardware en un segmento local. El módulo network de la cámara expone una sola perilla que vale la pena conocer: a qué red Wi-Fi unirse. Después de eso, todo lo de abajo es automático.

  • La capa de red (IP) – las direcciones IPv4 e IPv6 identifican hosts independientemente de a qué cable estén conectados. Los routers saltan los paquetes entre segmentos locales hasta que llegan. Los rangos de direcciones privadas y NAT son la razón por la que las redes domésticas y de oficina tienen su propio espacio de direcciones interno y una única dirección pública compartida en el borde; el tráfico saliente funciona libremente, el entrante necesita ayuda.

  • La capa de transporte – los puertos identifican programas dentro de un host; el par completo (IP, port) identifica un socket concreto. UDP es una capa fina que envía un datagrama autocontenido cada vez sin garantías – rápido, barato y la herramienta correcta cuando la pérdida es aceptable. TCP es un flujo de bytes orientado a conexión, fiable y ordenado – el caballo de batalla de la mayor parte del tráfico de internet, pagado con un viaje de ida y vuelta de latencia de apretón de manos.

  • La API de Python – socket.socket es la única clase para ambos protocolos. sendto() / recvfrom() para UDP; los patrones de conectar o escuchar más send() / recv() para TCP. Los sockets se combinan limpiamente con asyncio: asyncio.open_connection() y asyncio.start_server() dan a cada conexión TCP un par lector/escritor, de modo que muchas conversaciones concurrentes comparten un único bucle de eventos sin hilos.

  • Nombres y tiempo – socket.getaddrinfo() convierte un nombre como example.com en una dirección IP lista para entregar a un socket. network.hostname() establece el propio nombre de la cámara, que los routers registran en su DNS local y al que el respondedor mDNS integrado de la cámara contesta como <name>.local. ntptime.settime() es la misma idea de «buscar algo en la red» aplicada a la hora del reloj de pared, ajustando el reloj de a bordo a UTC desde un servidor NTP público.

  • Cifrado – ssl envuelve un socket en TLS. La cámara viene sin almacén de autoridades de certificación, así que de fábrica obtienes solo cifrado – la conversación ya no está en claro, pero la cámara no está verificando quién respondió. Para una autenticación real – verificar servidores HTTPS públicos, ejecutar la cámara como servidor TLS, TLS mutuo – el flujo de trabajo basado en certificados se trata en Trabajar con certificados TLS. DTLS (TLS sobre UDP) usa el mismo módulo de la misma manera.

  • Un protocolo de aplicación real – MQTT como ejemplo resuelto de todas las capas inferiores conectadas entre sí. Un byte de tipo y banderas de 1 byte, un campo de longitud restante de longitud variable, un tema UTF-8 con prefijo de longitud y la carga útil, todo viajando sobre TCP (y opcionalmente dentro de TLS) hacia un broker que reparte el mensaje a cada suscriptor del tema. El cliente mqtt incluido envuelve el formato de cable en una API connect / publish / subscribe lo bastante pequeña como para leerla de una sentada.

Eso es suficiente para escribir aplicaciones de cámara que se comuniquen con otras máquinas, publiquen datos en servicios remotos, acepten conexiones de clientes en la red local y hagan todo ello de forma concurrente con el resto del trabajo de la cámara.

9.20.1. Usar esta referencia más adelante

Trata los capítulos de redes como material de referencia; volver para consultar la forma exacta de un receptor UDP o el patrón de TLS con asyncio es el uso previsto. Las páginas de referencia network — configuración de red, socket — módulo socket, ssl — Módulo SSL/TLS y ntptime — cliente NTP simple enumeran cada método, bandera y constante en un solo lugar cuando la pregunta es simplemente «cuál es el nombre exacto de esta llamada».

9.20.2. Hacia dónde ir desde aquí

Los servidores web son el siguiente gran tema. Con los sockets funcionando y TLS disponible, la siguiente capa natural hacia arriba son los protocolos que se construyen sobre ellos: HTTP para servir contenido y APIs, WebSockets para mantener conexiones abiertas en ambos sentidos, y los pequeños frameworks que ocultan el código repetitivo. Todo lo de esta sección se traslada hacia adelante – un servidor web es, al fin y al cabo, solo un servidor TCP que habla HTTP en sus sockets aceptados, a menudo con TLS envolviéndolo todo.