9.20. Conclusão

Percorreu as camadas que uma mensagem de rede atravessa no seu caminho da câmara para o resto do mundo:

  • A motivação – as redes existem porque a ligação ponto a ponto deixa de escalar no momento em que mais do que alguns dispositivos precisam de comunicar, ou quando o interlocutor não está no mesmo cabo, ou quando vários programas partilham o mesmo elo ao mesmo tempo. A resposta são meios partilhados, endereços lógicos e encaminhamento.

  • O modelo em camadas – cinco camadas, cada uma a resolver um problema e a oferecer uma interface limpa para a seguinte. As camadas física e de ligação tratam de bits e fotogramas entre vizinhos imediatos, a camada de rede trata do endereçamento e encaminhamento pela internet, a camada de transporte trata da entrega programa a programa, e os protocolos de aplicação constroem sobre tudo isso.

  • As camadas inferiores – Ethernet e Wi-Fi como tecnologias de ligação práticas; os endereços MAC identificam o hardware num segmento local. O módulo network da câmara expõe um parâmetro que vale a pena conhecer: a que rede Wi-Fi aderir. Depois disso, tudo o que está abaixo é automático.

  • A camada de rede (IP) – os endereços IPv4 e IPv6 identificam anfitriões independentemente do cabo a que estão ligados. Os routers saltam pacotes entre segmentos locais até chegarem. Os intervalos de endereços privados e o NAT são a razão pela qual as redes domésticas e de escritório têm o seu próprio espaço de endereços interno e um único endereço público partilhado na extremidade; 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 anfitrião; o par completo (IP, port) identifica um socket específico. O UDP é uma camada fina que envia um datagrama auto-contido de cada vez sem garantias – rápido, barato e a ferramenta certa quando a perda é aceitável. O TCP é um fluxo de bytes ordenado, fiável e orientado à ligação – o motor para a maior parte do tráfego de internet, pago com uma latência de handshake de uma ida-e-volta.

  • A API Python – socket.socket é a única classe para ambos os protocolos. sendto() / recvfrom() para UDP; os padrões connect-or-listen mais send() / recv() para TCP. Os sockets combinam bem com asyncio: asyncio.open_connection() e asyncio.start_server() dão a cada ligação TCP um par leitor/escritor, de modo a que muitas conversas concorrentes partilhem um único ciclo de eventos sem necessidade de threads.

  • Nomes e tempo – socket.getaddrinfo() converte um nome como example.com num endereço IP pronto para ser entregue a um socket. network.hostname() define o próprio nome da câmara, que os routers registam sob o seu DNS local e ao qual o responder mDNS integrado da câmara responde como <name>.local. ntptime.settime() aplica a mesma ideia de «pesquisar algo na rede» à hora do relógio de parede, definindo o relógio integrado para UTC a partir de um servidor NTP público.

  • Encriptação – ssl envolve um socket em TLS. A câmara não inclui nenhum repositório de autoridades de certificação, pelo que de raiz obtém apenas encriptação – a conversa já não está em claro, mas a câmara não está a verificar quem respondeu. Para autenticação real – verificar servidores HTTPS públicos, executar a câmara como servidor TLS, TLS mútuo – o fluxo de trabalho baseado em certificados está descrito em Trabalhar com certificados TLS. O DTLS (TLS sobre UDP) utiliza o mesmo módulo da mesma forma.

  • Um protocolo de aplicação real – o MQTT como exemplo prático de todas as camadas abaixo ligadas entre si. Um byte de tipo e flags de 1 byte, um campo de comprimento restante de comprimento variável, um tópico UTF-8 prefixado por comprimento, e o payload, tudo a viajar sobre TCP (e opcionalmente dentro de TLS) para um broker que distribui a mensagem a todos os subscritores do tópico. O cliente mqtt incluído envolve o formato de rede numa API connect / publish / subscribe pequena o suficiente para ler numa só sessão.

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

9.20.1. Utilizar esta referência mais tarde

Trate os capítulos de rede como material de referência; voltar para a forma exacta de um ouvinte UDP ou o padrão TLS-com-asyncio é o uso previsto. 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 num único lugar quando a questão é apenas «qual é o nome exacto desta chamada».

9.20.2. Por onde continuar

Servidores Web é o próximo tema principal. Com sockets a funcionar e TLS disponível, a camada natural acima são os protocolos que constroem sobre eles: HTTP para servir conteúdo e APIs, WebSockets para manter ligações abertas em ambas as direcções, e os pequenos frameworks que ocultam o código repetitivo. Tudo desta secção avança – um servidor web é, afinal, apenas um servidor TCP que fala HTTP nos seus sockets aceites, muitas vezes com TLS a envolver tudo.