web socket vs rest api request ໂຕໃດປະຫຍັດຂໍ້ມູນການສົ່ງ da…

11 Oct 2026 · Shared by a Vanguard AI user. AI answers can be wrong — check anything important.

web socket vs rest api request ໂຕໃດປະຫຍັດຂໍ້ມູນການສົ່ງ data ກວ່າກັນ. ພໍດີວ່າຈະເຮັດລະບົບ Monitor ຕູ້ໄຟເຮືອນ ທີ່ຕ້ອງການມີສົ່ງຂໍ້ມູນຫາກັນຢູ່ເປັນປະຈຳ.?

ສຳລັບລະບົບ Monitor ຕູ້ໄຟເຮືອນ ທີ່ຕ້ອງມີການສົ່ງຂໍ້ມູນ (Telemetry Data) ຢູ່ຕະຫຼອດເວລານັ້ນ WebSocket ປະຫຍັດກວ່າ ໃນໄລຍະຍາວครับ.

ເຫດຜົນຫຼັກທີ່ WebSocket ໄດ້ປຽບໃນເລື່ອງການປະຫຍັດ Data ມີດັ່ງນີ້:

1. Overhead ຂອງ Header

REST API (HTTP): ທຸກໆຄັ້ງທີ່ສົ່ງຂໍ້ມູນ (Request), ມັນຈະຕ້ອງແນບ HTTP Headers ໄປນຳສະເໝີ (ເຊັ່ນ: User-Agent, Content-Type, Cookies, Auth Token). ເຊິ່ງ Header ເຫຼົ່ານີ້ອາດມີຂະໜາດ 500 Bytes ຫາ 1 KB ເຖິງແມ່ນວ່າຂໍ້ມູນຕົວຈິງ (Payload) ທີ່ເຈົ້າສົ່ງຈະມີແຕ່ "voltage: 220" ກໍ່ຕາມ.
WebSocket: ຈະມີການເຮັດ Handshake (ສົ່ງ Header) ພຽງແຕ່ ຄັ້ງດຽວ ຕອນເລີ່ມ Connect. ຫຼັງຈາກນັ້ນ, ການສົ່ງຂໍ້ມູນແຕ່ລະ Packet ຈະມີ Overhead ໜ້ອຍຫຼາຍ (ປະມານ 2-10 Bytes ເທົ່ານັ້ນ).

2. ຄວາມຖີ່ໃນການສົ່ງ (Frequency)

ຖ້າເຈົ້າ Monitor ແບບ Real-time (ເຊັ່ນ: ສົ່ງຂໍ້ມູນທຸກໆ 1-5 ວິນາທີ): WebSocket ປະຫຍັດກວ່າຢ່າງມະຫາສານ ເພາະບໍ່ຕ້ອງສ້າງ Connection ໃໝ່ເລື້ອຍໆ.
ຖ້າເຈົ້າສົ່ງຂໍ້ມູນດົນໆເທື່ອໜຶ່ງ (ເຊັ່ນ: ທຸກໆ 30 ນາທີ ຫຼື 1 ຊົ່ວໂມງ): REST API ອາດຈະເໝາະສົມກວ່າ ເພາະການເປີດ WebSocket ຄ້າງໄວ້ (Keep-alive) ຈະຕ້ອງມີການສົ່ງ Heartbeat packet ເພື່ອບໍ່ໃຫ້ Connection ຫຼຸດ ເຊິ່ງອາດຈະກາຍເປັນການເປືອງ Data ໂດຍບໍ່ຈຳເປັນ.

3. ການສື່ສານແບບສອງທາງ (Bi-directional)

