项目网络层存在问题的研究学习
##背景
在对龙建项目的业务逻辑和代码逻辑梳理过程中，碰到了大大小小的问题一箩筐，网络层尤甚，造成了很严重的界面卡顿和数据重复操作等等问题；在此我们重点分析下面两个问题：
*post和get请求乱用，造成的安全问题和代码阅读障碍，我们该怎么规避？
*大量请求循环并发开启，造成逻辑混乱和性能浪费，我们该怎么优化？
当我们捋顺这几个问题之后，会改善当前同步时大量并发请求造成的界面卡顿和崩溃问题。 同时对iOS的网络框架机制也会有更深层次的理解，方便我们更好地与服务端进行有效交互。
##Method梳理
对于第一个问题我们有必要做一下拓展一下Method类型相关知识， 我们根据版本和参数的处理上进行分类。
*版本：
1. HTTP1.0定义了三种请求方法： GET、POST 和 HEAD方法。
2. HTTP1.1新增了五种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
3. HTTP/2.0
*参数处理：
1. "GET", @"HEAD", @"DELETE"。
2. 其它
我们常用的get和post两种Method有什么区别？
###图片
众所周知，get和post最大的区别在于可见性：get的参数直接拼接在url之后，而post的参数则是放在httpbody里，安全性更高；因此，类似用户登录、注册、支付等安全性要求高的场景中，尽量使用post提交数据。
####GET和POST还有一个重大区别
#####简单的说：
GET产生一个TCP数据包；POST产生两个TCP数据包。
#####长的说：
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。
近来，越来越多的后端开发提供接口时，会使用第三方框架，而这些框架是默认同时支持GET和POST请求的，如果后台开发人员不注意，没有对接口做method限制的话：
###图片
会造成以上get和post错用的情况，引发不必要的麻烦，这种失误看起来就很低级。
因此：作为app开发者，应该严格按照pai文档执行，并随时review相关代码
##并发请求乱像
并发请求听起来有点高大上，但实际很low,给大家看一张相关代码图：
###图片
是不是感觉哭笑不得，原来是这种情况啊。。。遍历数组-》发送请求
这种情况应该是不符合api设计规范的，正确的姿势应该是：参数以数组形式传递给服务端。
有人会问：数据量太大怎么办？ 。。。 分页呀！
这时候既然已经入坑了，不能奢望后台哥们儿该逻辑跟你联调了，只能自力更生。
我们从网络请求本身分析得出了三个优化的可能性(仅供参考)：
*session单例
*NSOperationQueue 多线程行不行
*HTTPMaximumConnectionsPerHost：什么玩意？
###session单例
单例我们太清楚了，那么session单例有什么好处嘞？
*性能优化 ：首先我们来看一段官方解释：
```
The session object keeps a strong reference to
the delegate until your app exits or explicitly
invalidates the session. If you do not
invalidate the session, your app leaks memory
until it exits
```
这句话对于英语过四级的我自然不是问题，给大家翻译一哈:
session对象保持对委托的强引用，直到应用程序退出或显式地使session无效。如果你没有使session失效，你的应用程序会泄露内存直到它退出。 来张图佐证一下：
###图片
重要事情看三遍：内存泄露！、内存泄露！、内存泄露！
既然`session`会造成内存泄露，那么当然要单例它，越少创建`session`对象，越少内存泄露。
*网络层协议
我们也都知道，HTTP协议是基于TCP协议的。所以在每次的HTTP请求之前，客户端和服务器端，都先需要经过TCP连接的三次握手，即每次请求之前，网络的数据都已经在客户端和服务器端之间来回了三次。那么，为了让我们的请求更快，避免每次都产生一个TCP三次握手，成了一个优化的选项。于是在`HTTP 1.1`中，出现了`Connection: keep-alive`这个选项。这个优化选项，可以使得客户端和服务器端复用一个TCP连接，从而减小每次的网络请求时间。
**重点来了**，现在都`HTTP2.0`了，看不到`Connection: keep-alive`这个选项就该落伍了， 现在的网络请求中这个选项默认是打开的。共享的`Session`将会复用TCP的连接，而每次都新建`Session`的操作将导致每次的网络请求都开启一个TCP的三次握手。
###图片
mRequestTest 没有共享session的10次并发请求所用总时间
shareSessionRequestTest共享session的10次并发请求所用总时间
对比总是残酷的，一个平均400ms， 一个平均90ms 。 还用考虑吗？
###NSOperationQueue 行不行得通？
###图片
我们知道NSURLSession使用NSOperationQueue管理task的，而默认的delegateQueue的maxConcurrentOperationCount是多少呢？
###图片
搞了半天是个`串行队列`，我们考虑，用多个线程同时开启task会有什么效果呢？
多线程同时开启task，我们需要一个参照点，来测试单线程和多线程的效果，最有效的点就是task开启时间的统计，那么task的开启时间从哪取出来呢？
###图片
从图中我们可以看到，Task开启时间对应的key:`fetchStart`， 下一步就是找出`NSURLSessionTaskTransactionMetrics`类
我们可以从`NSURLSessionTaskDelegate`找到它
###图片
事实上,`NSURLSessionTask`是和`NSURLSession`共用一个代理的，当我们需要查看`NSURLSessionTaskDelegate`方法时，在`NSURLSessionDelegate`里实现该方法即可。
有了目标，设置：`maxConcurrentOperationCount` 1与5 进行对比参照 结果如下:
###图片
得出结论：task在队列中的开启操作，只是一瞬间的事儿，并不是我们想象中的等到`NSURLReponse`之后才进行下一个task`operation`，这也是为什么系统的`shareSession`和 AFN没有提供修改线程数的原因
所以：**多线程结论不可行**
*HTTPMaximumConnectionsPerHost
the maximum number of simultanous persistent
connections per host
每个主机的最大同时持久连接数，在iOS上最大链接数是4
当服务端有多个ip时，用得到它，但当我们尝试对其修改操作时,结果是失败， 我们猜想，该属性暂时是被弃置的。
##参考
*[https://www.jianshu.com/p/94d214129d4d](https://www.jianshu.com/p/94d214129d4d)
*[http://www.cocoachina.com/ios/20160202/15211.html](http://www.cocoachina.com/ios/20160202/15211.html)
*[https://www.jianshu.com/p/471a44e8bda5](https://www.jianshu.com/p/471a44e8bda5)
网友评论