项目网络层存在问题的研究学习

项目网络层存在问题的研究学习

##背景

在对龙建项目的业务逻辑和代码逻辑梳理过程中，碰到了大大小小的问题一箩筐，网络层尤甚，造成了很严重的界面卡顿和数据重复操作等等问题；在此我们重点分析下面两个问题：

*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)