AFNetworking-源码解析

最新推荐文章于 2024-02-20 16:49:06 发布

Focus_Now

最新推荐文章于 2024-02-20 16:49:06 发布

阅读量6.3k

点赞数

分类专栏： IOS 文章标签： AFNetworking IOS

IOS 专栏收录该内容

45 篇文章 0 订阅

订阅专栏

最近看AFNetworking2的源码，学习这个知名网络框架的实现，顺便梳理写下文章。AFNetworking2的大体架构和思路在这篇文章已经说得挺清楚了，就不再赘述了，只说说实现的细节。AFNetworking的代码还在不断更新中，我看的是AFNetworking2.3.1。

本篇先看看AFURLConnectionOperation，AFURLConnectionOperation继承自NSOperation，是一个封装好的任务单元，在这里构建了NSURLConnection，作为NSURLConnection的delegate处理请求回调，做好状态切换，线程管理，可以说是AFNetworking最核心的类，下面分几部分说下看源码时注意的点，最后放上代码的注释。

0.Tricks

AFNetworking代码中有一些常用技巧，先说明一下。

A.clang warning

 
         #pragma clang diagnostic push 
        
         #pragma clang diagnostic ignored "-Wgnu" 
        
         //code 
        
         #pragma clang diagnostic pop

表示在这个区间里忽略一些特定的clang的编译警告，因为AFNetworking作为一个库被其他项目引用，所以不能全局忽略clang的一些警告，只能在有需要的时候局部这样做，作者喜欢用?:符号，所以经常见忽略-Wgnu警告的写法，详见这里。

B.dispatch_once

为保证线程安全，所有单例都用dispatch_once生成，保证只执行一次，这也是iOS开发常用的技巧。例如：

 
         static 
         dispatch_queue_t url_request_operation_completion_queue() { 
        
         static 
         dispatch_queue_t af_url_request_operation_completion_queue; 
        
         static 
         dispatch_once_t onceToken; 
        
         dispatch_once(&onceToken, ^{ 
        
         af_url_request_operation_completion_queue = dispatch_queue_create( 
         "com.alamofire.networking.operation.queue" 
         ,   DISPATCH_QUEUE_CONCURRENT ); 
        
         }); 
        
         return 
         af_url_request_operation_completion_queue; 
        
         }

C.weak & strong self

常看到一个block要使用self，会处理成在外部声明一个weak变量指向self，在block里又声明一个strong变量指向weakSelf：

 
         __weak __typeof( 
         self 
         )weakSelf =  
         self 
         ; 
        
         self 
         .backgroundTaskIdentifier = [application beginBackgroundTaskWithExpirationHandler:^{ 
        
         __strong __typeof(weakSelf)strongSelf = weakSelf; 
        
         }];

weakSelf是为了block不持有self，避免循环引用，而再声明一个strongSelf是因为一旦进入block执行，就不允许self在这个执行过程中释放。block执行完后这个strongSelf会自动释放，没有循环引用问题。

1.线程

先来看看NSURLConnection发送请求时的线程情况，NSURLConnection是被设计成异步发送的，调用了start方法后，NSURLConnection会新建一些线程用底层的CFSocket去发送和接收请求，在发送和接收的一些事件发生后通知原来线程的Runloop去回调事件。

NSURLConnection的同步方法sendSynchronousRequest方法也是基于异步的，同样要在其他线程去处理请求的发送和接收，只是同步方法会手动block住线程，发送状态的通知也不是通过RunLoop进行。

使用NSURLConnection有几种选择：

A.在主线程调异步接口

若直接在主线程调用异步接口，会有个Runloop相关的问题：

当在主线程调用[[NSURLConnection alloc] initWithRequest:request delegate:self startImmediately:YES]时，请求发出，侦听任务会加入到主线程的Runloop下，RunloopMode会默认为NSDefaultRunLoopMode。这表明只有当前线程的Runloop处于NSDefaultRunLoopMode时，这个任务才会被执行。但当用户滚动tableview或scrollview时，主线程的Runloop是处于NSEventTrackingRunLoopMode模式下的，不会执行NSDefaultRunLoopMode的任务，所以会出现一个问题，请求发出后，如果用户一直在操作UI上下滑动屏幕，那在滑动结束前是不会执行回调函数的，只有在滑动结束，RunloopMode切回NSDefaultRunLoopMode，才会执行回调函数。苹果一直把动画效果性能放在第一位，估计这也是苹果提升UI动画性能的手段之一。

