帶你認識物聯網 Modbus 通訊協議 -- 補完計畫（二）
Modbus Protocol
在上一次的物聯網 Modbus 補完計畫（一）中，我們提到了 RTU 與 ASCII 兩種傳輸模式差異之處。接下來我們要繼續看第二個部分關於 Modbus TCP 的確認機制。
通訊就是不可靠
Line 通訊軟體有個神奇的「已讀」功能，代表傳送出去的訊息已經「順利送達」給對方且「已被讀取」，安全抵達與可被確認就是達成可靠通訊的要素。其他不具備「已讀」功能的通訊軟體，訊息送出後就會讓人在心裡一直產生「不知道對方有沒有收到」的不確定性，這種不確定性就是「很不可靠的感覺」。按照我們現在的 Serial 或是網路通訊架構來看，就會了解到通訊的不可靠不只是一種感覺而是一種必然會發生的現象，因為目前的通訊底層都是透過傳輸線的電位變化或是利用無線電磁波來傳遞訊號，這些乘載資訊的物理訊號非常脆弱，很容易遭受各種訊號干擾導致要傳輸資料內容損壞或通訊失效。
Modbus 是比 Ethernet (區域網路) 更簡單的通訊架構，走的是 Master-Slave 模式。協議有規定所有通訊活動只能靠 Master 作為溝通橋樑。而 Master 處理方式就是不斷輪詢對底下的 Slave 裝置來取得資訊，這種「連環 call 」的方法也叫做 Polling by poll。另一方面也是因為協議規定 Slave 裝置們都不可以主動回應，所以 Slave 們在通訊過程中遇到看不懂的、壞掉的資料封包，能做的處理方式就是直接丟掉，從外面看 Slave 裝置的行為就跟「已讀不回」一樣毫無反應。我們能做的也只能等 Master 啟動下一輪輪詢才有機會確認結果（還是有可能已讀不回直到 Timeout），因此 Master 反而成為 Modbus 的通訊的瓶頸，所有的 Slave 裝置們都讓人感覺很不可靠。
TCP 是可靠通訊關鍵
通訊不可靠還包含 Ethernet，Ethernet 就是我們熟知的區域網路。區域網路的設計是會盡力幫我們把資料封包往目的地送，但不保證一定能送到對方手上。而且網路的資料封包也會受各種訊號干擾，頻寬塞滿傳不出去，網路設備超載被丟包甚在網路上資料碰撞導致損毀的狀況，在雙向多工的網路通訊下，上述的各種不可靠的狀況隨時都在發生。既然網路通訊表現這麼糟糕，為什麼我們還是可以收到完整的檔案或圖片呢？這就得歸功於 TCP，Transmission Control Protocol 傳輸控制協定。TCP 是一個坐落在 OSI 網路七層架構的第四層的重要通訊協定，它的超能力是把不可靠網路通訊通訊變成絕對可靠。 (關於網路 OSI 7 層架構後續再找時間跟大家分享)。
由於 TCP 具備把通訊變可靠的超能力，只要是架構在 TCP 之上的通訊服務就都能享受到這個機制，當然也包含了 Modbus (over) TCP 。Modbus 既然要享受 TCP 帶來的好處，當然就要按照 TCP 的規矩來，把要傳輸的資料 PDU 封裝成 Modbus TCP 版本的 ADU (= MBAP + PDU) 的格式。
Modbus ADU
當 Client 端走 Modbus TCP 協議發送指令給 Server 端時候，就會觸發 Server 端的 TCP 的檢查機制，TCP 會把 MBAP header 裡的關鍵欄位全部檢查一遍，包含用來識別一收一送的 Transaction id , 代表 Modbus 通訊協議的 Protocol id 以及對接 Serial 的時候所需要的 Unit id，Unit id 也是 Slave 裝置 id。檢查的重點放在資料格式，確認格式沒有問題後就會把封包收下來並且傳回一個 ACK 訊號給 Client 端，被檢查出有問題後也會主動傳回一個 NACK 回去給 Client 端。反過來也一樣，當 Server 端處理完 Client 的需求後，要回覆給 Client 端訊息後也會觸發檢查機制，因此原本已讀不回的 Modbus 通訊模式變成了有問必答 Modbus TCP，從而保證了 Client 與 Server 兩邊資料的格式正確性。
Confirmation, Indication
另外，TCP 的保證機制並不能解決網路封包碰撞損毀、被丟包等問題，撞毀的資料一樣會被丟棄，TCP 要求重送直到收到正確的資料為止。
小結論
以上就是我這次要跟你分享的 Modbus TCP 確認機制。Modbus TCP 的出現改善了原本的 Master-Slave 這種低效率的通訊模式，升級成為 Client-Server 雙向多工的機制，有了 TCP 加持資料傳輸也變得非常可靠，上層使用者再也不用擔心資料會有收錯或收不到的問題了。可以說有了 Modbus TCP 的物聯網，才是真．物聯網的 Modbus。
