理解URL Session概念
一个session里面的task行为受以下三点影响：
- session类型
- default session：和foundation的相关url下载方法行为类似，也是使用基于磁盘的cache和在用户的keychain中保存credential
- ephemeral session：所有的cache、credential等都保存在内存中，而不会在磁盘中存储任何数据，并且是和session绑定的，如果session被应用invalidate了，那么这些数据就会被自动抹除
- backgroud session：除了是在一个单独的进程中处理所有数据传输之外，其他的和default session类似
- task类型
- data task：使用NSData来发送和接收数据，并且可以通过delegate来接收一小块一小块的数据，或者用block来一次接收完全部数据
- download task：以文件的形式来接收数据，并且支持后台下载
- upload task：以文件的形式来发送数据，并且支持后台上传
- 创建task时应用是否在前台
Backgroud Transfer
- 前提
使用background session配置对象创建的session才能有后台传输的能力，并且session必需提供一个自定义的delegate - 限制
后台传输是在另一个单独的进程中进行，考虑到这点，并且考虑到重新启动应用进程是一个相对高代价的行为，所以有如下的一些限制：- session必须提供一个delegate来进行事件处理
- 只支持http和https协议，自定义的协议不行
- 重定向总是允许
- 只有来自文件的上传task被支持（因为来源如果是数据对象或流的话会在应用退出后导致上传失败）
- 如果是应用在后台的时候启动了后台传输，那么配置对象的discretionary属性会被视为true（意味着由系统基于当前状态来调度这个传输行为）
- 事件处理
- 后台传输请求credential或者传输已经完成时，应用当前不在运行状态
那么系统会自动把应用启动起来并后台运行，且UIApplicationDelegate对象的application:handleEventsForBackgroundURLSession:completionHandler: 方法会被调用；应用应该把completion handler保存起来，并利用回调提供的session identifier创建一个后台配置对象，然后用这个后台配置对象再创建一个seesion，新创建的session会自动和这个正在进行的后台传输关联起来；后续当这个session的最后一个后台下载任务完成时，URLSessionDidFinishEventsForBackgroundURLSession: 这个方法会被调用，在回调中，再调用回之前存储的completion handler即可 - app被用户重启动后的处理
此时app应根据最后一个运行时还在执行的task的session identifier来重新生成后台配置对象，然后再使用后台配置对象创建新的session，这些新创建的session灰自动和正在进行中的后台传输关联起来（注意，session和session identifier是一对一的关系，不能有多个session对应同个session identifier的情况） - task完成时，应用已被挂起
会回调这个方法URLSession:downloadTask:didFinishDownloadingToURL:同样的，如果需要credential，那么会回调这个方法URLSession:task:didReceiveChallenge:completionHandler: 或这个方法URLSession:didReceiveChallenge:completionHandler:
- 后台传输请求credential或者传输已经完成时，应用当前不在运行状态
NSCopying行为
- 如果拷贝一个session或task，那么会得到相同的对象
- 如果拷贝一个配置对象，那么会得到一个新的拷贝，可以单独进行修改
- 创建一个session的时候，session会对参数输入的配置对象做一个深拷贝
注意点
- NSURLSession的回调可以使用block或delegate两种方式的任一种，但是不能同时使用；block方式的实质是系统提供了一个默认的delegate，然后通过这个delegate来调用我们的block
- iOS7的background session不支持data task
- 后台session的上传和下载task在网络出错的时候会自动重试
