长连接

TCP长连接 所谓长连接，指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。短连接是指通讯双方有数据交互时，就建立一个连接，数据发送完成后，则断开此连接，即每次连接只完成一项业务的发送。

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，下次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接，如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

总之，长连接和短连接的选择要视情况而定。

手机推送服务的原理很简单，就是通过建立一条手机与服务器的连接链路，当有消息需要发送到手机时，通过此链路发送即可。 推送服务的使用流程虽然略有差别但是大致都和IOS的APNS相似 　

1、首先是应用程序注册消息推送。 　

2、 IOS跟APNS Server要deviceToken。应用程序接受deviceToken。 　

3、应用程序将deviceToken发送给PUSH服务端程序。 　

4、 服务端程序向APNS服务发送消息。

5、APNS服务将消息发送给iPhone应用程序Push sevrice方案评价标准

推送方案的公认评价采取4s标准：1.Safe(安全) 2. Stable（稳定） 3.Save（省电省流量省成本） 4.Slim（体积小）

1.Safe (安全)

推送方案应支持透传及各种加密方案，保障信息传递安全。 　

推送方案的ID系统应该独立于已有的网站或服务的ID系统，这样保障用户在不同手机上登录后的信息投递准确性，避免因为取消绑定事件失败因网络传输而造成的信息误投送。

2. Stable（稳定）

稳定包括两个部分一个是服务器端的稳定性，一个是手机端的稳定性。 服务端稳定性，因为使用长连接方案，对服务器的开销和要求很大，推送方案对服务器开发要求很高，海量线程连接下的服务器稳定性是非常具有挑战性的。一般的评判标准包括：

- 同时在线时峰值 （一般按照百万并发连接时服务器稳定性评测）

- 高并发时消息平均延迟时间（一般按照1分钟处理1百万条信息评测）

- 服务稳定性 （一般要求全年99.9%以上可用，有备份，有负载均衡等）

鉴于服务器稳定的开发难度很大，小团队不建议自己开发，建议使用稳定的第三方推送方案，如个推，蝴蝶等。

手机端的稳定性，主要是因为中国的复杂网络状况及手机型号适配情况造成手机长时间稳定联网较困难，所以稳定性非常重要，一般的评判标准包括：

- 每日联网23.5小时以上用户比例 （表征联网稳定性）

- 消息发送后9小时内收到率 （表征到达率）

一般来说，推送方案要做网络的分运营商，分省，分机型适配，自己开发工作量较大

3.Save（节省）

省电应注意CPU休眠，一般用服务缩短待机时间百分比评判。省流量应注意协议的修改和冗余数据包的处理，一般用空载待机月流量评判。省成本应考虑单服务器承载同时连接数，可承载同时连接数越多成本越低，业内 顶尖水平为个推的单服务器50万连接

4.Slim（体积小）

推送服务应该体积尽量小，不影响主程序的大小和复杂度，一般以小于300K为宜。

标准协议TCP长连接与短连接的区别第三次握手示意图

1. TCP连接

　　当网络通信时采用TCP协议时，在真正的读写操作之前，server与client之间必须建立一个连接，当读写操作完成后，双方不再需要这个连接时它们可以释放这个连接，连接的建立是需要三次握手的，而释放则需要4次握手，所以说每个连接的建立都是需要资源消耗和时间消耗的第四次握手示意图　　

　　2. TCP短连接

　　我们模拟一下TCP短连接的情况，client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次读写就完成了，这时候双方任何一个都可以发起close操作，不过一般都是client先发起close操作。为什么呢，一般的server不会回复完client后立即关闭连接的，当然不排除有特殊的情况。从上面的描述看，短连接一般只会在client/server间传递一次读写操作

　　短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段

　　3.TCP长连接

　　接下来我们再模拟一下长连接的情况，client向server发起连接，server接受client连接，双方建立连接。Client与server完成一次读写之后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。

　　首先说一下TCP/IP详解上讲到的TCP保活功能，保活功能主要为服务器应用提供，服务器应用希望知道客户主机是否崩溃，从而可以代表客户使用资源。如果客户已经消失，使得服务器上保留一个半开放的连接，而服务器又在等待来自客户端的数据，则服务器将应远等待客户端的数据，保活功能就是试图在服务器端检测到这种半开放的连接。

　　如果一个给定的连接在两小时内没有任何的动作，则服务器就向客户发一个探测报文段，客户主机必须处于以下4个状态之一：

　　客户主机依然正常运行，并从服务器可达。客户的TCP响应正常，而服务器也知道对方是正常的，服务器在两小时后将保活定时器复位。

　　客户主机已经崩溃，并且关闭或者正在重新启动。在任何一种情况下，客户的TCP都没有响应。服务端将不能收到对探测的响应，并在75秒后超时。服务器总共发送10个这样的探测 ，每个间隔75秒。如果服务器没有收到一个响应，它就认为客户主机已经关闭并终止连接。

　　客户主机崩溃并已经重新启动。服务器将收到一个对其保活探测的响应，这个响应是一个复位，使得服务器终止这个连接。

　　客户机正常运行，但是服务器不可达，这种情况与2类似，TCP能发现的就是没有收到探查的响应。

　　从上面可以看出，TCP保活功能主要为探测长连接的存活状况，不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。

　　在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致server端服务受损;如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。

　　长连接和短连接的产生在于client和server采取的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择。