一般来说，移动应用推荐使用 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 协议，除非你有很特殊的需求
我们都知道HTTPS能够加密信息，以免敏感信息被第三方获取。所以很多银行网站或电子邮箱等等安全级别较高的服务都会采用HTTPS协议。
HTTPS简介
HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。具体是如何进行加密，解密，验证的，且看下图。
1. 客户端发起HTTPS请求
这个没什么好说的，就是用户在浏览器里输入一个https网址，然后连接到server的443端口。
2. 服务端的配置
采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面(startssl就是个不错的选择，有1年的免费服务)。这套证书其实就是一对公钥和私钥。如果对公钥和私钥不太理解，可以想象成一把钥匙和一个锁头，只是全世界只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
3. 传送证书
这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。
4. 客户端解析证书
这部分工作是有客户端的TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值。然后用证书对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。
5. 传送加密信息
这部分传送的是用证书加密后的随机值，目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
6. 服务段解密信息
服务端用私钥解密后，得到了客户端传过来的随机值(私钥)，然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。
7. 传输加密后的信息
这部分信息是服务段用私钥加密后的信息，可以在客户端被还原
8. 客户端解密信息
客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。
作者：朱祁林 出处：http://zhuqil.cnblogs.com 本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
