IoT 的成年儀式－通訊協(xié)定技術(shù)變革

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

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

　　上 述所提的例子，最終都想針對 HTTP 協(xié)定進(jìn)行改造。HTTP 是應(yīng)用層通訊協(xié)定(Application Layer Protocol)，現(xiàn)在的 IoT 架構(gòu)，發(fā)展重心就是使用 HTTP(Web)來交連(interoperate)，這個 IoT + Web 的架構(gòu)，稱為 WoT(Web of Things)。不只是 WoT 架構(gòu)，從通訊協(xié)定的角度來看，物聯(lián)網(wǎng)正進(jìn)入應(yīng)用層通訊協(xié)定技術(shù)變革的時代。

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

　　HTTP(Hypertext Transfer Protocol)是一種 request-response 形式的協(xié)定。就像我們所知道的，它已經(jīng)完全融入我們的生活之中。HTTP 在 PC 時代，已經(jīng)改變?nèi)藗兘邮召Y訊的方式與習(xí)慣，到了 Mobile 的時代，HTTP 更再次影響與改變?nèi)祟惖纳鐣幕?。到了物?lián)網(wǎng)時代，HTTP 將繼續(xù)影響與改變?nèi)祟惖纳盍?xí)慣，物聯(lián)網(wǎng)已經(jīng)開始受到 HTTP 的影響，這就是 Web of Things。HTTP 屬于 application-level 的協(xié)定，HTTP 的傳輸層就是使用 TCP。

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

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

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

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

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

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

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

　　未來，當(dāng) IoT 裝置大量布署后，屆時網(wǎng)路上將有十億，甚致百億計的 IoT 裝置，這個總數(shù)，絕對比純 web 時代時的 web server 還要更多。當(dāng)這些 IoT 裝置彼此間，發(fā)出大量且頻繁的 HTTP request/response 時，這些 TCP 連線就會累積出非?？膳碌?ldquo;連線負(fù)載”。未來迎接 IoT 的時代，降低 ACK 封包，并設(shè)計更適合的通訊協(xié)定，就成了重要的基礎(chǔ)研究?；蛟S，在通訊協(xié)定技術(shù)完成技術(shù)變革后，WoT 才會真正成為成熟市場。