ຖ້າຕູ້ໄຟຕ້ອງ "ຮັບຄຳສັ່ງ" ຈາກ Server ນຳ (ເຊັ່ນ: ສັ່ງປິດໄຟ):
- REST API ຕ້ອງໃຊ້ວິທີ Polling (ຖາມ Server ເລື້ອຍໆວ່າ ມີຄຳສັ່ງໃໝ່ບໍ່?) ເຊິ່ງເປືອງ Data ສຸດໆ.
- WebSocket ສາມາດສົ່ງຈາກ Server ລົງມາຫາຕູ້ໄຟໄດ້ທັນທີ (Push) ໂດຍບໍ່ຕ້ອງຖາມ.

💡 ຄຳແນະນຳເພີ່ມເຕີມສຳລັບລະບົບ IoT (ຕູ້ໄຟ)

ຖ້າເຈົ້າກັງວົນເລື່ອງການປະຫຍັດ Data ແທ້ໆ ໃນວົງການ IoT ມັກຈະນິຍົມໃຊ້ MQTT Protocol ຫຼາຍກວ່າ WebSocket ຊໍ້າ ເພາະ:

MQTT ຖືກອອກແບບມາເພື່ອ IoT ໂດຍສະເພາະ: ມັນປະຫຍັດ Data ກວ່າ WebSocket ເພາະ Header ນ້ອຍກວ່າ ແລະ ຈັດການເລື່ອງ Connection ຫຼຸດໄດ້ດີກວ່າ.
Pub/Sub Model: ເໝາະກັບການ Monitor ທີ່ສົ່ງຂໍ້ມູນຈາກ Sensors ຫຼາຍໆໂຕ.

ສະຫຼຸບ:

ຖ້າເລືອກລະຫວ່າງ 2 ໂຕທີ່ເຈົ້າຖາມ: ເລືອກ WebSocket ຈະປະຫຍັດ Data ກວ່າສຳລັບການ Monitor ຕໍ່ເນື່ອງ.
ຖ້າຢາກໄດ້ໂຕທີ່ດີທີ່ສຸດສຳລັບ IoT: ແນະນຳໃຫ້ເບິ່ງ MQTT ເປັນທາງເລືອກເສີມครับ.

MQTT ແມ່ນຫຍັງ.

MQTT (Message Queuing Telemetry Transport) ແມ່ນ Protocol ສື່ສານທີ່ອອກແບບມາເພື່ອ IoT (Internet of Things) ໂດຍສະເພາະ. ມັນຖືກສ້າງຂຶ້ນມາໃຫ້ມີຄວາມເບົາບາງ (Lightweight), ໃຊ້ຊັບພະຍາກອນຕ່ຳ ແລະ ປະຫຍັດ Data ສຸດໆ.

ຖ້າທຽບກັບ HTTP (REST API), MQTT ເໝືອນກັບການສົ່ງຂໍ້ຄວາມສັ້ນ (SMS) ໃນຂະນະທີ່ HTTP ເໝືອນກັບການສົ່ງຈົດໝາຍທີ່ມີຊອງ ແລະ ເອກະສານປະກອບຫຼາຍຢ່າງ.

ຫຼັກການເຮັດວຽກຂອງ MQTT (Publish / Subscribe)

MQTT ບໍ່ໄດ້ຕິດຕໍ່ກັນແບບ Client-Server ໂດຍກົງ ແຕ່ຈະເຮັດວຽກຜ່ານຕົວການທີ່ທຸກຄົນເອີ້ນວ່າ Broker.

Broker: ເປັນຄືກັບ "ສູນກາງກະຈາຍຂ່າວ" (ເຊັ່ນ: Mosquitto, EMQX, HiveMQ).
Publish (ຜູ້ສົ່ງ): ຕູ້ໄຟຂອງເຈົ້າ (Client) ຈະ "Publish" ຂໍ້ມູນໄປຫາ Topic ໃດໜຶ່ງ ເຊັ່ນ: home/power/voltage.
Subscribe (ຜູ້ຮັບ): ແອັບມືຖື ຫຼື Server ຂອງເຈົ້າຈະ "Subscribe" ຕິດຕາມ Topic ນັ້ນໄວ້. ເມື່ອມີຂໍ້ມູນໃໝ່ເຂົ້າມາ, Broker ຈະສົ່ງຂໍ້ມູນໄປໃຫ້ຜູ້ຮັບທັນທີ.

