Dotaz: Jak přenést data přes internet

[Pavel]

Ahoj, mám postavený logovací zařízení na platformě arduina a potřebuji přenášet několik měřených hodnot na server do MySQL databáze. Doteď jsem to řešil přes HTML POST, ale připadá mi tam zbytečně velká režie. Data se odesílají periodicky po 30 vteřinách, občas po 10 a vždy se navazuje nové spojení. Vůbec ale nevím jak jinak to řešit. Poslat nějaký stream dat na server? V jakém formátu? Musím dělat i kompletní aplikaci na linux a spustit jako démona? Není již něco hotovo abych nad tím nestrávil hromadu času?

---

---

Odpovědi

[Andrej]

Není již něco hotovo abych nad tím nestrávil hromadu času?

Vzdálený přístup do databáze.

Samozřejmě je pak naprosto nezbytné nastavit tam šifrování (TLS), je-li to „přes internet“.

Klient se dá spustit a udržovat v běhu třeba přes systemd, aby měl stálé spojení a nenavazoval ho pokaždé znova. Může poslouchat někde na unixovém socketu SQL příkazy a případné chyby někam logovat.

(Navíc bych vřele doporučoval použití skutečné databáze (příklad: PostgreSQL), nikoliv béčkové hračky MySQL, ale to už je malinko mimo téma.)

[Pavel]

Arduino je svým způsobem taky hračka :) Zpřístupit DB zvenku i když přes TLS je asi to poslední co bych chtěl mít, ale díky za tip.

[Heron]

Takového vzdáleného přístupu není nejmenší důvod se bát. Právě proto ho databáze (skutečné databáze, ne hračky, podotýkám) podporují a dobře umí, aby se používal.

V pg_hba.conf se nastaví povinná autentifikace (hostssl … scram-sha-256) a vzdálený přístup se (dejme tomu) povolí jenom takovému uživateli, který do příslušných tabulek smí jenom přidávat (INSERT) a nic jiného. V postgresql.conf pak stačí nastavit ssl = on, ssl_ca_file = '...', ssl_cert_file = '...', ssl_crl_file = '...', ssl_key_file = '...' a je to. Ještě se to dá v pg_hba.conf omezit podle IP adresy klienta, když na to přijde, i když to samozřejmě nenahrazuje ostatní autentifikační mechanismy.

Tohle^^^ má podle mě dostatek slupek bezpečnostní cibule. I kdyby někdo třeba ukradl soukromý klíč klienta + ukradl heslo k databázi (a to by musel už fakt hodně krást!), pořád by tam mohl data jenom přidávat, tj. nemohl by poškodit data, která tam už jsou.

Tolik tedy asi k tomu, jak přenést data přes internet a vyhnout se HTTPS POST. (Samozřejmě předpokládám, že tam to S je, jinak je to fakt výsměch, co do bezpečnosti.)

Pokud na bezpečnosti aspoň trochu záleží (a není to celé 100% jenom domácí hračka, tj. LAN místo internetu atd.), vzdálený přístup do databáze může být nakonec jednodušší řešení s lepší autentifikací než HTTPS. Autentifikace certifikátem se u většiny HTTPS command-line klientů dělá poměrně špatně, zatímco pro databázové klienty je samozřejmostí.

[Jendа]

Autor píše, že HTTP POST má moc velkou režii. Jak velkou režii má SQL protokol? Když budu chtít insertnout, řekněme, 3 čísla do tabulky, kolik mě to bude stát?

[Andrej]

Když budu chtít insertnout, řekněme, 3 čísla do tabulky, kolik mě to bude stát?

Řádově nulu. Na to se opravdu ptáš?

Tazatel neuvádí, kde je velká režie (a jak je velká režie definovaná). Předpokládám proto, že velká režie je na klientovi v souvislosti s opakovaným navazováním spojení.

Vyhodnocování SQL probíhá na serveru. Proto je krajně nepodstatné, kolik stojí SQL. Je snad INSERT 3 čísel těžký problém z hlediska vyhodnocení dotazu? Kdyby náhodou každé z těch čísel bylo výsledkem třeba 100 řádků SQL, co kdyby si správce celé vkládání připravil jako proceduru v PL/PgSQL? Vyřešeno. Nebudou náhodou mnohem dražší žurnálovací operace DBMS a jeho přístupy k úložišti nežli parsování toho dotazu? Asi jo, co?

Nemluvě o tom, že při použití HTTP bude k parsování SQL docházet taky, pokud bude HTTP frontend v nějakém dynamickém jazyce (místo ECPG s uloženými dotazy).

