HTTP 是應用層協議，TCP 是傳輸層協議（位於應用層之下），放在一起類比並不合適。 不過猜測樓主是想對比 “標準 HTTP 協議” 還是 “自定義的協議（基於 TCP Socket）” 。

一般來說，移動應用推薦使用 HTTP 協議，有很多優點： HTTP 發展成熟 HTTP 幾乎已經快成為一種通用的 Web 標準，Web Services、REST、Open API、OAuth 等等都是基於 HTTP 協議的。它已經不僅僅是 Hyper Text 的傳輸標準了，幾乎所有資料的傳輸（多媒體、XML、JSON）都可以採用 HTTP。 後臺複用 因為很多應用，除了有移動端，還有Web端，甚至桌面端。 Web 版中前後臺互動，無論是頁面請求還是 AJAX 請求，都是採用標準 HTTP 協議。那麼其他的客戶端沒有理由重新設計一套協議。 HTML 5 應用 現在不少移動產品都採用或者半採用 HTML 5 技術，那麼和伺服器的互動又迴歸到 AJAX 上。不用說，還是離不開 HTTP。 但是也有一些侷限性，比如以下場景就不適合 HTTP 協議： 實時資料推送 除了 iOS 開發提供有標準的 Apple 訊息推送中心，其他移動產品可能還是要採用 Socket 長連線才能保證實時通訊。 比較常見的有很多即時通訊軟體採用的 XMPP 協議。 流媒體 適用於音訊播放、視訊播放、語音會議等等，一般可能採用 RTMP 協議。

Http 是 TCP的上層協議，Http 是基於 TCP的，所以你用了HTTP，等同與你也在用TCP

所以，拿Http和TCP做優劣比較是一個不存在的問題。

當然，這問題提的很好，問的是相較基於tcp的自定義協議。

其實事實上，從巨集觀層面，已經自己回答了這個問題了。

為啥要自定義協議呢？很簡單啊，http協議滿足不了需求只好自定義協議啊。 也就是說，自定義協議可以滿足很多http協議滿足不了的需求啊。 那什麼需求是http協議滿足不了的呢？ 這也很簡單啊，可以查一下http協議的定義去看看它提供了什麼樣的包裝和定義，落在它之外的就是滿足不了的啊，要真的細說，那真是多了去了，比如：

例如：http是單工阻塞性質的協議，如果你需要一個全雙工，無阻塞的雙向傳輸，那http就滿足不了

例如：http定義提供了很多種的請求方法，從get到post不一一列舉了，但是你需要的請求應答模式和它定義的種種沒有任何一種能夠實現你需要的請求應答模式，你就需要自定義協議啊

例如：http定義自己的包頭，你要是覺得傳輸效率極其重要，這樣的包頭太臃腫，你也需要自定義協議啊

要是http都能完全滿足你的需求，那為啥要自定義協議呢？一個成熟的協議拿來就用明顯是很好的選擇啊。

現在REST一出，一改過去SOAP的複雜臃腫，HTTP協議本身一直也在擴充，因此適用的範圍更廣，更好用了。需要自定義協議的場景和需求也變少了。

如果要從微觀層面去對比優劣，至少你得告訴你這個自定義協議是啥？ TCP上的自定義協議，那可是多如繁星，我拿哪個去做對比呢？

TCP長連結是一直連著不斷開的。如果是TCP的話： 伺服器端不是很好擴充，考驗單臺伺服器的接入能力。伺服器叢集不是很好架設。 客戶端，處理socket連線的那個執行緒要負責幹各種事情，所有網路協議的邏輯集中在此，結構不太好搭。而http，結構就完全不同。

區別在於開發代價不同。http有大量現成架構，伺服器，資料庫，出了問題也不會全盤崩潰，除錯代價小。 tcp必須自定義協議，然後自己處理；自己實現伺服器，監聽埠；遇到問題，自己打造一系列除錯手段。自己動手造輪子，開發代價高了一個數量級。

最近正好在用http協議，是接手之前一個人做的，沒辦法程式碼重寫，基於socket自定義協議對於移動開發快速迭代不合適，除非是一些比較底層的需求。估計像微信這樣的也許會自定義協議，要不然頻寬負荷太高。但是具體我也不瞭解。

所以能用http的地方，就不要用tcp。不過有的東西必須用tcp，比如網遊，那是沒辦法的事情。

HTTP 協議的一個非常重要的優勢在於穿越防火牆。 如果客戶端到伺服器之間有安全裝置，那麼可能唯一開啟的埠就是TCP:80。

移動端的開發更是如此，你不想使用者整天抱怨說訪問不到你的伺服器吧。

這篇文章 介紹的很詳細

順便打個廣告， 七牛是國內golang做後端服務開發的先驅， 上傳 下載，資料處理介面全是走的是http協議

另外也可以混用，攜程的這個實踐很有參考意義

安卓很多框架都是基於http的，像 android-async-http, okhttp,AndroidAsync,volley ...等

綜上，建議使用http 協議，除非你有很特殊的需求