本篇文章仅介绍本人在公司项目中使用GCDAsyncSocket建立socket连接中使用的一些方法和心得体会。对GCDAsyncSocket方法不熟悉的同学可以先查看GCDAsyncSocket API简介这篇文章。
初始化
initWithDelegate：delegateQueue：
初始化，设置委托和委托队列。
内部会在初始化时保存传入的委托对象及委托对垒，创建套接字队列，初始化socket4FD（本地IPV4Socket）、socket6FD（本地IPV6Socket）、socketUN（unix域的套接字）、socketUrl（unix域 服务端 url）、stateIndex（状态Index）、readQueue（读队列）、currentRead（当前读入数据包）、writeQueue（写队列）、currentWrite（当前写入数据包）、preBuffer（公用缓冲区）、alternateAddressDelay（连接备选服务端地址的延时 ，另一个IPV4或IPV6，默认0.3S）等参数。
初始化完成，开启连接（如果是服务端，就需要去bind端口，并且accept，等待客户端的连接。）
连接
connectToHost：onPort：withTimeout：error：
1.host及端口校验
2.代理队列校验、是否开始连接（kSocketStarted）、是否支持IPV4 IPV6、清空读写队列
3.标记Socket为开始连接（kSocketStarted）进行一下异步连接并开启连接超时设置
4.根据host port，去获取server地址信息（异步，DNS解析,NSData类型）。
5.创建server地址连接（耗时，异步，完成后回调）
根据第4步中地址创建socket（返回socket的文件描述符，int类型，scoket其实就是Int类型）
->Socket绑定本机地址（本项目无特定端口，此步骤在连接服务器步骤connect自动完成端口绑定）
->连接服务器
成功：关闭无用socket->添加‘已连接’连接状态（kConnected）->关闭连接超时设置->创建读写流及读写回调注册
->回调成功代理（socket:didConnectToHost:port:返回数据为根据socket的文件描述符获取的服务器IP及端口）
->本机socket设置相关参数->开启读写
失败：关闭当前socket并置空->清空读写队列->退出读写监听->标记Socket连接状态为0->回调断开代理（socketDidDisconnect:withError:，error不为空，且socket已开始连接）
PS：当然连接过程不仅上述过程（如：连接超时设置等）且具体步骤未详细描述，本处列出的为本项目连接过程或需引起注意过程。
注意：连接之前判断当前socket连接状态，避免重复连接。
- 个人疑点
断开就清空读写队列？？？
断开
disconnect
立即断开连接（同步）。所有挂起的读取或写入操作都将被丢弃。
_localAsyncSocket.delegate = nil;
[_localAsyncSocket disconnect];
_localAsyncSocket = nil;
读
readDataWithTimeout：tag：
- 个人思考
由于项目中长连接模块有心跳业务且心跳有返回值，所以通过设置超时时间来间接判断长连接通道通畅性。
值得一提的是我们通过日志发现项目中没有发生断包问题，却存在粘包现象。如<7c50 ...00041299 7c7c80 ... 30dd7c>。我们会将信息进行数据转换和一系列的算法最终拼接为以<7c>开头和结尾的data数据，所以上述信息实际为<7c50 ...00041299 7c>和<7c80 ... 30dd7c>两条数据。我们的处理方式为读入数据后通过<7c>进行数据切割，之后在通过规定的算法校验数据的完整性。个人感觉这增加了不必要的业务，理想中的应该是返回给我们时就是一条完整的数据，所以当看到readDataToData: withTimeout: tag:方法时眼前猛然一亮，这不正是我所期望的吗？我们可以通过设置<7c>为分隔符，进行数据的分割。然而使用时想起我们也是以<7c>开头，所以开头标识也可能作为单独的一条数据发送，通过测试后发现我们拿到的数据为<7c>、<50 ...00041299 7c>、<7c>、<80 ... 30dd7c>，果然将我们一条数据切割成了两份😂。所以在此建议服务器设置不同的开头和结尾标识，以方便客户端读取时做数据切割。
写
writeData: withTimeout: tag:
- 个人思考
GCDAsyncSocket的更强大功能之一是其排队的体系结构。这使您可以在方便时控制套接字，而不是在套接字告知您已准备就绪时对其进行控制。 ——引用至Reference_GCDAsyncSocket
虽然GCDAsyncSocket认为其读写排队的体系结构是一项很强大的功能之一，然而本人却并不这样认为，而且直接使用其读写队列还可能引起一系列的问题。例如IM类项目，必须要保证每条消息的成功发送，此时如果我们直接使用writeData: withTimeout: tag:方法，如果当前网络不佳导致socket断开（socketDidDisconnect：withError：），此时会清空未处理的读写队列，这样必然会导致消息的丢失。
个人总感觉GCDAsyncSocket开发者在架构中未考虑重连的情况。
连接判断
isDisconnected
GCDAsyncSocket内部判断是否标记连接状态为kSocketStarted：已标记，返回NO，表示未断开；未标记，返回YES，表示已断开。
项目中在开启连接（connectToHost：onPort：withTimeout：error：）之前调用此方法判断是否已开启连接，做容错处理。
不推荐外部使用。
isConnected
GCDAsyncSocket内部判断是否标记连接状态为kConnected：已标记，返回YES，表示已成功连接；未标记，返回NO，表示未成功连接。
由于项目要求实时性比较高，所以在发送之前会使用本方法做通道通畅性的判断：YES，发送；NO，不发送，根据业务做相应处理。
推荐外部使用，如项目中连接状态便是使用此方法判断。
tag
- 个人思考
通过上面读写方法的介绍可知在每个读写方法中都会传入一个tag值，传递的tag值会在代理中回传给使用者。因此可以在写入（writeData: withTimeout: tag:）时为消息标记不同的tag值，然后通过代理方法（socket: didWriteDataWithTag:）中返回的tag值来判断消息完成写入。
有时我们会写入请求类消息，服务器收到请求后会返回某些信息，虽然我们可以在写入完成的代理方法（socket: didWriteDataWithTag:）中设置读消息（readDataWithTimeout：tag）相同的tag值，但是依然不能通过tag值来判断读入的消息为写入消息的返回数据，因为此时服务器很可能会主动推一条与本次写入的请求类消息毫无关联的信息。
重连
我们在代理回调的断开（socketDidDisconnect：withError：）方法中判断本次断开返回的error值是否为空，如果不为空则表示本次断开为异常断开，开启一次延时重连。注意在主动断开连接的方法中要取消本次延时重连。
ping
我们在异常断开时会调用RealReachability进行ping操作，主要用于判断异常断开时是否由网路异常引起，以及网路可用时是否能够正常重连。
-
具体实现
设置hostForPing值为长连接地址，hostForCheck为"www.apple.com"，同时根据需求对RealReachability库进行了部分修改，使其在ping结果的block中返回该次ping是否成功，是否使用VPN,网络状况，ping地址。返回结果如下：1.是否有可用网络
否：返回ping失败，未使用VPN，网络状态，hostForPing
2.是否使用VPN
是：返回ping失败，使用VPN，网络状态，hostForPing
3.ping hostForPing
成功：返回ping成功，未使用VPN，网络状态，hostForPing
失败：进行4步骤
4.是否使用VPN
是：返回ping失败，使用VPN，网络状态，hostForCheck
5.ping hostForCheck（延时1S）
返回ping结果，未使用VPN，网络状态，hostForCheck
通过对比对应的ping结果及当时的网络状况对比可以得出该次断开是否有网络引起。
同时记录本次为第几次连接（从发起到连接成功算一次，在连接成功的方法中进行+1操作）及本次连接失败后重连次数（需在连接成功的方法中将该参数置0），通过两个参数值与网络状态对比，可以判断网路可用时是否能够正常重连。
通过日志分析得出：
1.长连接断开后，ping失败，无可用网络，占比80%左右。
2.长连接断开后，ping成功（后续重连成功），占比20%左右。
3.长连接断开后，ping成功，但是持续异常断开，偶现。
异常断开code：60，61。均为电信网络，安卓用户也存在类似情况，怀疑网络服务引起。
参考资料
感谢涂耀辉、Cooci_和谐学习_不急不躁两位大神，两位大神在其博客上有关于GCDAsyncSocket连接、读写、断开、粘包等功能详细的文档（下面的链接）介绍。
强烈建议各位同学在着手开发之前先认真阅读两位大神的文档，对GCDAsyncSocket有整体的了解，这样可以充分利用GCDAsyncSocket已有的功能，避免开发过程中遇到疑难的问题，同时也方便后续bug的修改。而本人也是这样做的。
iOS即时通讯进阶 - CocoaAsyncSocket源码解析(Connect篇)
iOS即时通讯进阶 - CocoaAsyncSocket源码解析(Connect篇终)
iOS即时通讯下数据粘包、断包处理实例（基于CocoaAsyncSocket）
iOS即时通讯进阶 - CocoaAsyncSocket源码解析(Read篇)
iOS即时通讯进阶 - CocoaAsyncSocket源码解析(Read篇终)
CocoaAsyncSocket源码分析---Write
CocoaAsyncSocket源码解析---终
CocoaAsyncSocket源码注释（2017）
网友评论