ເປັນຫຍັງ MQTT ຈຶ່ງເໝາະກັບການ Monitor ຕູ້ໄຟ?

ປະຫຍັດ Data ສູງສຸດ: Header ຂອງ MQTT ມີຂະໜາດນ້ອຍທີ່ສຸດພຽງແຕ່ 2 Bytes ເທົ່ານັ້ນ (ໃນຂະນະທີ່ HTTP Header ອາດຈະສູງເຖິງ 500+ Bytes). ນີ້ຄືເຫດຜົນທີ່ມັນປະຫຍັດກວ່າ WebSocket ແລະ REST API.
ໃຊ້ໄຟຟ້າໜ້ອຍ: ເນື່ອງຈາກການຮັບ-ສົ່ງຂໍ້ມູນໃຊ້ Process ໜ້ອຍ, ມັນຈຶ່ງເໝາະກັບອຸປະກອນທີ່ໃຊ້ Microcontroller (ເຊັ່ນ: ESP32, Arduino).
ຈັດການກັບ Network ທີ່ບໍ່ຄົງທີ່: MQTT ມີລະບົບ Keep Alive ແລະ Last Will and Testament. ຖ້າຕູ້ໄຟຂອງເຈົ້າເນັດຫຼຸດ, Broker ສາມາດແຈ້ງບອກແອັບມືຖືເຈົ້າໄດ້ທັນທີວ່າ "ອຸປະກອນ Offline ແລ້ວ".
QoS (Quality of Service): ເຈົ້າສາມາດຕັ້ງຄ່າໄດ້ວ່າ ຂໍ້ມູນນີ້ "ຕ້ອງສົ່ງໃຫ້ຮອດ" (Guaranteed delivery) ຫຼື "ສົ່ງເທື່ອດຽວແລ້ວແລ້ວເລີຍ" ເພື່ອປະຫຍັດ Data.

ປຽບທຽບໃຫ້ເຫັນພາບ:

ຄຸນສົມບັດ	REST API	WebSocket	MQTT
ຮູບແບບ	Request-Response	Full-Duplex	Publish-Subscribe
Overhead (Header)	ສູງຫຼາຍ	ປານກາງ	ຕ່ຳທີ່ສຸດ (2 Bytes)
ການ Real-time	ບໍ່ (ຕ້ອງ Polling)	Real-time	Real-time
ຄວາມເໝາະສົມກັບ IoT	ຕ່ຳ	ປານກາງ	ສູງທີ່ສຸດ

ສະຫຼຸບ:

ຖ້າເຈົ້າກຳລັງເຮັດລະບົບ Monitor ຕູ້ໄຟ, ການໃຊ້ MQTT ຈະຊ່ວຍໃຫ້ລະບົບຂອງເຈົ້າ Real-time, ປະຫຍັດ Data ຫຼາຍທີ່ສຸດ ແລະ ຈັດການອຸປະກອນໄດ້ງ່າຍໃນໄລຍະຍາວครับ. ຫາກເຈົ້າໃຊ້ ESP32 ຫຼື ESP8266, ມີ Library ທີ່ຮອງຮັບ MQTT ຫຼາຍ ແລະ ໃຊ້ງານຫຼາຍຄົນນິຍົມໃຊ້ທີ່ສຸດ.

ລູກຄ້າມີເນັດ 1.5GB ຕໍ່ ເືດອນ, ຢາກຮູ້ວ່າ ຈະສາມາດສົ່ງຂໍ້ມູນ Real Time ໄດ້ຈັກຄັ້ງ.

