9.20. Conclusão

Você percorreu as camadas que uma mensagem de rede atravessa em seu caminho da câmera até o resto do mundo:

  • A motivação – as redes existem porque o cabeamento ponto a ponto deixa de escalar no momento em que mais do que alguns poucos dispositivos precisam se comunicar, ou em que o interlocutor não está no mesmo fio, ou em que muitos programas compartilham o mesmo enlace ao mesmo tempo. A resposta são meios compartilhados, endereços lógicos e roteamento.

  • O modelo em camadas – cinco camadas, cada uma resolvendo um problema e oferecendo uma interface limpa para a seguinte. As camadas física e de enlace lidam com bits e quadros entre vizinhos imediatos, a camada de rede lida com endereçamento e roteamento por toda a internet, a camada de transporte lida com a entrega de programa para programa, e os protocolos de aplicação se constroem sobre tudo isso.

  • As camadas inferiores – Ethernet e Wi-Fi como tecnologias de enlace práticas; endereços MAC identificam o hardware em um segmento local. O módulo network da câmera expõe um ajuste que vale a pena conhecer: a qual rede Wi-Fi se conectar. Depois disso, tudo abaixo é automático.

  • A camada de rede (IP) – endereços IPv4 e IPv6 identificam hosts independentemente do cabo em que estão conectados. Os roteadores saltam os pacotes entre segmentos locais até que cheguem. Faixas de endereços privados e NAT são a razão pela qual redes domésticas e de escritório têm seu próprio espaço de endereços interno e um único endereço público compartilhado na borda; o tráfego de saída funciona livremente, o de entrada precisa de ajuda.

  • A camada de transporte – as portas identificam programas dentro de um host; o par completo (IP, port) identifica um socket específico. O UDP é uma camada fina que envia um datagrama autocontido por vez sem garantias – rápido, barato e a ferramenta certa quando a perda é aceitável. O TCP é um fluxo de bytes orientado a conexão, confiável e ordenado – o burro de carga da maior parte do tráfego da internet, pago com uma ida e volta de latência de handshake.

  • A API Python – socket.socket é a única classe para ambos os protocolos. sendto() / recvfrom() para UDP; os padrões de connect-ou-listen mais send() / recv() para TCP. Os sockets combinam de forma limpa com o asyncio: asyncio.open_connection() e asyncio.start_server() dão a cada conexão TCP um par leitor/escritor, de modo que muitas conversas concorrentes compartilham um único event loop sem threading.

  • Nomes e tempo – socket.getaddrinfo() transforma um nome como example.com em um endereço IP pronto para ser entregue a um socket. network.hostname() define o próprio nome da câmera, que os roteadores registram em seu DNS local e pelo qual o respondedor mDNS embutido da câmera responde como <name>.local. ntptime.settime() é a mesma ideia de “procurar uma coisa na rede” aplicada à hora do relógio de parede, ajustando o relógio embutido para UTC a partir de um servidor NTP público.

  • Criptografia – ssl envolve um socket em TLS. A câmera vem sem um repositório de autoridades certificadoras, então, de fábrica, você obtém apenas criptografia – a conversa não está mais em texto aberto, mas a câmera não está verificando quem respondeu. Para autenticação real – verificar servidores HTTPS públicos, rodar a câmera como um servidor TLS, TLS mútuo – o fluxo de trabalho baseado em certificados é abordado em Trabalhando com certificados TLS. O DTLS (TLS sobre UDP) usa o mesmo módulo da mesma forma.

  • Um protocolo de aplicação real – o MQTT como exemplo trabalhado de todas as camadas abaixo dele ligadas entre si. Um byte de tipo e flags de 1 byte, um campo de comprimento restante de tamanho variável, um tópico UTF-8 com prefixo de comprimento e o payload, tudo trafegando sobre TCP (e opcionalmente dentro de TLS) até um broker que distribui a mensagem para cada assinante do tópico. O cliente mqtt incluído envolve o formato de fio em uma API connect / publish / subscribe pequena o suficiente para ler de uma só vez.

Isso é o bastante para escrever aplicações de câmera que se comunicam com outras máquinas, publicam dados em serviços remotos, aceitam conexões de clientes na rede local e fazem tudo isso de forma concorrente com o resto do trabalho da câmera.

9.20.1. Usando esta referência mais tarde

Trate os capítulos de rede como material de referência; voltar para conferir o formato exato de um ouvinte UDP ou o padrão de TLS-com-asyncio é o uso pretendido. As páginas de referência network — configuração de rede, socket — módulo socket, ssl — Módulo SSL/TLS e ntptime — cliente NTP simples listam cada método, flag e constante em um só lugar quando a pergunta é apenas “qual é o nome exato desta chamada”.

9.20.2. Para onde ir a partir daqui

Servidores web é o próximo grande tópico. Com os sockets funcionando e o TLS disponível, a próxima camada natural acima são os protocolos que se constroem sobre eles: HTTP para servir conteúdo e APIs, WebSockets para manter conexões abertas nos dois sentidos, e os pequenos frameworks que escondem o código repetitivo. Tudo desta seção é levado adiante – afinal, um servidor web é apenas um servidor TCP que fala HTTP em seus sockets aceitos, frequentemente com TLS envolvendo o todo.