解決了傳輸層的問(wèn)題，再回到應(yīng)用層來(lái)看 HTTP。因?yàn)?nbsp;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 的話(huà)，目前仍必須使用 HTTP + QUIC + UDP 的堆疊。
因?yàn)?nbsp;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)?nbsp;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ì)累積出非常可怕的“連線負(fù)載”。未來(lái)迎接 IoT 的時(shí)代，降低 ACK 封包，并設(shè)計(jì)更適合的通訊協(xié)定，就成了重要的基礎(chǔ)研究?；蛟S，在通訊協(xié)定技術(shù)完成技術(shù)變革后，WoT 才會(huì)真正成為成熟市場(chǎng)。
