HTTPDNS:iOS の WebView シナリオにおける HTTPDNS の使用

1. はじめに

iOS プラットフォームのネイティブシナリオで HTTPDNS を使用してハイジャック対策、正確なスケジューリング、およびインスタント DNS 名前解決を実装する方法については、「iOS のネイティブシナリオで HTTPDNS を使用する」で学習しました。

WKWebView は、iOS 上でネットワークリクエストが頻繁に関わるもう一つのシナリオです。WKWebView は、iOS アプリケーションで Web コンテンツを表示するために WebKit フレームワークが提供する最新の Web ビューです。従来の UIWebView に代わるもので、より優れたパフォーマンス、より多くの機能、そしてより高いセキュリティを提供します。WKWebView が Web ページを読み込む際に HTTPDNS を使用することで、ネットワークのセキュリティとパフォーマンスを向上させることができます。

2. 現在の技術

iOS システムの進化に伴い、HTTPDNS と WKWebView を統合するための技術的ソリューションも進化しています：

• iOS 17.0 以前：Apple は WKWebView での DNS 名前解決のための公式なフックインターフェイスを提供していませんでした。また、カスタムのネットワークリクエスト実装のためのインターフェイスも直接提供していませんでした。このため、非公開 API をフックしてトラフィックをインターセプトする複雑なソリューションが必要でした。

• iOS 17.0 以降: Apple は ProxyConfiguration API を導入しました。この API は、WKWebView の公式プロキシ構成機能を提供します。これにより、すべてのネットワークリクエストを確実にインターセプトできるため、HTTPDNS をシームレスに統合できます。

Apple の公式統計 (2025 年 6 月 4 日時点) によると、iOS 17 以降はすべての iPhone デバイスの 85% 以上にインストールされており、この数は増加し続けています。HTTPDNS は、ハイジャック対策、正確なスケジューリング、即時解決など、WKWebView シナリオに対して非機能的な改善を提供します。したがって、このソリューションを使用して HTTPDNS を統合することを推奨します。このアプローチは、ほとんどの顧客をカバーします。古いシステムバージョンのユーザーは、アップグレードするにつれて徐々にこの機能を利用できるようになります。

3. 推奨ソリューション: iOS 17 以降向けのローカルプロキシベースのソリューション

source 'https://github.com/aliyun/aliyun-specs.git'

target 'yourAppTarget' do
    use_framework!
    
    pod 'AlicloudHTTPDNS', 'x.x.x'
    pod 'EMASLocalProxy', 'x.x.x'
end

#import <EMASLocalProxy/EMASLocalProxy.h>
#import <AlicloudHttpDNS/AlicloudHttpDNS.h>

// Create a WKWebViewConfiguration
WKWebViewConfiguration *config = [[WKWebViewConfiguration alloc] init];

// Configure the DNS resolver
[EMASLocalHttpProxy setDNSResolverBlock:^NSArray<NSString *> *(NSString *hostname) {
    // Get the HTTPDNS service instance
    HttpDnsService *httpdns = [HttpDnsService sharedInstance];
    HttpdnsResult *result = [httpdns resolveHostSyncNonBlocking:hostname byIpType:HttpdnsQueryIPTypeBoth];

    if (result && (result.hasIpv4Address || result.hasIpv6Address)) {
        NSMutableArray<NSString *> *allIPs = [NSMutableArray array];
        if (result.hasIpv4Address) {
            [allIPs addObjectsFromArray:result.ips];
        }
        if (result.hasIpv6Address) {
            [allIPs addObjectsFromArray:result.ipv6s];
        }
        NSLog(@"HTTPDNS resolution successful. Domain name: %@, IP: %@", hostname, allIPs);
        return allIPs;
    }

    NSLog(@"HTTPDNS resolution failed. Domain name: %@", hostname);
    return nil;
}];

// Set the log level
[EMASLocalHttpProxy setLogLevel:EMASLocalHttpProxyLogLevelDebug];

