Internet data verbruik van één apparaat monitoren

[DataGhost]

laurens0619 schreef op donderdag 16 februari 2023 @ 11:10:
mijn wireshark skills zijn wat roestig maar als ik naar dat plaatje kijk dan gaat er dus 49.9 op aan MQTT, waar gaat de ander 50% dan naartoe? unknown protocols?

Ik zou denken 609kb/uur. Dat is het optellen van de TX en RX

De packets zijn gemiddeld 71 bytes, dat is best klein. Daar gaat al best veel aan headers op (MAC x2, IP x2, poort x2 heb je al 24 bytes te pakken). Aangezien het TCP is en 5592 bijna de helft is van 11210 gok ik dat de resterende packets voornamelijk ACKs zijn.

[ Voor 39% gewijzigd door DataGhost op 16-02-2023 11:15 ]

[laurens0619]

@Scott81
MQTT is ook TCP maar waarschijnlijk wordt de response niet herkend als MQTT
Dat zal idd die missende 50% verklaren.

Maar dan denk ik dat het klopt

[Scott81]

Als mijn berekening klopt verbruikt het dus 372mb per maand als ik elke seconde publish.
Ik zet het nu eens op eens per minuut (wat ook al veel meer is dan het uiteindelijke realistische gebruik), maar dan valt het achteraf gezien misschien redelijk mee

[dion_b]

Scott81 schreef op donderdag 16 februari 2023 @ 11:14:
Misschien zeg ik wat doms, maar elke seconde publish ik een bericht via mqtt (via de ESP32) en in wireshark komen (elke seconde dus) deze 2 regels.

Eentje is MQTT en eentje is TCP. Misschien is dit het?[Afbeelding]

Hou de OSI-lagen in de gaten. MQTT werkt op layer 7 (applicatie), dus gebruikt het daaronder ook een layer 4 (transport) protocol, specifieker, het gebruikt hier TCP. Dat MQTT bericht zit dus in een TCP segment, en eigenschap van TCP is dat elk bericht bevestigd moet worden met een ACK.

Dit is dus een TCP conversation, specifiek de kleinst mogelijke succesvolle. Je payload (MQTT bericht) is aangekomen en dat bevestigt de ontvanger.

Edit: spuit 11

[laurens0619]

Size of Ethernet frame - 24 Bytes
Size of IPv4 Header (without any options) - 20 bytes
Size of TCP Header (without any options) - 20 Bytes

Total size of an Ethernet Frame carrying an IP Packet with an empty TCP Segment - 24 + 20 + 20 = 64 bytes

In een maand zitten 2,628,288 seconds dus dan kom je op 168210432 Bytes. Dat is 168Mb.
Maar je hebt 2 paketten nodig per transactie, heen en terug.

De wens van iedere seconde communiceren kost je dus al minimaal 336Mb, en dan heb je nog helemaal niets "gezegd". Druk je daar de MQTT headers en wat content bij dan is 372Mb dus inderdaad geen gek getal.

Hopelijk geen rekenfoutjes gemaakt, ik twijfel vooral of die *2 berekening die ik doe klopt. @dion_b enig idee?

[ Voor 10% gewijzigd door laurens0619 op 16-02-2023 13:11 ]

[dion_b]

laurens0619 schreef op donderdag 16 februari 2023 @ 13:08:
[...]

In een maand zitten 2,628,288 seconds dus dan kom je op 168210432 Bytes. Dat is 168Mb.
Maar je hebt 2 paketten nodig per transactie, heen en terug.

De wens van iedere seconde communiceren kost je dus al minimaal 336Mb, en dan heb je nog helemaal niets "gezegd". Druk je daar de MQTT headers en wat content bij dan is 372Mb dus inderdaad geen gek getal.

Hopelijk geen rekenfoutjes gemaakt, ik twijfel vooral of die *2 berekening die ik doe klopt. @dion_b enig idee?

Allereerst is 168210432 Bytes 168MB, niet Mb. het zou ongeveer 1344Mb zijn.

Maar goed, ik zie twee pakketten van 89B en 54B, dus toaal 143B per conversation.

