socket的心跳间隔和可用连接数的矛盾和平衡

我们都知道http（https）需要处理超时的情况。超时只所以产生是因为网络（特别是移动网络）的复杂性，导致数据包不能到达目的端并返回给发送端合规的数据。当然像AFNetworking在发送请求时发现手机端无网络连接立即返回错误处理，不需要等待超时再返回错误。局域网络的丢包率几乎接近为0，广域网的丢包率要大的多，手机网络的丢包率更大。
同理socket一般靠select直接侦听到连接错误，从而返回错误或自己组件自己重新连接，但是也有不能及时收不到select连接错误，靠心跳来识别连接不可用，从而关闭连接，释放端口号。一般心跳和定时器轮询来识别出不可用的连接。后面描述的端口号，连接数，文件描述符都是电脑的同一资源，只是叫法不同。
心跳只是为了处理收不到链接异常的情况。若后台在发送消息时收到连接异常，就立即关闭连接并删除连接。若app 发送消息时收到异常就断开连接重新连接，连接成功后再发送消息。
websocet连接由app维护，每29秒app发送一次心跳消息，后台收到后给予响应消息，app收到后台的响应消息判定为websocet连接可用，若59秒之内没有收到后台的消息（包括心跳和后台推送的消息），app就判定为连接不可用，断开连接，app网络可用，重新创建连接。
现在是后台10分钟主动向app发送一次心跳，若下次发送心跳前若没有发送成功的标志就判断为连接不可用，断开连接。这样每20分钟才把无用连接断开和删除，并且是后台主动发起，给后台增加了很大的压力。
一台电脑的文件描述符（连接时用到）65535个，就是一台电脑的理论TCP最大连接数65535个（因为一台电脑只有65535个端口），再除去系统保留文件描述符号，一般10000个以下创建socket产生冲突的概率不大，当达到2万以上冲突的概率超大。
所以要及时维护连接，把无用的连接关闭并删除了，这就需要维护周期不能太长，20分钟显然太长，容易把连接数占完。但是维护周期太短，app太费电和流量。linux和window的默认套接字是最大90秒超时（有微软mfc接口文档说明），苹果系统的套接字最大超时时间是大约75秒（实际测试值，不是官方文档的说明，仅作为参考）。
手机网络的IP是运营商动态分配的，若超过30分钟（国内移动运营商配置的大都是30分钟，也有配置的是15分钟）没有任何流量，运营商就会收回ip，用户再次使用时会重新分配给手机IP。所以心跳时间最好要超过15分钟。
要兼顾套接字（文件描述符号，连接数）的及时释放（处理周期越短释放越及时）；还要兼顾app流量和省电（心跳越短越费电和费流量）；要考虑数据处理和失败冗余处理，最好一个维护连接周期发送两次心跳。
后台的轮询周期最好能动态配置，在用户量很大时和客户端配置缩减轮询周期，当前期用户量很小时增大轮询周期，来达到降低服务器压力，降低app的能耗和节省流量。
端口冲突问题:一台电脑,端口号的理论范围是从0到65535，公共端口是0-1023 ，注册端口是1024-49152，还有随机动态端口是49152-65535，共是65536个端口。我在做push service时，华为赛门铁克老板说他们把他们的防火墙路由器电脑芯片可以把端口号个数从1万个增加到2万个是很大的成功。一台服务器，当端口号被申请超过1万个以后，再申请端口号后就经常遇到端口冲突，做得好的能做到达到2万以上才出现经常端口冲突。实际很难做到，把所有端口好都利用起来。解决方案是采用动态虚拟端口的方式（我不知道怎么实现，这个是服务器方面的问题，理论上和我们客户端无关），其次是增加长连接服务器集群。
如果一端的Socket被关闭（或主动关闭，或因为异常退出而 引起的关闭），另一端仍发送数据，发送的第一个数据包引发该异常(Connect reset by peer)。

Receive failed with error "Connection reset by peer

Socket默认连接60秒，60秒之内没有进行心跳交互，即读写数据，就会自动关闭连接。所以要保证60秒有一次心跳或收发消息。最好29秒发送一次心跳消息，59若秒收不到没有更新消息就干掉连接，重新连接。