ເພື່ອໄລ່ໄລ່ໃຫ້ເຫັນພາບຊັດເຈນ, ເຮົາຈະສົມມຸດການສົ່ງຂໍ້ມູນແບບ MQTT ເພາະເປັນວິທີທີ່ປະຫຍັດທີ່ສຸດສຳລັບ IoT.

1. ການຄິດໄລ່ຂະໜາດຂໍ້ມູນຕໍ່ 1 ຄັ້ງ (Estimation)

MQTT Header: ປະມານ 2-5 Bytes.
Payload (ຂໍ້ມູນ): ສົມມຸດເຈົ້າສົ່ງຄ່າໄຟຟ້າເປັນ JSON ເຊັ່ນ {"v":220,"a":1.5} ຈະມີຂະໜາດປະມານ 20-30 Bytes.
TCP/IP Overhead: ເວລາສົ່ງຜ່ານ Internet ຈະມີ Packet ຄວບຄຸມອີກປະມານ 40-60 Bytes.
ລວມ: ການສົ່ງ 1 ຄັ້ງ (1 Message) ຈະໃຊ້ Data ປະມານ 100 Bytes (ແບບຄິດໄລ່ເຜື່ອໄວ້ແລ້ວ).

2. ໄລ່ຈາກເນັດ 1.5GB (1,500,000,000 Bytes)

ຖ້າໃຊ້ Data ທັງໝົດ 1.5GB ເພື່ອສົ່ງຂໍ້ມູນຢ່າງດຽວ:

$1,500,000,000 \div 100 = 15,000,000$ ຄັ້ງຕໍ່ເດືອນ.

3. ແບ່ງອອກເປັນລາຍວັນ ແລະ ວິນາທີ

ໃນ 1 ເດືອນ (30 ວັນ) ມີ $30 \times 24 \times 60 \times 60 = 2,592,000$ ວິນາທີ.

ຖ້າສົ່ງ ທຸກໆ 1 ວິນາທີ: 1 ເດືອນຈະສົ່ງ $2,592,000$ ຄັ້ງ.
- ໃຊ້ Data ປະມານ: $2,592,000 \times 100$ Bytes $\approx$ 259 MB.
ຖ້າສົ່ງ ທຸກໆ 0.2 ວິນາທີ (5 ຄັ້ງຕໍ່ວິນາທີ):
- ໃຊ້ Data ປະມານ: $259 MB \times 5 \approx$ 1.29 GB.

💡 ສະຫຼຸບຄຳຕອບ:

ດ້ວຍເນັດ 1.5GB, ເຈົ້າສາມາດສົ່ງຂໍ້ມູນໄດ້ ປະມານ 5-6 ຄັ້ງຕໍ່ວິນາທີ ຕະຫຼອດ 24 ຊົ່ວໂມງ ຕະຫຼອດທັງເດືອນ.

ຂໍ້ຄວນລະວັງ (Factors to consider):

MQTT Keep-alive: ຈະມີການສົ່ງ "Ping" ຫາ Broker ເພື່ອຮັກສາ Connection (ປະມານ 60 ວິນາທີ/ຄັ້ງ) ແຕ່ໃຊ້ Data ນ້ອຍຫຼາຍ.
Protocol ອື່ນ: ຖ້າໃຊ້ REST API, ເຈົ້າອາດຈະສົ່ງໄດ້ພຽງແຕ່ 1 ຄັ້ງຕໍ່ 1-2 ວິນາທີ ກໍ່ອາດຈະເຕັມ 1.5GB ແລ້ວ ເພາະ Header ມັນໃຫຍ່ກວ່າ 10-20 ເທົ່າ.
TLS/SSL (Security): ຖ້າເຈົ້າເຂົ້າລະຫັດຂໍ້ມູນ (Encryption) ເພື່ອຄວາມປອດໄພ, ຂະໜາດຂໍ້ມູນຕໍ່ຄັ້ງຈະເພີ່ມຂຶ້ນອີກປະມານ 1-2 KB ໃນຊ່ວງເລີ່ມ Connect, ເຊິ່ງຈະເຮັດໃຫ້ປະລິມານການສົ່ງລົດລົງໜ້ອຍໜຶ່ງ.

