Control do ESP8266 sen redirección de portos: unha ruta MQTT de saída

O dispositivo está detrás dun router doméstico sen redirección de portos e sen enderezo público, e aínda así ten que recibir a configuración en cuestión de segundos. O truco non é un burato na devasa. É unha conexión que o dispositivo abre cara a fóra cara a un broker ao que pode chegar, e que despois devolve as mensaxes por ese mesmo camiño xa establecido. Todas as propiedades que gustan deste deseño, e todas as trampas que contén, veñen desa inversión.

Que atravesa realmente o NAT

Cando o dispositivo abre unha conexión TCP ao broker, o router da casa crea unha asignación e mantena viva mentres dura o fluxo. As respostas dese fluxo volven ao dispositivo porque a asignación xa existe. O broker nunca inicia nada cara á casa, así que non hai ningún paquete entrante non solicitado que o router deba rexeitar. Ese é todo o argumento de rede, e por iso o enfoque funciona en redes que non controlas.

O dispositivo debe manter viva a conexión ou restablecela, o que se converte na cuestión de fiabilidade unha vez fixada a arquitectura.

O broker encamiña temas, non fai de proxy HTTP

MQTT define intercambios de publicación e subscrición: o dispositivo subscríbese a un filtro de temas que ten permiso para ler, e un controlador autorizado publica nun tema coincidente. O broker emparella as publicacións coas subscricións e entrega copias. Non sabe que é unha petición de navegador e non reenviará un HTTP GET ao servidor web do dispositivo. Se o firmware existente só fala HTTP, o deseño con broker necesita un cambio de aplicación ou un compoñente de tradución deliberado.

Os nomes dos temas tampouco son autorización. A maioría dos brokers admiten listas de control de acceso por cliente, e os dispositivos deberían limitarse ás súas propias árbores de publicación e subscrición en lugar de compartir un único espazo de nomes global.

Os recursos do dispositivo deciden a forma de TLS

O ESP8266 ten RAM limitada, e o aperto de mans TLS é o máis caro que fai. O núcleo de Arduino inclúe BearSSL precisamente por esta restrición, e a elección entre verificar unha CA e fixar unha impresión dixital cambia tanto o consumo de memoria como o que pode facer un atacante cun certificado válido para outro nome. Verificar a CA do broker é a opción máis forte cando o heap o permite. O tamaño da carga útil tamén importa: o cliente MQTT mantén un búfer, e as mensaxes máis grandes có truncan en silencio a menos que o búfer se aumente deliberadamente.

O keepalive e os tempos de espera do socket forman parte do mesmo orzamento, porque un cliente que nunca nota unha conexión morta deixa de recibir ordes sen informar dun erro.

A semántica das mensaxes que morde

Unha mensaxe retida gárdaa o broker e entrégase aos subscritores coincidentes posteriores, o cal é excelente para o estado actual e perigoso para ordes dun só uso: un dispositivo que se reconecta pode recibir a orde de onte coma se fose nova. QoS 1 garante a entrega polo menos unha vez, así que os duplicados son normais e a aplicación debe ser segura ante repeticións, idealmente cun identificador ou unha marca de tempo que poida rexeitar. O último testamento dache un sinal de estado cando o dispositivo cae, pero só se a conexión falla de verdade en lugar de quedar colgada.

O comportamento de sesión limpa decide se o broker conserva as túas subscricións mentres estás fóra, e equivocarse niso é a razón pola que algúns dispositivos perden a primeira mensaxe despois de cada reconexión.

TLS protexe o treito ata o broker. Non é cifrado da carga útil de extremo a extremo fronte ao operador do broker, que pode ler todo o que publicas a través del.

Limita o ciclo de vida e proba con datos inocuos

Planifica a reconexión con retroceso en lugar dun bucle de reintentos apertado, volve subscribirte explicitamente se a sesión non é persistente, e rexistra o resultado da conexión para que un dispositivo silencioso fóra de liña deixe probas. Proba o camiño de reconexión con cargas de exemplo que non fagan nada, porque a primeira proba de produción dunha canle de ordes non debería ser unha orde real. Despois confirma que fai unha mensaxe retida obsoleta ao reconectar, e decide se ese comportamento é aceptable para cada tema.

Feito así, o deseño elimina un requisito de rede de entrada e deixa o software do dispositivo, a política do broker e a semántica das mensaxes como traballo visible en lugar de suposicións ocultas.