選擇http協議仍是tcp協議

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 協議，除非你有很特殊的需求