HTTPS POST má velkou režii, protože se:

• naváže nové TCP spojení,
• naváže nové TLS spojení a dohodnou se nové symetrické klíče (ufufuf, tady je asi tak celá režie),
• pošle malý HTTP dotaz s těmi třemi čísly,
• vyhodnotí odpověď,
• zavře spojení.

Běžící PostgreSQL klient

• pošle SQL dotaz s těmi třemi čísly,
• vyhodnotí odpověď.

To je všechno. Spojení je navázané (TCP i TLS), poslat v plaintextu 3 čísla je stejně "náročné" v HTTP i v SQL a ve finále se spojení nebude zavírat.
(Samozřejmě se nastaví keepalive, aby systemd klienta po výpadku sítě / serveru obnovil, ale to už jsou technikálie (podle vzoru fekálie).)

Další možnost je HTTP pipelining, jenže: Command-line klienti, kdo z vás to má? (Nastavení pak bude přinejmenším stejně náročné jako nastavení databázového klienta. Na straně serveru to ovšem bude složitější.)

[Jendа]

Tazatel neuvádí, kde je velká režie (a jak je velká režie definovaná). Předpokládám proto, že velká režie je na klientovi v souvislosti s opakovaným navazováním spojení.

A já zase automaticky předpokládal, že tím myslí přenesená data.

[Max]

Ad: https, proto tu máme http2 .
Ta komunikace s SQL, co jsi popsal, vypadá jednoduše, ale reál je poněkud horší (= jeden sql dotaz vygeneruje víc spojení, než ten http post). SQL na takové věci není úplně ok.
Souhlasím, že řešením je MQTT nebo http post, který nějak dál optimalizovat (třeba využitím http2 protokolu).
Zdar Max

[ehmmm]

Nerozumim vete "jeden sql dotaz vygeneruje víc spojení". Co ja mam zkusenost, tak SQL klient otevre (TCP) spojeni a tim pak posila dotazy podle potreby a nakonec to spojeni zavre.

[Max]

Pardon, requestů.
Zdar Max

[Kit]

Doporučil bych zůstat u HTTP POST, například pomocí nástroje curl. Ti zdatnější mohou použít švýcarský nožík netcat, u kterého je režie vskutku zanedbatelná.

[Pavel]

Netcat zní zajímavě. Předpokládám, že dokáže běžet na pozadí, odchytit komunikaci a dále zpracovat v nějakém scriptu. Šlo by i navázat spojení natrvalo? Aby i když klient posílá data po minutě, mohl server kdykoliv poslat data klientovi?

[z_sk]

Websocket si nepocul?

[Pavel]

Teď na to koukám, nevypadá to špatně...

[Kit]

Netcat jsem už sice použil jako server, ale dost věcí nemá ošetřených a umí běžet jen v jednom vláknu. Uváděl jsem ho jako dietního klienta. Na serveru bych použil buď Nginx, který je v základu velmi dietní (takových webserverů je hromada), anebo si napsal vlastní v Pythonu nebo Go. Go je na tyto záležitosti přímo určeno, je to jen na několik řádek. Osobně používám v intranetu PHP jako server, ale vystavit ven si ho netroufám.

[z_sk]

Osobně používám v intranetu PHP jako server

Myslis toto?

[Kit]

Ano, přesně to. Výhodou je, že si mohu dělat instantní servery, jak se mi zlíbí a kolik se mi zlíbí. Na vývoj je to skvělé.

[z_sk]

server - zozstan pri webovom servery (bezpecnost) - pripadne pozri menej rezijne servery na hardwer

client - simple apka s libcurl a POST, len posiel cez jeden curl_descriptor stale. Ale osetri, ze treba nanovo navadzat spojenie, ak spojenie skonci (kedze ma server limit na dlzku aktivneho jedneho spojenie). - spustis a ides, nic viac nemusis v systeme nastavovat.

vymena dat - cez JSON (napr. v PHP je jedna na to funkcia na konverzie medzi objekt/pole vs JSON_RAW), pokial je to jedno na strane klienta (alebo iny format, ak chces usetrit kazdy takt z baterky snimaca).

[Bugsa]

Ještě tu nikdo nezmínil MQTT. To je přímo dělané na časté posílání hodnot sensorů. Na straně serveru je pak potřeba MQTT broker, např. Mosquitto. Hojně se využívá na ESP8266 ve spojení s firmware Tasmota.

[OldFrog {Ondra Nemecek}]

