<meter id="pryje"><nav id="pryje"><delect id="pryje"></delect></nav></meter>
          <label id="pryje"></label>

          新聞中心

          EEPW首頁(yè) > 手機(jī)與無線通信 > 業(yè)界動(dòng)態(tài) > IoT 的成年儀式-通訊協(xié)定技術(shù)變革

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

          作者: 時(shí)間:2015-08-12 來源:CTIMES 收藏

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

          本文引用地址:http://www.ex-cimer.com/article/278595.htm

            

           

            未來,當(dāng) 裝置大量布署后,屆時(shí)網(wǎng)路上將有十億,甚致百億計(jì)的 裝置,這個(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)來交連(interoperate),這個(gè) IoT + Web 的架構(gòu),稱為 WoT(Web of Things)。不只是 WoT 架構(gòu),從通訊協(xié)定的角度來看,正進(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é)定來發(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)裝置來說,可能會(huì)形成一個(gè)問題。這個(gè)問題在于,確認(rèn)的動(dòng)作需要花費(fèi)較多的 硬體資源(運(yùn)算能力、記憶體等),對(duì)硬體資源較缺乏的裝置(稱為 Constrained Device),這個(gè) TCP 的確認(rèn)過程,就成為一個(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)開始受到 HTTP 的影響,這就是 Web of Things。HTTP 屬于 application-level 的協(xié)定,HTTP 的傳輸層就是使用 TCP。

            一個(gè)開放式且符合 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)單來說,CoAP 可以看做是一個(gè) HTTP over UDP 的技術(shù)。CoAP 是物聯(lián)網(wǎng)的重要技術(shù),它讓 Constrained Device 都能具備 HTTP 的能力。大部份的 MCU 裝置都是 Constrained Device,因此,就也像是 MCU + HTTP。

            從實(shí)作的角度來看,CoAP 并非直接采用 HTTP 標(biāo)準(zhǔn),而是透過轉(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 未來也可能在物聯(lián)網(wǎng)應(yīng)用上,扮演重要角色。HTTP over TCP 的 ACK 會(huì)造成的一些負(fù)擔(dān),因此如果讓 HTTP over UDP 的話,就可以解決這個(gè)問題。Google 所提出的 QUIC(Quick UDP Internet Connection)就是這樣的技術(shù)。QUIC 可以讓 HTTP 基于 UDP 傳輸層,就是 HTTP + QUIC + UDP。

            解決了傳輸層的問題,再回到應(yīng)用層來看 HTTP。因?yàn)?HTTP request/response headers 設(shè)計(jì)上的一些缺點(diǎn),讓 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 的堆疊。

            因?yàn)?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,到時(shí)就能舍棄 HTTP + SPDY + QUIC + UDP 的做法,畢竟這只是過渡時(shí)期的解決方案。

            從 IoT 裝置的角度來看,在一個(gè)硬體很受限的環(huán)境里,HTTP over TCP 的過程不但消耗硬體資源,也考驗(yàn)硬體的運(yùn)算能力。同時(shí),這個(gè)過程因?yàn)?handshake 的過程繁復(fù),也可能造成“response time”過長(zhǎng)。CoAP、HTTP over UDP 或是 HTTP/2 over QUIC 則是修改了 handshake 的過程,解決了包含 response time 在內(nè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ù)載”。未來迎接 IoT 的時(shí)代,降低 ACK 封包,并設(shè)計(jì)更適合的通訊協(xié)定,就成了重要的基礎(chǔ)研究?;蛟S,在通訊協(xié)定技術(shù)完成技術(shù)變革后,WoT 才會(huì)真正成為成熟市場(chǎng)。

          物聯(lián)網(wǎng)相關(guān)文章:物聯(lián)網(wǎng)是什么


          數(shù)字通信相關(guān)文章:數(shù)字通信原理


          通信相關(guān)文章:通信原理




          關(guān)鍵詞: IoT 物聯(lián)網(wǎng)

          評(píng)論


          相關(guān)推薦

          技術(shù)專區(qū)

          關(guān)閉
          看屁屁www成人影院,亚洲人妻成人图片,亚洲精品成人午夜在线,日韩在线 欧美成人 (function(){ var bp = document.createElement('script'); var curProtocol = window.location.protocol.split(':')[0]; if (curProtocol === 'https') { bp.src = 'https://zz.bdstatic.com/linksubmit/push.js'; } else { bp.src = 'http://push.zhanzhang.baidu.com/push.js'; } var s = document.getElementsByTagName("script")[0]; s.parentNode.insertBefore(bp, s); })();