Bij eentje per uur kost dat 3.4kB/dag
Bij eentje per minuut is het 201kB/dag
Bij eentje per seconde is het 12MB/dag

Edit: factor 1024 ernaast

Maar...

Dit is theorie, geextrapoleerd op basis van een enkele conversatie.

Ik zou aanraden om niet te rekenen, maar te meten. Zet gewoon een Wireshark capture aan met capture filter om alleen verkeer van/naar IP of MAC van het Thing. Laat het een etmaal lopen en kijk wat het met huidige instellingen doet. Meet totaal dat je opgevangen hebt (staat gewoon onderaan de capture). Herhaal evt met andere instellingen.

[laurens0619]

dion_b schreef op donderdag 16 februari 2023 @ 13:22:
[...]

Allereerst is 168210432 Bytes 168MB, niet Mb. het zou ongeveer 1344Mb zijn.

Maar goed, ik zie twee pakketten van 89B en 54B, dus toaal 143B per conversation.

Bij eentje per uur kost dat 3.4MB/dag
Bij eentje per minuut is het 201MB/dag
Bij eentje per seconde is het 12GB/dag

Maar...

Dit is theorie, geextrapoleerd op basis van een enkele conversatie.

Ik zou aanraden om niet te rekenen, maar te meten. Zet gewoon een Wireshark capture aan met capture filter om alleen verkeer van/naar IP of MAC van het Thing. Laat het een etmaal lopen en kijk wat het met huidige instellingen doet. Meet totaal dat je opgevangen hebt (staat gewoon onderaan de capture). Herhaal evt met andere instellingen.

Je hebt gelijk, ik had de waarde van de online calculater niet goed overgenomen.

Maar puur theoreitsch gezien: Wat gaat het je aan data kosten door iedere seconde een TCP pakket heen en weer te sturen, is dat 168MB of 168MB*2 (of iets anders?)

Verder ben ik het eens met meten maar het kan wel helpen als je deze baseline weet.

[Scott81]

Hoe komen we nu aan dee getallen?

Bij eentje per uur kost dat 3.4MB/dag
Bij eentje per minuut is het 201MB/dag
Bij eentje per seconde is het 12GB/dag

Mijn resultaten zijn toch de "metingen"?
Daar kom ik uit op 370MB (megabytes) per maand voor elke seconden een publish. Hoe komen we nu aan 12GB per dag?

[laurens0619]

143B per conversation.

1/sec:
1dag == 86400seconde
143B * 86400 =12355200 Byte
= 12MB/dag == 360MB/maand
Dus ik gok dat dion daar een rekenfoutje maakte in de conversie (MB ipv GB)

Met daarbij de voetnooit dat ieder sec communiceren je sowieso al 336MB kost door de overhead van TCP.
Wil je lager uitkomen dan gaat rommelen aan de payload niet zoveel oplossen, afwijken van TCP zou ik ook niet zo snel doen. Dan blijft de frequentie verlagen dus over

[ Voor 42% gewijzigd door laurens0619 op 16-02-2023 13:42 ]

[Scott81]

Okay duidelijk.
Het iedere seconde communiceren is puur voor de test, uiteindelijk gaan er waarschijnlijk maar enkele tientallen communicaties per dag plaatsvinden maar zo kan ik in elk geval een "worst case scenario" monitoren.

Alhoewel ik de MQTT verbinding wel moet openhouden en meet dus meer dan bijvoorbeeld 10x 143 bytes

[dion_b]

Meten is weten. Altijd realistischer en nauwkeuriger dan welke extrapolatie ook.

[ Voor 7% gewijzigd door dion_b op 16-02-2023 18:18 ]

[W1ck1e]

dion_b schreef op donderdag 16 februari 2023 @ 17:14:
Meten is weten. Altijd realistischer en nauwkeuriger dan welke meting ook.

?
(Lees even hardop wat je schrijft)

[ Voor 8% gewijzigd door W1ck1e op 16-02-2023 18:07 ]

[dion_b]

W1ck1e schreef op donderdag 16 februari 2023 @ 17:19:
[...]

?

