開發物聯網的過程中,很多人常常在想該用什麼樣的通訊協定傳遞資料,而這部份的困擾常常來來自於考量穩定、效能與安全性,以下為台灣較為常見的使用開發使用技術的通訊協定:

  1. RS-485
  2. MQTT
  3. Socket (TCP/IP)
  4. UDP
  5. HTTP Client

 

RS-485

在早期的硬體發展中,為了讓硬體與電腦上的資料傳遞上較多為常見的RS-232,爾後開發另一種規格為RS-485。

但此規格的特性在發展的應用上,較為容易發生控制上的穩定問題,例如使用模式上的控制時,需要同時控制多個裝制時,就容易導制僅啟動某一個裝置,或者在通訊的程式上,需要做retry 3次以上亦或有遲頓的現象,甚至無法做控制。許多在軟體硬用的發展上,通常會希望儘量避免使用RS-485的應用。

 

MQTT

英文全名(MQ Telemetry Transport or Message Queuing Telemetry Transport),主要應用在於機器與機器的通訊協定,都是以TCP/IP或是Web Socket做為間接發展。而下列所設計的方式,都有採用到Load Balance的設計架構。

Reference

  1. mosquitto(Open Source):採用使用TCP/IP的方式做為溝通
  2. HiveMQ(付費) : 使用Message Queue概念使用的通訊協定,也是以TCP/IP,採用NAT的方式為標準。
  3. ActiveMQ (Open Source) : 使用Message Queue概念使用的通訊協定,也是以TCP/IP
  4. RabbitMQ : 使用Message Queue概念使用的通訊協定,包括有以TCP/IP及Web Socket

 

TCP/IP

詳細說明可參考TPC/IP的Wikipedia,在這裡就不另加說明。在這個部份,雖然會與MQTT的方式重疊,但這部份僅是針對在單純使用TCP/IP的Socket連接。在物聯網中,有些公司會單採用此種做法作為硬體與軟體的資料溝通的方式,通常在考慮此種做法時,會需要考慮到物聯網的硬體與Server之間的數量是否超過負荷的承受度。

若是Server本身是具有Cloud Server的等級,且需要負載大量的硬體數量,那小弟可能就會鼓勵開發者需要考慮到Socket Server的Load Balance的設計,若是真的需要迫切到自行開發且具本身特色,那想必開發者就要多加考慮設計上的網路上的風險。

 

UDP

詳細說明可參考UDP的Wikipedia。在設計此協定時,勢必也一定會考慮到系統與物聯網的硬默本身上的限制與網路上的應用,但通常這部份的限制,會讓使用者僅限制應用在某一特定範圍,並將資料集中在該地區某單台或多台Server,例如:某一飯店、辦公室或農場等。但若是想在此種協定的架構應用在Cloud Service的發展上,也是可以,但那就要另外設計與Cloud Server架構做資料的整合功能。

在此種的協定上,雖然UDP本身速度快,可快速傳遞大量資料,但也是有相對性的缺點與風險,例如掉封包或是網路安全性的不足。

 

HTTP Client

 

GET

POST

待續...

 

 

居印室內裝修股份有限公司

arrow
arrow

    nandin 發表在 痞客邦 留言(0) 人氣()