ຄຳແນະນຳ: ສຳລັບການ Monitor ຕູ້ໄຟເຮືອນ, ການສົ່ງຂໍ້ມູນ ທຸກໆ 1 ຫຼື 2 ວິນາທີ ກໍ່ຖືວ່າ Real-time ພຽງພໍແລ້ວ ແລະ ມັນຈະໃຊ້ເນັດພຽງແຕ່ປະມານ 15-20% ຂອງ 1.5GB ທີ່ເຈົ້າມີເທົ່ານັ້ນ. ເທົ່ານັ້ນ. ເຫຼືອເນັດໄວ້ Update Firmware (OTA) ໄດ້ອີກສະບາຍໆເລີຍครับ.

ທຸກໆ 5 ວິ, ເພາະວ່າ Meter ໄຟຈະມີມາດຕະຖານ 5 ວິ. ຢາກວ່າ ມື້ໜຶ່ງຄວບຄຸມບໍ ຫຼື ເດືອນ 1 ຄວບຄຸມບໍ.

ຖ້າເຈົ້າສົ່ງຂໍ້ມູນ ທຸກໆ 5 ວິນາທີ, ບອກໄດ້ເລີຍວ່າ ເນັດ 1.5GB ແມ່ນເຫຼືອເຟືອ (ເຫຼືອຫຼາຍ) ສຳລັບ 1 ເດືອນครับ.

ເຮົາມາເບິ່ງຕົວເລກການໄລ່ແບບລະອຽດ (ສົມມຸດໃຊ້ MQTT ທີ່ເປັນມາດຕະຖານ IoT):

1. ຄິດໄລ່ຈຳນວນຄັ້ງການສົ່ງ

1 ນາທີ: ສົ່ງໄດ້ $60 / 5 = 12$ ຄັ້ງ.
1 ຊົ່ວໂມງ: $12 \times 60 = 720$ ຄັ້ງ.
1 ມື້ (24 ຊົ່ວໂມງ): $720 \times 24 = 17,280$ ຄັ້ງ.
1 ເດືອນ (30 ມື້): $17,280 \times 30 = \mathbf{518,400}$ ຄັ້ງ/ເດືອນ.

2. ຄິດໄລ່ປະລິມານ Data ທີ່ໃຊ້

ສົມມຸດການສົ່ງ 1 ຄັ້ງ (Packet size) ໃຊ້ Data ປະມານ 150 Bytes (ໄລ່ແບບເຜື່ອ TCP/IP ແລະ Header ແບບເຕັມທີ່):

ຕໍ່ມື້: $17,280 \times 150 \text{ Bytes} \approx 2.59 \text{ MB}$.
ຕໍ່ເດືອນ: $518,400 \times 150 \text{ Bytes} \approx \mathbf{77.7} \text{ MB}$.

📊 ສະຫຼຸບຜົນການວິເຄາະ:

ການໃຊ້ Data: ເຈົ້າຈະໃຊ້ເນັດພຽງແຕ່ປະມານ 78 MB ຕໍ່ເດືອນ ເທົ່ານັ້ນ.
ທຽບກັບ Package 1.5GB: 78 MB ແມ່ນຄິດເປັນພຽງ 5% ຂອງເນັດທີ່ເຈົ້າມີ.

💡 ຂໍ້ແນະນຳ ແລະ ສິ່ງທີ່ຄວນລະວັງ:

