解決了傳輸層的問題，再回到應用層來看 HTTP。因為 HTTP request/response headers 設計上的一些缺點，讓 HTTP 的網(wǎng)路傳輸效能無法提升。為解決這些問題，Google 便提出了 SPDY 協(xié)定。SPDY 協(xié)定后來成為 HTTP/2(HTTP 2.0)的基礎。IETF 在 2015 年 5 月正式發(fā)布 HTTP/2 標準(RFC 7540)。HTTP/2 是基于 TCP 協(xié)定，因此要讓物聯(lián)網(wǎng)裝置使用 HTTP over UDP 的話，目前仍必須使用 HTTP + QUIC + UDP 的堆疊。
因為 HTTP/2 標準就是 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 的過程繁復，也可能造成“response time”過長。CoAP、HTTP over UDP 或是 HTTP/2 over QUIC 則是修改了 handshake 的過程，解決了包含 response time 在內(nèi)的各種問題。
未來，當 IoT 裝置大量布署后，屆時網(wǎng)路上將有十億，甚致百億計的 IoT 裝置，這個總數(shù)，絕對比純 web 時代時的 web server 還要更多。當這些 IoT 裝置彼此間，發(fā)出大量且頻繁的 HTTP request/response 時，這些 TCP 連線就會累積出非?？膳碌?/span>“連線負載”。未來迎接 IoT 的時代，降低 ACK 封包，并設計更適合的通訊協(xié)定，就成了重要的基礎研究?；蛟S，在通訊協(xié)定技術完成技術變革后，WoT 才會真正成為成熟市場。