Gewoon Wireshark 24u laten draaien en werkelijke hoeveelheid data capturen in plaats van te extrapoleren op basis van een enkele communicatie.

[RGAT]

laurens0619 schreef op donderdag 16 februari 2023 @ 13:40:
143B per conversation.

1/sec:
1dag == 86400seconde
143B * 86400 =12355200 Byte
= 12MB/dag == 360MB/maand
Dus ik gok dat dion daar een rekenfoutje maakte in de conversie (MB ipv GB)

Met daarbij de voetnooit dat ieder sec communiceren je sowieso al 336MB kost door de overhead van TCP.
Wil je lager uitkomen dan gaat rommelen aan de payload niet zoveel oplossen, afwijken van TCP zou ik ook niet zo snel doen. Dan blijft de frequentie verlagen dus over

Als je toch al elke seconde pingt, kan je net zo goed naar UDP uitwijken, scheelt je weer een paar Bytes per packet, kan je de payload een nummer meegeven zodat je weet welke reply je verwacht, als je je eigen server pingt iig.

[deHakkelaar]

@Scott81 , als je ping gebruikt, kijk dan ofdat je de afmeting omlaag kunt schroeven:

$ man ping
[..]
       -s packetsize
           Specifies the number of data bytes to be sent. The default is 56, which
           translates into 64 ICMP data bytes when combined with the 8 bytes of
           ICMP header data.

$ ping -c 1 -s 0 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 0(28) bytes of data.
8 bytes from 127.0.0.1: icmp_seq=1 ttl=64

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

$ sudo tcpdump -nti any icmp
[..]
lo    In  IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 21, seq 1, length 8
lo    In  IP 127.0.0.1 > 127.0.0.1: ICMP echo reply, id 21, seq 1, length 8

Maar ik zou een andere heuristic gebruiken om bij benadering te bepalen ofdat een service up is.
Ik zou kijken ofdat bv met web poortje 80 TCP hieronder alleen een verbinding is te maken.
Alleen het TCP FIN-->ACK-->FIN-->ACK gedeelte:

$ nc -vz 127.0.0.1 80
Connection to 127.0.0.1 80 port [tcp/http] succeeded!

$ sudo tcpdump -nti any tcp port 80
[..]
lo    In  IP 127.0.0.1.46324 > 127.0.0.1.80: Flags [S], seq 2584648338, win 65495, options [mss 65495,sackOK,TS val 3533265509 ecr 0,nop,wscale 6], length 0
lo    In  IP 127.0.0.1.80 > 127.0.0.1.46324: Flags [S.], seq 4198683657, ack 2584648339, win 65483, options [mss 65495,sackOK,TS val 3533265509 ecr 3533265509,nop,wscale 6], length 0
lo    In  IP 127.0.0.1.46324 > 127.0.0.1.80: Flags [.], ack 1, win 1024, options [nop,nop,TS val 3533265509 ecr 3533265509], length 0
lo    In  IP 127.0.0.1.46324 > 127.0.0.1.80: Flags [F.], seq 1, ack 1, win 1024, options [nop,nop,TS val 3533265514 ecr 3533265509], length 0
lo    In  IP 127.0.0.1.80 > 127.0.0.1.46324: Flags [F.], seq 1, ack 2, win 1024, options [nop,nop,TS val 3533265515 ecr 3533265514], length 0
lo    In  IP 127.0.0.1.46324 > 127.0.0.1.80: Flags [.], ack 2, win 1024, options [nop,nop,TS val 3533265515 ecr 3533265515], length 0

Vergelijk "length" maar in de respectievelijke tcpdump outputs.

Nog mooier zou zijn als je al na de FIN-->ACK kunt stoppen want je hebt toch al de ACK ontvangen van de server.
Dat scheelt weer extra communicatie.

EDIT:

$ nc -z 127.0.0.1 80 && echo 'UP' || echo 'DOWN'
UP

$ nc -z 127.0.0.1 9999 && echo 'UP' || echo 'DOWN'
DOWN

[ Voor 3% gewijzigd door deHakkelaar op 16-02-2023 20:28 ]