所以若要在主线程使用NSURLConnection异步接口，需要手动把RunloopMode设为NSRunLoopCommonModes。这个mode意思是无论当前Runloop处于什么状态，都执行这个任务。

 
    
         NSURLConnection 
         *connection = [[ 
         NSURLConnection 
         alloc] initWithRequest:request delegate: 
         self 
         startImmediately: 
         NO 
         ]; 
        
 
         [connection scheduleInRunLoop:[ 
         NSRunLoop 
         currentRunLoop] forMode: 
         NSRunLoopCommonModes 
         ]; 
        
 
         [connection start]; 
        
 
  

B.在子线程调同步接口

若在子线程调用同步接口，一条线程只能处理一个请求，因为请求一发出去线程就阻塞住等待回调，需要给每个请求新建一个线程，这是很浪费的，这种方式唯一的好处应该是易于控制请求并发的数量。

C.在子线程调异步接口

子线程调用异步接口，子线程需要有Runloop去接收异步回调事件，这里也可以每个请求都新建一条带有Runloop的线程去侦听回调，但这一点好处都没有，既然是异步回调，除了处理回调内容，其他时间线程都是空闲可利用的，所有请求共用一个响应的线程就够了。

AFNetworking用的就是第三种方式，创建了一条常驻线程专门处理所有请求的回调事件，这个模型跟nodejs有点类似。网络请求回调处理完，组装好数据后再给上层调用者回调，这时候回调是抛回主线程的，因为主线程是最安全的，使用者可能会在回调中更新UI，在子线程更新UI会导致各种问题，一般使用者也可以不需要关心线程问题。

以下是相关线程大致的关系，实际上多个NSURLConnection会共用一个NSURLConnectionLoader线程，这里就不细化了，除了处理socket的CFSocket线程，还有一些Javascript:Core的线程，目前不清楚作用，归为NSURLConnection里的其他线程。因为NSURLConnection是系统控件，每个iOS版本可能都有不一样，可以先把NSURLConnection当成一个黑盒，只管它的start和callback就行了。如果使用AFHttpRequestOperationManager的接口发送请求，这些请求会统一在一个NSOperationQueue里去发，所以多了上面NSOperationQueue的一个线程。

相关代码：-networkRequestThread:, -start:, -operationDidStart:。

2.状态机

继承NSOperation有个很麻烦的东西要处理，就是改变状态时需要发KVO通知，否则这个类加入NSOperationQueue不可用了。NSOperationQueue是用KVO方式侦听NSOperation状态的改变，以判断这个任务当前是否已完成，完成的任务需要在队列中除去并释放。

AFURLConnectionOperation对此做了个状态机，统一搞定状态切换以及发KVO通知的问题，内部要改变状态时，就只需要类似self.state = AFOperationReadyState的调用而不需要做其他了，状态改变的KVO通知在setState里发出。

总的来说状态管理相关代码就三部分，一是限制一个状态可以切换到其他哪些状态，避免状态切换混乱，二是状态Enum值与NSOperation四个状态方法的对应，三是在setState时统一发KVO通知。详见代码注释。

相关代码：AFKeyPathFromOperationState, AFStateTransitionIsValid, -setState:, -isPaused:, -isReady:, -isExecuting:, -isFinished:.

3.NSURLConnectionDelegate

处理NSURLConnection Delegate的内容不多，代码也是按请求回调的顺序排列下去，十分易读，主要流程就是接收到响应的时候打开outputStream，接着有数据过来就往outputStream写，在上传/接收数据过程中会回调上层传进来的相应的callback，在请求完成回调到connectionDidFinishLoading时，关闭outputStream，用outputStream组装responseData作为接收到的数据，把NSOperation状态设为finished，表示任务完成，NSOperation会自动调用completeBlock，再回调到上层。

4.setCompleteBlock

NSOperation在iOS4.0以后提供了个接口setCompletionBlock，可以传入一个block作为任务执行完成时（state状态机变为finished时）的回调，AFNetworking直接用了这个接口，并通过重写加了几个功能：

A.消除循环引用

