转载

iOS IP 直连原理剖析

移动互联网的网络状况是十分复杂的，三大运营商、3G、4G、Wi-Fi、地点等任何一个状态的改变都会导致网络状况的变化，并且运营商、代理商们还可能在其中搞一些小破坏，比如经常会有用户反馈说某个页面访问不了或者返回结果不正确等问题，这种状况一般都是发生了域名劫持，通用的解决方案就是使用 IP 直连，跨过运营商 LocalDNS 服务器解析过程，从而达到降低延迟、避免劫持的效果。

Why IP

为什么大家会选择直接使用 IP 来进行连接呢？它具有多方面的优势：

防劫持，可以绕过运营商 LocalDNS 解析过程，避免域名劫持，提高网络访问成功率
降低延迟，DNS 解析是一个相对耗时的工作，跳过这个过程可以降低一定的延迟
精准调度，运营商解析返回的节点不一定是最优的，自己获取 IP 可以基于自己的策略来获取最精准的、最优的节点

对于获取 IP，我了解到的是两种方案，一种是直接接入腾讯或者阿里的 HTTPDNS 服务，在发起请求的时候是通过 HTTPDNS 获取 IP，然后直接使用 IP 来进行业务访问；一种是内置 Server IP，可以在启动等阶段由服务端下发域名和 IP 的对应列表，客户端来进行缓存，发起网络请求的时候直接根据缓存 IP 来进行业务访问。

HTTPS & DNS 劫持

起初我是存在一些疑问的，为什么 HTTPS 还会存在 DNS 劫持问题呢？HTTPS 从身份认证、内容加密、防止篡改三个方面来保证网络安全，但是它的时机相对靠后，DNS 解析是网络请求的第一个步骤，完整的步骤是 DNS 解析 -> TCP 连接 -> TLS 握手 -> Request -> Response，所以 HTTPS 对 DNS 劫持也无能为力，但是可以通过客户端身份认证来避免被塞广告等状况的发生，被劫持后直接访问失败。

iOS IP 直连原理剖析

身份认证

HTTPS 网络下我们会对服务端的身份进行认证，就拿 AFNetworking 来说，它提供了三种身份认证的可选方案：

AFSSLPinningModeNone(Default)
AFSSLPinningModePublicKey
AFSSLPinningModeCertificate

对于 AFSSLPinningModeNone，客户端自己不会对服务端证书进行自主校验，而是直接默认信任，将证书交给系统来进行校验，判断返回的证书是否是官方机构颁发的，如果是则信任，这个应该也是普通开发者采用最多的方案。这种认证方案如果被劫持后返回的证书也是官方机构颁发的，那么客户端就会正常进行网络访问，但是返回的数据就不是想要的数据，比如被塞广告等现象的出现。

对于 AFSSLPinningModePublicKey、AFSSLPinningModeCertificate 两种方案，客户端本地通常会保存一份服务端证书， AFSSLPinningModePublicKey 代表客户端会将服务器端返回的证书与本地保存的证书中的 PublicKey 部分进行自主校验，AFSSLPinningModeCertificate 代表客户端会将服务器端返回的证书和本地保存的证书中的所有内容，包括 PublicKey 和证书部分全部进行自主校验。如果校验成功，才继续进行系统验证等后续行为。

HTTP IP Connect

虽然 Apple 很早就开始推 ATS，但是由于国内的网络情况特别复杂，所以 Apple 还是支持 HTTP 网络请求的，并且 HTTP 协议下的网络请求的比例也很大。实现 HTTP 协议下 IP 连接其实是很简单的，我们只需要通过 NSURLProtocol 来拦截网络请求，然后将符号条件的网络请求 URL 中的域名修改为 IP 就可以啦。

但是也会存在一些小问题，域名置换为 IP 之后，服务端无法根据 URL 来判断你要访问哪个域名，所以我们需要手动的将 host 字段塞到 header 中去，方便服务器的正确识别。

HTTPS IP Connect

HTTPS 比 HTTP 多了一个 TLS 握手的过程，这个过程中涉及到一个证书校验的问题，服务端会在第二次握手的时候返回一个证书，来使得客户端可以校验它的身份，避免出现假冒的状况。在这次校验过程中，会校验证书的 domain 域是否包含本次 Request 的 host，并且校验返回的证书是否是官方机构颁发的可信证书。由于 IP 连接会将 URL 中的域名置换为 IP，所以就会导致返回的证书和我们的 Request 校验失败的问题。

为了解决证书的校验的问题，我们需要在证书校验前，再进行一次域名的替换，这次需要把 URL 中 IP 置换为域名，这样证书校验的问题便可迎刃而解。

iOS IP 直连原理剖析

SNI IP Connect

通常情况下我们的证书是和域名绑定的，有时候会存在一个 IP 对应多个域名的情况，这种情况如果客户端 IP 直连的时候，没有告诉服务端他要请求的是哪个域名的证书，服务端就没办法返回正确的证书，从而导致客户端证书校验失败。

SNI 的全称 Server Name Indication，为了解决一个服务器使用多个域名和证书的 SSL/TLS 扩展。在连接到服务器建立 SSL 连接时，客户端可以在第一次握手的 Client Hello 中的 SNI 扩展字段中填入要访问站点的域名（Hostname），这样服务器就可以根据域名返回一个合适的证书。

iOS IP 直连原理剖析

综上所述，我们在进行 IP 直连的时候，面对单 IP 多域名的情况需要客户端手动配置 SNI 字段，但是上层的网络库 NSURLSession、NSURLConnection 都没有提供配置的接口，我们需要使用更加底层的 libcurl 库和 CFNetwork 来完成 SNI 字段的配置。以 CFNetwork 为例，可以使用如下代码进行 SNI 的配置。

// HTTPS 请求处理 SNI 场景
NSString *host = [self.swizzleRequest.allHTTPHeaderFields objectForKey:@"host"];
if (!host) {
    host = self.originalRequest.URL.host;
}
[self.inputStream setProperty:NSStreamSocketSecurityLevelNegotiatedSSL forKey:NSStreamSocketSecurityLevelKey];
NSDictionary *sslProperties = @{ (__bridge id) kCFStreamSSLPeerName : host };
[self.inputStream setProperty:sslProperties forKey:(__bridge_transfer NSString *) kCFStreamPropertySSLSettings];

写在最后

其实 IP 直连的文章早已数不胜数，本篇也只是一个学习实践的笔记而已，更多相关资料和代码我会在末尾给出。NSURLProtocol 和 IP 直连有很多要注意的点，比如 NSURLProtocol 拦截 post 请求获取 httpbody 为空、Cookie 的处理、WebView 的处理等。有些知识本人也没有实践，不过可以在参考文章中找到相应的处理方案。

参考文献

可能是最全的iOS端HttpDns集成方案

DNS污染方案调研

HTTPDNS 在 iOS 中的实践

移动解析HTTPDNS在App开发中实践总结

也谈 HTTPS - HTTPDNS + HTTPS

HTTPDNS 域名解析场景下如何使用 Cookie？

阿里云相关最佳实践

Server Name Indication（SNI）

正文到此结束