// Configure the WebView proxy
BOOL proxyConfigured = [EMASLocalHttpProxy installIntoWkWebViewConfiguration:config];
if (proxyConfigured) {
    NSLog(@"WebView proxy configuration successful.");
} else {
    NSLog(@"WebView proxy configuration failed. Using the system network.");
}

WKWebView *webView = [[WKWebView alloc] initWithFrame:self.view.bounds configuration:config];

4. グローバル NSURLProtocol インターセプトソリューション

このソリューションは、HTTPDNS を iOS WebView と統合するための最も初期の実行可能な選択肢でした。導入のハードルが非常に高く、効果もあまり高くありません。しかし、初期の iOS には他の選択肢がなかったため、存続してきました。その原理は NSURLProtocol に基づいており、iOS 上の NSURLConnection/NSURLSession などの上位ネットワークライブラリから送信されるネットワークリクエストをインターセプトできます。WKWebView からのリクエストも含まれます。リクエストをインターセプトした後、このソリューションは HTTPDNS を使用してドメイン名の名前解決と後続の処理を行います。手順は次のとおりです：

1. 次のインターフェイスを介してカスタム NSURLProtocol を登録し、WKWebView からの上位ネットワークリクエストをインターセプトできます。その後、新しいネットワークリクエストを作成して、データ送受信、リダイレクト、その他の処理ロジックを引き継ぎます。結果は元のリクエストにフィードバックされます。

   [NSURLProtocol registerClass:[HttpDnsNSURLProtocolImpl class]];

2. 以下は、カスタム NSURLProtocol の処理手順の概要です：

   • canInitWithRequest で、HTTPDNS ドメイン名解決が必要なリクエストをフィルタリングします。

   • リクエストがインターセプトされた後、HTTPDNS ドメイン名解決を実行します。

   • 名前解決が完了した後、通常のリクエストと同様に、URL.host フィールドと HTTP ヘッダーの Host フィールドを置き換えます。その後、このリクエストのデータ送受信、リダイレクト、その他の処理を引き継ぎます。

   • NSURLProtocol インターフェイスを使用して、リクエスト処理結果を元の WebView リクエストにフィードバックします。

3. カスタム NSURLProtocol の実装ロジックの詳細については、提供されているデモの HttpDnsNSURLProtocolImpl.m をご参照ください。

5. ソリューションのまとめと比較

このドキュメントでは、iOS の WKWebView シナリオで HTTPDNS を統合するための 2 つの主要な技術ソリューションを紹介しました：iOS 17 以降に基づくローカルプロキシソリューションと、グローバル NSURLProtocol インターセプトソリューションです。

各ソリューションには、特定のシナリオ、利点、欠点、および実装の複雑さがあります。迅速な意思決定を支援するために、次の表ではこれら 2 つのソリューションを横並びで比較しています：

安定性、開発・メンテナンスコスト、および将来のトレンドを考慮すると、iOS 17 以降に基づくローカルプロキシソリューションを強く推奨します。

iOS 17 以降のシステムバージョンが急速に普及するにつれて、このソリューションは最小限のコストで大多数のユーザーに安定した信頼性の高い HTTPDNS サービスを提供します。これにより、ドメインハイジャックを効果的に解決し、ネットワークパフォーマンスを向上させます。その洗練された実装と公式サポートにより、ソリューションの長期的な実現可能性が保証されます。iOS 17 より前のシステムバージョンでは、スムーズなフォールバック戦略が使用されます。これは、システムのデフォルトのネットワークリクエストが使用されることを意味します。ユーザーがシステムをアップグレードすると、自動的に HTTPDNS の恩恵を受けることができます。

もう一方のソリューションには、固有の複雑さと不確実性があります。慎重に採用してください。特別な要件と深い技術的専門知識を持つチームが、慎重な評価と徹底的なテストを行った後にのみ推奨されます。