在NSOperation的实现里，completionBlock是NSOperation对象的一个成员，NSOperation对象持有着completionBlock，若传进来的block用到了NSOperation对象，或者block用到的对象持有了这个NSOperation对象，就会造成循环引用。这里执行完block后调用[strongSelf setCompletionBlock:nil]把completionBlock设成nil，手动释放self(NSOperation对象)持有的completionBlock对象，打破循环引用。

可以理解成对外保证传进来的block一定会被释放，解决外部使用使很容易出现的因对象关系复杂导致循环引用的问题，让使用者不知道循环引用这个概念都能正确使用。

B.dispatch_group

这里允许用户让所有operation的completionBlock在一个group里执行，但我没看出这样做的作用，若想组装一组请求（见下面的batchOfRequestOperations）也不需要再让completionBlock在group里执行，求解。

C.”The Deallocation Problem”

作者在注释里说这里重写的setCompletionBlock方法解决了”The Deallocation Problem”，实际上并没有。”The Deallocation Problem”简单来说就是不要让UIKit的东西在子线程释放。

这里如果传进来的block持有了外部的UIViewController或其他UIKit对象（下面暂时称为A对象），并且在请求完成之前其他所有对这个A对象的引用都已经释放了，那么这个completionBlock就是最后一个持有这个A对象的，这个block释放时A对象也会释放。这个block在什么线程释放，A对象就会在什么线程释放。我们看到block释放的地方是url_request_operation_completion_queue()，这是AFNetworking特意生成的子线程，所以按理说A对象是会在子线程释放的，会导致UIKit对象在子线程释放，会有问题。

但AFNetworking实际用起来却没问题，想了很久不得其解，后来做了实验，发现iOS5以后苹果对UIKit对象的释放做了特殊处理，只要发现在子线程释放这些对象，就自动转到主线程去释放，断点出来是由一个叫_objc_deallocOnMainThreadHelper的方法做的。如果不是UIKit对象就不会跳到主线程释放。AFNetworking2.0只支持iOS6+，所以没问题。

5.batchOfRequestOperations

这里额外提供了一个便捷接口，可以传入一组请求，在所有请求完成后回调complionBlock，在每一个请求完成时回调progressBlock通知外面有多少个请求已完成。详情参见代码注释，这里需要说明下dispatch_group_enter和dispatch_group_leave的使用，这两个方法用于把一个异步任务加入group里。

一般我们要把一个任务加入一个group里是这样：

 
         dispatch_group_async(group, queue, ^{ 
        
         block(); 
        
         });

这个写法等价于

 
         dispatch_async(queue, ^{ 
        
         dispatch_group_enter(group); 
        
         block() 
        
         dispatch_group_leave(group); 
        
         });

如果要把一个异步任务加入group，这样就行不通了：

 
         dispatch_group_async(group, queue, ^{ 
        
         [ 
         self 
         performBlock:^(){ 
        
         block(); 
        
         }]; 
        
         //未执行到block() group任务就已经完成了 
        
         });

这时需要这样写：

 
         dispatch_group_enter(group); 
        
         [ 
         self 
         performBlock:^(){ 
        
         block(); 
        
         dispatch_group_leave(group); 
        
         }];

异步任务回调后才算这个group任务完成。对batchOfRequest的实现来说就是请求完成并回调后，才算这个任务完成。

其实这跟retain/release差不多，都是计数，dispatch_group_enter时任务数+1，dispatch_group_leave时任务数-1，任务数为0时执行dispatch_group_notify的内容。

相关代码：-batchOfRequestOperations:progressBlock:completionBlock:

6.其他

A.锁

AFURLConnectionOperation有一把递归锁，在所有会访问/修改成员变量的对外接口都加了锁，因为这些对外的接口用户是可以在任意线程调用的，对于访问和修改成员变量的接口，必须用锁保证线程安全。

B.序列化

AFNetworking的多数类都支持序列化，但实现的是NSSecureCoding的接口，而不是NSCoding，区别在于解数据时要指定Class，用-decodeObjectOfClass:forKey:方法代替了-decodeObjectForKey:。这样做更安全，因为序列化后的数据有可能被篡改，若不指定Class，-decode出来的对象可能不是原来的对象，有潜在风险。另外，NSSecureCoding是iOS6以上才有的。详见这里。