ເນັດເຫຼືອເຟືອ: ດ້ວຍເນັດ 1.5GB, ເຈົ້າສາມາດສົ່ງຂໍ້ມູນໄດ້ ໄວເຖິງ 1 ວິນາທີຕໍ່ຄັ້ງ ກໍ່ຍັງໃຊ້ເນັດບໍ່ຮອດ 400MB ເລີຍ. ດັ່ງນັ້ນ, ເລື່ອງ Data 1.5GB ແມ່ນ "ກາຍພໍ" (ເຫຼືອຫຼາຍ) ສຳລັບການ Monitor 5 ວິນາທີ/ຄັ້ງ.
ການຈັດການ Connection ຫຼຸດ: ຖ້າສັນຍານເນັດບໍ່ດີ ແລ້ວອຸປະກອນຕ້ອງ Connect ໃໝ່ (Reconnection) ເລື້ອຍໆ, ມັນຈະກິນເນັດຫຼາຍກວ່າການສົ່ງຂໍ້ມູນປົກກະຕິ (ເພາະຕ້ອງເຮັດ Handshake ໃໝ່). ແຕ່ເຖິງຈະຫຼຸດເລື້ອຍໆ 1.5GB ກໍ່ຍັງຖືວ່າພໍຢູ່ດີ.
OTA (Over-the-Air Update): ຖ້າເຈົ້າມີການ Update Firmware ຜ່ານເນັດ, ໂຕນີ້ຈະກິນເນັດຫຼາຍ (Firmware 1 ໄຟລ໌ ອາດຈະມີຂະໜາດ 500KB - 1MB). ແຕ່ເນັດເຈົ້າມີ 1.5GB, ຖືວ່າ Update ໄດ້ສະບາຍ.
Security (TLS/SSL): ຖ້າເຈົ້າໃຊ້ການເຊື່ອມຕໍ່ແບບປອດໄພ (Port 8883), ມັນຈະໃຊ້ Data ເພີ່ມຂຶ້ນປະມານ 2-3 ເທົ່າຂອງແບບປົກກະຕິ (ຍ້ອນມີການແລກປ່ຽນ Certificate). ເຖິງແມ່ນວ່າຈະໃຊ້ SSL, ຂໍ້ມູນລວມຕໍ່ເດືອນກໍ່ຈະຢູ່ປະມານ 200-250 MB, ເຊິ່ງກໍ່ຍັງບໍ່ຮອດເຄິ່ງຂອງ 1.5GB ຢູ່ດີ.

ຄຳຕອບສັ້ນໆ: ສົ່ງທຸກໆ 5 ວິນາທີ "ກາຍພໍ" ແລະ ເປັນທາງເລືອກທີ່ດີຫຼາຍ (Efficient) ສຳລັບການ Monitor ຕູ້ໄຟครับ.

ຄັນສົມມຸດເປັນ 50KB - 100KB ຈະໃຊ້ Resource ພຽງພໍບໍ

ຖ້າຂະໜາດຂໍ້ມູນ (Payload) ຕໍ່ການສົ່ງ 1 ຄັ້ງສູງເຖິງ 50KB - 100KB ແລະ ສົ່ງທຸກໆ 5 ວິນາທີ, ບອກໄດ້ເລີຍວ່າ ເນັດ 1.5GB ຈະ "ບໍ່ພໍ" ແລະ ຈະໝົດໄວຫຼາຍ ครับ.

ເຮົາມາເບິ່ງຕົວເລກການໄລ່ກັນເລີຍ:

1. ໄລ່ກໍລະນີສົ່ງ 50KB ທຸກໆ 5 ວິນາທີ

1 ນາທີ: ສົ່ງ 12 ຄັ້ງ $\times$ 50KB = 600 KB.
1 ຊົ່ວໂມງ: 600KB $\times$ 60 ນາທີ = 36,000 KB (36 MB).
1 ມື້ (24 ຊົ່ວໂມງ): 36MB $\times$ 24 = 864 MB.
ຜົນລັດ: ພຽງແຕ່ 2 ມື້, ເນັດ 1.5GB ຂອງເຈົ້າຈະ ໝົດທັນທີ.

