1 问题描述
传统的域名解析会面临以下几个问题：
- 域名劫持
- 调度不精准
- 解析生效滞后
- 延迟大
HTTP DNS可以解决以上问题，同时也会带来一些问题，其中一个就是SNI问题。
SNI（Server Name Indication）是为了解决一个服务器使用多个域名和证书的SSL/TLS扩展。它的工作原理如下：
- 客户端和服务器建立SSL之前，先发送域名（hostname）。
- 服务器根据这个域名返回一个合适的证书。
上述过程中，当客户端使用HTTPDNS解析域名时，请求URL中的host会被替换成HTTPDNS解析出来的IP，导致服务器获取到的域名为解析后的IP，无法找到匹配的证书，只能返回默认的证书或者不返回，所以会出现SSL/TLS握手不成功的错误。
1.1 已有方案的问题
iOS上层网络库NSURLConnection/NSURLSession没有提供接口进行SNI字段的配置，因此需要Socket层级的底层网络库例如CFNetwork，来实现IP直连网络请求适配方案。
自定义类继承NSURLProtocol，拦截NSURLConnection/NSURLSession。但是已有参考代码存在如下问题：
- 重定向时，重定向的response被回调到上层，和原生系统的表现不一样
- 由于使用了CoreFoundation，CF对象和OC对象的转化存在一些问题
- 某些方法行数太长，可以拆分成更短的方法
2 问题解决方案
2.1 系统表现
首先看看原生的NSURLSession的表现，不发生重定向的请求，其回调的顺序如下：
-----URLSession:task:didReceiveChallenge:completionHandler:
-----URLSession:dataTask:didReceiveResponse:completionHandler:
-----URLSession:dataTask:didReceiveData:
-----URLSession:task:didCompleteWithError:
如果有重定向，其回调的顺序如下。其重定向了2次
-----URLSession:task:didReceiveChallenge:completionHandler:
-----URLSession:task:willPerformHTTPRedirection:newRequest:completionHandler:
-----URLSession:task:didReceiveChallenge:completionHandler:
-----URLSession:task:willPerformHTTPRedirection:newRequest:completionHandler:
-----URLSession:task:didReceiveChallenge:completionHandler:
-----URLSession:dataTask:didReceiveResponse:completionHandler:
-----URLSession:dataTask:didReceiveData:
-----URLSession:dataTask:didReceiveData:
-----URLSession:dataTask:didReceiveData:
-----URLSession:dataTask:didReceiveData:
-----URLSession:task:didCompleteWithError:
参考代码中，Protocol中处理重定向的方式如下：
- 将重定向的响应头和响应体抛到上层
- 最后在该重定向结束的时候，从响应头拿到location，发起新的请求
而系统表现中，并不会将重定向的响应体进行回调，我觉得这是参考代码可以优化的地方。我的处理方式是：
- 如果在响应头中发现是重定向，首先关闭此次请求
- 如果上层实现了重定向的方法，从stream中读取响应头信息，再进行回调；如果上层没有实现重定向的方法，从stream中读取响应头信息，再重新发请求
if ([self.client respondsToSelector:@selector(URLProtocol:wasRedirectedToRequest:redirectResponse:)]) {
// 通知上层进行redirect
[self.client URLProtocol:self wasRedirectedToRequest:[NSURLRequest requestWithURL:redirectUrl] redirectResponse:response];
} else {
// 内部进行redirect
[self redirect:headDict];
}
2 CF对象和OC对象的转化
以下是参考代码中，CF对象和OC对象进行转换有误的地方:
// 获取响应头部信息
//后面没有释放代码。而且这儿也没有必要retain，inputstream是成员变量
CFReadStreamRef readStream = (__bridge_retained CFReadStreamRef) inputStream;
// 此处应该使用__bridge_transfer
NSDictionary *headDict = (__bridge NSDictionary *) (CFHTTPMessageCopyAllHeaderFields(message));
3 代码风格问题
多个行数较长的方法，其实可以拆成更小的方法
许多复制粘贴的方法，其实可以抽取成统一的方法
- (void)startRequest {
// 原请求的header信息
NSDictionary *headFields = curRequest.allHTTPHeaderFields;
// 添加http post请求所附带的数据
CFStringRef requestBody = CFSTR("");
CFDataRef bodyData = CFStringCreateExternalRepresentation(kCFAllocatorDefault, requestBody, kCFStringEncodingUTF8, 0);
if (curRequest.HTTPBody) {
bodyData = (__bridge_retained CFDataRef) curRequest.HTTPBody;
} else if (headFields[@"originalBody"]) {
// 使用NSURLSession发POST请求时，将原始HTTPBody从header中取出
bodyData = (__bridge_retained CFDataRef) [headFields[@"originalBody"] dataUsingEncoding:NSUTF8StringEncoding];
}
CFStringRef url = (__bridge CFStringRef) [curRequest.URL absoluteString];
CFURLRef requestURL = CFURLCreateWithString(kCFAllocatorDefault, url, NULL);
// 原请求所使用的方法，GET或POST
CFStringRef requestMethod = (__bridge_retained CFStringRef) curRequest.HTTPMethod;
// 根据请求的url、方法、版本创建CFHTTPMessageRef对象
CFHTTPMessageRef cfrequest = CFHTTPMessageCreateRequest(kCFAllocatorDefault, requestMethod, requestURL, kCFHTTPVersion1_1);
CFHTTPMessageSetBody(cfrequest, bodyData);
// copy原请求的header信息
for (NSString *header in headFields) {
if (![header isEqualToString:@"originalBody"]) {
// 不包含POST请求时存放在header的body信息
CFStringRef requestHeader = (__bridge CFStringRef) header;
CFStringRef requestHeaderValue = (__bridge CFStringRef) [headFields valueForKey:header];
CFHTTPMessageSetHeaderFieldValue(cfrequest, requestHeader, requestHeaderValue);
}
}
// 创建CFHTTPMessage对象的输入流
CFReadStreamRef readStream = CFReadStreamCreateForHTTPRequest(kCFAllocatorDefault, cfrequest);
inputStream = (__bridge_transfer NSInputStream *) readStream;
// 设置SNI host信息，关键步骤
NSString *host = [curRequest.allHTTPHeaderFields objectForKey:@"host"];
if (!host) {
host = curRequest.URL.host;
}
[inputStream setProperty:NSStreamSocketSecurityLevelNegotiatedSSL forKey:NSStreamSocketSecurityLevelKey];
NSDictionary *sslProperties = [[NSDictionary alloc] initWithObjectsAndKeys:
host, (__bridge id) kCFStreamSSLPeerName,
nil];
[inputStream setProperty:sslProperties forKey:(__bridge_transfer NSString *) kCFStreamPropertySSLSettings];
[inputStream setDelegate:self];
if (!curRunLoop)
// 保存当前线程的runloop，这对于重定向的请求很关键
curRunLoop = [NSRunLoop currentRunLoop];
// 将请求放入当前runloop的事件队列
[inputStream scheduleInRunLoop:curRunLoop forMode:NSRunLoopCommonModes];
[inputStream open];
CFRelease(cfrequest);
CFRelease(requestURL);
CFRelease(url);
cfrequest = NULL;
CFRelease(bodyData);
CFRelease(requestBody);
CFRelease(requestMethod);
}
优化后的代码：
- (void)startRequest {
// 创建请求
CFHTTPMessageRef requestRef = [self createCFRequest];
CFAutorelease(requestRef);
// 添加请求头
[self addHeadersToRequestRef:requestRef];
// 添加请求体
[self addBodyToRequestRef:requestRef];
// 创建CFHTTPMessage对象的输入流
CFReadStreamRef readStream = CFReadStreamCreateForHTTPRequest(kCFAllocatorDefault, requestRef);
self.inputStream = (__bridge_transfer NSInputStream *) readStream;
// 设置SNI
[self setupSNI];
// 设置Runloop
[self setupRunloop];
// 打开输入流
[self.inputStream open];
}
其他问题
使用自定义URLProtocol之后，UIWebView加载H5页面，H5的Host被替换成了IP，字体，css等资源如果使用相对路径加载，则会自动用IP请求，但是这个请求进到URLProtocol的时候已经是IP了，没办法给这个请求在请求头添加Host（不知道他的Host是什么），就会导致证书问题。
参考文档
Demo地址：https://github.com/xiaoLong1010/HTTPDNS-SNI
//www.greatytc.com/p/cd4c1bf1fd5f
//www.greatytc.com/p/63a94cb46cd2
使用Protocol拦截：https://nemocdz.github.io/post/ios-设置代理proxy方案总结/
https://blog.csdn.net/leelit/article/details/77829196
https://help.aliyun.com/document_detail/30143.html
https://techblog.toutiao.com/2017/10/11/untitled-12/
http://www.sites-help.com/aliyun/1512799152.html
DNS原理
https://blog.csdn.net/xyxjn/article/details/55271041
http://www.ttlsa.com/web/httpdns-detailed-service/