这里在序列化时保存了当前任务状态，接收的数据等，但回调block是保存不了的，需要在取出来发送时重新设置。可以像下面这样持久化保存和取出任务：

 
         AFHTTPRequestOperation *operation = [[AFHTTPRequestOperation alloc] initWithRequest:request]; 
        
         NSData 
         *data = [ 
         NSKeyedArchiver 
         archivedDataWithRootObject:operation]; 
        
         AFHTTPRequestOperation *operationFromDB = [ 
         NSKeyedUnarchiver 
         unarchiveObjectWithData:data]; 
        
         [operationFromDB start];

C.backgroundTask

这里提供了setShouldExecuteAsBackgroundTaskWithExpirationHandler接口，决定APP进入后台后是否继续发送接收请求，并在后台执行时间超时后取消所有请求。在dealloc里需要调用[application endBackgroundTask:]，告诉系统这个后台任务已经完成，不然系统会一直让你的APP运行在后台，直到超时。

相关代码：-setShouldExecuteAsBackgroundTaskWithExpirationHandler:, -dealloc:

7.AFHTTPRequestOperation

AFHTTPRequestOperation继承了AFURLConnectionOperation，把它放一起说是因为它没做多少事情，主要多了responseSerializer，暂停下载断点续传，以及提供接口请求成功失败的回调接口-setCompletionBlockWithSuccess:failure:。详见源码注释。

8.源码注释

——————————————————————————————————————————————————————————

AFURLRequestSerialization用于帮助构建NSURLRequest，主要做了两个事情：
1.构建普通请求：格式化请求参数，生成HTTP Header。
2.构建multipart请求。
分别看看它在这两点具体做了什么，怎么做的。

1.构建普通请求

A.格式化请求参数

一般我们请求都会按key=value的方式带上各种参数，GET方法参数直接加在URL上，POST方法放在body上，NSURLRequest没有封装好这个参数的解析，只能我们自己拼好字符串。AFNetworking提供了接口，让参数可以是NSDictionary, NSArray, NSSet这些类型，再由内部解析成字符串后赋给NSURLRequest。

转化过程大致是这样的：

 
    
         @{ 
        
 
               
         @"name" 
         : 
         @"bang" 
         , 
        
 
               
         @"phone" 
         : @{ 
         @"mobile" 
         : 
         @"xx" 
         , 
         @"home" 
         : 
         @"xx" 
         }, 
        
 
               
         @"families" 
         : @[ 
         @"father" 
         , 
         @"mother" 
         ], 
        
 
               
         @"nums" 
         : [ 
         NSSet 
         setWithObjects: 
         @"1" 
         , 
         @"2" 
         , 
         nil 
         ] 
        
 
         } 
        
 
         -> 
        
 
         @[ 
        
 
               
         field: 
         @"name" 
         , value:  
         @"bang" 
         , 
        
 
               
         field: 
         @"phone[mobile]" 
         , value:  
         @"xx" 
         , 
        
 
               
         field: 
         @"phone[home]" 
         , value:  
         @"xx" 
         , 
        
 
               
         field: 
         @"families[]" 
         , value:  
         @"father" 
         , 
        
 
               
         field: 
         @"families[]" 
         , value:  
         @"mother" 
         , 
        
 
               
         field: 
         @"nums" 
         , value:  
         @"1" 
         , 
        
 
               
         field: 
         @"nums" 
         , value:  
         @"2" 
         , 
        
 
         ] 
        
 
         -> 
        
 
         name=bang&phone[mobile]=xx&phone[home]=xx&families[]=father&families[]=mother&nums=1&num=2 
        
 
  

第一部分是用户传进来的数据，支持包含NSArray,NSDictionary,NSSet这三种数据结构。
第二部分是转换成AFNetworking内自己的数据结构，每一个key-value对都用一个对象AFQueryStringPair表示，作用是最后可以根据不同的字符串编码生成各自的key=value字符串。主要函数是AFQueryStringPairsFromKeyAndValue，详见源码注释。
第三部分是最后生成NSURLRequest可用的字符串数据，并且对参数进行url编码，在AFQueryStringFromParametersWithEncoding这个函数里。

最后在把数据赋给NSURLRequest时根据不同的HTTP方法分别处理，对于GET/HEAD/DELETE方法，把参数加到URL后面，对于其他如POST/PUT方法，把数据加到body上，并设好HTTP头，告诉服务端字符串的编码。

B.HTTP Header

