公司产品使用自己的私有协议实现socket通信，但是连接socket的时候会概率性的出现连接不上socket的情况，需要大概一分钟才能连接上socket。查了很久都找不到原因。google了一下https://stackoverflow.com/questions/36861373/socket-closed-by-remote-peer-gcdasyncsocket，
http://blog.csdn.net/smking/article/details/7373787
服务器出现这个问题有2个原因：
1.没有定时发送心跳包
2.有2个相同的socket向服务器发起连接
所有，我基本锁定是心跳包的问题，后来在连接成功后立马发了一个心跳（有一个定时器20s发一次心跳），感觉连不上的情况基本解决了，但是测试的时候还是出现了一次，虽然情况比之前好多了，很少再出现连接不上的情况了，,但是偶尔还是会出现这个问题，这个问题还是没有解决，只是出现的机会貌似少一些了（好吧，可能是我的错觉）。
有几个地方解释不通：
1.为什么连接成功后立马发一次心跳，情况会好一些（按道理来说就算一开始没有发20s后也发了）
2.为什么一直保持心跳（20s一次），会在大概一分钟后才成功进入直播间
3.为什么成功的代理和失败的代理都调用了
首先，服务器那边，超时时间是61s。所以会出现连接1分钟左右重新连接socket。我打断点也是这样的，先进socket连接成功的代理，大概1分钟之后，进入socket连接失败的代理，我们在里面进行重连，然后里面就能连接成功了。
所以，大概1分钟应该是服务器超时后的重连导致的，但是重连的时候基本立马就连接上socket服务器了
确实连接成功了，从后台那边已经得到确认了
服务器61s后就会超时，这时会销毁socket的
为什么每次都是走到重连的时候，才能成功连接上服务器呢？
因为使用的私有的协议，解析的时候需要按照数据包的长度来解析，但是我在还没有和服务器完成秘钥交换的时候，就发了一个请求过去，这个时候的包是没有使用秘钥加密的，但是服务器却按照加密的数据解析，导致每次过来的数据全部错位的，所有没法和后台通信，直到服务器主动断开，把之前的socket栈中的数据全部释放。重新连接的时候，已经在之前拿到服务器派发的秘钥了，所有直接就可以连接上了
其实已经排查出是心跳包的问题了，但是关键是我们确实有发心跳包，这里有一个非常重要的问题：我们的心跳包压根就没有起作用，服务器认为是垃圾数据，因为通信都经过加密的，包括心跳包也是
