在 iOS 设备内截取 HTTP/HTTPS 信息

悠悠小仙仙

0x01.Why？

做移动测试的同学经常会在app和server中间架设一个代理（例如charles或者fiddler等），由经代理，app和server之间的交互及交互内容变得可视化，使得我们不再摸黑测试。事实上，能够很好的掌握app和server端的交互不仅对于测试，对于开发，对于产品的整个质量提高都是有非常大益处的。但是，有些场景下，架设代理变得不易，或者难于满足要求，举几个例子：

想要找出正常用户使用时候，哪些场景最耗流量（你不能让用户挂代理，如果有针对网络流量的优化，挂代理也看不出问题来）。
想要找出请求的各种接口中，哪些服务不稳定，如间歇出现4xx或者5xx错误，这需要统计大量的数据，单一客户端挂代理是做不到的（当然服务端监控如果做得好也能实现）。
想要找出某些特定条件下（如弱网，网络切换等）客户端自己产生的请求错误或者超时等等。
想要查看一些特殊场景下接口是否会发生重复调用，错误调用序列。这些issue往往藏的很深，不易出现。这时候往往需要分析日志的pattern来把问题揪出来，这时候你就会发现，代理软件做日志分析很麻烦，也要导出来专门分析，而且总挂着代理极为不方便（至少不能切换网络，日志也要根据app做筛查，因为一般都是全流量截取）。
这时候需求就变成了：最好在app内部能够截取所有的HTTP/HTTPS流量，以某种方式保存下来，并且能够以某种方式传递给需要用这些数据的人。这其实是一种APM（Application Performance Monitoring）的概念，国外最早已经有人实现了这种功能，如 newrelic https://newrelic.com/ 国内也有一些类似的厂商了。

0x02. How？

先想一下我们每天都在使用的代理工具是如何实现的呢？代理工具会拦截所有的http的请求，记录下我们需要的信息后替代客户端重新发送相同的请求给服务端；拦截返回，记录下想要的东西后返回给客户端。如果JAVA写的多，你可能看到过各种 interceptor 来截取流量。OKHttp的作者介绍这款被广泛应用的http client的时候曾经说过：OKHttp只不过是请求和响应之间做了一堆interceptor而已。

具体落到iOS上。iOS的Foundation框架提供了 URL Loading System 这个库(后面简写为ULS)，所有基于URL（例如http://，https:// ,ftp://这些应用层的传输协议)的协议都可以通过ULS提供的基础类和协议来实现，你甚至可以自定义自己的私有应用层通讯协议。

而ULS库里提供了一个强有力的武器 NSURLProtocol。 继承NSURLProtocol 的子类都可以实现截取行为，具体的方式就是：如果注册了某个NSURLProtocol子类，ULS管理的流量都会先交由这个子类处理，这相当于实现了一个拦截器。由于现在处于统治地位的的http client库 AFNetworking和 Alamofire 都是基于 URL Loading System实现的，所以他们俩和使用基础URL Loading System API产生的流量理论上都可以被截取到。

注意一点，NSURLProtocol是一个抽象类，而不是一个协议（protocol）。

为了达到监控流量的目的，我们就先设计一个类来实现NSURLProtocol吧:

1. // MyHttpProtocol.h
   
2. #import <Foundation/Foundation.h>
   
3. @interface MyHttpProtocol : NSURLProtocol
   
4. @end

复制代码

1. //MyHttpProtocol.m
   
2. 
   
3. #import <Foundation/Foundation.h>
   
4. #import "MyHttpProtocol.h"
   
5. 
   
6. @implementation MyHttpProtocol
   
7. 
   
8. +(BOOL)canInitWithRequest:(NSURLRequest *)request{   
   
9.    NSString *scheme =[[request URL] scheme];
   
10.     if([[scheme lowercaseString] isEqualToString:@"http"]||
    
11.        [[scheme lowercaseString] isEqualToString:@"https"])
    
12.     {
    
13.         if([NSURLProtocol propertyForKey:@"processed" inRequest:request]){
    
14.             return NO;
    
15.         }
    
16.         return YES;
    
17.     }
    
18.     return NO;
    
19. }
    
