通訊協(xié)定技術(shù)革命將推進(jìn)物聯(lián)網(wǎng)發(fā)展

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

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

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

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

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

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

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

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

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

解決了傳輸層的問(wèn)題，再回到應(yīng)用層來(lái)看 HTTP。因?yàn)?HTTP request/response headers 設(shè)計(jì)上的一些缺點(diǎn)，讓 HTTP 的網(wǎng)路傳輸效能無(wú)法提升。為解決這些問(wèn)題，Google 便提出了 SPDY 協(xié)定。SPDY 協(xié)定后來(lái)成為 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 的堆疊。

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

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

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