移动网络应用开发中，使用 HTTP 协议比起使用 socket 实现基于 TCP 的自定义协议有哪些优势？

以下汇总的是知乎上一些网友的回家，用以记录

=========================================

HTTP 是应用层协议，TCP 是传输层协议（位于应用层之下），放在一起类比并不合适。
不过猜测楼主是想对比 “标准 HTTP 协议” 还是 “自定义的协议（基于 TCP Socket）” 。

一般来说，移动应用推荐使用 HTTP 协议，有很多优点：

1. HTTP 发展成熟
   HTTP 几乎已经快成为一种通用的 Web 标准，Web Services、REST、Open API、OAuth 等等都是基于 HTTP 协议的。它已经不仅仅是 Hyper Text 的传输标准了，几乎所有数据的传输（多媒体、XML、JSON）都可以采用 HTTP。
2. 后台复用
   因为很多应用，除了有移动端，还有Web端，甚至桌面端。
   Web 版中前后台交互，无论是页面请求还是 AJAX 请求，都是采用标准 HTTP 协议。那么其他的客户端没有理由重新设计一套协议。
3. HTML 5 应用
   现在不少移动产品都采用或者半采用 HTML 5 技术，那么和服务器的交互又回归到 AJAX 上。不用说，还是离不开 HTTP。

但是也有一些局限性，比如以下场景就不适合 HTTP 协议：

1. 实时数据推送
   除了 iOS 开发提供有标准的 Apple 消息推送中心，其他移动产品可能还是要采用 Socket 长连接才能保证实时通讯。
   比较常见的有很多即时通讯软件采用的 XMPP 协议。
2. 流媒体
   适用于音频播放、视频播放、语音会议等等，一般可能采用 RTMP 协议。

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

再补充一下。
TCP长链接是一直连着不断开的。如果是TCP的话：
服务器端不是很好扩充，考验单台服务器的接入能力。服务器集群不是很好架设。
客户端，处理socket连接的那个线程要负责干各种事情，所有网络协议的逻辑集中在此，结构不太好搭。而http，结构就完全不同。
－－－－－－－－
区别在于开发代价不同。http有大量现成架构，服务器，数据库，出了问题也不会全盘崩溃，调试代价小。
tcp必须自定义协议，然后自己处理；自己实现服务器，监听端口；遇到问题，自己打造一系列调试手段。自己动手造轮子，开发代价高了一个数量级。
________________
所以能用http的地方，就不要用tcp。不过有的东西必须用tcp，比如网游，那是没办法的事情。

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

作者：天光
链接：https://www.zhihu.com/question/20406436/answer/28856924
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

Http 是 TCP的上层协议，Http 是基于 TCP的，所以你用了HTTP，等同与你也在用TCP

所以，拿Http和TCP做优劣比较是一个不存在的问题。

当然，这问题提的很好，问的是相较基于tcp的自定义协议。

其实事实上，从宏观层面，已经自己回答了这个问题了。

为啥要自定义协议呢？很简单啊，http协议满足不了需求只好自定义协议啊。
也就是说，自定义协议可以满足很多http协议满足不了的需求啊。
那什么需求是http协议满足不了的呢？
这也很简单啊，可以查一下http协议的定义去看看它提供了什么样的包装和定义，落在它之外的就是满足不了的啊，要真的细说，那真是多了去了，比如：

例如：http是单工阻塞性质的协议，如果你需要一个全双工，无阻塞的双向传输，那http就满足不了

例如：http定义提供了很多种的请求方法，从get到post不一一列举了，但是你需要的请求应答模式和它定义的种种没有任何一种能够实现你需要的请求应答模式，你就需要自定义协议啊

例如：http定义自己的包头，你要是觉得传输效率极其重要，这样的包头太臃肿，你也需要自定义协议啊

要是http都能完全满足你的需求，那为啥要自定义协议呢？一个成熟的协议拿来就用明显是很好的选择啊。

现在REST一出，一改过去SOAP的复杂臃肿，HTTP协议本身一直也在扩充，因此适用的范围更广，更好用了。需要自定义协议的场景和需求也变少了。