20. 
    
21. 
    
22. + (NSURLRequest *)canonicalRequestForRequest:(NSURLRequest *)request
    
23. {
    
24.     NSMutableURLRequest * duplicatedRequest;
    
25.     duplicatedRequest =  [request mutableCopy];
    
26.     [NSURLProtocol setProperty:@YES forKey:@"processed" inRequest:duplicatedRequest];
    
27.     NSLog(@"%@",request.HTTPBody);
    
28.     return (NSURLRequest *) duplicatedRequest;
    
29. }
    

复制代码

上边的MyHttpProtocol类继承了NSURLProtocol，并实现了 NSURLProtocol的两个方法。

1. + (BOOL)canInitWithRequest:(NSURLRequest *)request

复制代码

这个方法返回YES，MyHttpProtocol类就会处理一个 request，否则就按照原有方式处理。在上边的代码里，我先判断了协议的类型是不是http/https，如果不是，则返回NO，如果是，则会做一个判断：这个request是否带有一个叫做 "processed"的标签，如果是，则返回NO，不交给MyHttpProtocol处理；如果不是，则交给MyHttpProtocol处理。

重点说一下标签“processed”：每当需要加载一个URL资源时，URL Loading System会询问MyURLProtocol是否处理，如果返回YES，URL Loading System会创建一个MyURLProtocol实例，实例做完拦截工作后，会重新调用原有的方法，如session GET，URL Loading System会再一次被调用，如果在+canInitWithRequest:中总是返回YES，这样URL Loading System又会创建一个MyURLProtocol实例。。。。这样就导致了无限循环。为了避免这种问题，我们可以利用+setProperty:forKey:inRequest:来给被处理过的请求打标签，然后在+canInitWithRequest:中查询该request是否已经处理过了，如果是则返回NO。 上文中的“processed”就是打的一个标签，标签是一个字符串，可以任意取名。而这个打标签的方法，通常会在

1. + (NSURLRequest *)canonicalRequestForRequest:(NSURLRequest *)request

复制代码

中实现。

实现这个子类以后，在程序加载的地方，注册这个类，这样，理论上，请注意“理论上”这三个字，就可以截获所有的http/https流量了。注册的代码如下

1. - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
   
2.     [NSURLProtocol registerClass:[MyHttpProtocol class]];
   
3.     return YES;
   
4. }

复制代码

做完了上述工作，我们仍然无法实现我们所想：记录下所有的请求和响应。这是因为：如果你拦截了请求，你就需要对你的拦截负责：比如重新发送拦截的请求，处理请求对应的返回等。这里就需要完成非常多的dirty work了。下面的玩具代码只会处理最简单的情况，如果真实使用，得处理很多细节问题。

为了便于理解，先介绍NSURLProtocol的几个内置的属性，包括：client，request，cachedResponse，类型如下

1. @property(readonly, retain) id<NSURLProtocolClient> client;
   
2. @property(readonly, copy) NSURLRequest *request;
   
3. @property(readonly, copy) NSCachedURLResponse *cachedResponse;

复制代码

这三个概念稍微有点儿绕，先简要说一下：request被用作接收ULS转给NSURLProtocol的请求；client的实现了NSURLProtocolClient这个协议，这里边有一堆callback函数，我们一会儿会用到didLoadData；cachesResponse，顾名思义，请求对应的相应会被缓存在这里。

我们还要实现NSURLProtocol的两个方法。startLoading和stopLoading

