1. 多路TCP的支持。这个多路TCP跟多路复用有没有关系目前我还不清楚，根据文档上描述的，应该就是一个TCP链路可以选择多条网络通道（或者说多个接口）进行传输，这样也就会产生多个子流(subflow)，类似分片传输，只是每一片放到了不同的通道上。具体的内容可以看看这个：MPTCP的介绍
这里的网络通道有两种：
第一类网络-功耗较低、代价较小的（流量不计费），如wifi, 以太网；
第二类网络-功耗较高、代价较大的（流量要计费），如3g,LTE(4G应该也属于LTE)。
NSURLSessionMultipathServiceTypeNone = 0, 默认情况，不使用多路传输，这种情况下要么通过wifi，要么通过4g传输
NSURLSessionMultipathServiceTypeHandover = 1, 当第一类网络不能充分使用时会使用第二类网络，也就是说只要wifi稳定，就不会开启4g，这么做主要是为了减少用户的流量消耗，如果wifi不稳定，就会尝试通过4g去传输， 这中间探测网络拥堵需要一定的时间，因此比较适合对稳定性要求较高而对延迟不那么敏感的场景。
NSURLSessionMultipathServiceTypeInteractive = 2, 会更积极的使用第二类网络，也就是说只要允许，就会同时开启wifi和4g。这种情况下以保证服务的低延迟为目的，两个通道一起使用，但是流量消耗大一些。
NSURLSessionMultipathServiceTypeAggregate = 3 ，最大化利用带宽，把wifi和4g的流量结合起来使用，各自传输一部分数据，再合成一起，以此获得最大的传输效率。不过很可惜，这种模式只能在开发者模式下使用。
2. 请求任务调度
这一次更新的api感觉大部分是针对后台请求进行的优化，比如:
earliestBeginDate ，请求最早的开始时间(仅对后台请求适用)
countOfBytesClientExpectsToSend 客户端期望发送的字节数(仅对后台请求适用)
countOfBytesClientExpectsToReceive 客服端期望接收的字节数(仅对后台请求适用)
新增一个代理方法,配合earliestBeginDate 使用，当请求被延迟调用时，会走这个方法，你可以选择撤销之前的请求并重新创建一个或者继续沿用之前的请求，又或者仅仅只是撤销请求(仅对后台请求适用)
- (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task
willBeginDelayedRequest:(NSURLRequest *)request
completionHandler:(void (^)(NSURLSessionDelayedRequestDisposition disposition, NSURLRequest * _Nullable newRequest))completionHandler
新增一个代理方法,配合earliestBeginDate 使用，当请求被延迟调用时，会走这个方法，你可以选择撤销之前的请求并重新创建一个或者继续沿用之前的请求，又或者仅仅只是撤销请求(仅对后台请求适用)
- (void)URLSession:(NSURLSession *)session task:(NSURLSessionTask *)task
willBeginDelayedRequest:(NSURLRequest *)request
completionHandler:(void (^)(NSURLSessionDelayedRequestDisposition disposition, NSURLRequest * _Nullable newRequest))completionHandler
我想大概是因为后台请求是由系统调度的，所以这些是让系统更清楚的了解该什么时候请求，以何种方式调度吧。
不过，也有一些不针对后台请求的，比如:
waitsForConnectivity 当检测到无网络时不会立刻发送请求，而是等网络恢复时才发送(对后台请求不适用)
新增代理方法配合waitsForConnectivity使用，当由于网络不通导致请求等待时，会调用这个方法，每个请求只会调一次，且后台请求不会调用。
- (void)URLSession:(NSURLSession *)session taskIsWaitingForConnectivity:(NSURLSessionTask *)task
因为后台请求默认会等待网络连接通畅后才开始，所以也没有必要让开发者去干预了。
