一个app和后端的通信，遇到如题的情况，那是全部数据都通过websocket传输好，还是部分使用http传输好？
两个是不同的机制，保持长连接用ws，否则用http吧
websocket我觉得应该起到锦上添花的功能，比如说实时通知，没有发过来，用户体验受影响，但是系统不至于瘫痪。
而核心业务不应该依赖websocket，因为ws在复杂的网络上的可靠性一般。而且在一些很远古的浏览器（比如xp下的ie8）又根本不支持。
主要还是看业务内容，不同业务处理也是不一样的。一般使用长连接就可以了，不用再使用http。不过考虑到app的使用网络环境不是很稳定，如果长连接频繁的断线重连也是比较消耗性能。所以长连接的断线重连需要考虑下策略。
http服务架设比较容易，通过http获得数据也容易被窃取到（浏览器访问下就看到数据了），除非你加密客户端再解密，websocket服务架设麻烦点，发送的数据相对不那么容易窃取吧，需要抓包分析，根据项目实际需求合理安排协议就可以
ebSocket 可能进入某种半死不活的状态。这实际上也是原有网络世界的一些缺陷性设计。WebSocket 长连接虽然解决了服务器和客户端两边的问题，但坑爹的是网络应用除了服务器和客户端之外，另一个巨大的存在是中间的网络链路。一个 HTTP/WebSocket 连接往往要经过无数的路由，防火墙。你以为你的数据是在一个“连接”中发送的，实际上它要跨越千山万水，经过无数次转发，过滤，才能最终抵达终点。在这过程中，中间节点的处理方法很可能会让你意想不到。
WebSocket是HTML5开始提供的一种在单个 TCP 连接上进行全双工通讯的协议。
在WebSocket API中，浏览器和服务器只需要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。
浏览器通过 JavaScript 向服务器发出建立 WebSocket 连接的请求，连接建立以后，客户端和服务器端就可以通过 TCP 连接直接交换数据。
当你获取 Web Socket 连接后，你可以通过 send() 方法来向服务器发送数据，并通过 onmessage 事件来接收服务器返回的数据。
以下 API 用于创建 WebSocket 对象。
对于web的设计，有一个总的原则是平稳降级，不丧失可用性。
服务器能同时维持的socket有限，如果都使用websocket长连接服务器所能提供的服务对象数量就有限了，如果采用关闭websocket的策略维持连接总量那长连接也失去意义了。最终还是要看服务器提供的事啥服务
主页业务都使用http，http是主流，各个浏览器对他都有优化，而且现在有了http2，性能会更快。
websocket仅处理订阅类型的业务，即，websocket的任务就是处理http无法办到了订阅消息，举个例子，在聊天室这个业务中，websocket仅用于接收消息，而其他的业务比如发送消息，使用http。