1. - (void)startLoading{
   
2.     NSLog(@"Start loading -------");
   
3.     NSLog(@"request url is: %@",self.request.URL); //这里的self.request就是ULS传过来的请求体，这里我们记录下一些请求体的信息。
   
4.     NSLog(@"http method is:%@",self.request.HTTPMethod); //
   
5.     for (NSString *key in[self.request.allHTTPHeaderFields allKeys]){    //打印http请求的header
   
6.         NSLog(@"key:%@,value:%@",key,[self.request.allHTTPHeaderFields objectForKey:key]);
   
7.     }
   
8. 
   
9.     //重新转发请求
   
10.     NSMutableURLRequest *newRequest = [self.request mutableCopy];
    
11.     NSURLSessionConfiguration *configuration = [NSURLSessionConfiguration defaultSessionConfiguration];
    
12.     NSURLSession * session = [NSURLSession sessionWithConfiguration:configuration delegate:self delegateQueue:nil];
    
13.     self.task = [session dataTaskWithRequest:newRequest];
    
14.     [self.task resume];
    
15. }
    
16. 
    
17. -(void) stopLoading{
    
18.     NSLog(@"Stop loading -------");   
    
19.     [self.task cancel];
    
20. }

复制代码

通过上述代码，我们成功的记录下来了请求体的一些信息，但是如何记录返回信息呢？由于ULS是异步框架，所以，响应会推给回调函数，我们必须在回调函数里进行截取。为了实现这一功能，我们需要实现 NSURLSessionDataDelegate 这个委托协议（NSURLSessionDataDelegate也有局限性，这里不展开说了）。

1. @interface MyHttpProtocol ()<NSURLSessionDataDelegate>
   
2. @property (nonatomic, strong) NSMutableData *data;
   
3. @property (nonatomic, strong) NSURLSessionDataTask *task;
   
4. @end
   
5. 
   
6. 
   
7. //当服务端返回信息时，这个回调函数会被ULS调用，在这里实现http返回信息的截取
   
8. - (void)URLSession:(NSURLSession *)session dataTask:(NSURLSessionDataTask *)dataTask didReceiveData:(NSData *)data {
   
9. 
   
10.     [self.client URLProtocol:self didLoadData:data]; //返回给URL Loading System接收到的数据，这个很重要，不然光截取不返回，就瞎了。
    
11.     NSLog(@"--data received");
    
12. 
    
13.    //下面的代码只打印json类型的http返回。
    
14.     NSError *error = nil;
    
15.     NSString *jsonObject = [NSJSONSerialization JSONObjectWithData:data options:0 error:&error];
    
16.     if(error){
    
17.         NSLog(@"error occured!");
    
18.         return;
    
19.     }
    
20.     NSData *jsonData = [NSJSONSerialization dataWithJSONObject:jsonObject options:NSJSONWritingPrettyPrinted error:nil];
    
21.     NSString *jsonString = [[NSString alloc]initWithData:jsonData encoding:NSUTF8StringEncoding];
    
22.     NSLog(@"nsdata is %@",jsonString);   
    
23. }

复制代码

好了，上边这一坨代码，理论上实现了我们想要的功能的最小集：拦截http/https请求和响应，并打印出来。为什么说理论上呢。如果你使用AFNETworking，你会发现，你的代码根本没有被调用。这是因为它根本不屌上边的注册，也就是下边这句代码：

1. [NSURLProtocol registerClass:[MyHttpProtocol class]];

复制代码

际上 ULS允许加载多个NSURLProtocol，它们被存在一个数组里，默认情况下，AFNETWorking只会使用数组里的第一个protocol。这看起来是个悲剧，如果不改源码，我想做的事儿不就止步于此了么？多亏Objective C是动态语言。我们可以用一项“尖端科技”，也就是object-c的动态方法替换来实现动态的修改源码来达到目的。
实现一个类：MySessionConfiguration.m (这部分代码基本照抄的一个叫做Netfox的开源项目，大家有兴趣可以搜索)。

悠悠小仙仙

1. #import <Foundation/Foundation.h>
   
2. #import "MySessionConfiguration.h"
   
3. #import "MyHttpProtocol.h"
   
4. #import <objc/runtime.h>
   
5. 
   
6. @implementation MySessionConfiguration
   