Nic jednoduššího než přímý přístup do vzdálené mysql databáze asi nenajdeš. Takže se na tom arduinu ve vhodném programovacím jazyce připojit k mysql a ta data tam posílat, třeba dávkově.

[OldFrog {Ondra Nemecek}]

Pokud by se někdo chtěl vydat cestou přímého připojení do Mysql, tady je tu konektor MySQL_Connector_Arduino.

Osobně bych se s webservicema (ani na koleně vymyšleným vlastním UDP protokolem) nepatlal. Použil bych buď přímé připojení do mysql anebo univerzálnější MQTT/UDP.

[Jendа]

Nejmenší možnou režii bude mít syrový protokol nad UDP. Poslat měření jako UDP paket, a server pošle potvrzení. Pokud potvrzení do X sekund nepřijde, poslat měření znovu.

V Pythonu je to na pár řádků, hledej něco jako „python udp socket example“.

Jinak u toho HTTP se dá držet keep-alive, abys nedělal pokaždé nové spojení. Jak na to se dozvíš v dokumentaci ke knihovně, kterou používáš; pro Python je knihovna requests.

Lidé tu doporučují vzdálený přístup do databáze, ale tam bych se bál, že ten protokol bude velmi komplexní, a spolu s tím bude režie velká.

[OldFrog {Ondra Nemecek}]

UDP bude mít určitě menší režii, ale jde jen o:

...několik měřených hodnot na server do MySQL databáze ... po 30 vteřinách, občas po 10...

To by podle mě arduino mohlo zvládnout levou zadní. Místo vlastního UDP protokolu bych zvážil MQTT/UDP, jelikož to jde přes UDP ale ten protokol je opět hotový a připravený k použití.

Při srovnávní webserver + json api versus mysql klient bych použil radši mysql klienta, protože je tam tam opět ten protokol už hotový a připravený k použití, režie přitom bude podle mě nebude větší než u webserveru.

[Jendа]

To by podle mě arduino mohlo zvládnout levou zadní.

Já do teď nepochopil, jestli je klientem přímo to Arduino (pak by asi MySQL klient přes TLS moc realizovat nešel), nebo je Arduino připojené k linuxovému počítači.

To by podle mě arduino mohlo zvládnout levou zadní.

Já to pochopil tak, že se tazatel snaží minimalizovat přenosy po síti, ne že má nedostatek výkonu.

Při srovnávní webserver + json api versus mysql klient bych použil radši mysql klienta, protože je tam tam opět ten protokol už hotový a připravený k použití, režie přitom bude podle mě nebude větší než u webserveru.

Zase pokud těch klientů bude mít víc, tak bude opruz dělat jim v mysql uživatele a nastavovat správně oprávnění k té tabulce, aby nemohli vkládat data „za cizího“ a tak. Ve vlastním webovém handleru si autentizaci a tak vyřeší snadno jak potřebuje (a třeba klienty bude mít v další tabulce).

[Pavel]

Ano, jedná se o klienta stavěného na arduinu. Je to na jiném HW než mají komerčně prodávané, takže výkonu je dost, ale TLS zabezpečení se mi moc implementovat nechce. Data nejsou tak moc důvěrná a bylo by to tak jen kvůli té databázi. Jde opravdu o minimalizaci datového toku a případně realtime bi-komunikaci server - klient. Je možné, že klientů bude postupně více, ale víc jak 5 jich zase nebude. I Když byla by škoda při zvednutí nad 5 předělávat celý komunikační protokol.

[Bherzet]

Doteď jsem to řešil přes HTML POST, ale připadá mi tam zbytečně velká režie.

Co znamená „připadá“? Nějakých 100 bajtů nezbytných hlaviček u HTTP (nikoliv HTML) POST je problém? Nebo navázání spojení je problém? Nebo v čem je problém?

Pokud nelze použít TCP spojení (ani ho recyklovat, aby se nemuselo navazovat pořád znovu), tak potom jedině to UDP, jak zmiňoval Jenda, ale nemá to korekci chyb, takže záleží, jak moc bude vadit, když ta data buď vůbec nedorazí, nebo dorazí poškozená.

[Jendа]

1) UDP má samozřejmě taky checksum, 2) Píšu že to server má potvrzovat.

[Kit]

Další možností je při chybě data jednoduše zahodit. Klientovi se tím dost ulehčí.

[Bherzet]

