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