AFNetworking帮你组装好了一些HTTP请求头，包括语言Accept-Language，根据[NSLocale preferredLanguages]方法读取本地语言，告诉服务端自己能接受的语言。还有构建User-Agent，以及提供Basic Auth认证接口，帮你把用户名密码做base64编码后放入HTTP请求头。详见源码注释。

C.其他格式化方式

HTTP请求参数不一定是要key=value形式，可以是任何形式的数据，可以是json格式，苹果的plist格式，二进制protobuf格式等，AFNetworking提供了方法可以很容易扩展支持这些格式，默认就实现了json和plist格式。详见源码的类AFJSONRequestSerializer和AFPropertyListRequestSerializer。

2.构建multipart请求

构建Multipart请求是占篇幅很大的一个功能，AFURLRequestSerialization里2/3的代码都是在做这个事。

A.Multipart协议介绍

Multipart是HTTP协议为web表单新增的上传文件的协议，协议文档是rfc1867，它基于HTTP的POST方法，数据同样是放在body上，跟普通POST方法的区别是数据不是key=value形式，key=value形式难以表示文件实体，为此Multipart协议添加了分隔符，有自己的格式结构，大致如下：
—AaB03x content-disposition: form-data; name=“name"

bang
–AaB03x
content-disposition: form-data; name=”pic”; filename=“content.txt”
Content-Type: text/plain

… contents of bang.txt …
–AaB03x–

以上表示数据name=bang以及一个文件，content.txt是文件名，… contents of bang.txt …是文件实体内容。分隔符—AaB03x是可以自定义的，写在HTTP头部里：
Content-type: multipart/form-data, boundary=AaB03x
每一个部分都有自己的头部，表明这部分的数据类型以及其他一些参数，例如文件名，普通字段的key。最后一个分隔符会多加两横，表示数据已经结束：—AaB03x—。

B.实现

接下来说说怎样构造Multipart里的数据，最简单的方式就是直接拼数据，要发送一个文件，就直接把文件所有内容读取出来，再按上述协议加上头部和分隔符，拼接好数据后扔给NSURLRequest的body就可以发送了，很简单。但这样做是不可用的，因为文件可能很大，这样拼数据把整个文件读进内存，很可能把内存撑爆了。

第二种方法是不把文件读出来，不在内存拼，而是新建一个临时文件，在这个文件上拼接数据，再把文件地址扔给NSURLRequest的bodyStream，这样上传的时候是分片读取这个文件，不会撑爆内存，但这样每次上传都需要新建个临时文件，对这个临时文件的管理也挺麻烦的。

第三种方法是构建自己的数据结构，只保存要上传的文件地址，边上传边拼数据，上传是分片的，拼数据也是分片的，拼到文件实体部分时直接从原来的文件分片读取。这方法没上述两种的问题，只是实现起来也没上述两种简单，AFNetworking就是实现这第三种方法，而且还更进一步，除了文件，还可以添加多个其他不同类型的数据，包括NSData，和InputStream。

AFNetworking里multipart请求的使用方式是这样：

 
         AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager]; 
        
 
         NSDictionary 
         *parameters = @{ 
         @"foo" 
         : 
         @"bar" 
         }; 
        
 
         NSURL 
         *filePath = [ 
         NSURL 
         fileURLWithPath: 
         @"file://path/to/image.png" 
         ]; 
        
 
         [manager POST: 
         @"http://example.com/resources.json" 
         parameters:parameters constructingBodyWithBlock:^( 
         id 
         formData) { 
        
 
              
         [formData appendPartWithFileURL:filePath name: 
         @"image" 
         error: 
         nil 
         ]; 
        
 
         } success:^(AFHTTPRequestOperation *operation,  
         id 
         responseObject) { 
        
 
              
         NSLog 
         ( 
         @"Success: %@" 
         , responseObject); 
        
 
         } failure:^(AFHTTPRequestOperation *operation,  
         NSError 
         *error) { 
        
 
              
         NSLog 
         ( 
         @"Error: %@" 
         , error); 
        
 
         }]; 
        

