IoT 的成年儀式－通訊協定技術變革

　　IoT 成為成熟市場前，勢必經歷通訊協定技術變革的過程。物聯網的發展，進入到銜接 web(over HTTP)的階段后，典型的通訊協定堆疊(Protocol Stacks)開始產生變化。更進一步的話，物聯網在 2015 年開始，進入通訊協定技術變革的時代。過去使用的通訊協定技術，開始有了改良版本。幾個知名的例子：Google 提倡的 SPDY 協定、專為 Constrained Device 所設計的 CoAP，以及 QUIC 改良傳統的 UDP。

　　未來，當 IoT 裝置大量布署后，屆時網路上將有十億，甚致百億計的 IoT 裝置，這個總數，絕對比純 web 時代時的 web server 還要更多。

　　上 述所提的例子，最終都想針對 HTTP 協定進行改造。HTTP 是應用層通訊協定(Application Layer Protocol)，現在的 IoT 架構，發展重心就是使用 HTTP(Web)來交連(interoperate)，這個 IoT + Web 的架構，稱為 WoT(Web of Things)。不只是 WoT 架構，從通訊協定的角度來看，物聯網正進入應用層通訊協定技術變革的時代。

　　TCP/IP Stacks 是網路協定的基礎，其中有一層稱為傳輸層(Transport Layer)，傳輸層包含 TCP 與 UDP 二個協定。UDP 協定比 TCP 更輕量化，但因為 TCP 的可靠性佳高，因此，知名的應用層協定“HTTP”，就基于 TCP 協定來發展。基于 TCP 的 HTTP(或稱為 HTTP over TCP)的特色就是 Client/Server 間會進行資料傳輸的確認(ACK)，因此可靠度高。然而，這個確認的動作對物聯網裝置來說，可能會形成一個問題。這個問題在于，確認的動作需要花費較多的 硬體資源(運算能力、記憶體等)，對硬體資源較缺乏的裝置(稱為 Constrained Device)，這個 TCP 的確認過程，就成為一個很大的負擔。

　　HTTP(Hypertext Transfer Protocol)是一種 request-response 形式的協定。就像我們所知道的，它已經完全融入我們的生活之中。HTTP 在 PC 時代，已經改變人們接收資訊的方式與習慣，到了 Mobile 的時代，HTTP 更再次影響與改變人類的社會文化。到了物聯網時代，HTTP 將繼續影響與改變人類的生活習慣，物聯網已經開始受到 HTTP 的影響，這就是 Web of Things。HTTP 屬于 application-level 的協定，HTTP 的傳輸層就是使用 TCP。

　　一個開放式且符合 Web of Things 設計原則的 IoT Cloud 架構，應該以 application-level 的協定為主，因此 HTTP 成為自然當選人。但物聯網硬體本身，有它的局限性，例如：低功耗、運算頻率較低、主記憶體較少等，當軟體在這樣受局限的硬體環境上運作時，就需要一個比 HTTP 更適合的應用層協定-CoAP(Contrained Application Protocol)就因應而生。

　　CoAP 并不是要取代 HTTP，它是針對 Constrained Device 的 HTTP 需求。CoAP(Constrained Application Protocol)是更簡單且輕量化的 HTTP 技術，簡單的意思是，CoAP 簡化了 HTTP 的內容，輕量化的意思是，CoAP 采用 UDP 進行傳輸。簡單來說，CoAP 可以看做是一個 HTTP over UDP 的技術。CoAP 是物聯網的重要技術，它讓 Constrained Device 都能具備 HTTP 的能力。大部份的 MCU 裝置都是 Constrained Device，因此，就也像是 MCU + HTTP。

　　從實作的角度來看，CoAP 并非直接采用 HTTP 標準，而是透過轉換(translate)的方式將訊息對應成標準的 HTTP。CoAP 采納了 REST 架構，并且也是采取 request/response 的模式。因此，要將 CoAP 轉換為 HTTP，或是將 HTTP 轉換為 CoAP，其實是非常容易的。實際上，CoAP 只對 request/response 的部份做轉換，也就是 CoAP 的 request 都能轉換為 HTTP request headers;response 的部份亦同。

　　除了 CoAP 外，HTTP/2.0 未來也可能在物聯網應用上，扮演重要角色。HTTP over TCP 的 ACK 會造成的一些負擔，因此如果讓 HTTP over UDP 的話，就可以解決這個問題。Google 所提出的 QUIC(Quick UDP Internet Connection)就是這樣的技術。QUIC 可以讓 HTTP 基于 UDP 傳輸層，就是 HTTP + QUIC + UDP。

　　解決了傳輸層的問題，再回到應用層來看 HTTP。因為 HTTP request/response headers 設計上的一些缺點，讓 HTTP 的網路傳輸效能無法提升。為解決這些問題，Google 便提出了 SPDY 協定。SPDY 協定后來成為 HTTP/2(HTTP 2.0)的基礎。IETF 在 2015 年 5 月正式發布 HTTP/2 標準(RFC 7540)。HTTP/2 是基于 TCP 協定，因此要讓物聯網裝置使用 HTTP over UDP 的話，目前仍必須使用 HTTP + QUIC + UDP 的堆疊。

　　因為 HTTP/2 標準就是 SPDY 的內容，如果有意在物聯網裝置上使用 HTTP/2 的特性，就要采用 HTTP + SPDY + QUIC + UDP 的堆疊。不過，Google 未來有意將 HTTP/2 over QUIC 提交給 IETF，到時就能舍棄 HTTP + SPDY + QUIC + UDP 的做法，畢竟這只是過渡時期的解決方案。

　　從 IoT 裝置的角度來看，在一個硬體很受限的環境里，HTTP over TCP 的過程不但消耗硬體資源，也考驗硬體的運算能力。同時，這個過程因為 handshake 的過程繁復，也可能造成“response time”過長。CoAP、HTTP over UDP 或是 HTTP/2 over QUIC 則是修改了 handshake 的過程，解決了包含 response time 在內的各種問題。

　　未來，當 IoT 裝置大量布署后，屆時網路上將有十億，甚致百億計的 IoT 裝置，這個總數，絕對比純 web 時代時的 web server 還要更多。當這些 IoT 裝置彼此間，發出大量且頻繁的 HTTP request/response 時，這些 TCP 連線就會累積出非常可怕的“連線負載”。未來迎接 IoT 的時代，降低 ACK 封包，并設計更適合的通訊協定，就成了重要的基礎研究。或許，在通訊協定技術完成技術變革后，WoT 才會真正成為成熟市場。