嚴格來說，MQTT跟WebSocket關系不大。他們不是在一個層級的。
MQTT和TCP、WebSocket的關系可以用下圖一目了然：
參考資料：
http://www.zhihu.com/question/21816631
WebSocket的優勢
以前，很多網站使用輪詢實現推送技術。輪詢是在特定的的時間間隔（比如1秒），由瀏覽器對服務器發出HTTP request，然后由服務器返回最新的數據給瀏覽器。輪詢的缺點很明顯，瀏覽器需要不斷的向服務器發出請求，然而HTTP請求的header是非常長的，而實際傳輸的數據可能很小，這就造成了帶寬和服務器資源的浪費。
Comet使用了AJAX改進了輪詢，可以實現雙向通信。但是Comet依然需要發出請求，而且在Comet中，普遍采用了長鏈接，這也會大量消耗服務器帶寬和資源。
於是，WebSocket協議應運而生。 瀏覽器通過 JavaScript 向服務器發出建立 WebSocket 連接的請求，連接建立以后，客戶端和服務器通過 TCP 連接直接交換數據。WebSocket 連接本質上是一個 TCP 連接。
WebSocket在數據傳輸的穩定性和數據傳輸量的大小方面，具有很大的性能優勢。Websocket.org 比較了輪詢和WebSocket的性能優勢：
HTTP 輪訓每次需要返回871個字節，websocket每次只需要2個字節
Use Case A： 1,000個客戶端每秒接受一個message，網絡吞吐量 （2*1,000）=2,000 bytes = 16,000 每秒bits
Use Case B： 10,000個客戶端每秒接受一個message，網絡吞吐量 （2*10,000）=20,000 bytes = 160,000 每秒bits
Use Case C： 100,000個客戶端每秒接受一個message，網絡吞吐量 （2*100,000）=200,000 bytes = 1,600,000 每秒bits
參考：
http://segmentfault.com/a/1190000000382788
Spring 4.0 中的 WebSocket 架構
http://www.oschina.net/translate/websocket-architecture-in-spring-4-0
MQTT
MQTT 協議是為大量計算能力有限，且工作在低帶寬、不可靠的網絡的遠程傳感器和控制設備通訊而設計的協議，它具有以下主要的幾項特性：
- 非常小的通信開銷（最小的消息大小為 2 字節），小型傳輸，開銷很小（固定長度的頭部是 2 字節），協議交換最小化，以降低網絡流量。
- 支持各種流行編程語言（包括 C，Java，Ruby，Python 等等）且易於使用的客戶端；
- 使用發布 / 訂閱消息模式，提供一對多的消息發布，解除應用程序耦合。
- 對負載內容屏蔽的消息傳輸。
- 使用 TCP/IP 提供網絡連接。
- 有三種消息發布服務質量，讓消息能按需到達目的地，適應在不穩定工作的網絡傳輸需求 ：
- "至多一次"，消息發布完全依賴底層 TCP/IP 網絡。會發生消息丟失或重復。這一級別可用於如下情況，環境傳感器數據，丟失一次讀記錄無所謂，因為不久后還會有第二次發送。
- "至少一次"，確保消息到達，但消息重復可能會發生。
- "只有一次"，確保消息到達一次。這一級別可用於如下情況，在計費系統中，消息重復或丟失會導致不正確的結果。
- 使用 Last Will 和 Testament 特性通知有關各方客戶端異常中斷的機制。
參考：
MQTT技術：為物聯網而生
http://www.leiphone.com/0828-danice-mqtt.html
MQTT 折騰筆記----協議簡讀
http://www.cnblogs.com/youxilua/archive/2013/04/25/3041528.html
基於 WebSocket 的 MQTT 移動推送方案
http://www.ibm.com/developerworks/cn/websphere/library/techarticles/1308_xiangr_mqtt/1308_xiangr_mqtt.html