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 劫持也无能为力，可是能够经过客户端身份认证来避免被塞广告等情况的发生，被劫持后直接访问失败。

身份认证

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 置换为域名，这样证书校验的问题即可迎刃而解。

SNI IP Connect

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

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

综上所述，咱们在进行 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）