这里通过constructingBodyWithBlock向使用者提供了一个AFStreamingMultipartFormData对象，调这个对象的几种append方法就可以添加不同类型的数据，包括FileURL/NSData/NSInputStream，AFStreamingMultipartFormData内部把这些append的数据转成不同类型的AFHTTPBodyPart，添加到自定义的AFMultipartBodyStream里。最后把AFMultipartBodyStream赋给原来NSMutableURLRequest的bodyStream。NSURLConnection发送请求时会读取这个bodyStream，在读取数据时会调用这个bodyStream的-read:maxLength:方法，AFMultipartBodyStream重写了这个方法，不断读取之前append进来的AFHTTPBodyPart数据直到读完。

AFHTTPBodyPart封装了各部分数据的组装和读取，一个AFHTTPBodyPart就是一个数据块。实际上三种类型(FileURL/NSData/NSInputStream)的数据在AFHTTPBodyPart都转成NSInputStream，读取数据时只需读这个inputStream。inputStream只保存了数据的实体，没有包括分隔符和头部，AFHTTPBodyPart是边读取变拼接数据，用一个状态机确定现在数据读取到哪一部份，以及保存这个状态下已被读取的字节数，以此定位要读的数据位置，详见AFHTTPBodyPart的-read:maxLength:方法。

AFMultipartBodyStream封装了整个multipart数据的读取，主要是根据读取的位置确定现在要读哪一个AFHTTPBodyPart。AFStreamingMultipartFormData对外提供友好的append接口，并把构造好的AFMultipartBodyStream赋回给NSMutableURLRequest，关系大致如下图：

C.NSInputStream子类

NSURLRequest的setHTTPBodyStream接受的是一个NSInputStream*参数，那我们要自定义inputStream的话，创建一个NSInputStream的子类传给它是不是就可以了？实际上不行，这样做后用NSURLRequest发出请求会导致crash，提示[xx _scheduleInCFRunLoop:forMode:]: unrecognized selector。

这是因为NSURLRequest实际上接受的不是NSInputStream对象，而是CoreFoundation的CFReadStreamRef对象，因为CFReadStreamRef和NSInputStream是toll-free bridged，可以自由转换，但CFReadStreamRef会用到CFStreamScheduleWithRunLoop这个方法，当它调用到这个方法时，object-c的toll-free bridging机制会调用object-c对象NSInputStream的相应函数，这里就调用到了_scheduleInCFRunLoop:forMode:，若不实现这个方法就会crash。详见这篇文章。

3.源码注释

——————————————————————————————————————————————————————————

本篇说说安全相关的AFSecurityPolicy模块，AFSecurityPolicy用于验证HTTPS请求的证书，先来看看HTTPS的原理和证书相关的几个问题。

HTTPS

HTTPS连接建立过程大致是，客户端和服务端建立一个连接，服务端返回一个证书，客户端里存有各个受信任的证书机构根证书，用这些根证书对服务端返回的证书进行验证，经验证如果证书是可信任的，就生成一个pre-master secret，用这个证书的公钥加密后发送给服务端，服务端用私钥解密后得到pre-master secret，再根据某种算法生成master secret，客户端也同样根据这种算法从pre-master secret生成master secret，随后双方的通信都用这个master secret对传输数据进行加密解密。

以上是简单过程，中间还有很多细节，详细过程和原理已经有很多文章阐述得很好，就不再复述，推荐一些相关文章：
关于非对称加密算法的原理：RSA算法原理<一> <二>
关于整个流程：HTTPS那些事<一> <二> <三>
关于数字证书：浅析数字证书

这里说下一开始我比较费解的两个问题：

1.证书是怎样验证的？怎样保证中间人不能伪造证书？

首先要知道非对称加密算法的特点，非对称加密有一对公钥私钥，用公钥加密的数据只能通过对应的私钥解密，用私钥加密的数据只能通过对应的公钥解密。

我们来看最简单的情况：一个证书颁发机构(CA)，颁发了一个证书A，服务器用这个证书建立https连接。客户端在信任列表里有这个CA机构的根证书。

首先CA机构颁发的证书A里包含有证书内容F，以及证书加密内容F1，加密内容F1就是用这个证书机构的私钥对内容F加密的结果。（这中间还有一次hash算法，略过。）

建立https连接时，服务端返回证书A给客户端，客户端的系统里的CA机构根证书有这个CA机构的公钥，用这个公钥对证书A的加密内容F1解密得到F2，跟证书A里内容F对比，若相等就通过验证。整个流程大致是：F->CA私钥加密->F1->客户端CA公钥解密->F。因为中间人不会有CA机构的私钥，客户端无法通过CA公钥解密，所以伪造的证书肯定无法通过验证。

