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

　　WoT 成為成熟市場前，勢必經(jīng)歷通訊協(xié)定技術(shù)變革的過程。物聯(lián)網(wǎng)的發(fā)展，進入到銜接 web(over HTTP)的階段后，典型的通訊協(xié)定堆疊(Protocol Stacks)開始產(chǎn)生變化。更進一步的話，物聯(lián)網(wǎng)在 2015 年開始，進入通訊協(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é)定進行改造。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)正進入應(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 間會進行資料傳輸?shù)拇_認(ACK)，因此可靠度高。然而，這個確認的動作對物聯(lián)網(wǎng)裝置來說，可能會形成一個問題。這個問題在于，確認的動作需要花費較多的硬體資源(運算能力、記憶體等)，對硬體資源較缺乏的裝置(稱為 Constrained Device)，這個 TCP 的確認過程，就成為一個很大的負擔(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 進行傳輸。簡單來說，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 會造成的一些負擔(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 連線就會累積出非?？膳碌摹斑B線負載”。未來迎接 IoT 的時代，降低 ACK 封包，并設(shè)計更適合的通訊協(xié)定，就成了重要的基礎(chǔ)研究?；蛟S，在通訊協(xié)定技術(shù)完成技術(shù)變革后，WoT 才會真正成為成熟市場。