7. 
   
8. //返回一个默认配置的单体
   
9. + (MySessionConfiguration *) defaultConfiguration{
   
10.     static MySessionConfiguration *staticConfiguration;
    
11.     static dispatch_once_t onceToken;
    
12.     dispatch_once(&onceToken, ^{
    
13.         staticConfiguration =[[MySessionConfiguration alloc] init];
    
14.     });
    
15.     return staticConfiguration;
    
16. }
    
17. 
    
18. 
    
19. - (instancetype) init{
    
20.     self = [super init];
    
21.     if(self){
    
22.         self.isSwizzle=NO;
    
23.     }
    
24.     return self;
    
25. }
    
26. 
    
27. //load被调用的时候，其实吧session.configuration.protocolClasses 这个数组从原有配置换成了只有MyHttpProtocol
    
28. - (void)load{
    
29.     NSLog(@"----configuration load --");
    
30.     self.isSwizzle=YES;
    
31.     Class cls = NSClassFromString(@"__NSCFURLSessionConfiguration") ?:NSClassFromString(@"NSURLSessionConfiguration");
    
32.     [self swizzleSelector:@selector(protocolClasses) fromClass:cls toClass:[self class]];
    
33. 
    
34. }
    
35. 
    
36. - (void)unload {
    
37.     self.isSwizzle=NO;
    
38.      Class cls = NSClassFromString(@"__NSCFURLSessionConfiguration") ?:NSClassFromString(@"NSURLSessionConfiguration");
    
39.      [self swizzleSelector:@selector(protocolClasses) fromClass:cls toClass:[self class]];
    
40. }
    
41. 
    
42. - (void)swizzleSelector:(SEL)selector fromClass:(Class)original toClass:(Class)stub{
    
43.     Method originalMethod = class_getInstanceMethod(original, selector);
    
44.     Method stubMethod = class_getInstanceMethod(stub, selector);
    
45.     if(!originalMethod || !stubMethod){
    
46.         [NSException raise:NSInternalInconsistencyException format:@"Could't load NSURLSessionConfiguration "];
    
47.     }
    
48. 
    
49.    //真正的替换在这里
    
50.     method_exchangeImplementations(originalMethod, stubMethod);
    
51. }
    
52. 
    
53. //返回MyHttpProtocol
    
54. - (NSArray *)protocolClasses{
    
55.     return @[[MyHttpProtocol class]];
    
56. }
    
57. 
    
58. @end

复制代码

最后，简单粗暴的，在程序启动的时候加入这么一句：

1. - (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
   
2. 
   
3.    //就是这一句
   
4.    [[[MySessionConfiguration alloc] init] load];
   
5. 
   
6.     return YES;
   
7. }
   

复制代码

这样，一个简单的监控功能就实现了。实际上，想让它能够变得实用起来还有无数的坑要填，代码量大概再增加20倍吧，这些坑包括：https的证书校验，NSURLConnection和NSURLSession兼容，重定向，超时处理，返回值内容解析，各种异常处理（不能因为你崩了让程序跟着崩了），开关，截获的信息本地存储策略，回传服务端策略等。真正写一个可用的工具不是那么简单。所以，如果金钱允许，还是让公司去采购吧。。。

0x03 BTW：

1.本人OC菜鸟，肯定有理解不当的地方，有高手请多加指正。
2.有小伙伴想一起做的话可以一同起个开源啊，一起利用一下碎片化的时间（除非专职的开发测试，否则几乎没有大把时间和机会写产品形态的测试工具的）。

草帽路飞UU

objc 代码块已经可以用了。

乐哈哈yoyo

之前做过相同的功能，如果是POST请求，拿到的body会为空的。&#128517;
这是基于URLSession的，如果是老版本URLConnection或者CFNetwork，可能抓不到

巴黎的灯光下

写成sdk，能用。如果swift里面api都是静态连接的花, oc以后还是硬通货, qa得掌握. 这个技术还是挺实用的.