(1) app后端要慎重考虑网络传输的流量，主要是api设计，图片处理上
现阶段，手机上网的资费还是要按照流量算的，一般的３G用户，每个月的流量几百Ｍ，４Ｇ用户，每个月的流量也就几Ｇ。
如果不考虑网络传输的流量，一张图片就占了几百Ｋ，流量用得飞快的。
api的返回结果一般是json格式，使用json格式的一个重要原因是，同样的内容，用json格式更省流量。
app下载的图片也一样，默认是让app下载经过压缩处理的图片（一般是几十K以下），当用户需要查看原图时，才让用户下载原图。
(2) 移动手机弱网络环境，稳定性，到达率
移动手机因为移动的特性，特别是在高速移动的时候，3G信号是时有时无。
因此，后端发给app的信息，是无法保证一定到达app的，极有可能当发送的时候app是有３Ｇ信号的，但发送的过程中，３Ｇ信号就没了，这样消息就没了。
针对这种情况，需要做app端的信号的确认。
例如，推送系统中，app要保存接收到的消息编号。
服务端发送了编号为1,2,3这３条推送给app，app端记录下来的消息编号只有１，２,那就意味着编号为３的消息丢失了，但是推送服务器是认为编号为３的消息已经推送成功的。
app每隔一段时间，询问一下服务器已经发送了哪几条消息，通过比对消息编号，如果有遗漏的，那就要求服务器再发送一次。
通过这种策略，就能在很大程度上保证信息的完整性。
(3) 手机电量有限
普通的手机，充满电池能用一天左右，如果是在app端做大量的网络请求和运算，那么手机的电是消耗得很快的。
但是，如果所有的运算都集中在服务端，也会增加了服务器的负担。
这两者之间的平衡，需要在项目中仔细斟酌
-------
一、Web服务器
Web服务器可以解析(handles)HTTP协议。当Web服务器接收到一个HTTP请求(request)，会返回一个HTTP响应(response)，例如送回一个HTML页面。为了处理一个请求(request)，Web服务器可以响应(response)一个静态页面或图片，进行页面跳转(redirect)，或者把动态响应(dynamic response)的产生委托(delegate)给一些其它的程序例如CGI脚本，JSP(JavaServer Pages)脚本，servlets，ASP(Active Server Pages)脚本，服务器端(server-side)JavaScript，或者一些其它的服务器端(server-side)技术。无论它们(译者注：脚本)的目的如何，这些服务器端(server-side)的程序通常产生一个HTML的响应(response)来让浏览器可以浏览。
要知道，Web服务器的代理模型(delegation model)非常简单。当一个请求(request)被送到Web服务器里来时，它只单纯的把请求(request)传递给可以很好的处理请求(request)的程序(译者注：服务器端脚本)。Web服务器仅仅提供一个可以执行服务器端(server-side)程序和返回(程序所产生的)响应(response)的环境，而不会超出职能范围。服务器端(server-side)程序通常具有事务处理(transaction processing)，数据库连接(database connectivity)和消息(messaging)等功能。
虽然Web服务器不支持事务处理或数据库连接池，但它可以配置(employ)各种策略(strategies)来实现容错性(fault tolerance)和可扩展性(scalability)，例如负载平衡(load balancing)，缓冲(caching)。集群特征(clustering—features)经常被误认为仅仅是应用程序服务器专有的特征。
小鸟云虚拟主机，架设于纯SSD架构的高性能云服务器之上，具有高在线率、高安全性、高稳定性等多项优势。基于自建的核心骨干网络，能有效保证高品质网络环境和充足的带宽资源，适用于对网站运行质量有高要求的用户使用。
二、APP服务器
根据我们的定义，作为应用程序服务器，它通过各种协议，可以包括HTTP，把商业逻辑暴露给(expose)客户端应用程序。Web服务器主要是处理向浏览器发送HTML以供浏览，而应用程序服务器提供访问商业逻辑的途径以供客户端应用程序使用。应用程序使用此商业逻辑就象你调用对象的一个方法(或过程语言中的一个函数)一样。
应用程序服务器的客户端(包含有图形用户界面(GUI)的)可能会运行在一台PC、一个Web服务器或者甚至是其它的应用程序服务器上。在应用程序服务器与其客户端之间来回穿梭(traveling)的信息不仅仅局限于简单的显示标记。相反，这种信息就是程序逻辑(program logic)。 正是由于这种逻辑取得了(takes)数据和方法调用(calls)的形式而不是静态HTML，所以客户端才可以随心所欲的使用这种被暴露的商业逻辑。
在大多数情形下，应用程序服务器是通过组件(component)的应用程序接口(API)把商业逻辑暴露(expose)(给客户端应用程序)的，例如基于J2EE(Java 2 Platform, Enterprise Edition)应用程序服务器的EJB(Enterprise JavaBean)组件模型。此外，应用程序服务器可以管理自己的资源，例如看大门的工作(gate-keeping duties)包括安全(security)，事务处理(transaction processing)，资源池(resource pooling)， 和消息(messaging)。就象Web服务器一样，应用程序服务器配置了多种可扩展(scalability)和容错(fault tolerance)技术。
如今，WEB服务器也可以通过传送XML有效载荷(payload)给服务器，具有处理数据和响应(response)的能力，APP服务器服务器在一定程度上也包含有WEB服务器功能
http协议（识别数据内容）与webSocket协议
同：建立在TCP之上，同http一样通过TCP来传输数据
不同：
HTTP协议为单向协议，即浏览器只能向服务器请求资源，服务器才能将数据传送给浏览器，而服务器不能主动向浏览器传递数据。分为长连接和短连接，短连接是每次http请求时都需要三次握手才能发送自己的请求，每个request对应一个response；长连接是短时间内保持连接，保持TCP不断开，指的是TCP连接。
WebSocket解决客户端发起多个http请求到服务器资源浏览器必须要经过长时间的轮询问题。
一种双向通信协议，在建立连接后，WebSocket服务器和Browser/UA都能主动的向对方发送或接收数据，就像Socket一样，不同的是WebSocket是一种建立在Web基础上的一种简单模拟Socket的协议；
WebSocket需要通过握手连接，类似于TCP它也需要客户端和服务器端进行握手连接，连接成功后才能相互通信。
WebSocket在建立握手连接时，数据是通过http协议传输的，“GET/chat HTTP/1.1”，这里面用到的只是http协议一些简单的字段。但是在建立连接之后，真正的数据传输阶段是不需要http协议参与的。
TCP/IP协议（用来传输数据）
socket是对TCP/IP协议的封装，本身并不是协议，而是一个调用接口(API)，通过Socket，我们才能使用TCP/IP。
四层，分别为应用层（Telnet、FTP和Email等）、运输层（TCP、UDP）、网络层（IP、ICMP、IGMP等）和链路层（设备驱动程序）
三次握手完毕后，客户端与服务器才正式开始传送数据
四次挥手后断开连接
套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认
TCP：面向连接，通过三次握手建立连接，通讯完成时要拆除连接，只能端到端传输
UDP：无连接，可实现广播发送
TCP/IP通信数据流
下面是我们访问一个网页，各种协议在里面起的作用