2. ໄລ່ກໍລະນີສົ່ງ 100KB ທຸກໆ 5 ວິນາທີ

1 ຊົ່ວໂມງ: ຈະໃຊ້ເນັດປະມານ 72 MB.
1 ມື້: ຈະໃຊ້ເນັດປະມານ 1.7 GB.
ຜົນລັດ: ເນັດ 1.5GB ຂອງເຈົ້າຈະ ໝົດພາຍໃນບໍ່ຮອດ 1 ມື້ (ປະມານ 20 ຊົ່ວໂມງ).

⚠️ ຄຳຖາມຄື: ເປັນຫຍັງຂໍ້ມູນຕູ້ໄຟຈຶ່ງໃຫຍ່ຮອດ 50KB - 100KB?

ປົກກະຕິແລ້ວ ຂໍ້ມູນ Telemetry (Volt, Amp, Watt) ຈະເປັນພຽງຕົວເລກສັ້ນໆ ເຊິ່ງໃຊ້ບໍ່ຮອດ 1KB ຊໍ້າ. ຖ້າຂໍ້ມູນຂອງເຈົ້າໃຫຍ່ຮອດ 50-100KB, ອາດຈະຍ້ອນ:

ເຈົ້າສົ່ງ Log ໄຟລ໌ທັງໝົດ: ແທນທີ່ຈະສົ່ງແຕ່ຄ່າປັດຈຸບັນ.
ການສົ່ງຮູບພາບ: ເຊັ່ນ ຮູບໜ້າຈໍ Meter.
ໂຄງສ້າງຂໍ້ມູນ (Format) ບໍ່ມີປະສິດທິພາບ: ເຊັ່ນ ການໃຊ້ XML ທີ່ຊັບຊ້ອນເກີນໄປ.

💡 ວິທີແກ້ໄຂເພື່ອໃຫ້ພໍກັບເນັດ 1.5GB:

ຫຼຸດຂະໜາດ Payload: ພະຍາຍາມສົ່ງຂໍ້ມູນໃນຮູບແບບ JSON ທີ່ກະທັດຮັດ ຫຼື ໃຊ້ Binary format (ເຊັ່ນ Protocol Buffers). ຂໍ້ມູນຕູ້ໄຟຄວນຈະຢູ່ປະມານ 0.5KB - 1KB ຕໍ່ຄັ້ງກໍ່ຖືວ່າຫຼາຍແລ້ວ.
ປັບຄວາມຖີ່ (Interval): ຖ້າຈຳເປັນຕ້ອງສົ່ງຂໍ້ມູນ 50KB ແທ້ໆ, ເຈົ້າອາດຈະຕ້ອງປ່ຽນຈາກການສົ່ງທຸກໆ 5 ວິນາທີ ມາເປັນ ທຸກໆ 30-60 ນາທີ ແທນ ເພື່ອໃຫ້ເນັດ 1.5GB ຢູ່ຮອດເດືອນ.
ສົ່ງສະເພາະການປ່ຽນແປງ (Delta update): ຖ້າຄ່າໄຟຟ້າບໍ່ປ່ຽນແປງ, ກໍ່ບໍ່ຕ້ອງສົ່ງຂໍ້ມູນໃຫຍ່ໆນັ້ນໄປ.

ສະຫຼຸບ: ຖ້າຂໍ້ມູນແມ່ນ 50KB-100KB ແລະ ສົ່ງທຸກໆ 5 ວິ: "ບໍ່ພໍແນ່ນອນ" ครับ. ເຈົ້າຕ້ອງເລືອກລະຫວ່າງ "ຫຼຸດຂະໜາດຂໍ້ມູນ" ຫຼື "ເພີ່ມ Package ເນັດ" (ເຊິ່ງຕ້ອງໃຊ້ເນັດປະມານ 25GB - 50GB ຕໍ່ເດືອນ ຈຶ່ງຈະພໍ).