Prestazioni di MQTT su TLS rispetto a MQTT

Mentre MQTT è abbastanza versatile, non è anche sicuro su se stesso. Questo è di progettazione.

Secondo Stanford-Clark, inizialmente la sicurezza è stata consapevolmente esclusa dal protocollo perché lui e Nipper sapevano che i meccanismi di sicurezza potevano essere avvolti attorno a MQTT per aumentare la sicurezza. Inoltre, all'epoca, Stanford-Clark ha affermato che le informazioni inviate tramite MQTT, come i dati sulla velocità del vento provenienti da una stazione meteorologica, non avevano particolarmente bisogno di essere protette. - Fonte

Uno di quei meccanismi di sicurezza che possono essere integrati in MQTT è TLS. La maggior parte dei broker lo supporta oggi. Naturalmente qualsiasi misura di avvolgimento produce spese generali. Questo sovraccarico potrebbe essere trascurabile (cfr. Blog HiveMQ ).

Attualmente sto cercando informazioni (si spera una fonte autorevole) sulla perdita di prestazioni di MQTT su TLS rispetto al semplice MQTT per valutare la fattibilità di MQTT per il mio progetto. Soprattutto quando la tecnologia si ridimensiona in un gran numero di abbonati.

Esiste un modo oltre alla prototipazione per ottenere dati validi sulle prestazioni di MQTT su TLS?

Non mi aspetto che la differenza sia troppo significativa, una volta stabilita la connessione .

Una ripartizione delle spese generali che TLS produce in generale può essere trovata qui . I bit importanti sono:

• L'overhead totale per stabilire una nuova sessione TLS è in media di circa 6,5k byte
• L'overhead totale per riprendere una sessione TLS esistente è in media di circa 330 byte
• L'overhead totale dei dati crittografati è di circa 40 byte (20 + 15 + 5)
• È facile modificare i calcoli di cui sopra per riflettere più precisamente le specifiche di un ambiente, quindi questo dovrebbe essere considerato una base per il sovraccarico TLS e non la risposta autorevole alla domanda posta.

Vale la pena leggere per vedere come sono stati calcolati questi dati: dovresti capire meglio come TLS funziona con tutto ciò. Come notato in altre risposte, è probabile che la trasmissione radio sia uno dei maggiori utilizzi di energia, che è spesso un vincolo nell'IoT, quindi una volta stabilita la sessione, l'overhead non è troppo significativo, in particolare se i tuoi messaggi sono non banalmente breve.

Come osservato da HiveMQ nell'articolo In che modo TLS influisce sulle prestazioni MQTT? :

La buona notizia è che un client MQTT deve solo stabilire una connessione una volta per sessione, al contrario di protocolli come HTTP, che deve ristabilire una connessione su ogni richiesta (se non viene utilizzato keep-alive o altre tecniche come Long Il polling è attivo). Una volta connesso al broker, il client può inviare e ricevere messaggi senza costi aggiuntivi di handshake. L'uso di TLS deve allocare buffer aggiuntivi, quindi anche il consumo di RAM è leggermente superiore per connessione MQTT.

Forniscono inoltre un grafico dell'utilizzo della CPU sul broker quando si collegano 50.000 client:

^{Fonte immagine: HiveMQ (vedi sopra l'articolo collegato)}

Do atto che questo è quasi certamente non è un modello tipico utilizzo, ma i dati sono comunque interessante. Come puoi vedere, c'è un grande overhead mentre sono in corso le strette di mano, ma dopo questo, l'overhead della CPU è quasi identico. Mi aspetterei una cosa simile sul cliente.

Tuttavia, il consiglio generale qui è corretto: un benchmark inventato non ti fornirà le informazioni di cui hai veramente bisogno; per sapere in che modo TLS influirà sul tuo caso d'uso, devi provarlo in ... il tuo caso d'uso !

Non proprio, dovrai testare e confrontare la tua situazione specifica. È probabile che quanto segue abbia un impatto diretto sulle prestazioni.

• Quale hardware client / broker stai usando, ha qualche accelerazione hardware per crypto?
• Qual è la dimensione del payload che stai inviando?
• Qual è il profilo di connessione / riconnessione per la tua applicazione?

Fare utili stime delle prestazioni è difficile. È probabile che l'applicazione richieda la crittografia per almeno parte del suo traffico, quindi è improbabile che ci siano costi di implementazione per rendere la sicurezza disponibile per questo sottoinsieme del traffico.

Per un'implementazione a basso consumo energetico, è probabile che la trasmissione sia wireless. Anche con un canale radio adatto, è probabile che il costo energetico della configurazione del canale e della negoziazione della connessione superi il costo di elaborazione per la crittografia di un semplice messaggio, in particolare se alcuni messaggi richiedono la crittografia.

Se i messaggi non sono banali, potrebbe esserci qualche giustificazione nell'eseguire più elaborazioni nell'endpoint per ridurre il traffico di rete.

Infine, in uno scenario in cui il canale è pesantemente caricato, le prestazioni potrebbero non essere buone come previsto dall'analisi di un'implementazione più banale dell'intero sistema.

Anche se riesci a trovare un riferimento per i dati che stai cercando, è improbabile che risponda a una domanda sufficiente per basare le decisioni di progettazione.