Checksumem ale detekuješ jen poškození, nejde to opravit. Šlo by to řešit na úrovni protokolu buď samoopravnými kódy nebo potvrzením (přehlédl jsem, že se o tom zmiňuješ, sorry), ale to už mi přijde lepší použít rovnou to TCP. UDP bych použil tam, kde je důležitá rychlost a na ztraceném paketu až tak moc nesejde (což může být případ třeba v online hře, kde hráč pravidelně hlásí svou absolutní pozici a když vypadne jedna zpráva, opraví se to hned s tou další).

[j]

UDP ti predevsim nijak nezarucuje poradi, ve kterym ti ty data dorazej, ani uplnost tech dat. Takze kdyz posles 10 paketu s 10 sadama cisel, tak ti muze dorazit paketu 8 a to v naprosto libovolnym poradi, takze jeste navic musis resit, ktery cisla byly platny kdy, coz na tcp treba resit nemusis, protoze ti zarucene dorazej ve stejnym poradi a navic vsechny.

Implementovat pak potvrzovani na UDP je naprosta chujovina. Protoze pak prozmenu musis resit nejen to potvrzeni samotny, ale i to, ze ti zdroj posila data opakovane, proste proto, ze mu to potvrzeni z nejakyho duvodu nedorazi.

Dtto poskozeni paketu ... vpodstatne bys musel reimplementovat to co dela tcp. Proto je to totalni kravinium. UDP se proste pouziva tam, kde ti na ztracenych datech nezalezi.

****

A jinak se podobny kravoviny delaji tak, ze se data ladujou do neceho vykonejsiho lokalne (nejake GW), klidne k tomu muzou byt takhle naparovany i tisice cidel, a teprve ta krabka, ktera ma vykonu dost, resi komunikaci po netu.

Vzdycky me pak pobavi, kdyz nekdo pinda na tema, ze to neni nic tajnyho a sifrovat to nepotrebuje. To si treba takhle posila teplotu, podle ktery se zapina kotel, je pak docela sranda mu poslat pekne -30 uprostred leta.

---

Dete s tim guuglem dopice!

[ehmmm]

TCP ti rozhodne nezarucuje, ze data dorazi vsechny. Tak mocne neni. :) Skoro naopak, zotaveni TCP spojeni po vypadku je nekdy tak zdlouhave, ze pro nekoho muze byt vyhodnejsi valit UDP pakety tam a zpatky a udelat si to potvrzovani a opakovani po svem.

[AraxoN]

Ľudia, Vy ste sa všetci zbláznili! Na Arduine implementovať MySQL klienta cez TLS? Nadväzovať komplikovaný Websocket?

Typické Arduino má 2048 bajtov RAM! Obvykle je človek rád, že sa mu tam okrem vlastných dát zmestí ešte buffer na ten jeden sieťový packet, ktorý chce odoslať! Na nejaké vyššie sieťové funkcie a kryptografiu môže zabudnúť.

Pavel, HTTP POST je ten správny nástroj. Jeho réžia je minimálna. Jeho implementácia na oboch stranách triviálna. Neviem, čo riešiš.

[Peter Golis]

No tak zmigruje z Arduina na niečo kompatibilné, napríklad na Raspberry PI. A ako bonus mu vyjde že TCO bude lacnejšie. HW bude síce trošku drahší, ale vývoj SW bude rapidne rýchlejší.

Až na spotrebu, ak by to chcel živiť z baterky bez dotiahnutého napájania.

[netix]

Uplne by postacilo ESP32 a vie aj nejake to crypto :) Mame tak vela senzorov (aktualne 150+) cez MQTT s ESP32 a ziaden problem.

[Jendа]

Vždyť tu píše, že to není Arduino na těch malých AVR… A na tom ESP32 může mít taky Arduino a HTTPS to samozřejmě taky umí (podobně jako na jiných dostatečně výkonných platformách). Ale PostgreSQL klienta bych tam teda fakt implementovat nechtěl :).

[qwer]

Ľudia, Vy ste sa všetci zbláznili! Na Arduine implementovať MySQL klienta cez TLS? Nadväzovať komplikovaný Websocket?

Protoze je potreba chranit data assets! (Samozrejmne, ze je naprosta blobost aby se koncove zarizeni pripojovalo do DB a to i v jinych pripadech.)

Na tyhle ulohu bylo vymyslene MQTT pokud jej nelze pouzit tak HTTP POST.

[Filip Jirsák]

To, že má HTTP POST velkou režii, je jenom váš způsob implementace. HTTP klidně může vypadat tak, že navážete jedno HTTPS spojení, a přes něj pak posíláte jeden POST za druhým. Fungují takhle všechny prohlížeče.