2.什么是SSL Pinning？

可以理解为证书绑定，是指客户端直接保存服务端的证书，建立https连接时直接对比服务端返回的和客户端保存的两个证书是否一样，一样就表明证书是真的，不再去系统的信任证书机构里寻找验证。这适用于非浏览器应用，因为浏览器跟很多未知服务端打交道，无法把每个服务端的证书都保存到本地，但CS架构的像手机APP事先已经知道要进行通信的服务端，可以直接在客户端保存这个服务端的证书用于校验。

为什么直接对比就能保证证书没问题？如果中间人从客户端取出证书，再伪装成服务端跟其他客户端通信，它发送给客户端的这个证书不就能通过验证吗？确实可以通过验证，但后续的流程走不下去，因为下一步客户端会用证书里的公钥加密，中间人没有这个证书的私钥就解不出内容，也就截获不到数据，这个证书的私钥只有真正的服务端有，中间人伪造证书主要伪造的是公钥。

为什么要用SSL Pinning？正常的验证方式不够吗？如果服务端的证书是从受信任的的CA机构颁发的，验证是没问题的，但CA机构颁发证书比较昂贵，小企业或个人用户可能会选择自己颁发证书，这样就无法通过系统受信任的CA机构列表验证这个证书的真伪了，所以需要SSL Pinning这样的方式去验证。

AFSecurityPolicy

NSURLConnection已经封装了https连接的建立、数据的加密解密功能，我们直接使用NSURLConnection是可以访问https网站的，但NSURLConnection并没有验证证书是否合法，无法避免中间人攻击。要做到真正安全通讯，需要我们手动去验证服务端返回的证书，AFSecurityPolicy封装了证书验证的过程，让用户可以轻易使用，除了去系统信任CA机构列表验证，还支持SSL Pinning方式的验证。使用方法：

1

2

3

4

5

6

7

 
          //把服务端证书(需要转换成cer格式)放到APP项目资源里，AFSecurityPolicy会自动寻找根目录下所有cer文件 
         
          AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModePublicKey]; 
         
          securityPolicy.allowInvalidCertificates =  
          YES 
          ; 
         
          [AFHTTPRequestOperationManager manager].securityPolicy = securityPolicy; 
         
          [manager GET: 
          @"https://example.com/" 
          parameters: 
          nil 
          success:^(AFHTTPRequestOperation *operation,  
          id 
          responseObject) { 
         
          } failure:^(AFHTTPRequestOperation *operation,  
          NSError 
          *error) { 
         
          }];

AFSecurityPolicy分三种验证模式：

AFSSLPinningModeNone

这个模式表示不做SSL pinning，只跟浏览器一样在系统的信任机构列表里验证服务端返回的证书。若证书是信任机构签发的就会通过，若是自己服务器生成的证书，这里是不会通过的。

AFSSLPinningModeCertificate

这个模式表示用证书绑定方式验证证书，需要客户端保存有服务端的证书拷贝，这里验证分两步，第一步验证证书的域名/有效期等信息，第二步是对比服务端返回的证书跟客户端返回的是否一致。

这里还没弄明白第一步的验证是怎么进行的，代码上跟去系统信任机构列表里验证一样调用了SecTrustEvaluate，只是这里的列表换成了客户端保存的那些证书列表。若要验证这个，是否应该把服务端证书的颁发机构根证书也放到客户端里？

AFSSLPinningModePublicKey

这个模式同样是用证书绑定方式验证，客户端要有服务端的证书拷贝，只是验证时只验证证书里的公钥，不验证证书的有效期等信息。只要公钥是正确的，就能保证通信不会被窃听，因为中间人没有私钥，无法解开通过公钥加密的数据。

整个AFSecurityPolicy就是实现这这几种验证方式，剩下的就是实现细节了，详见源码。

源码注释

sdfs

Focus_Now

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
AFNetworking-源码解析

最近看AFNetworking2的源码，学习这个知名网络框架的实现，顺便梳理写下文章。AFNetworking2的大体架构和思路在这篇文章已经说得挺清楚了，就不再赘述了，只说说实现的细节。AFNetworking的代码还在不断更新中，我看的是AFNetworking2.3.1。本篇先看看AFURLConnectionOperation，AFURLConnectionOperation继承自
复制链接

扫一扫